Current Server Time: 11:40 (Central Europe)

#apertus IRC Channel Logs

2022/02/12

Timezone: UTC


03:55
Bertl_oO
off to bed now ... have a good one everyone!
03:55
Bertl_oO
changed nick to: Bertl_zZ
07:39
Spirit532
left the channel
07:39
Spirit532
joined the channel
10:49
Bertl_zZ
changed nick to: Bertl_oO
17:41
vup
se6astian: the axiom_snap snapshots are taken without locking the buffers, right?
18:37
se6astian
Yes
18:38
se6astian
Should i change that in the capture Script?
18:48
vup
Yeah that is probably a good idea
18:49
vup
right now some of them look like the buffer was overwritten while the snap script ran
19:21
se6astian
will do
19:21
se6astian
did you see anything else in the capture script that you would change/add?
19:23
vup
looks fine from the steps taken
19:23
vup
i guess a snap before capturing the average frame would be interesting
19:23
vup
(or atleast a register dump)
19:24
vup
for example to estimate any temperature changes over the capturing of the average frame
19: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
19:25
vup
all in all, the frames look all reasonable
19:25
vup
ill have to look into the dark columns a bit more
19:26
vup
for these, capturing a non averaged stack would be pretty interesting
19:26
vup
I think 256 frames of one specific exposure time should be enough for now
19:26
vup
Oh also, with which framerate was this captured?
19: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
19:28
vup
Oh a maybe 32 frame stack of a long exposure time (100ms+) would be pretty interesting
19:28
vup
I guess of a "normal" motive to compare aswell
19:29
vup
Finally having a lot more exposure steps would be very interesting
19:30
vup
There certainly seems to be a relationship between the darkframe and the exposure time, but its pretty ehm noisy curently
19:30
vup
https://files.niemo.de/darkframe_deviation_hist.png
19:31
se6astian
capturing a non averaged stack would be pretty interesting <- with 256 frames for one exposure?
19:31
vup
yeah
19:31
se6astian
noted
19:31
se6astian
this is now being captured with 50 FPS, so 25 real frames
19:31
se6astian
per second
19:31
vup
right
19: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?
19: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
19:32
vup
Hmm
19:32
vup
I wonder why
19:33
se6astian
I was about to add the ssh lines that set up the camera to the capture script
19: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
19:34
se6astian
and also waiting for the command to finish before doing anything else...
19:34
se6astian
so I left that to be done manually for now
19:34
vup
well
19:34
vup
I thought maybe a script that you basically run after the camera has just been booted
19:34
se6astian
yes I created that one
19:35
se6astian
https://pastebin.com/W6irhmz0
19:36
vup
right
19:36
vup
having one that combines this with one that calls the other script for the different exposures would be handy
19:37
vup
so one can simply with one call get comparable darkframes from other betas
19:37
se6astian
I can capture the "32 frame stack of a long exposure time (100ms+)" with axiom_snaps
19:37
se6astian
a lot more exposure steps <- how many and what range would you like?
19: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
19: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
19:39
se6astian
noted
19: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
19:39
vup
but if it doesn't work, that doesn't help
19: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
19:40
vup
And then maybe 10 or 20 steps from there to maybe 100ms?
19:40
vup
Also maybe some super long ones?
19:41
vup
Whats the current limit?
19:41
se6astian
good question :)
19:42
se6astian
lets ask herbert about the longer exposures, but I assume its an issue with sequencer and output generator not being independent currently
19:42
se6astian
but Bertl will work on changing that soon
19: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
19:43
se6astian
ok
19: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
19:44
se6astian
https://cloud.apertus.org/index.php/apps/gallery/s/aroXPrykksDCnwk#IMG_20220212_184353.jpg
19:44
se6astian
this will alow us to build a frame for the ZIF sockets to prevent wrong insertion
19: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?
19:47
vup
thats pretty neat
19:47
se6astian
thanks :)
19:48
vup
(I get a lower bound of ~105.5 seconds, but this is ignoring the FOT, so actually a bit longer)
19:48
se6astian
I will try long exposure times
19:48
vup
(*the actual maximum should be a bit longer)
19:49
se6astian
so about longer exposure times with snap
19:49
se6astian
do they help you currently or only if they come through the recorder?
19:50
vup
nice re ZIF frames
19:50
vup
se6astian: they help aswell, but capturing 256 for 10 different exposure times sounds really slow
19: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 :)
19:51
se6astian
yes but 32 would be doable for one exposure time...
19:51
se6astian
right
19:51
vup
right, 32 for one exposure time is probably super interesting
19:51
vup
especially if it is a exposure time few people are likely to use
19:52
se6astian
noted
22: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)
22:57
Bertl_oO
i.e. the HDMI sequencer does not advance when the exposure is still going on