01:01 | anuejn | that would be a very useful script
| |
01:02 | anuejn | if you want to look into it se6astian that would be much appreachiated
| |
01:10 | Bertl_oO | off to bed now ... have a good one everyone!
| |
01:10 | Bertl_oO | changed nick to: Bertl_zZ
| |
01:20 | vup | so anuejn and I started looking into the sensor calibration stuff aswell, especially motivated by the working hdmi raw setup, because that means we can capture a huge amount of darkframes, etc in a short amount of time.
| |
01:20 | vup | We started with simply capturing darkframes for different gain and exposure settings
| |
01:22 | vup | one thing we noticed is, that the darkframes seem show some gradient in the x direction
| |
01:22 | vup | this seems to occur regardless of gain setting and exposure time
| |
01:23 | vup | so it should not be stray light getting in
| |
01:23 | vup | is this a known effect, or are we maybe still making a mistake in capturing or analyzing the darkframes?
| |
01:25 | vup | (for example this is 256 darkframes at 4x gain, 11ms exposure averaged and the colormap goes from μ - 3σ to μ + 3σ: https://files.niemo.de/4x_11ms_mean.png)
| |
01:28 | vup | another interesting effect is, that the histogram of the pixel values seems to be pretty skewed at 1x gain: https://files.niemo.de/1x_hist.png
| |
01:28 | vup | and for 4x gain the histogram is even weirder, having two plateaus: https://files.niemo.de/4x_hist.png
| |
01:30 | vup | finally, subtracting the mean of the pixels in a column from the respective column produces some interesting patterns: https://files.niemo.de/1x_10ms_mean_by_column.png
| |
01:31 | vup | maybe we can use these to better compensate the row noise...
| |
07:52 | se6astian | I will try to pursue this script and collect all the relevant information yes
| |
07:53 | se6astian | will create issue on github first to keep track of the relevant information
| |
08:23 | se6astian | https://github.com/apertus-open-source-cinema/axiom-firmware/issues/196
| |
08:24 | se6astian | Bertl_zZ: which register is the frame counter in the generator block?
| |
08:25 | se6astian | vup: very interesting findings, I have not seen such behavior before
| |
08:25 | se6astian | but its great that you are now getting to the bottom of things in this regard
| |
08:48 | lexano | left the channel | |
09:01 | lexano | joined the channel | |
09:09 | Bertl_zZ | changed nick to: Bertl
| |
09:09 | Bertl | morning folks!
| |
09:10 | se6astian | hello!
| |
09:11 | Bertl | se6astian: see https://wiki.apertus.org/index.php/CMV12000_Register_Blocks (scan generator, second read only register)
| |
09:12 | Bertl | I've updated the raw hdmi gateware to allow for using both the scan fcnt as well as the cseq fcnt in the marker overlays
| |
09:12 | Bertl | http://vserver.13thfloor.at/Stuff/AXIOM/BETA/HDMIRAW/cmv_hdmi3_raw.bit
| |
09:13 | Bertl | this should simplify testing and allow for sanity checks
| |
09:13 | se6astian | 0x80000004 RO [27:16] Scan Frame Counter is the one we want I assume
| |
09:14 | se6astian | what are "current events"?
| |
09:14 | se6astian | many thanks
| |
09:15 | Bertl | the current events are the event flags currently active
| |
09:16 | se6astian | how does this register correlate with scn_reg call from commandline?
| |
09:17 | Bertl | in the raw_mark.sh script, the 0xF000 value needs to be replaced with 0xF800 for the pixels where you want to use the cseq_fcnt instead of the scan_fcnt
| |
09:18 | Bertl | I would suggest to have the top-left and bottom-right with 0xF000 while the top-right and bottom-left use the 0xF800
| |
09:18 | Bertl | this way you can compare the sequencer and scan generator counts
| |
09:19 | se6astian | axiom_scn_regi is the correct cal here I assume?
| |
09:19 | se6astian | https://github.com/apertus-open-source-cinema/axiom-firmware/blob/main/software/scripts/axiom_mp1_reg.func
| |
09:19 | Bertl | yep, looks good
| |
09:20 | se6astian | thanks, I think now we have all the required info together
| |
09:20 | se6astian | I updated https://github.com/apertus-open-source-cinema/axiom-firmware/issues/196
| |
09:21 | Bertl | note that you need to make sure (for the alternating raw data output) that the hdmi output rate has a factor of two to the acquisition frame rate
| |
09:22 | Bertl | so the exposure time has to be within the proper limits
| |
09:23 | se6astian | noted
| |
14:52 | Bertl | off for now ... bbl
| |
14:52 | Bertl | changed nick to: Bertl_oO
| |
15:13 | vup | se6astian: so re the darkframes, when anuejn pushes his local changes it would be pretty interesting to capture some darkframes from as many different sensors as possible, to look into these patterns and see if this is just random or actually present on multiple sensors. How many sensors do we currently have available?
| |
15:17 | vup | and how many community members with a beta would be willing to capture some?
| |
15:18 | vup | it doesn't really take a lot of time, I think we did a pretty comprehensive scan of 12 different exposure values + 4 gains in ~30 minutes
| |
15:18 | vup | it just produces a lot of data
| |
15:18 | vup | (~120Gb uncompressed)
| |
15:18 | vup | but it might be possible to compress them atleast a bit (naive xz or zstd only gives atmost a factor of two compression)
| |
15:19 | vup | also Bertl_oO: how difficult would it be to always have the dark columns transmitted, even when not capturing the full sensor resolution?
| |
15:25 | vup | oh also, do we know if there are different revision of the cmv12k?
| |
15:27 | se6astian | well I can offer 1 sensor
| |
15:28 | se6astian | I dont think anyone else has a magewell setup ready at this point
| |
15:28 | se6astian | maybe Bertl as well
| |
15:28 | se6astian | I am not aware of different cmv12000 revisions
| |
15:28 | se6astian | just color/mono/nir
| |
15:29 | se6astian | they had more loose defect samples in the beginning but after they saw the defects are not comon they lowered them
| |
15:29 | se6astian | and called it V2
| |
15:29 | se6astian | but that quickly disappeared as V1 vs V2 differeces were just defect specificationsa nd therefore irelevant
| |
15:30 | se6astian | regading black coloumns, we can do 2048x1080 via hdmi
| |
15:30 | se6astian | resulting in a full width raw frame with A+B frames
| |
15:34 | aombk | joined the channel | |
15:35 | vup | ok, thats atleast on sensor to compare against
| |
15:35 | vup | so probably no relevant revisions, thats nice to know
| |
15:36 | vup | so with the black columns, it probably would be pretty interesting to just have them always present, regardless of wether we do the full width or not
| |
15:36 | vup | as there might be legit reasons for not wanting the full width probably
| |
15:38 | anuejn | I pushed my changes
| |
15:38 | vup | nice :)
| |
15:38 | anuejn | I captured the dark-frames with a bash one liner and changing the gain in between
| |
15:39 | anuejn | the one liner is:
| |
15:39 | anuejn | for time in $(seq 0 11); do ssh operator@192.168.0.95 "echo 1 > /axiom-api/devices/cmv12000/computed/exposure_time_ms/value; cat /axiom-api/devices/cmv12000/computed/exposure_time_ms/value"; done
| |
15:39 | anuejn | so
| |
15:39 | anuejn | *no
| |
15:39 | anuejn | for time in 1; do cargo run --release -- WebcamInput --device 0 ! DualFrameRawDecoder --first-red-x true --first-red-y false ! RawBlobWriter --number-of-frames 256 --path target/darkframe_2x_$(ssh operator@192.168.0.95 "echo $time > /axiom-api/devices/cmv12000/computed/exposure_time_ms/value; cat /axiom-api/devices/cmv12000/computed/exposure_time_ms/value").blob; done
| 15:39 | anuejn | is afk for a while now
|
16:05 | se6astian | 3d printed new recorder enclosure
| |
16:05 | se6astian | now heading home
| |
20:47 | se6astian | the recorder has been assembled, and miraculously everything seems to fit now with the connectors and bulky cables
| |
20:47 | se6astian | will finish and start it up tomorrow
| |
21:25 | anuejn | nice
|