Current Server Time: 11:10 (Central Europe)

#apertus IRC Channel Logs

2019/02/20

Timezone: UTC


23:04
ASHU
joined the channel
23:05
ASHU
left the channel
23:39
futarisIRCcloud
joined the channel
06:44
se6astian|away
changed nick to: se6astian
06:54
BAndiT1983|away
changed nick to: BAndiT1983
06:55
se6astian
good day
07:39
Bertl_zZ
changed nick to: Bertl
07:39
Bertl
morning folks!
07:44
futarisIRCcloud
left the channel
07:45
sebix
joined the channel
09:40
mrohit[m]
Morning Bertl , I have a doubt regarding RAW:
09:40
mrohit[m]
If RAW12 is a binary file, then why am I not able to read it using a bitset container format?
09:41
se6astian
you can look at the raw12 file in a hex editor if you want to see "inside"
09:43
BAndiT1983
mrohit[m], what do you mean?
09:46
mrohit[m]
BAndiT1983: I mean that if the RAW12 file consists of binary numbers (i.e only 0's and 1's) then we can load the file into a bitset container and thus extract any number of bits at a time from it to perform operations.
09:46
BAndiT1983
why do you need a bitset container?
09:47
danieel
isnt bitset rather a random access abstraction?
09:47
vandy2000
joined the channel
09:47
danieel
seems like a hugely inefficient way to do anything useful
09:48
BAndiT1983
i would just grab every 3 bytes and extract the 2 sensels by shifting and concatenating
09:49
mrohit[m]
Yes BAndiT1983 , I was trying to skip the part of shifting and concatenating by extracting only 12 bits at a time
09:50
BAndiT1983
it won't work
09:50
BAndiT1983
or do you know a 12bit native type?
09:50
BAndiT1983
i would use uint16_t for a sensel
09:51
BAndiT1983
you can't go as simple as shifting and concatenating
09:53
mrohit[m]
Okay, was just trying to look for a new approach as I thought it would reduce the load of grabbing an extra half byte and discarding everytime
09:53
BAndiT1983
discarding what?
09:54
mrohit[m]
Not exactly discarding, but rather shifting and concatenating
09:54
BAndiT1983
i don't understand the problem there, it's the usual way to handle such data streams
09:55
danieel
what do you think that bitset class does?
09:56
BAndiT1983
off for a while, will be back later, but will also check the logs from time to time
09:56
BAndiT1983
changed nick to: BAndiT1983|away
09:57
mrohit[m]
danieel: It loads the data in binary form, but rather than alloting a whole char for 0 or 1 it just uses one bit to store
09:57
mrohit[m]
danieel: Please correct me if I am wrong
09:58
danieel
but the raw data when load by read() / fread() is same
09:59
mrohit[m]
Sorry, couldn't understand what do you mean by the data is same?
10:00
danieel
it just adds an abstraction to address individual bits
10:00
danieel
a file blob when loaded into memory is taking up the same space as on drive
10:01
mrohit[m]
ohh...I get it now
10:01
danieel
the bitset is a random access tool
10:01
danieel
if you still want a variable sized bitfield loading, then look into some bitbuff implementations, eg. in ffmpeg or mplayer
10:02
danieel
these do provide only streamed access, and you can read each time a given (and different) number of bits
10:02
danieel
but you cant skip in the stream to random location, it is just a bitstream reader
10:03
vandy2000
left the channel
10:04
mrohit[m]
ok, so I guess bitbuff is what I was looking for
10:06
mrohit[m]
So can we load 12 bits at a time using bitbuff or is it still inefiicient than to load 3 bytes and then splitting them
10:07
danieel
it should be fairly efficient, most of the codecs use them to unpack the variable length encoding
10:07
danieel
there is an overhead for the calling.. but can be inlined.
10:08
danieel
the reason why you do not need this is that the raw12 is a fixed field format, and you can unpack it with a non-parametrized, hardcoded shifts and loads
10:11
mrohit[m]
yes, that makes more sense to use shifts and loads
10:13
mrohit[m]
Thanks danieel
10:16
danieel
i can tell you my approach - for a semi optimal code - process each line individually, and within the line split the processing into a bulk (block type) and the corner case
10:17
danieel
the block part can load the common multiple of input * register size, so with 12 bits, it is the best to load 12 bytes = 3x4 bytes on input, and unpack these to 2x4 pixel values
10:18
danieel
then the corner case at end of line has to ensure to not read past the input buffer boundary, and not write past the output boundary (so it processes single pixels, not a whole block)
10:28
mrohit[m]
Here unpacking to 2x4 pixel values means shifting and concatenating.. right?
10:30
danieel
yes, so from u32 a,b,c, you make a u16 pixel[8]
10:31
danieel
what you need is the a,b,c to be loaded, and then just a u16 dst* that you use as *dst++ = (some shift combo)
10:33
danieel
the abc is read from *src++ that is u32*
10:33
danieel
further simplification - if the image size is fixed and result using only the bulk blocks, you can forget the implementation of the unused corner case :)
10:36
mrohit[m]
What exactly do you mean by *dst++?
10:37
Cyna_
left the channel
10:38
mrohit[m]
You mean the 12 bit data to be seperated is to be stored in *dst right?
10:39
danieel
the in memory buffer of unpacked pixels, which you can later work on
10:39
danieel
(if your algo is unable to work in a streamed way on input data)
10:42
mrohit[m]
Ok. I get it, will try to implement it this way by evening. Will let you know I have any further doubts
10:46
RexOrCine
changed nick to: RexOrCine|away
13:29
danieel
left the channel
13:30
danieel
joined the channel
14:55
ASHU
joined the channel
14:56
ASHU
Hello , everyone !!!
14:58
ASHU
this is about task T872 , Do we need to print 5*5 tile for each R,G,G,B channel or for rgb CFA ?
14:59
ASHU
can you please elaborate ?
14:59
se6astian
hi ASHU
14:59
se6astian
please clarify you question
14:59
se6astian
as the RGGB is the RGB CFA
15:03
ASHU
My question is whether we are suppose to print 5*5 pixel intensity for each extracted channel
15:03
ASHU
or for the whole image we get after debayering ?
15:05
BAndiT1983|away
changed nick to: BAndiT1983
15:06
BAndiT1983
mrohit[m], the sizes are known, 4096x3072, don't see any need for streaming
15:06
BAndiT1983
also the buffers are processed as whole usually, also no streaming there
15:08
BAndiT1983
ASHU, the task description says following -> Output the intensity values of the first 5x5 pixels (square tile) R, G, G, B channels.
15:11
Dev_
joined the channel
15:12
Dev_
Hey Ashu and Bandit1983
15:13
BAndiT1983
hi Dev_
15:15
Dev_
Ashu , i also had the same doubt , I guess he meant , we need to print a small window of 5 * 5 of each grayscale which we have extracted
15:16
mrohit[m]
BAndiT1983: actually my question was in line for finding another approach to load the 12 bits of a pixel (which I thought possibly could be done if I had access to the whole data inside the raw12 file in binary form, for which I looked for bitset as a container of binary values), but as danieel explained why would that be inefficient in case of RAW12, I think using bitset is not a good idea
15:16
BAndiT1983
you could contact Supragy to ask about the details for the 5x5 pixels
15:16
ASHU
Hi dev _
15:17
BAndiT1983
i don't know of any other efficient approach besides shifting and concatenating, additional performance can be achieved by using openmp pragmas possibly
15:18
ASHU
okay thanks BAndiT1983 and Dev_ , got it .
15:18
BAndiT1983
as we know the sizes, we can predict the workflow for the buffer
15:20
ASHU
left the channel
15:20
mrohit[m]
yes, in this case going with shifting and concatenating looks simple and efficient.
15:20
Dev_
left the channel
15:23
mrohit[m]
Thanks BAndiT1983
15:25
BAndiT1983
no problem
15:58
sebix
left the channel
16:01
adnan
joined the channel
16:01
adnan
left the channel
16:16
Cyna_
joined the channel
17:11
niemand
joined the channel
17:11
niemand
left the channel
17:11
niemand
joined the channel
18:17
Cyna_
left the channel
18:17
cryteno[m]
joined the channel
19:24
intrac
left the channel
19:28
intrac
joined the channel
21:08
danieel
left the channel
21:10
niemand
left the channel
21:13
danieel
joined the channel
21:48
se6astian
changed nick to: se6astian|away
22:04
BAndiT1983
changed nick to: BAndiT1983|away
22:19
futarisIRCcloud
joined the channel
22:33
BAndiT1983|away
changed nick to: BAndiT1983
22:45
Bertl
off to bed now ... have a good one everyone!
22:45
Bertl
changed nick to: Bertl_zZ