Current Server Time: 10:33 (Central Europe)

#apertus IRC Channel Logs

2022/01/08

Timezone: UTC


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