apertus° IRC 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.