Recent comments

Reply to: PURE RAW. Is it possible access bayer-pattern cell before demosaicing ?   12 years 9 months ago

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)
Reply to: PURE RAW. Is it possible access bayer-pattern cell before demosaicing ?   12 years 9 months ago

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.

Reply to: PURE RAW. Is it possible access bayer-pattern cell before demosaicing ?   12 years 9 months ago

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

Reply to: PURE RAW. Is it possible access bayer-pattern cell before demosaicing ?   12 years 9 months ago

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

Reply to: PURE RAW. Is it possible access bayer-pattern cell before demosaicing ?   12 years 9 months ago

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

Reply to: PURE RAW. Is it possible access bayer-pattern cell before demosaicing ?   12 years 9 months ago

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

Reply to: PURE RAW. Is it possible access bayer-pattern cell before demosaicing ?   12 years 9 months ago

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

Reply to: PURE RAW. Is it possible access bayer-pattern cell before demosaicing ?   12 years 9 months ago

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

.........

Reply to: PURE RAW. Is it possible access bayer-pattern cell before demosaicing ?   12 years 9 months ago

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

Reply to: PURE RAW. Is it possible access bayer-pattern cell before demosaicing ?   12 years 9 months ago

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?

Reply to: PURE RAW. Is it possible access bayer-pattern cell before demosaicing ?   12 years 9 months ago

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.

Reply to: PURE RAW. Is it possible access bayer-pattern cell before demosaicing ?   12 years 9 months ago

I found the answer,

Libraw v 0.14.5

file-> libraw_cxx.cpp

lines 810 to 862 //Calculate channel maximum..

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

Reply to: Getting OpenMP to compile on OS X   12 years 9 months ago

Unfortunately, OpenMP under MacOS 10.6 have problems with multithreaded apps.
So, we disabled openmp under MacOS X entirely.

If you want to use it, you may uncomment openmp lines in Makefile.dist and use make -f Makefile.dist to compile LibRaw.

Reply to: Use of uninitialized variable in dcraw_common.cpp   12 years 10 months ago

Fixed in 0.14.5 (released today)

Thanks for the report!

Reply to: LibRaw License   12 years 10 months ago

You may choose LGPL or CDDL license and just use LibRaw in your (closed source) app. Most users (developers) do so. You don't need to notify us about your app.

The LibRaw own licensing is used only for compatibility with LibRaw-pre-0.9 (commercial version).

Reply to: Multithreaded?   12 years 10 months ago

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

Reply to: CrossCompiling for Android   12 years 10 months ago

Ok, thanks.

Reply to: CrossCompiling for Android   12 years 10 months ago

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)

Reply to: CrossCompiling for Android   12 years 10 months ago

Yes, added a simple missing function of swab did made it compile.
However, when I try to use the lib on android, I keep getting link errors, since it still searches for libraw.so.5 internally. Android doesn't support the .5 extension, it needs to have a .so file. So this one doesn't load.

Is there an option to just output a .so file instead of having versioned ones?

Reply to: Use of uninitialized variable in dcraw_common.cpp   12 years 10 months ago

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

Reply to: CrossCompiling for Android   12 years 10 months ago

I know nothing about android.

But I googled good replacement for swab, using __arch_swab16: http://www.crystax.net/trac/ndk/attachment/ticket/32/swab.patch

Reply to: CrossCompiling for Android   12 years 10 months ago

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?

Reply to: Shared library   12 years 10 months ago

Any chance someone can point to a guide to compile this for Android?

Reply to: LibRaw crashes on malformed JPEG file   12 years 10 months ago

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.

Reply to: API Overview (C++)   13 years 1 week ago

Thanks for report!

The code is surely incomplete, because call to postprocessing is missing. It is added now.

For real-life example take a look into samples/ folder in LibRaw distribution.

Pages