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

This error is also there when I just use ndk-build on only the dcraw.c file.
Is android missing a library where this 'swab' function comes from?

Thanks for report

This issue is fixed now. The fix will be available in LibRaw 0.14.4. Hope, we'll release this version today.

The code doesn't work. I get an null pointer exception inside the for loop for iProcessor.imgdata.image.

I'm using libraw 0.14.2 with MSVC10. My sample file is Canon 1DSM3. You can find here

http://www.rawsamples.ch/raws/canon/1dsm3/RAW_CANON_1DSM3.CR2

Christian