Unfortunately, KDE/digiKam has moved to git repsitory, so I'm unable to find right place to point to.
Try to download entire digiKam source distribution (e.g. from here: http://www.digikam.org/drupal/download) and find .h file with extensions list (rawfiles.h or so).
Thanks for reply.
I've need this list to filter files that could be opened by libraw in my application.
And official raw camera use official extension (cr2,crw, ...).
There is no such list in LibRaw distribution, because LibRaw does not rely on file extension.
You may use list from digiKam distribution, although it may be incomplete.
For example, some cameraw write .tif or .tiff files, adding this extension to list is not good idea in general case.
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.
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 ?
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 can start with list from digiKam sources.
Unfortunately, KDE/digiKam has moved to git repsitory, so I'm unable to find right place to point to.
Try to download entire digiKam source distribution (e.g. from here: http://www.digikam.org/drupal/download) and find .h file with extensions list (rawfiles.h or so).
Thanks for reply.
I've need this list to filter files that could be opened by libraw in my application.
And official raw camera use official extension (cr2,crw, ...).
LibRaw does not contains complete color library.
You may consider use of lcms2 and try to set Lab as output profile.
There is no such list in LibRaw distribution, because LibRaw does not rely on file extension.
You may use list from digiKam distribution, although it may be incomplete.
For example, some cameraw write .tif or .tiff files, adding this extension to list is not good idea in general case.
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
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.
No, there are no such call.
No, channel maximum is absolute value, you dont need to add maximum.
For the whitelevel can I then assume that the
whitelevel
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
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())
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:
#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
.........
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!
Pages