#apertus IRC Channel Logs

off to bed now ... have a good one everyone!

alexML, are you here?

morning folks!

alexML, noise is still high:

Col noise : 0.86 (134.2%)

- even rows : 0.79 (122.7%)

But then the darkframe seems to be not applied at all

there is a systemd service called cmv12k, which can be enabled or disabled

in kick.sh (and halt.sh) there is an optional (normally commented out) 'exit 0' early in the script

now to the 'dies instantly'

accessing AXI/AMBA bus addresses from the ARM cores when there is no formware loaded instantly locks up the arm cores (this is a known ZYNQ bug)

now to adjusting RCN (dark frame data)

if you need to take a controlled snap, you can simply disable the live feed via registers

it could be, really depends on the RCN values

they allow for some +/- adjustments per row and column

note that RCN and linearization LUTs affect both, the snaps and the HDMI output

k

It's ok in the hdmi output

try with rcn_clear.py it should disable all rcn configurations

did you try the raw2dng option to switch the bayer pattern (as suggested some time ago)

yep

less purple. But still much more different than the hdmi output.

well, I have no idea what the raw2dng does regarding color matrix and how that is interpreted by different dng readers

I tried shotwell, gwenview, ufraw, darktable. all the same

but the convert sequence (simple debayer) works and gives the correct results?

then it's very likely a problem with the raw2dng converter

it still can be a user error

off for now ... bbl

already did that

alexML, I don't have an hdmi recorder

We want to use the axiom for streaming

*can get access to

using the color matrix, a white balance is also doable and tested afaik

the main problem so far was to get RCN working correctly and to set the linearization LUTs properly

(wich if all else fails, can be done with a simple linear lut entry)

I'm cooking now, will join the conversation later

http://vserver.13thfloor.at/Stuff/AXIOM/BETA/mat4_conf.py

(because it can be imported)

RCN works fine (static offsets in the dark frame are gone), but there is still some visible pattern noise (I guess it's caused by variable row/column gains; on my beta this isn't really a problem, but niemand's one has significant column noise after RCN correction - but this column noise is not present in the dark frame)

can the apertus foundation/company sign this: https://fsfe.org/activities/radiodirective/statement.en.html ?

OTOH, there is the overlay data (16bit per HDMI pixel), so we could in theory encode some 'per pixel' corrections there

the overlay data can be made semi-transparent, I guess

we don't need to do tricks with the overlay, we can simply define a new mode where the overlay data is used for something else, like correcting the pixel data

iirc you said there are memory bandwidth issues a while ago regarding dark frame subtraction

there would be no change in memory bandwidth used as the overlay is fetched anyway

what is the largest correction we typically get per sensel?

yes, for gain it's usually very close to 1.0, with the exception of hot/dead pixels (which I'm not really sure they can be corrected with a simple gain anyway)

for offset, a quick test gives 99.8% of the values between -22 and 22

this offset is after RCN correction

pixel noise is about 4 units, so 16 levels for dark frame correction should be fine (if we don't use any gain correction)

if it is the gain which differs much, then we should correct for that instead

we could also make it non linear by putting it through a simple LUT if the range is large

sure

i.e. we will replace the sensor and SFE this week to verify

not sure what you mean, have an image?

alexML: https://sebix.at/tmp/test_color_marked.png

I would have suspected the RCN values to cause the bight stripes at the top and left side, but niemand said that even with rcn_clear.py they are still there

okay, that looks a lot better :)

rnc seems to be off on the right side though?

we could also do gain on a per column base, if that is the case?

this is a dark frame after RCN

the remaining defects are dynamic row noise (that changes with every frame) and static offsets that couldn't be modelled as RCN

+6 EV in ufraw

okay, so how about an RCN table for gain settings then?

same layout as for the offsets

we could do a multiply by 16 or maybe 18 bits and fixed divide by 14 or 15?

so should I do the step 3 now?

Or something else?

currently we have four column tables and two row tables

like that

will see how many resources we have left

maybe with a gain that I can tweak (can be hardcoded)

that would give a gain of 1,2,4 and 8

perfect

yep

https://www.kickstarter.com/projects/chipsetter/chipsetter-one-a-desktop-pick-and-place-machine

bb

alexML: I'd propose the following gain/offset scheme to allow for optimal pipelining/parallelization:

the c_off and c_gain vary based on even/odd rows

then we multiply the sensel value with the gain product and add the offset sum in one step

I can't give the exact bit widths yet, but I suspect them to increase compared to the current settings

sounds fine; that means I need to adjust the offsets to account for the gains, right?

yes, the offset is applied last

but let me check if we can change the order

anyway, should be doable

e.g. 1.1*1.1 = 1.21, 1.1+1.1-1 = 1.2

okay, so we do the following:

second stage: pre-adder (-1) on gain

ah, I missed the value + offset in the second stage

and third stage is the multiplication

alexML: okay, I did some calculations and checks with the DSP units

i.e. when we do (as planned):

then value/16 - o/13 -> x/16, g/13 - 1 -> y/13

we use up 2+2+4 DSP units

c_o/12+r_o/12 -> o/13, c_g/12+r_g/12 -> g/13

then value/16 * (g/13 -1) -> z/30

we only require 2+4 DSP units, or we could use 8 DSP units as above and increase the offset to 24 bit

for small gains, the changed order should not even matter, as we have

so if you are tight on resources, probably it's best to optimize for that

i.e. we don't want to waste a lot of resolution by encoding 0-2

then 0x10000 would be 1

if we do 0x10xxx and 0xFxxx we only need 13 bits to have a 16 bit gain

yeah, 0x10fff/0x10000 is 1.062, which is pretty tight

i.e. 0.75-1.25 roughly

if we account for the over/underflow with 2 bits on each

we could easily extend the LUTs to 18 bit

let's assume we do the following steps:

the we can do the entire g/19-1, mul, +o/19 in one DSP (i.e. another 4 DSPs)

which is way more than we ever need

the reason why I'm considering those possibilities is because it is very likely that this design will stick for a while :)

okay, so I go for the simplest version, which is 12bit for now and mul/add in one DSP per channel

ok, let's try that first

* swap row/col (sorry, it's late)

some figures:

xcov(r0, r1, 0, 'coeff') => 0.99954

so, row noise doesn't really depend on odd/even columns

i see ...

impulses, equally spaced

hold a second

https://dl.dropboxusercontent.com/u/4124919/bleeding-edge/apertus/noise-pattern-flats2.png

notice how the horizontal pattern gets shifted

the camera was on battery, connected to laptop (also on battery), at about 50 meters from nearest power source (outside)

according to at least one cmosis AN, this can be compensated with the black columns

it's not

(or, if it is, it's buried in noise)

fair enough ...

and to me, that noise looks like a perturbation in some feedback loop

camera was pointed at the sky, no clouds

and the sensor has global shutter

but I have no clue how the row exposure would change in the sensor

sure, what's puzzling is the periodicity of that signal

indeed

counting the pixels in gimp gives 189, 186, 180, 190 (multiply by 2, since the screenshot is zoomed at 50%)

so it would be something between 850 and 900 Hz

fan interference?

and would explain the slight variation too