Current Server Time: 10:42 (Central Europe)

#apertus IRC Channel Logs

2022/02/06

Timezone: UTC


06:00
Bertl
off to bed now ... have a good one everyone!
06:00
Bertl
changed nick to: Bertl_zZ
11:49
aombk2
joined the channel
11:50
aombk
left the channel
14:22
Bertl_zZ
changed nick to: Bertl
14:22
Bertl
morning folks!
14:22
vup
morning :)
16:29
vup
Bertl: ok, so I looked at some more things
16:29
vup
for one, the "weird" pixels seem to always be the same between different exposures
16:29
vup
(I assumed that previously, but did not actually check)
16:30
vup
furthermore, for the odd rows, they are pretty much 50% of the pixels
16:30
vup
(so 25% in total)
16:30
vup
and they follow a pretty strong pattern
16:30
vup
https://files.niemo.de/weird_pixels_even_rows_even_cols.png
16:30
vup
https://files.niemo.de/weird_pixels_even_rows_odd_cols.png
16:30
vup
https://files.niemo.de/weird_pixels_odd_rows_even_cols.png
16:30
vup
https://files.niemo.de/weird_pixels_odd_rows_odd_cols.png
16:31
vup
white pixels are the "weird" ones, black are ones with approx linear response curve
16:32
vup
btw these horizonatl "stripes", where the pattern is the same for every row are 240 pixels high
16:32
vup
any clue why that could be?
16:32
vup
also anuejn, se6astian^
16:38
Bertl
so for about 240 readout rows the 'pattern' stays the same
16:38
vup
yeah
16:39
Bertl
interesting
16:39
vup
(240 readouts of two rows obviously)
16:39
vup
would be interesting if any changes if one does one-sided readout
16:41
Bertl
well, if the pattern would be uniform, I'd say some of the ADCs have nonlinearity issues
16:41
vup
uniform over all rows?
16:41
vup
yeah
16:41
Bertl
(still might be the case for the 'white' columns)
16:42
Bertl
but the shift definitely looks weird
16:42
vup
yep
16:42
Bertl
to be honest, I'd double check the evaluation code ;)
16:43
vup
oh I already did a lot
16:43
vup
but this pattern is even visible in darkframes for example
16:43
vup
(this pattern of every 240 readout rows being approx the same)
16:43
vup
also note, that this is super low light conditions
16:43
Bertl
from how many sensors do we have this data?
16:43
vup
one
16:44
Bertl
okay, so maybe we should check with a different sensor then?
16:44
vup
yes definitely
16:44
vup
(low light conditions -> 13ms exposure gives pixel values of 20 to 40 after subtracting the darkframe)
16:47
Bertl
and they were captured via HDMI?
16:47
vup
yeah
16:47
Bertl
but not at 30/60FPS I presume?
16:48
vup
why not? It should have been done at 60fps
16:48
vup
right se6astian ?
16:49
vup
I pushed the stuff to https://github.com/rroohhh/cmv12k_color_science
16:50
vup
flatfield_experiments.ipynb contains pretty ad-hoc / hacky code that I used for the last plots (and the hexbin histograms)
16:53
vup
but in principle the code is all super straight forward
16:53
vup
For me the biggest source of uncertainty is the actual capture process by the recorder
16:53
vup
but with the current code, the frame counters and the wrsel seem to check out
16:53
vup
and "normal" footage also looks correct
16:54
vup
so I am not sure what could be wrong there
17:03
se6astian
I captured at 24 fps so 48 fps hdmi
17:04
se6astian
What about creating a capture script to guarantee controlled conditions?
17:05
se6astian
And it can also including capturing a few snaps with axiom_snap
17:05
se6astian
Then you can compare hdmi to internal raw frames
17:06
vup
sure, that sounds pretty useful
17:06
vup
we probably need some kind of "script" sooner or later anyways
17:06
vup
maybe you can start one? Its pretty hard for me to do it without a beta
17:07
se6astian
Will do, getting back to Vienna tomorrow eveing
17:07
vup
Sure, no hurry
17:26
vup
(also the axiom_snap references sound like a really good idea)
17:32
se6astian
With full sensor register dump
19:10
vup
Sure