Current Server Time: 12:06 (Central Europe)

#apertus IRC Channel Logs

2022/02/12

Timezone: UTC


04:55
Bertl_oO
off to bed now ... have a good one everyone!
04:55
Bertl_oO
changed nick to: Bertl_zZ
08:39
Spirit532
left the channel
08:39
Spirit532
joined the channel
11:49
Bertl_zZ
changed nick to: Bertl_oO
18:41
vup
se6astian: the axiom_snap snapshots are taken without locking the buffers, right?
19:37
se6astian
Yes
19:38
se6astian
Should i change that in the capture Script?
19:48
vup
Yeah that is probably a good idea
19:49
vup
right now some of them look like the buffer was overwritten while the snap script ran
20:21
se6astian
will do
20:21
se6astian
did you see anything else in the capture script that you would change/add?
20:23
vup
looks fine from the steps taken
20:23
vup
i guess a snap before capturing the average frame would be interesting
20:23
vup
(or atleast a register dump)
20:24
vup
for example to estimate any temperature changes over the capturing of the average frame
20:25
vup
I also looked at the memory consumption again and am really not sure what the problem there could be, the memory consumption for me (when using RawDirectoryReader as source) is definitely not dependent on the `--n` of `Average` and I can do 10000 frames easily
20:25
vup
all in all, the frames look all reasonable
20:25
vup
ill have to look into the dark columns a bit more
20:26
vup
for these, capturing a non averaged stack would be pretty interesting
20:26
vup
I think 256 frames of one specific exposure time should be enough for now
20:26
vup
Oh also, with which framerate was this captured?
20:27
vup
Ah also I think having a script that combines the whole process of setting up the camera and then capturing the frames would be handy
20:28
vup
Oh a maybe 32 frame stack of a long exposure time (100ms+) would be pretty interesting
20:28
vup
I guess of a "normal" motive to compare aswell
20:29
vup
Finally having a lot more exposure steps would be very interesting
20:30
vup
There certainly seems to be a relationship between the darkframe and the exposure time, but its pretty ehm noisy curently
20:30
vup
https://files.niemo.de/darkframe_deviation_hist.png
20:31
se6astian
capturing a non averaged stack would be pretty interesting <- with 256 frames for one exposure?
20:31
vup
yeah
20:31
se6astian
noted
20:31
se6astian
this is now being captured with 50 FPS, so 25 real frames
20:31
se6astian
per second
20:31
vup
right
20:31
vup
so 20ms is already in the region that previously caused problems with the hdmi raw setup because its slows down the actual framerate, right?
20:32
se6astian
I cant go higher with the exposure time than what I provided with the latest uploads as then the recorder cant find A+B pairs anymore
20:32
vup
Hmm
20:32
vup
I wonder why
20:33
se6astian
I was about to add the ssh lines that set up the camera to the capture script
20:33
se6astian
but then the problem again that I need to check every time if axiom_start had already been run before on the camera
20:34
se6astian
and also waiting for the command to finish before doing anything else...
20:34
se6astian
so I left that to be done manually for now
20:34
vup
well
20:34
vup
I thought maybe a script that you basically run after the camera has just been booted
20:34
se6astian
yes I created that one
20:35
se6astian
https://pastebin.com/W6irhmz0
20:36
vup
right
20:36
vup
having one that combines this with one that calls the other script for the different exposures would be handy
20:37
vup
so one can simply with one call get comparable darkframes from other betas
20:37
se6astian
I can capture the "32 frame stack of a long exposure time (100ms+)" with axiom_snaps
20:37
se6astian
a lot more exposure steps <- how many and what range would you like?
20:38
se6astian
so 20ms is already in the region that previously caused problems with the hdmi raw setup because its slows down the actual framerate, right? <- yes
20:39
vup
se6astian: I added a `--debug` flag to the DualFrameRawDecoder, capturing the output of the recorder with that flag active `--debug=true` for a exposure time that causes problems would be interesting
20:39
se6astian
noted
20:39
vup
se6astian: right the 32 frame stack of a long exposure time would be to check if the recorder actually does the "right" thing
20:39
vup
but if it doesn't work, that doesn't help
20:40
vup
As for which exposure range and the number of steps, about 100 steps from 0 to the upper limit of what one would actually use would be interesting
20:40
vup
And then maybe 10 or 20 steps from there to maybe 100ms?
20:40
vup
Also maybe some super long ones?
20:41
vup
Whats the current limit?
20:41
se6astian
good question :)
20:42
se6astian
lets ask herbert about the longer exposures, but I assume its an issue with sequencer and output generator not being independent currently
20:42
se6astian
but Bertl will work on changing that soon
20:43
vup
right, maybe we can find something that works in the meantime aswell, so getting a log of the DualFrameRawDecoder with `--debug=true` would be handy for that
20:43
se6astian
ok
20:44
se6astian
on another front: I visited manfred today and we successfully were able to laser cut the plastic sheets I took from a DVD case
20:44
se6astian
https://cloud.apertus.org/index.php/apps/gallery/s/aroXPrykksDCnwk#IMG_20220212_184353.jpg
20:44
se6astian
this will alow us to build a frame for the ZIF sockets to prevent wrong insertion
20:47
vup
hmm maybe I am calculating this completely wrong, but if we keep reg85 at 130, exposure times of 100 secods should be possible?
20:47
vup
thats pretty neat
20:47
se6astian
thanks :)
20:48
vup
(I get a lower bound of ~105.5 seconds, but this is ignoring the FOT, so actually a bit longer)
20:48
se6astian
I will try long exposure times
20:48
vup
(*the actual maximum should be a bit longer)
20:49
se6astian
so about longer exposure times with snap
20:49
se6astian
do they help you currently or only if they come through the recorder?
20:50
vup
nice re ZIF frames
20:50
vup
se6astian: they help aswell, but capturing 256 for 10 different exposure times sounds really slow
20:51
vup
But its also not that interesting atm, so if you have limited time, using than for capturing flatfields instead of long exposure darkframes would be a lot more interseting :)
20:51
se6astian
yes but 32 would be doable for one exposure time...
20:51
se6astian
right
20:51
vup
right, 32 for one exposure time is probably super interesting
20:51
vup
especially if it is a exposure time few people are likely to use
20:52
se6astian
noted
23:57
Bertl_oO
long exposures should not be a problem at all, but you will get a number of identical HDMI frames (alternating between A and B)
23:57
Bertl_oO
i.e. the HDMI sequencer does not advance when the exposure is still going on