Current Server Time: 23:44 (Central Europe)

#apertus IRC Channel Logs

2022/02/06

Timezone: UTC


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