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

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())

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.

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

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[]

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

.........

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?

I found the answer,

Libraw v 0.14.5

file-> libraw_cxx.cpp

lines 810 to 862 //Calculate channel maximum..

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

Fixed in 0.14.5 (released today)

Thanks for the report!

unpack() is not multithreaded because
1) it is not possible for Lossless JPEG format (Canon CR2 and so), you need to read input byte-to-byte
2) for simple formatts (e.g. Fuji RAWs) the code is disk limited already.

Postprocessing steps are partially multithreaded via OpenMP

Versioning is critical for normal use of libraw because different versions are binary incompatible, so app using .so.4 should not link with .so.5 and vice versa.

You may consider static linking (and ./configure --static)

Thanks, it looks like bug. Unfortunately, I've now samples of this format, so this piece of code is not covered by tests.

To be fixed in 0.14.5