apertus° IRC logs

2019/02/20

Timezone: UTC

00:04

ASHU

joined the channel

00:05

ASHU

left the channel

00:39

futarisIRCcloud

joined the channel

07:44

se6astian|away

changed nick to: se6astian

07:54

BAndiT1983|away

changed nick to: BAndiT1983

07:55

se6astian

good day

08:39

Bertl_zZ

changed nick to: Bertl

08:39

Bertl

morning folks!

08:44

futarisIRCcloud

left the channel

08:45

sebix

joined the channel

10:40

mrohit[m]

Morning Bertl , I have a doubt regarding RAW:

10:40

mrohit[m]

If RAW12 is a binary file, then why am I not able to read it using a bitset container format?

10:41

se6astian

you can look at the raw12 file in a hex editor if you want to see "inside"

10:43

BAndiT1983

mrohit[m], what do you mean?

10: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.

10:46

BAndiT1983

why do you need a bitset container?

10:47

danieel

isnt bitset rather a random access abstraction?

10:47

vandy2000

joined the channel

10:47

danieel

seems like a hugely inefficient way to do anything useful

10:48

BAndiT1983

i would just grab every 3 bytes and extract the 2 sensels by shifting and concatenating

10:49

mrohit[m]

Yes BAndiT1983 , I was trying to skip the part of shifting and concatenating by extracting only 12 bits at a time

10:50

BAndiT1983

it won't work

10:50

BAndiT1983

or do you know a 12bit native type?

10:50

BAndiT1983

i would use uint16_t for a sensel

10:51

BAndiT1983

you can't go as simple as shifting and concatenating

10: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

10:53

BAndiT1983

discarding what?

10:54

mrohit[m]

Not exactly discarding, but rather shifting and concatenating

10:54

BAndiT1983

i don't understand the problem there, it's the usual way to handle such data streams

10:55

danieel

what do you think that bitset class does?

10:56

BAndiT1983

off for a while, will be back later, but will also check the logs from time to time

10:56

BAndiT1983

changed nick to: BAndiT1983|away

10: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

10:57

mrohit[m]

danieel: Please correct me if I am wrong

10:58

danieel

but the raw data when load by read() / fread() is same

10:59

mrohit[m]

Sorry, couldn't understand what do you mean by the data is same?

11:00

danieel

it just adds an abstraction to address individual bits

11:00

danieel

a file blob when loaded into memory is taking up the same space as on drive

11:01

mrohit[m]

ohh...I get it now

11:01

danieel

the bitset is a random access tool

11:01

danieel

if you still want a variable sized bitfield loading, then look into some bitbuff implementations, eg. in ffmpeg or mplayer

11:02

danieel

these do provide only streamed access, and you can read each time a given (and different) number of bits

11:02

danieel

but you cant skip in the stream to random location, it is just a bitstream reader

11:03

vandy2000

left the channel

11:04

mrohit[m]

ok, so I guess bitbuff is what I was looking for

11: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

11:07

danieel

it should be fairly efficient, most of the codecs use them to unpack the variable length encoding

11:07

danieel

there is an overhead for the calling.. but can be inlined.

11: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

11:11

mrohit[m]

yes, that makes more sense to use shifts and loads

11:13

mrohit[m]

Thanks danieel

11: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

11: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

11: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)

11:28

mrohit[m]

Here unpacking to 2x4 pixel values means shifting and concatenating.. right?

11:30

danieel

yes, so from u32 a,b,c, you make a u16 pixel[8]

11: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)

11:33

danieel

the abc is read from *src++ that is u32*

11: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 :)

11:36

mrohit[m]

What exactly do you mean by *dst++?

11:37

Cyna_

left the channel

11:38

mrohit[m]

You mean the 12 bit data to be seperated is to be stored in *dst right?

11:39

danieel

the in memory buffer of unpacked pixels, which you can later work on

11:39

danieel

(if your algo is unable to work in a streamed way on input data)

11: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

11:46

RexOrCine

changed nick to: RexOrCine|away

14:29

danieel

left the channel

14:30

danieel

joined the channel

15:55

ASHU

joined the channel

15:56

ASHU

Hello , everyone !!!

15: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 ?

15:59

ASHU

can you please elaborate ?

15:59

se6astian

hi ASHU

15:59

se6astian

please clarify you question

15:59

se6astian

as the RGGB is the RGB CFA

16:03

ASHU

My question is whether we are suppose to print 5*5 pixel intensity for each extracted channel

16:03

ASHU

or for the whole image we get after debayering ?

16:05

BAndiT1983|away

changed nick to: BAndiT1983

16:06

BAndiT1983

mrohit[m], the sizes are known, 4096x3072, don't see any need for streaming

16:06

BAndiT1983

also the buffers are processed as whole usually, also no streaming there

16:08

BAndiT1983

ASHU, the task description says following -> Output the intensity values of the first 5x5 pixels (square tile) R, G, G, B channels.

16:11

Dev_

joined the channel

16:12

Dev_

Hey Ashu and Bandit1983

16:13

BAndiT1983

hi Dev_

16: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

16: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

16:16

BAndiT1983

you could contact Supragy to ask about the details for the 5x5 pixels

16:16

ASHU

Hi dev _

16: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

16:18

ASHU

okay thanks BAndiT1983 and Dev_ , got it .

16:18

BAndiT1983

as we know the sizes, we can predict the workflow for the buffer

16:20

ASHU

left the channel

16:20

mrohit[m]

yes, in this case going with shifting and concatenating looks simple and efficient.