PURE RAW. Is it possible access bayer-pattern cell before demosaicing ?

Submitted by juanmafont on

Is it possible to access the cells from bayer-pattern(like R,G1,B and G2) before demosaicing ?

Thanks a lot of

Forums: 

Autoreply

Submitted by juanmafont on

I found the answer,

Libraw v 0.14.5

file-> libraw_cxx.cpp

lines 810 to 862 //Calculate channel maximum..

Thanks.... for me jejeje :))))

Yes, this is right piece of

Submitted by lexa on

Yes, this is right piece of code to look to.
Do not forget to check decoder_flags to ensure image format.

Also, please note that black level is not subtracted from rawdata.raw_image[] values.

-- Alex Tutubalin @LibRaw LLC

Thank you, lexa, if I had any

Submitted by juanmafont on

Thank you, lexa, if I had any doubt I would put here.

By the way, speaking about doubts...jejeje ....

Should not had and example, with code if possible, where it build a linearization table like using into DNG specification?

Please explain you problem

Submitted by lexa on

Please explain you problem in more detail.

Generally speaking, any LUT conversion of raw data is very simple
rawdata.raw_image[idx] = LUT[rawdata.raw_image[idx]]

But the LUT values itself will depend on lens flare, themperature and so on....

-- Alex Tutubalin @LibRaw LLC

The problem: I wanna merge

Submitted by juanmafont on

The problem:

I wanna merge some raw files, but output is linear, with 16 bits (that's the most you can get into the DNG) achieving a useful dynamic range up to about 13 stop, so from the shadows you got posterize (in this article explains: http://www.guillermoluijk.com/article/superhdr/index.htm).

So would be good to investigate whether the DNG support encoding data in a nonlinear way. If this is possible, then these 16-bit DNG nonlinear will has a big..big.big dynamic range, like 20 stops or more, which neither exists in the real world ).

I thing that a linearization table (LUT) will be the solution to this.

I wanna "merge" raw files, before demosaicing for obtain the lowest noise.

Thanks...

About datas R,G1,B,G2 before demosaising

Submitted by juanmafont on

I want "see" data-cell before demosaicing, so some values into cells must be 0. Later demosaicing will fill this values (interpolation).

This is my code:

#define LR_IMGDT this->rawProcessor->imgdata
#define LR_SIZE  LR_IMGDT.sizes
#define LR_RDATA LR_IMGDT.rawdata
 
// ...create this->rawProcessor and open file (type .CR2)
// ...unpack()
 
 
unsigned int rowcol=10;
ushort pxVal;
cout << "Showing " << rowcol << " firts columns and rows of raw image."<<endl;
 
for (unsigned int row = 0; row<rowcol; row++) // Later to LR_SIZE.raw_height
    {
 
     unsigned int colors[4];
     for (unsigned int xx=0;xx<4;xx++)
          colors[xx] = this->rawProcessor->COLOR(row,xx);
 
     unsigned int pos1= row*LR_SIZE.raw_width;
 
     for (unsigned int col = 0; col<rowcol; col++) // later to LR_SIZE.raw_width
      {
      unsigned int cc = colors[col&3];
      pxVal= LR_RDATA.raw_image[pos1+col];
 
      cout << "col "<<col<<" row "<<row<<" color "<<cc<<" value: " << pxVal<<endl;
      }

But values of R,G1,B and G2 never are 0, why?

Output shunk example:

......

col 98 row 98 color 0 value: 426
col 99 row 98 color 1 value: 549
col 0 row 99 color 3 value: 255
col 1 row 99 color 2 value: 255
col 2 row 99 color 3 value: 255
col 3 row 99 color 2 value: 260
col 4 row 99 color 3 value: 256
col 5 row 99 color 2 value: 250
col 6 row 99 color 3 value: 250
col 7 row 99 color 2 value: 252
col 8 row 99 color 3 value: 244
col 9 row 99 color 2 value: 262

.........

raw_image[] array contains

Submitted by lexa on

raw_image[] array contains one value per pixel. The bayer pattern is the same: each pixel have one value (and one color).

So, no extra zeroes in raw_image[]

-- Alex Tutubalin @LibRaw LLC

Hi, I'm not so clear on this

Submitted by Jos (not verified) on

Hi,

I'm not so clear on this neither .. If you could spell out a bit.

I understand raw_image[] is stored such that there are no unnecessary zeroes.
I.e. for a normal RGBG it would store one pixel and identify the color. How to know which color ? What's the size of this raw_image ? Are margins already subtracted or still to be subtracted ?
I hope blacklevel is not yet extracted nor scaling is done ?

And what about raw2image() ? I understand it to transform to the "normal" format with zeroes for the yet-to-be-interpolated colors ? I assume COLOR(r,c) gives the color at a location ? What's the size of this image ? Are margins ... ? And again I hope blacklevel is not subtracted nor scaling is done ?

I want to use libraw "just" for decoding. All processing is mine.

Jos

1) Yes, COLOR(r,c) gives you

