| 00:28 | balrog | left the channel |
| 00:33 | balrog | joined the channel |
| 03:50 | Bertl_oO | off to bed now ... have a good one everyone!
|
| 03:50 | Bertl_oO | changed nick to: Bertl_zZ
|
| 07:04 | illwieckz | left the channel |
| 07:39 | Spirit532 | left the channel |
| 07:39 | Spirit532 | joined the channel |
| 09:09 | se6astian | good day
|
| 09:20 | se6astian | anuejn / vup regarding the darkframe capture line you created, do you store the exposure time with the images somewhere or is metadata not required for the post processing afterwards?
|
| 11:26 | vup | we just put the gain and the exposure time into the filename for now
|
| 11:27 | vup | (thats what the bash one liner anuejn shared already does)
|
| 12:06 | se6astian | right
|
| 12:37 | illwieckz | joined the channel |
| 12:38 | illwieckz | left the channel |
| 12:41 | Bertl_zZ | changed nick to: Bertl
|
| 12:41 | Bertl | morning folks!
|
| 12:57 | illwieckz | joined the channel |
| 13:11 | illwieckz | left the channel |
| 13:26 | Bertl | off for now ... bbl
|
| 13:26 | Bertl | changed nick to: Bertl_oO
|
| 13:28 | illwieckz | joined the channel |
| 14:01 | sidsh | joined the channel |
| 14:01 | sidsh | left the channel |
| 14:47 | se6astian | anuejn / vup: thinking about the weird motion block artifacts with the realtime debayer we discussed some time ago I am now thinking if this wasnt always from wrong A/B frames being combined
|
| 14:47 | vup | yeah I am pretty sure that was the case
|
| 14:47 | se6astian | because that would explain the factor motion had on the issue (difference between two frames)
|
| 14:48 | vup | you can kind of force it if you increate the exposure beyond 11ms
|
| 14:48 | vup | (and fix it if you are lucky enough and get the right timing when setting the exposure back to something below 11ms again)
|
| 14:49 | se6astian | lol, ok :)
|
| 14:49 | vup | s/increate/increase/
|
| 16:45 | Bertl_oO | btw, it should be easy to verify this on captured data with the raw marks
|
| 16:45 | Bertl_oO | the read and write buffer selection is encoded there as well, so looking at the read buffer selection should always mark the matching frames
|
| 17:05 | vup | can you expand on this a bit? :)
|
| 17:07 | Bertl_oO | raw_out_ch0 <= scan_fcnt(7 downto 0) & "00" & raw_wrsel(3 downto 2);
|
| 17:07 | Bertl_oO | raw_out_ch1 <= "00" & raw_wrsel(1 downto 0) & x"AA";
|
| 17:07 | Bertl_oO | raw_out_ch2 <= scan_fcnt(7 downto 0) & "00" & raw_wrsel(3 downto 2);
|
| 17:07 | Bertl_oO | raw_out_ch3 <= "00" & raw_wrsel(1 downto 0) & x"55";
|
| 17:07 | Bertl_oO | raw_wrsel() contains the read/write buffer selection bits
|
| 17:08 | vup | in which order?
|
| 17:08 | Bertl_oO | wbuf_sel & rbuf_sel
|
| 17:08 | Bertl_oO | so while the write buffer tells you were the sensor is currently writing to (or going to write to)
|
| 17:09 | Bertl_oO | the read buffer selection tells you where the data is coming from
|
| 17:09 | Bertl_oO | so a matching read buffer selector would mean that the two frames are matching as well
|
| 17:12 | vup | right, nice
|
| 17:24 | se6astian | vup is your current focus still to write original raw12 sequences or is the goal to go straight to DNG with all compensations applied in realtime?
|
| 17:25 | vup | well I think if we can write reversibly compensated DNGs in realtime that would be the nicer than just uncompensated raw12 sequences
|
| 17:25 | se6astian | sounds good
|
| 17:26 | vup | but the current focus is mainly gathering some test data (darkframes, flat fields, etc) and try to recreate / understand everything a1ex did
|
| 17:29 | illwieckz | left the channel |
| 17:37 | se6astian | right
|
| 17:41 | vup | Bertl_oO: unless I am mistaken, the wrsel information should land in the green byte of the corners, right?
|
| 17:42 | vup | so the green byte should be "00" & raw_wrsel(3 downto 2) & "00" & raw_wrsel(1 downto 0)
|
| 17:42 | vup | did this change at some point?
|
| 17:43 | vup | because I have values like `0b1110` and `0b1001` for the green byte, which doesn't seem like it would match this
|
| 17:48 | illwieckz | joined the channel |
| 18:07 | Bertl_oO | ch0/1/2/3 should be mapped to R/G1/G2/B
|
| 18:17 | illwieckz | left the channel |
| 18:31 | illwieckz | joined the channel |
| 18:32 | vup | right, and R/G1 get mapped to the corner marker of a A frame, which then should contain first the 4 LSB of ch0 and then the 4 MSB of ch1 in the green channel of the rgb pixel, right?
|
| 18:49 | vup | also am I right in the assumption, that raw_wrsel is not held constant during a single frame?
|
| 19:23 | illwieckz | left the channel |
| 19:39 | illwieckz | joined the channel |
| 19:42 | se6astian | vup is the new raw hdmi bitstream already pushed to repo? because then I need to update the raw hdmi structure documentation on the wiki
|
| 19:43 | se6astian | just moved that over from the google doc
|
| 19:43 | se6astian | for the corner markers
|
| 19:58 | lexano | left the channel |
| 20:30 | lexano | joined the channel |
| 22:56 | vup | no the new raw hdmi bitstream is not yet pushed
|