Current Server Time: 08:16 (Central Europe)

#apertus IRC Channel Logs

2016/10/23

Timezone: UTC


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