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)
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.
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 !
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
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.
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.
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
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).
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)
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?
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
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.
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) 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
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
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[]
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...
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:
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
.........
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....
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?
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.
I found the answer,
Libraw v 0.14.5
file-> libraw_cxx.cpp
lines 810 to 862 //Calculate channel maximum..
Thanks.... for me jejeje :))))
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.
Fixed in 0.14.5 (released today)
Thanks for the report!
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).
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
Ok, thanks.
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)
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?
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
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
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?
Any chance someone can point to a guide to compile this for Android?
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.
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