Current Server Time: 01:06 (Central Europe)

#apertus IRC Channel Logs

2016/10/23

Timezone: UTC


00:23
BogdanXor
left the channel
00:23
BogdanXor
joined the channel
00:45
BogdanXor
left the channel
00:53
BogdanXor
joined the channel
01:05
BogdanXor
left the channel
01:06
BogdanXor
joined the channel
01:14
BogdanXor
left the channel
01:15
BogdanXor
joined the channel
01:33
hozer
left the channel
01:43
BogdanXor
left the channel
01:44
BogdanXor
joined the channel
01:44
hozer
joined the channel
02:03
jucar
joined the channel
02:07
BogdanXor
left the channel
02:19
BogdanXor
joined the channel
02:42
BogdanXor
left the channel
02:43
BogdanXor
joined the channel
02:51
arpu
left the channel
03:00
BogdanXor
left the channel
03:01
BogdanXor
joined the channel
03:05
arpu
joined the channel
03:13
illwieckz
left the channel
03:23
BogdanXor
left the channel
03:26
BogdanXor
joined the channel
03:45
BogdanXor
left the channel
03:46
BogdanXor
joined the channel
03:53
illwieckz
joined the channel
04:00
BogdanXor
left the channel
04:15
BogdanXor
joined the channel
04:21
jucar
left the channel
04:46
hozer
left the channel
04:55
BogdanXor
left the channel
04:55
BogdanXor
joined the channel
04:57
hozer
joined the channel
05:03
BogdanXor
left the channel
05:04
Bertl
off to bed now ... have a good one everyone!
05:04
Bertl
changed nick to: Bertl_zZ
05:16
BogdanXor
joined the channel
05:40
BogdanXor
left the channel
05:41
BogdanXor
joined the channel
05:46
BogdanXor
left the channel
05:48
BogdanXor
joined the channel
06:10
BogdanXor
left the channel
06:13
BogdanXor
joined the channel
06:42
BogdanXor
left the channel
06:43
BogdanXor
joined the channel
06:53
Alex_Chooks_
joined the channel
07:32
BogdanXor
left the channel
07:33
BogdanXor
joined the channel
08:10
BogdanXor
left the channel
08:10
BogdanXor
joined the channel
08:44
niemand
joined the channel
08:55
aombk2
joined the channel
08:58
aombk
left the channel
09:08
BogdanXor
left the channel
09:09
Spirit532
joined the channel
09:19
BogdanXor
joined the channel
09:26
sebix
joined the channel
09:30
niemand
left the channel
09:40
BogdanXor
left the channel
09:43
BogdanXor
joined the channel
09:58
sebix
changed nick to: niemand
10:00
sebix
joined the channel
10:03
niemand
left the channel
10:12
BogdanXor
left the channel
10:13
BogdanXor
joined the channel
10:15
sebix
changed nick to: niemand
10:26
BogdanXor
left the channel
10:27
BogdanXor
joined the channel
10:43
BogdanXor
left the channel
10:44
BogdanXor
joined the channel
10:46
niemand
alexML, are you here?
11:04
Bertl_zZ
changed nick to: Bertl
11:04
Bertl
morning folks!
11:13
alexML
niemand: yes
11:17
BogdanXor
left the channel
11:18
BogdanXor
joined the channel
11:22
niemand
alexML, noise is still high:
11:23
niemand
Row noise : 0.88 (136.9%)
11:23
niemand
Col noise : 0.86 (134.2%)
11:23
niemand
- odd rows : 1.11 (173.3%)
11:23
niemand
- even rows : 0.79 (122.7%)
11:37
BogdanXor
left the channel
11:38
BogdanXor
joined the channel
11:44
BogdanXor
left the channel
11:47
BogdanXor
joined the channel
12:02
BogdanXor
left the channel
12:14
BogdanXor
joined the channel
12:38
BogdanXor
left the channel
12:45
BogdanXor
joined the channel
12:53
BogdanXor
left the channel
12:53
BogdanXor
joined the channel
13:31
Spirit532_
joined the channel
13:32
Spirit532
left the channel
13:37
BogdanXor
left the channel
13:38
BogdanXor
joined the channel
13:41
niemand
My axiom is currently configured to no start the hdmi output on boot (not sure how to change it). When running rcn_darkframe.py the OS dies instantly. No output on minicom too. When I run kick_manual first, it works
13:43
niemand
But then the darkframe seems to be not applied at all
13:59
BogdanXor
left the channel
14:00
BogdanXor
joined the channel
14:01
Bertl
the auto start can be managed in two ways
14:01
Bertl
there is a systemd service called cmv12k, which can be enabled or disabled
14:02
Bertl
this service in turn runs kick.sh on startup and halt.sh on shutdown
14:02
Bertl
in kick.sh (and halt.sh) there is an optional (normally commented out) 'exit 0' early in the script
14:03
Bertl
by making sure that the 'exit 0' is commented out, and the cmv12k service is enabled, you will enable HDMI live autostart
14:03
Bertl
now to the 'dies instantly'
14:03
Bertl
with autostart disabled, no firmware is loaded into the FPGA
14:04
Bertl
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)
14:05
Bertl
in the future, we will load a basic FPGA firmware from the bootloader, so that this cannot happen and the proper AMBA replies are generated for missing addresses
14:05
Bertl
now to adjusting RCN (dark frame data)
14:06
Bertl
you can do that at any time, even during live HDMI out
14:06
Bertl
if you need to take a controlled snap, you can simply disable the live feed via registers
14:10
niemand
I knew of the cmv12k service, but the exit 0 in the kick.sh was active
14:29
BogdanXor
left the channel
14:34
niemand
without rcn offsets the hdmi output is much more darker, does this make sense?
14:35
Bertl
it could be, really depends on the RCN values
14:35
niemand
thanks for the explanation for the freeze!
14:35
Bertl
they allow for some +/- adjustments per row and column
14:36
Bertl
so if the RCN values are all on the positive end of the possible adjustments, the picture will get brighter
14:36
Bertl
note that RCN and linearization LUTs affect both, the snaps and the HDMI output
14:37
Bertl
i.e. they happen early in the image pipeline, before the image is stored in memory
14:37
niemand
k
14:37
Bertl
while the color matrix and gamma LUTs work late in the image pipeline and thus do not affect the snap
14:41
BogdanXor
joined the channel
14:59
BogdanXor
left the channel
15:00
BogdanXor
joined the channel
15:10
niemand
In snaps I still have these bright stripes in the left and top (you said it might be a wrong rcn correction which I did now myself)
15:10
niemand
It's ok in the hdmi output
15:11
niemand
And the snaps (after running them through raw2dng) are stille very purple. (But they are no 12bit!) With convert it works fine.
15:12
Bertl
try with rcn_clear.py it should disable all rcn configurations
15:12
Bertl
then take a snap and see if the stripes are still there
15:13
Bertl
did you try the raw2dng option to switch the bayer pattern (as suggested some time ago)
15:14
niemand
the --swap-lines ?
15:14
Bertl
yep
15:15
niemand
the stripes are still there but not so bright
15:15
niemand
less purple. But still much more different than the hdmi output.
15:15
Bertl
interesting
15:16
Bertl
well, I have no idea what the raw2dng does regarding color matrix and how that is interpreted by different dng readers
15:17
Bertl
there are also two raw2dng tools out there IIRC, one is written from scratch and the other is based on magic lantern code (but maybe I'm completely wrong here, I don't use dng)
15:17
niemand
I tried shotwell, gwenview, ufraw, darktable. all the same
15:18
niemand
I have the one from your github repo
15:18
Bertl
but the convert sequence (simple debayer) works and gives the correct results?
15:19
niemand
yes, it looks good
15:19
Bertl
then it's very likely a problem with the raw2dng converter
15:19
niemand
i can upload a raw12 file
15:19
niemand
it still can be a user error
15:20
Bertl
se6astian is away maybe alexML can check that
15:32
Bertl
off for now ... bbl
15:32
Bertl
changed nick to: Bertl_oO
15:35
se6astian|away
changed nick to: se6astian
15:37
se6astian
please upload raw12 and email alex about it
15:37
niemand
already did that
15:38
niemand
not sure how to proceed
15:39
BogdanXor
left the channel
15:39
alexML
niemand: which file are you talking about? snap.raw12 looks fine here with --swap-lines
15:40
BogdanXor
joined the channel
15:40
jucar
joined the channel
15:41
niemand
alexML, I don't have an hdmi recorder
15:43
alexML
ok, then why are you trying to perform the HDMI calibration?
15:44
niemand
We want to use the axiom for streaming
15:45
niemand
I can get to a capture device tomorrow, but then we are already in "production mode"
15:45
niemand
*can get access to
15:48
BogdanXor
left the channel
15:49
BogdanXor
joined the channel
15:55
alexML
hm, if you want to do live streaming, we have a problem (I've never tried to output color-correct image on the hdmi)
16:17
hozer
left the channel
16:25
jucar
left the channel
16:29
hozer
joined the channel
16:31
BogdanXor
left the channel
16:33
BogdanXor
joined the channel
16:41
tezburma
joined the channel
16:47
se6astian
changed nick to: se6astian|away
16:51
BogdanXor
left the channel
16:51
BogdanXor
joined the channel
16:58
BogdanXor
left the channel
16:58
BogdanXor
joined the channel
17:20
BogdanXor
left the channel
17:22
BogdanXor
joined the channel
17:26
Bertl_oO
niemand, alexML: I don't think the live video color correction is a big problem
17:26
BogdanXor
left the channel
17:26
Bertl_oO
niemand already has a script to adjust hue, saturation and lightness
17:27
Bertl_oO
using the color matrix, a white balance is also doable and tested afaik
17:27
BogdanXor
joined the channel
17:27
Bertl_oO
the main problem so far was to get RCN working correctly and to set the linearization LUTs properly
17:28
Bertl_oO
i.e. to expand the sensor data over the entire linear range
17:28
Bertl_oO
(wich if all else fails, can be done with a simple linear lut entry)
17:30
niemand
alexML, the RGB+HSV script is here: sebix.at/tmp/rgbhsv.py (it's a stripped and modified mat4_conf.py)
17:30
niemand
I'm cooking now, will join the conversation later
17:31
Bertl_oO
and here is the updated mat4_conf.py, in case you missed that one:
17:31
Bertl_oO
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/mat4_conf.py
17:42
Bertl_oO
actually better to use this one: http://sebix.at/tmp/mat4_conf.py
17:43
Bertl_oO
(because it can be imported)
17:49
alexML
Bertl_oO: sensor data already covers the full range, see ./set_gain.sh
17:51
alexML
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)
17:52
alexML
will try to fix with a flat frame, but - afaik - this kind of correction isn't applied in the fpga
17:54
comradekingu
can the apertus foundation/company sign this: https://fsfe.org/activities/radiodirective/statement.en.html ?
17:57
Bertl_oO
not sure the 'foundation' can sign it, but the members will happily sign it I guess :)
17:58
BogdanXor
left the channel
17:58
Bertl_oO
alexML: the RCN offsets could be used to optimize for a flat frame instead of the dark frame to reduce the amount of pattern noise
17:58
BogdanXor
joined the channel
17:59
Bertl_oO
if the pattern noise is row/column specific that is
18:01
Bertl_oO
OTOH, there is the overlay data (16bit per HDMI pixel), so we could in theory encode some 'per pixel' corrections there
18:02
tezburma
left the channel
18:05
alexML
the overlay data can be made semi-transparent, I guess
18:06
alexML
and the blending is done after LUT, right?
18:07
Bertl_oO
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
18:07
alexML
ah, so it can be used as a correction frame (e.g. dark frame or gain correction frame)?
18:08
alexML
iirc you said there are memory bandwidth issues a while ago regarding dark frame subtraction
18:12
BogdanXor
left the channel
18:14
BogdanXor
joined the channel
18:14
Bertl_oO
we have the overlay already, so it's either 16 bit per bayer pixel (RG/GB) or 4 bit per sensel
18:14
Bertl_oO
there would be no change in memory bandwidth used as the overlay is fetched anyway
18:17
alexML
4 bit per sensel is a little tight, but still useful
18:30
Bertl_oO
what is the largest correction we typically get per sensel?
18:31
Bertl_oO
I presume it is a multiplication around 1.0
18:40
alexML
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)
18:41
Bertl_oO
how about reserving one value (0xF for example) to skip over dead/bright sensel and just use the previous sensel value instead
18:41
alexML
for offset, a quick test gives 99.8% of the values between -22 and 22
18:41
alexML
yes
18:41
alexML
this offset is after RCN correction
18:41
Bertl_oO
in the future, we could expand that to interpolating between neighbour sensel
18:42
alexML
pixel noise is about 4 units, so 16 levels for dark frame correction should be fine (if we don't use any gain correction)
18:43
Bertl_oO
well, the question is what is more prominent in 'typical' sensor data
18:43
Bertl_oO
if it is the gain which differs much, then we should correct for that instead
18:44
Bertl_oO
if it is just an offset, then we are fine with providing that (maybe as signed offset?)
18:44
Bertl_oO
we could also make it non linear by putting it through a simple LUT if the range is large
18:45
alexML
yeah, on niemand's beta, gain defects seem to be more obvious (waiting for some flat frames to confirm though)
18:45
alexML
sure
18:45
Bertl_oO
note that maybe niemands Beta has a sensor problem
18:45
Bertl_oO
i.e. we will replace the sensor and SFE this week to verify
18:46
Bertl_oO
I still don't have any explanation for the shaded borders on the top and left of the raw snaps
18:54
alexML
not sure what you mean, have an image?
18:55
BogdanXor
left the channel
18:57
BogdanXor
joined the channel
19:06
g3gg0
joined the channel
19:10
Bertl_oO
alexML: https://sebix.at/tmp/test_color_marked.png
19:11
Bertl_oO
ignore the change in exposure time, that was because the snap had a different value than before
19:15
Bertl_oO
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
19:16
alexML
so what I should look at? the snap he sent me looks like this: https://dl.dropboxusercontent.com/u/4124919/bleeding-edge/apertus/sebix-snap.jpg
19:16
Bertl_oO
okay, that looks a lot better :)
19:16
alexML
this is after RCN correction
19:17
Bertl_oO
rnc seems to be off on the right side though?
19:17
alexML
the dark frame has no more vertical defects, so I guess those from the picture are gain variations
19:17
BogdanXor
left the channel
19:18
Bertl_oO
okay, so we might opt for a gain correction instead of an offset?
19:18
Bertl_oO
we could also do gain on a per column base, if that is the case?
19:18
alexML
https://dl.dropboxusercontent.com/u/4124919/bleeding-edge/apertus/sebix-dark.jpg
19:18
alexML
this is a dark frame after RCN
19:18
BogdanXor
joined the channel
19:19
alexML
the remaining defects are dynamic row noise (that changes with every frame) and static offsets that couldn't be modelled as RCN
19:19
Bertl_oO
this is stretched to the full range I presume :)
19:20
alexML
+6 EV in ufraw
19:20
niemand
re
19:21
Bertl_oO
okay, so how about an RCN table for gain settings then?
19:21
alexML
yep, let's try
19:21
alexML
same layout as for the offsets
19:21
niemand
step 3 in calibration?
19:22
Bertl_oO
we could do a multiply by 16 or maybe 18 bits and fixed divide by 14 or 15?
19:23
alexML
sure, 16 is perfect, div by 1<<15
19:29
niemand
so should I do the step 3 now?
19:30
Bertl_oO
do we need to split it up into cxr0/cxr1
19:30
niemand
Or something else?
19:30
alexML
not sure what those codes mean, can you make it the same as the RCN offsets?
19:31
Bertl_oO
currently we have four column tables and two row tables
19:31
alexML
yes
19:31
alexML
like that
19:31
Bertl_oO
okay
19:31
Bertl_oO
will see how many resources we have left
19:31
alexML
and while you are at it, can you add a HDMI mode that uses the overlay as dark frame (signed offset)?
19:32
alexML
maybe with a gain that I can tweak (can be hardcoded)
19:32
Bertl_oO
we can easily do a shift mix, i.e. allow for 0, 1, 2, 3 bit shift
19:33
Bertl_oO
that would give a gain of 1,2,4 and 8
19:33
Bertl_oO
(only for the offsets that is)
19:33
alexML
perfect
19:34
Bertl_oO
okay, then we do that ... but I start with the gain rcn, and try to make it work/available first, so that it can be tested
19:34
alexML
yep
19:37
Bertl_oO
hmm, I just saw that the clut size for the rcn is 12bit, so I will limit the gain table to 12bit as well (which shouldn't hurt much) we do a shift by 10 or 11 bits then
19:37
g3gg0
left the channel
19:40
alexML
ok
19:56
derWalter
joined the channel
19:56
derWalter
hey se6astian|away, just sent you an email regarding: "Chipsetter ONE: A desktop pick-and-place machine"
19:56
derWalter
https://www.kickstarter.com/projects/chipsetter/chipsetter-one-a-desktop-pick-and-place-machine
19:56
derWalter
just stumbled across it, maybe its interessting? but just three days left :S
19:57
derWalter
bb
20:01
derWalter
left the channel
20:03
Bertl_oO
alexML: I'd propose the following gain/offset scheme to allow for optimal pipelining/parallelization:
20:03
Bertl_oO
for each sensel we have a c_off, r_off and c_gain, r_gain
20:04
Bertl_oO
the c_off and c_gain vary based on even/odd rows
20:05
Bertl_oO
we calculate c_off+r_off and c_gain*r_gain in parallel
20:06
Bertl_oO
then we multiply the sensel value with the gain product and add the offset sum in one step
20:06
Bertl_oO
(this should be doable with the DSPs)
20:06
Bertl_oO
I can't give the exact bit widths yet, but I suspect them to increase compared to the current settings
20:07
Bertl_oO
does that sound like something you can work with?
20:11
alexML
sounds fine; that means I need to adjust the offsets to account for the gains, right?
20:11
alexML
(ideally, you first subtract the offset, then multiply)
20:11
Bertl_oO
yes, the offset is applied last
20:11
BogdanXor
left the channel
20:12
Bertl_oO
but let me check if we can change the order
20:13
BogdanXor
joined the channel
20:21
niemand
left the channel
20:24
Bertl_oO
hmm, tricky, averaging the gain values instead of multiplying them won't work I guess?
20:25
Bertl_oO
anyway, should be doable
20:33
alexML
for small gains (close to 1), adding (not averaging) followed by subtracting 1 seems to do the trick
20:33
alexML
e.g. 1.1*1.1 = 1.21, 1.1+1.1-1 = 1.2
20:33
Bertl_oO
ah, okay, that should be easy then
20:36
Bertl_oO
okay, so we do the following:
20:37
Bertl_oO
first stage: c_off/12 + r_off/12, c_gain/12 + r_gain/12
20:38
Bertl_oO
second stage: pre-adder (-1) on gain
20:39
Bertl_oO
third stage: multiply value with (gain - 1)
20:39
Bertl_oO
ah, I missed the value + offset in the second stage
20:40
Bertl_oO
so second stage is actually gain - 1, value - off
20:40
Bertl_oO
and third stage is the multiplication
20:40
alexML
sounds good
20:42
BogdanXor
left the channel
20:45
BogdanXor
joined the channel
21:08
BogdanXor
left the channel
21:09
BogdanXor
joined the channel
21:14
Bertl_oO
alexML: okay, I did some calculations and checks with the DSP units
21:14
Bertl_oO
we could definitely improve resolution and performance if we do the offset after the multiplication
21:15
Bertl_oO
i.e. when we do (as planned):
21:16
Bertl_oO
c_o/12+r_o/12 -> o/13, c_g/12+r_g/12 -> g/13
21:17
Bertl_oO
then value/16 - o/13 -> x/16, g/13 - 1 -> y/13
21:17
Bertl_oO
and finally the multiply with x/16 * y/13 -> z/30
21:18
Bertl_oO
we use up 2+2+4 DSP units
21:18
Bertl_oO
but when we do:
21:19
Bertl_oO
c_o/12+r_o/12 -> o/13, c_g/12+r_g/12 -> g/13
21:19
Bertl_oO
then g/13 - 1
21:20
Bertl_oO
then value/16 * (g/13 -1) -> z/30
21:20
Bertl_oO
and finally z/30 - o/13
21:21
Bertl_oO
we only require 2+4 DSP units, or we could use 8 DSP units as above and increase the offset to 24 bit
21:22
Bertl_oO
(actually 18bit would be more apropriate, because that is the memory size)
21:22
BogdanXor
left the channel
21:23
BogdanXor
joined the channel
21:25
Alex_Chooks_
left the channel
21:25
alexML
well, thinking a bit about it, I would have to adjust the offsets anyway if I want a nonzero black level
21:25
Bertl_oO
for small gains, the changed order should not even matter, as we have
21:26
Bertl_oO
(v - a)*b = v*b - a*b
21:26
alexML
so if you are tight on resources, probably it's best to optimize for that
21:27
Bertl_oO
another aspect is we want to have gains near 1, so we need to encode them properly
21:27
Bertl_oO
i.e. we don't want to waste a lot of resolution by encoding 0-2
21:27
Bertl_oO
let's say we have a shift of 16 bit
21:28
Bertl_oO
then 0x10000 would be 1
21:28
alexML
if we have 16 or 18 bits, I'd rather keep it simple
21:28
Bertl_oO
if we do 0x10xxx and 0xFxxx we only need 13 bits to have a 16 bit gain
21:29
Bertl_oO
but this time, the gain is more around 1
21:30
alexML
yeah, 0x10fff/0x10000 is 1.062, which is pretty tight
21:30
Bertl_oO
doesn't need to be that tight, let's say 2 bits?
21:30
Bertl_oO
i.e. 0.75-1.25 roughly
21:30
alexML
that should be fine
21:31
BogdanXor
left the channel
21:31
Bertl_oO
because we have a 25x18 multiplier anyway
21:31
Bertl_oO
if we account for the over/underflow with 2 bits on each
21:32
Bertl_oO
we get 23x16 but we have 16 and 13 bit input values
21:32
Bertl_oO
we could easily extend the LUTs to 18 bit
21:32
Bertl_oO
but that would also increase the resources
21:33
BogdanXor
joined the channel
21:33
Bertl_oO
but that would be something with a benefit if we need fine tuning (not sure we do)
21:34
Bertl_oO
let's assume we do the following steps:
21:35
Bertl_oO
c_o/18+r_o/18 -> o/19, c_g/18+r_g/18 -> g/19 (cost us 4 DSPs)
21:36
Bertl_oO
the we can do the entire g/19-1, mul, +o/19 in one DSP (i.e. another 4 DSPs)
21:36
Bertl_oO
assuming we do 2 bits expansion on the gain part, we get 21 bit gain, 19 bit offset and 16 bit value in/out
21:37
Bertl_oO
which is way more than we ever need
21:38
Bertl_oO
(in this case, we do not even need the bit exansion, as it doesn't make any sense)
21:41
Bertl_oO
the reason why I'm considering those possibilities is because it is very likely that this design will stick for a while :)
21:42
Bertl_oO
and no, at the moment we are not critical on DSP resources, but when we decide to implement a 3D lut at some point, they might become scarce
21:51
Bertl_oO
okay, so I go for the simplest version, which is 12bit for now and mul/add in one DSP per channel
21:52
Bertl_oO
we can easily extend that to 18/24bit if needed
21:52
alexML
ok, let's try that first
21:53
BogdanXor
left the channel
21:55
BogdanXor
joined the channel
21:56
Bertl_oO
btw, would having 2x4 LUTs (i.e. different row values depending on even/odd columns) help in any way?
21:58
Spirit532_
changed nick to: Spirit532
22:03
BogdanXor
left the channel
22:04
BogdanXor
joined the channel
22:05
alexML
for dark frame, it does't seem to help (column noise for odd/even rows are highly correlated, nearly identical)
22:08
alexML
* swap row/col (sorry, it's late)
22:15
Bertl_oO
okay
22:20
alexML
some figures:
22:20
alexML
r0 = mean(a'(1:2:end,:)); r1 = mean(a'(2:2:end,:)); # row noise
22:20
BogdanXor
left the channel
22:20
alexML
c0 = mean(a (1:2:end,:)); c1 = mean(a (2:2:end,:)); # col noise
22:20
alexML
xcov(r0, r1, 0, 'coeff') => 0.99954
22:21
alexML
xcov(c0, c1, 0, 'coeff') => -0.99358
22:21
alexML
so, row noise doesn't really depend on odd/even columns
22:22
alexML
but column noise (the vertical one) actually has opposite values on odd/even rows
22:23
BogdanXor
joined the channel
22:24
alexML
so, if you try to measure the overall column noise (for the entire image), this will trick you (you will get a tiny value, but you will still have strong vertical noise)
22:31
Bertl_oO
i see ...
22:33
alexML
btw, looking at some flats, I've noticed an interesting pattern for row noise
22:33
alexML
impulses, equally spaced
22:34
Bertl_oO
got a picture/graph?
22:34
alexML
hold a second
22:39
alexML
https://dl.dropboxusercontent.com/u/4124919/bleeding-edge/apertus/noise-pattern-flats1.png
22:39
alexML
https://dl.dropboxusercontent.com/u/4124919/bleeding-edge/apertus/noise-pattern-flats2.png
22:40
alexML
two images taken at 1 minute difference iirc
22:40
alexML
notice how the horizontal pattern gets shifted
22:41
Bertl_oO
that is probably the dynamic row noise which can be reduced by some hardware modifications
22:41
alexML
the camera was on battery, connected to laptop (also on battery), at about 50 meters from nearest power source (outside)
22:42
alexML
in shadows, this pattern is not obvious as other sources of noise are probably much stronger
22:42
Bertl_oO
according to at least one cmosis AN, this can be compensated with the black columns
22:47
Bertl_oO
can you confirm that the pattern is also visible in the black columns?
22:47
alexML
it's not
22:48
Bertl_oO
then it might be a problem with the light source?
22:48
alexML
(or, if it is, it's buried in noise)
22:48
alexML
heh, I doubt the sunlight has such patterns :P
22:48
Bertl_oO
fair enough ...
22:50
alexML
the distance between those lines is about 400px, but not very constant
22:54
alexML
and to me, that noise looks like a perturbation in some feedback loop
22:55
Bertl_oO
well, if it doesn't affect the black columns, then it has to be the result of varying exposure
22:56
alexML
camera was pointed at the sky, no clouds
22:56
alexML
no shadows around
22:56
alexML
and the sensor has global shutter
22:57
Bertl_oO
not saying it is a problem with the motive
22:57
Bertl_oO
but I have no clue how the row exposure would change in the sensor
22:58
Bertl_oO
OTOH, it could be a varying ADC gain on readout as well
22:58
alexML
sure, what's puzzling is the periodicity of that signal
22:59
alexML
that makes me think it may be some electrical interference (and if you know the readout frequency, you should be able to tell the speed of the clock that's causing it)
22:59
Bertl_oO
indeed
23:00
Bertl_oO
the current LVDS speed is 250MHz IIRC, but there is some overhead for each line
23:02
alexML
counting the pixels in gimp gives 189, 186, 180, 190 (multiply by 2, since the screenshot is zoomed at 50%)
23:03
Bertl_oO
we get 32 lanes in parallel, so with 12 bit, that will roughly give a 162.76 kHz line rate
23:04
Bertl_oO
so it would be something between 850 and 900 Hz
23:04
Bertl_oO
or half if you multiply by two
23:05
alexML
fan interference?
23:05
Bertl_oO
maybe, should be easy to verify
23:05
alexML
and would explain the slight variation too
23:06
Bertl_oO
indeed
23:12
BogdanXor
left the channel
23:15
BogdanXor
joined the channel
23:20
BogdanXor
left the channel
23:22
BogdanXor
joined the channel
23:52
BogdanXor
left the channel
23:53
BogdanXor
joined the channel
23:58
BogdanXor
left the channel
23:58
BogdanXor
joined the channel