#apertus IRC Channel Logs

(this is just the first 10 darkframes minus the average of 256 darkframes with that gain / exposure)

this column does does not seem to have occured in a1ex analysis...

vup, interesting finding

I have no immediate idea where it might be coming from

morning folks!

(i.e. would biasing the columns with the mean value eliminate the issue? how would the bias corrected result look like?)

off for now ... bbl

Bertl_oO: you mean substract the mean value of each column from the column values for each frame?

but how does one determine these offsets for an actual image that is not a darkframe?

there are also some more interesting patterns

meaning the first group is column 0, 32, 64, etc, the second is 1, 33, 65, etc

instead of being all over the place, like when plotting a line for columns, 0, 1, 2, 3, ...

finally the residual noise per column (what was visible in the pdf I linkend) also seems to follow some interesting patterns

then for example the column wise mean of the columns 0, 1, 2 is pretty similar. Again for 32, 33, 34, etc

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)

very interesting

yeah thats what I thought about aswell

ie you get pixels 0 through 127 on channel one, 128 through 255 on channel two, etc

does this also mean it should be possible to compensate the coloumns effectively?

there are some interesting patterns one could maybe use to have some try at compensating it

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

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

(pixel = pixel position (row, col))

hmm ok

I only have stacks of 255

hmm would even and odd rows side by side be more interesting?

that's what I mean with 8192

i.e. the first two rows are sent in one go

ah right and then if you have even rows beneath each other on the one side and odd ones on the other side

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

(early next week that is, maybe even on the weekend ;)

and yeah I fully agree re capturing multiple sensors

(for example the fft of the column means has the same general shape, but different peaks)

sorry, was on the phone now

single gain

file upload or analysis script execution locally?

as we had also not configured the sensor correctly when we got the beta hdmi up and running initially

https://github.com/apertus-open-source-cinema/axiom-firmware/blob/main/software/scripts/axiom_ingmar.sh

just axiom_cmv_reg 107 is different

seems to be an undocmented register

as the datasheet says: "When you are running at a lower speed, register 107[13:7] has to be adjusted to keep the image

and then a chart with CLK speed and register settings

this section in the datasheet seems new

which gives me 10462 as correct value

this could influence image quality!

yep 240-250MHz depending on the gateware version

as the graph has 50MHz steps basically

for new darkframe tests/captures

not 100% sure yet we cant use more options

setting register ADC_range_mult2 (reg 100) to x16 definitely works judging from the image on HDMI

eta 1h

vup: https://cloud.apertus.org/index.php/s/aJwdQ9BHQnm4k4p