Submitted by lexa on

1) Yes, COLOR(r,c) gives you the color of (bayer) pixels. All other components in this location are zeroes.

2) The raw2image() call prepares imgdata->image[][4] structure with 4-components for each pixels (only one is non-zero). Please note, that two different greens are handled as different colors, because some cameras (e.g. Olympus E-520) have different color filters on two green channels.

Please note, that imgdata->image[] does not contains "masked pixels" (black frame without image around image data), so sizes of image[][4] is imgdata.sizes.iheight and imgdata.sizes.iwidth

-- Alex Tutubalin @LibRaw LLC

Thanks Alex. Its about what I

Submitted by Jos (not verified) on

Thanks Alex.

Its about what I understood after some peeking around in the code.

So I guess that for the purpose of an own processor the sequence should be :
open_file->unpack->raw2image
and from here I can do my own processing.

Can I have some more questions :
- I saw that there is an raw2image_ex as well ?
- In above process , what geometrical transformations are done on fuji types, non square or flipped image ?
- Concerning the blacklevel , can I assume it is black+cblack[color] (i.e. are they always properly initialized ?)
- Concerning the whitelevel, can I assume it is maximum ? (and blacklevel nor whitelevel is processed in any respect in the pipe I showed above, again I want to control ...)

By the way, thanks for your efforts making and keeping a library of dcraw !

Jo

1) raw2image_ex do several

Submitted by lexa on

1) raw2image_ex do several operations in one pass: creates image[] structure, subtracts black and re-calculates channel maximum and do geometrical transformation for Fuji.

2) black level is black+cblack

3) White levels may be different for different channels (e.g. many Nikons)

-- Alex Tutubalin @LibRaw LLC

For the whitelevel can I then

Submitted by Jos (not verified) on

For the whitelevel can I then assume that the
whitelevel

 = maximum + channel_maximum[c],
i.e. that the maximum=0 when channel_maximum[c]!=0 and vice versa ?
 
Jos

No, channel maximum is

Submitted by lexa on

No, channel maximum is absolute value, you dont need to add maximum.

-- Alex Tutubalin @LibRaw LLC

Hi Alex, Sorry for the many

Submitted by Jos (not verified) on

Hi Alex,

Sorry for the many questions :)

Is there for this imgdata.image some safe way of "taking" the image without copying it while you keep doing the memory management correct. Let me explain with pseudo code :

LibRaw* LibRawProcessor = new LibRaw;
LibRawProcessor->open_file(...);
LibRawProcessor->unpack();
LibRawProcessor->raw2image();
ushort (*MyImage)[4] = Take(LibRawProcessor->imgdata.image);
delete LibRawProcessor; // You should be aware not "freeing" or "deleting" imgdata.image.

You don't need to delete

Submitted by lexa on

You don't need to delete LibRawProcessor (if you plan to process another image).

There are two calls:
LibRaw::free_image() - frees image[] array. You may call raw2image() again and you'll get another image[] allocated.

LibRaw::recycle() - frees all allocated data for file (it will be called automatically on next open_file())

-- Alex Tutubalin @LibRaw LLC

Alex, Thanks already so far.

Submitted by Jos (not verified) on

Alex,

Thanks already so far. But there are reasons I *want* to delete LibRaw (partly architectural, partly to get rid of as many unnecessary resources as possible).

So I would like to understand if I can get somehow the image data without copying (i.e. take over the pointer ownership) ?

Or , alternatively, is there a call that frees all allocated data, except for the image ?

Jos

Ok, thanks, Lexa No

Submitted by juanmafont on

Ok, thanks, Lexa

No zeroes.. but why my cuestion ? Because, long ago, I was debugging the raw-demosaicing to tiff process into dcraw, and I could see these zeroes into memory, but of course, these zeroes are not in the raw file.

Yes: 1) the imgdata.image[]

Submitted by lexa on

Yes:

1) the imgdata.image[] (constructed by raw2image() call) have 4 components per pixel and only one non-zero component

2) the rawdata.raw_image have only one non-zero component per pixel

-- Alex Tutubalin @LibRaw LLC