| 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 |