Current Server Time: 19:54 (Central Europe)

#apertus IRC Channel Logs

2022/01/08

Timezone: UTC


01:28
balrog
left the channel
01:33
balrog
joined the channel
04:50
Bertl_oO
off to bed now ... have a good one everyone!
04:50
Bertl_oO
changed nick to: Bertl_zZ
08:04
illwieckz
left the channel
08:39
Spirit532
left the channel
08:39
Spirit532
joined the channel
10:09
se6astian
good day
10: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?
12:26
vup
we just put the gain and the exposure time into the filename for now
12:27
vup
(thats what the bash one liner anuejn shared already does)
13:06
se6astian
right
13:37
illwieckz
joined the channel
13:38
illwieckz
left the channel
13:41
Bertl_zZ
changed nick to: Bertl
13:41
Bertl
morning folks!
13:57
illwieckz
joined the channel
14:11
illwieckz
left the channel
14:26
Bertl
off for now ... bbl
14:26
Bertl
changed nick to: Bertl_oO
14:28
illwieckz
joined the channel
15:01
sidsh
joined the channel
15:01
sidsh
left the channel
15: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
15:47
vup
yeah I am pretty sure that was the case
15:47
se6astian
because that would explain the factor motion had on the issue (difference between two frames)
15:48
vup
you can kind of force it if you increate the exposure beyond 11ms
15: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)
15:49
se6astian
lol, ok :)
15:49
vup
s/increate/increase/
17:45
Bertl_oO
btw, it should be easy to verify this on captured data with the raw marks
17: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
18:05
vup
can you expand on this a bit? :)
18:07
Bertl_oO
raw_out_ch0 <= scan_fcnt(7 downto 0) & "00" & raw_wrsel(3 downto 2);
18:07
Bertl_oO
raw_out_ch1 <= "00" & raw_wrsel(1 downto 0) & x"AA";
18:07
Bertl_oO
raw_out_ch2 <= scan_fcnt(7 downto 0) & "00" & raw_wrsel(3 downto 2);
18:07
Bertl_oO
raw_out_ch3 <= "00" & raw_wrsel(1 downto 0) & x"55";
18:07
Bertl_oO
raw_wrsel() contains the read/write buffer selection bits
18:08
vup
in which order?
18:08
Bertl_oO
wbuf_sel & rbuf_sel
18:08
Bertl_oO
so while the write buffer tells you were the sensor is currently writing to (or going to write to)
18:09
Bertl_oO
the read buffer selection tells you where the data is coming from
18:09
Bertl_oO
so a matching read buffer selector would mean that the two frames are matching as well
18:12
vup
right, nice
18: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?
18:25
vup
well I think if we can write reversibly compensated DNGs in realtime that would be the nicer than just uncompensated raw12 sequences
18:25
se6astian
sounds good
18:26
vup
but the current focus is mainly gathering some test data (darkframes, flat fields, etc) and try to recreate / understand everything a1ex did
18:29
illwieckz
left the channel
18:37
se6astian
right
18:41
vup
Bertl_oO: unless I am mistaken, the wrsel information should land in the green byte of the corners, right?
18:42
vup
so the green byte should be "00" & raw_wrsel(3 downto 2) & "00" & raw_wrsel(1 downto 0)
18:42
vup
did this change at some point?
18:43
vup
because I have values like `0b1110` and `0b1001` for the green byte, which doesn't seem like it would match this
18:48
illwieckz
joined the channel
19:07
Bertl_oO
ch0/1/2/3 should be mapped to R/G1/G2/B
19:17
illwieckz
left the channel
19:31
illwieckz
joined the channel
19: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?
19:49
vup
also am I right in the assumption, that raw_wrsel is not held constant during a single frame?
20:23
illwieckz
left the channel
20:39
illwieckz
joined the channel
20: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
20:43
se6astian
just moved that over from the google doc
20:43
se6astian
for the corner markers
20:58
lexano
left the channel
21:30
lexano
joined the channel
23:56
vup
no the new raw hdmi bitstream is not yet pushed