Current Server Time: 22:03 (Central Europe)

#apertus IRC Channel Logs

2022/01/14

Timezone: UTC


23:51
aombk2
joined the channel
23:52
aombk
left the channel
00:27
Bertl_oO
off to bed now ... have a good one everyone!
00:27
Bertl_oO
changed nick to: Bertl_zZ
01:16
vup
hmm our darkframes seem to have a lot of (dynamic) column noise: https://files.niemo.de/darkframe_pdfs/darkframe_1x_4.990224.blob.single_frame_analysis.pdf
01:16
vup
(this is just the first 10 darkframes minus the average of 256 darkframes with that gain / exposure)
01:16
vup
does anybody have a idea why this might be the case?
01:17
vup
this column does does not seem to have occured in a1ex analysis...
03:54
aombk2
left the channel
06:48
se6astian
vup, interesting finding
06:49
se6astian
I will capture more darkframes on my beta soon to help verify the issue
06:49
se6astian
I have no immediate idea where it might be coming from
08:47
Bertl_zZ
changed nick to: Bertl
08:47
Bertl
morning folks!
08:49
Bertl
vup: could you average the columns and check the deviation from the mean? from the pictures it looks like each column receives a separate 'dynamic offset' here
08:50
Bertl
(i.e. would biasing the columns with the mean value eliminate the issue? how would the bias corrected result look like?)
09:45
mecrisp
left the channel
11:05
illwieckz
left the channel
11:19
illwieckz
joined the channel
13:37
Bertl
off for now ... bbl
13:37
Bertl
changed nick to: Bertl_oO
13:47
vup
Bertl_oO: you mean substract the mean value of each column from the column values for each frame?
13:48
vup
yes that pretty much eliminates the offsets
13:48
vup
but how does one determine these offsets for an actual image that is not a darkframe?
13:48
vup
because the column mean over many frames is pretty much zero
13:49
vup
there are also some more interesting patterns
13:50
vup
if one groups the columns in steps of 32
13:50
vup
meaning the first group is column 0, 32, 64, etc, the second is 1, 33, 65, etc
13:51
vup
one get a pretty interesting image for the column means of the mean of many darkframes: https://files.niemo.de/darkframe_pdfs/column_wise_averages.png
13:51
vup
instead of being all over the place, like when plotting a line for columns, 0, 1, 2, 3, ...
13:51
vup
they follow a pretty smooth line, just all with different offsets
13:53
vup
finally the residual noise per column (what was visible in the pdf I linkend) also seems to follow some interesting patterns
13:53
vup
if again one groups the column in steps of 32
13:54
vup
then for example the column wise mean of the columns 0, 1, 2 is pretty similar. Again for 32, 33, 34, etc
13:54
vup
the column wise mean of columns 4, 5, 6 is again very similar, same for (4, 5, 6) + n * 32
13:55
vup
even more interesting is, that the column wise mean of columns 3 + n * 32 seems to be very similar to the mean of 0, 1, 2 and 4, 5, 6 (all + n * 32)
13:56
vup
for all columns this forms this pretty interesting symmetrical pattern: https://paste.niemo.de/raw/anihafahax
14:04
se6astian
very interesting
14:04
se6astian
might this be related to the 32 lvds channels we use to acquire data?
14:08
vup
yeah thats what I thought about aswell
14:08
vup
but it does not really match how the lvds channels work
14:08
vup
ie you get pixels 0 through 127 on channel one, 128 through 255 on channel two, etc
14:09
vup
my first throught was, that they maybe have all the analog readout stuff 32x times, multiplexed to 128 pixels each
14:11
se6astian
does this also mean it should be possible to compensate the coloumns effectively?
14:11
vup
well not sure yet really how to do it
14:12
vup
there are some interesting patterns one could maybe use to have some try at compensating it
14:12
vup
but in general, because it seems completely dynamic it will be pretty hard
14:12
vup
I am more wondering if we have some setting wrong in the sensor, because this column noise is not present at all in a1ex's experiments
14:18
se6astian
I see
15:40
aombk
joined the channel
15:53
illwieckz
left the channel
16:07
illwieckz
joined the channel
17:31
Bertl_oO
vup: I have to look that up but what comes to mind is the top vs bottom read-out channels
17:34
Bertl_oO
it would probably be quite interesting to average over each pixel individually for a reasonably large number of dark frames and then put the mean as well as the std in some false color scale
17:35
vup
Bertl_oO: what does "a reasonably large number of dark frames" mean?
17:35
Bertl_oO
(pixel = pixel position (row, col))
17:35
Bertl_oO
maybe a 1000 or so
17:35
vup
hmm ok
17:35
vup
maybe anuejn or se6astian can capture a stack of 1024 darkframes
17:36
vup
I only have stacks of 255
17:37
Bertl_oO
we then should visualize it as 4096x3072 (or whatever the full resolution captured is) and also as 8192x1536 (i.e. where two rows are side by side)
17:37
vup
hmm would even and odd rows side by side be more interesting?
17:37
vup
as that would be the ones read of by top vs bottom
17:38
Bertl_oO
that's what I mean with 8192
17:38
vup
right ok
17:38
Bertl_oO
i.e. the first two rows are sent in one go
17:38
Bertl_oO
putting them in one long row should show the entire transfer in one line
17:38
vup
ah right and then if you have even rows beneath each other on the one side and odd ones on the other side
17:39
Bertl_oO
precisely
17:41
Bertl_oO
and also note: we should probably do that for more than one camera/sensor just to get a feeling how much this is a sensor/camera specific bias
17:42
Bertl_oO
I'll probably join the dark frame club with my setup next week ;)
17:42
Bertl_oO
(early next week that is, maybe even on the weekend ;)
17:43
vup
nice :)
17:43
vup
and yeah I fully agree re capturing multiple sensors
17:43
vup
there are already some pretty interesting differences I noticed between the sensor with anuejn and the one se6astian captured
17:44
vup
(for example the fft of the column means has the same general shape, but different peaks)
17:55
se6astian
will boot up the beta now
18:15
se6astian
sorry, was on the phone now
18:15
se6astian
so single exposure
18:15
se6astian
single gain
18:15
se6astian
1024 instead of 255 frames
18:16
se6astian
file upload or analysis script execution locally?
18:26
se6astian
regarding sensor misconfiguration, I just checked some files
18:26
se6astian
as we had also not configured the sensor correctly when we got the beta hdmi up and running initially
18:26
se6astian
and ingmar was then so kind to figure out all the missing default values
18:26
se6astian
https://github.com/apertus-open-source-cinema/axiom-firmware/blob/main/software/scripts/axiom_ingmar.sh
18:27
se6astian
but those are now all moved to https://github.com/apertus-open-source-cinema/axiom-firmware/blob/main/software/scripts/axiom_cmv_init.sh
18:27
se6astian
just axiom_cmv_reg 107 is different
18:27
se6astian
need to read up why
18:28
se6astian
seems to be an undocmented register
18:30
se6astian
hmm, might be worth looking into to double check our current default is good
18:30
se6astian
as the datasheet says: "When you are running at a lower speed, register 107[13:7] has to be adjusted to keep the image
18:30
se6astian
quality good."
18:31
se6astian
and then a chart with CLK speed and register settings
18:32
se6astian
we currently run on the default, non adjusted value
18:33
se6astian
this section in the datasheet seems new
18:38
se6astian
we run at 250 MHz for the LVDS CLK correct?
18:40
se6astian
which gives me 10462 as correct value
18:40
se6astian
which is also what ingmar suggested
18:40
se6astian
this could influence image quality!
18:41
se6astian
pushed: https://github.com/apertus-open-source-cinema/axiom-firmware/commit/d773b7aa4cb77465f5b728ff243b488f4b2df890
18:42
Bertl_oO
yep 240-250MHz depending on the gateware version
18:44
se6astian
value seems also ok for 240 MHz
18:45
se6astian
as the graph has 50MHz steps basically
18:53
aombk
left the channel
18:55
aombk
joined the channel
18:56
se6astian
anuejn: please also make sure to change https://github.com/apertus-open-source-cinema/axiom-firmware/commit/d773b7aa4cb77465f5b728ff243b488f4b2df890 with your beta
18:56
se6astian
for new darkframe tests/captures
19:31
se6astian
also looked into ADC settings
19:31
se6astian
not 100% sure yet we cant use more options
19:31
se6astian
added https://github.com/apertus-open-source-cinema/axiom-firmware/issues/197
19:32
se6astian
setting register ADC_range_mult2 (reg 100) to x16 definitely works judging from the image on HDMI
19:47
se6astian
uploading new 1024 darkframe blob
19:47
se6astian
eta 1h
20:01
aombk
left the channel
20:51
se6astian
vup: https://cloud.apertus.org/index.php/s/aJwdQ9BHQnm4k4p