Current Server Time: 14:27 (Central Europe)

#apertus IRC Channel Logs

2014/05/27

Timezone: UTC

1
02:00
gcolburn
joined the channel
2
02:14
gcolburn
left the channel
3
07:17
intracube
joined the channel
4
07:40
se6astian
joined the channel
5
07:57
sb0
joined the channel
6
08:41
Marco742
joined the channel
7
08:43
mars_
hi marco
8
09:25
Marco742
hi
9
09:27
Marco742
mars_: just on another client, therefore other username
10
09:36
sb0
left the channel
11
09:55
Marco742
left the channel
12
10:04
Bertl
morning folks!
13
10:36
Marco74
mahlzeit
14
11:10
se6astian
left the channel
15
11:15
Marco74
left the channel
16
11:30
Marco74
joined the channel
17
11:32
troy_s
left the channel
18
14:26
Lunastyx
left the channel
19
14:29
Lunastyx
joined the channel
20
14:36
Lunastyx
left the channel
21
14:39
Lunastyx
joined the channel
22
14:48
Lunastyx
left the channel
23
14:50
Lunastyx
joined the channel
24
15:20
se6astian
joined the channel
25
15:21
se6astian
good evening
26
15:38
Bertl
evening se6astian!
27
15:39
Marco74
good evening
28
15:40
Marco74
Bertl: just trying to figure out how image data will be represented in the memory
29
15:41
Marco74
I assume pixel_remap.vhd defines the architecure for this?
30
15:41
Bertl
in memory, we currently have blocks of 4 sensel (R/G/G/B) packed together in a 64bit word
31
15:41
Bertl
they come from the first and second row/column
32
15:42
Bertl
there is some space left in that word because the data is 12bit (atm) which leaves 16 bit for other stuff (currently used as overlay)
33
15:42
Bertl
the pixel_remap.vhd reorders the data from the sensor to match this format
34
15:43
Bertl
the data is transmitted as sensel over two lines with 128 columns distance
35
15:43
Marco74
as the cmv12000 spec says
36
15:45
Bertl
yep, precisely
37
15:46
Marco74
So, I need to read an image from a file an store it to the memory in the same manner?
38
15:53
Bertl
yes, I'd suggest to read some kind of standard deep bit (i.e. 12 or 16bit) format like PNG or TIFF or PPM either gray or in color and generate the sensel information and the memory layout from that
39
15:53
Bertl
note that you want to apply the parts of the sensor pipeline which affect the data
40
15:54
Bertl
namely the 4 LUTs (12 to 18bit signed) and the Row/Col Noise correction
41
15:56
Bertl
there is also a clipping which can be enabled and disabled at the end of the R/C Noise correction
42
15:57
Bertl
i.e. values greater than 4095 (12bit) will become white (4095) and values less than 0 will become black (0)
43
15:57
Bertl
the clipping can be enabled independantly
44
15:59
Marco74
ok, but at the moment I'm struggling to figure out where the single pixels are stored in memory
45
15:59
Marco74
Is is like that:
46
15:59
Marco74
|row 1|row 2|...|row n|
47
15:59
Marco74
where
48
15:59
Marco74
row1 is like
49
16:00
Marco74
|col 1|col 2|...|col n|
50
16:00
Marco74
?
51
16:00
Bertl
no
52
16:00
Marco74
sorry indexes should start with 0
53
16:00
Bertl
the sensor has sensel (different colors) in a bayer pattern
54
16:00
Bertl
so the first row looks like this:
55
16:00
Bertl
R G R G R G .... (4096 sensel total)
56
16:01
Bertl
the second row looks like this:
57
16:01
Bertl
G B G B G B .... (again 4096 sensel)
58
16:01
Marco74
ah, ok the cmv12000 does not recalculate the colors...
59
16:01
Marco74
s/colors/full colors/
60
16:01
Bertl
no, it would give the same data with a monochrome sensor
61
16:02
Bertl
where all sensel would just report brightness
62
16:02
Marco74
exactly
63
16:02
Bertl
the remap part now isolates blocks of 4 pixels
64
16:02
Bertl
(0,0) (1,0) (0,1) and (1,1)
65
16:03
Bertl
i.e. the first red in the first row, the first green in the first row, the first green in the second row and the first blue in the second row form one block
66
16:03
Bertl
12x4 = 48 bit
67
16:04
Bertl
those get mapped through the 4 12u->18s LUTs
68
16:04
Bertl
i.e. each sensel in the block has its own LUT
69
16:04
Bertl
creating 4 18bit signed values
70
16:05
Bertl
then the R/C correction adds a certain value (depending on row and column) to each 18s value
71
16:06
Bertl
and then the result is optionally clipped and again reduced to 12bit unsigned per value
72
16:06
Bertl
the result is packed in the upper 48bit of a 64bit word in memory
73
16:07
Bertl
this happens along a row, for each two rows (3072/2) of the sensor
74
16:08
Marco74
ok, now also the two sided read-out makes really sense ...
75
16:12
Bertl
note that it would be nice to model the R/C noise correction as well, as it would allow to test various corrections without actual hardware
76
16:12
Marco74
so 4096x3072 sensel information form a 2048x1536 image or will the "missing" information be interpolated?
77
16:13
Bertl
the sensor on the alpha has 4096x3072 sensel
78
16:13
Bertl
we can assume that the input image can be scaled to fit the size
79
16:14
Bertl
but, only certain information will hit the sensel, i.e. from the pixel at (0,0) only the red channel
80
16:14
Bertl
from the pixel at (0,1) only the green channel
81
16:14
Marco74
so my input image should be 2048x1536, because one rgb pixel can be used for two rows and two columns
82
16:14
Marco74
s/should/could/
83
16:14
Bertl
I wouldn't do that because the spacial information is different
84
16:15
Bertl
here is an example:
85
16:15
Marco74
ah, ok
86
16:15
Bertl
consider a pattern of white and black 1pixel wide bars
87
16:15
Bertl
assuming they start with white, then sensor will see some kind of yellow
88
16:16
Bertl
as there is no blue (black bars) and only half of the green lit
89
16:16
Marco74
but full red
90
16:16
Bertl
yep, this is not immediately obvious to the tester, so it is probably better to take a larger image and do the spacial sampling
91
16:17
Marco74
interesting aspect ... :)
92
16:18
Bertl
if you want to cover all cases, add a switch to change the image processing from bayer pattern (R/G/G/B) to gray (just brightness)
93
16:18
Bertl
which would be what we would get from a monochrome cmv12k
94
16:23
Marco74
ok.
95
17:48
jucar
joined the channel
96
18:30
jucar
left the channel
97
20:35
se6astian
left the channel
98
23:43
FergusL
left the channel