From what you said, it seems like the "white balance" is necessary before normal demosaic. If a user want to supply her/his own white balance factors, it can still be done through "user_mul[i]", correct?
Also, when I use "output_color = 0" and "half_size = 1" together (regardless other parameter), the image seems to look strange. Can you take a look at it?
I would like to use the RAW data without calling "dcraw_mem_image()"; however, there is still a need for demosaic. Currently, I have to use "dcraw_mem_image()" with the parameters listed before to get it as close as possible.
If there is a function that I can call to get the image data that only goes through demosaic step (with no other adjustment), that would be great!
"Unaltered image" is something close to what I am interested. Given the parameters that I enlisted, do they look reasonable to get the "Unaltered image"?
Also, only if you have time, would you mind replicating my test by adding "half_size = 1" (see below) and see if the converted image looks correct?
I understand there are several steps if dcraw_process () is called. Since I am interested in getting the image data that is very close to the "demosaic RAW", I manually set some parameter to "avoid" unnecessary processing on the RGB code values. For example, I did the following:
I did not understand exactly what you want
Standard raw processing sequence is (for decoded/linearized data) in dcraw_process is
- black subtraction
- white balance
- demosaic
- data scaling to use full range
- conversion to output color space
Than, on output
- brightness correction
- gamma curve
What stages do you need and what is not?
BTW, besides demosaic, all other steps are trivial and very easy to implement.
I meant the "raw image data" that only has demosaic process. In this case, I may still need "dcraw_process", right? if it is, then when I use "output_color = 0" and "half_size = 1", the output seems like missing a channel.
To get fully unprocessed raw data you may
1) Access imgdata.rawimage.raw_data array which stores raw values read from sensor as is
2) set params.half_size=1 and call raw2image() after unpack (instead of dcraw_process).
raw2image will arrange raw_data to imgdata.image[][4] array
Nice and thanks! I think the only issue for having this be a general solution (and not just having me rework the source a touch - fine for me, but...) is that scale_colors is protected rather than public.
unpack() is affected by camera_wb only in some (very rare) cases (I can not remember the details, it affects very small set of cameras, may be old Kodaks and/or foveon /old ones, before Sigma Merill).
For modern cameras unpack is not affected by color setting (but default for 'use_camera_matrix' for some cameras depends on wb settings)
subtract_black and scale_colors works with image[][4] array, so you need to call raw2image() before subtract_black().
Also, there is single call for raw2image and subtract_black:
int LibRaw::raw2image_ex(int do_subtract_black);
So:
open_file()
unpack();
raw2image_ex(1);
scale_colors();
will put black-subtracted and white-balanced image in image[][4]
Thank you for all the details! I've been using:
RawProcessor.raw2image()
CFA data then from RawProcessor.imgdata.image[r*RAW_S.iwidth+c][RawProcessor.FC(r,c)]
in my code since ... well, a long time ago... to extract the unprocessed data for Bayer-matrix data. (The idea being, I do my own hot pixel / bad pixel mapping -- this is astrophotography work). When non-Bayer, I run:
RawProcessor.dcraw_process();
red data then from RawProcessor.imgdata.image[r*RAW_S.iwidth+c][0]
green from[1], blue from [2]
I poked around in the debugger and docs last night but still couldn't see the effect of use_camera_wb. The docs (http://www.libraw.org/docs/API-notes.html#imgdata_params) say that unpack() is affected by this but no matter what the setting, the output of raw2image() seems the same.
For Bayer matrices, is there a spot where I can pull off the still-CFA encoded data but having run say black level and color scaling? Or, should I just:
unpack()
subtract_black()
scale_colors()
raw2image()
and find CFA data then from RawProcessor.imgdata.image[r*RAW_S.iwidth+c][RawProcessor.FC(r,c)]
'real picture' is more complex than single raw_image array.
For non-bayer images, raw_image is NULL after unpack(), but color3_image or color4_image is not null (color4 image's 4'th component usually zero, but for 4-shot files from Leaf or Pentax it is not zero).
For floating point (DNGs) float_image, float3_image, float4_image pointers are not zero (bayer, 3-component, 4-component data).
Please note, that row pitch may be greater than raw_with*(element size). real pitch is stored in imgdata.rawdata.sizes.raw_pitch and it is always in bytes (divide by 2 for raw_image to get items, divide by 16 for float4_image, etc).
Also, rawdata.*image arrays contains 'black frame' pixels, so use rawdata.sizes: raw_width/height, top_/left_margin and width/height to access image part containing real image data.
the raw2image() call handles all specifics, so look into source for details :)
Followup:
dcraw_make_mem_image() will skip 4'th component from image[][4] array, so if you need to access full data for de-bayer you need to work with either raw_image or image[][4]
no_interpolation=1 will skip bayer interpolation pass, but all other processing to be done (data scaling, white balance, convert to output color space /useless and even wrong step for not interpolated data).
If you want to do your own data processing and use LibRaw only as data decoder (the way we use it in, for example, FastRawViewer) it may be better to access bayer data directly:
rawdata.raw_image contains pointer to bayer data array 'as decoded' (so, no black level subtracted, but unpacked and linearization curve applied).
If you prefer to use imgdata.image[][4] for demosaic you may use
raw2image() to copy raw_image in image[][4] components
and
subtract_black() to subtract black level
I folllowed you instruction, and it works. I have LibRaw-0.17.2\lib\libraw.a
(996KB) and also have several .exe files at LibRaw-0.17.2\bin folder.
When I executed
simple_dcraw.exe -e myfile.raw
I could get myfile.thumb.jpg
So it works properly now. Thank you very much. As you indicated, I think the mistake I did was that I did not put needed compile options like -DLIBRAW_NODLL
-DLIBRAW_NOTHREADS.
1) I've Installed Qt-5.6.2-mingw-492
2) Run Qt/Mingw prompt (Qt 5.6 desktop from Start menu), than bash in this window
3) cd /path/to/LibRaw-0.17.2
4) mingw-32-make -f Makefile.mingw (no need to run ./configure, but it does not change Makefile.mingw, so it does not matter).
several bin/*.exe created after that, so both library and samples compiles OK.
The proper command line for samples creation (from Makefile.mingw):
Thank you for the response.
You may qt-opensource-windows-x86-mingw492-5.6.2.exe. It has mingw32-make.exe.
I installed it and installed MSYS 1.0.11 where I referenced mingw directory.
After setting the paths to mingw and MSYS, in windows 7 command prompt I compiled libraw by
sh ./configure
mingw32-make -f makefile.mingw
I could get libraw.a (994kb), but not sure whether it is properly compiled or
not.
Because the line
#include "libraw/libraw.h"
in simple_dcraw.cpp suggests that it would be better to put simple_dcraw.cpp to
the parent of samples (../samples), I copied simple_dcraw.cpp to the parent of
samples(../sample) and executed
g++ simple_dcraw.cpp -o simple.exe -Ilibraw -Llib -lraw
at there(../samples). So I think "-Ilibraw -Llib -lraw" seems OK.
I've tried to install Qt+mingw package (Qt 5.8.0-mingw), it installed, but no make(.exe) in this package.
MSYS/mingw setup looks made for someone who is already 'in context' and know what to do to install it.
Your error messages looks like no libraw library is linked. This may be because you've specified wrong library or library path:
g++ simple_dcraw.cpp -o simple.exe -Ilibraw -Llib -lraw
I assume you're already in samples folder, so right path is -L../lib, not -Llib
To use .pro files you may need to edit .pro files to specify (or disable) jpeg library and rawspeed library
Yes, you can set custom WB via user_mul. But for wrong WB demosaic results may be not good as expected.
dcraw_emu -o 0 -h works for me
(-o 0 translates to output_color=0, -h translates to half_size-1)
Hi Alex,
From what you said, it seems like the "white balance" is necessary before normal demosaic. If a user want to supply her/his own white balance factors, it can still be done through "user_mul[i]", correct?
Also, when I use "output_color = 0" and "half_size = 1" together (regardless other parameter), the image seems to look strange. Can you take a look at it?
Thanks so much and have a nice day!
Normal demosaic (not 'half' or 'linear interpolation') is useless without white balance first.
Hi Alex,
I would like to use the RAW data without calling "dcraw_mem_image()"; however, there is still a need for demosaic. Currently, I have to use "dcraw_mem_image()" with the parameters listed before to get it as close as possible.
If there is a function that I can call to get the image data that only goes through demosaic step (with no other adjustment), that would be great!
Thanks,
I'm still cannot understand what kind of data you need. You wrote 'close to', but could you please describe what you really need?
What is 'converted image'? imgdata.image array, or result of dcraw_mem_image() call?
Hi Alex,
"Unaltered image" is something close to what I am interested. Given the parameters that I enlisted, do they look reasonable to get the "Unaltered image"?
Also, only if you have time, would you mind replicating my test by adding "half_size = 1" (see below) and see if the converted image looks correct?
-----------------------------------------
use_camera_matrix = 0;
highlight = 0;
use_camera_wb = 0;
output_color = 0;
gamm[0] = 1.0; gamm[1] = 1.0;
no_auto_bright = 1;
user_mul[0] = 1.0; user_mul[1] = 1.0; user_mul[2] = 1.0;
half_size = 1;
-----------------------------------------
Thanks a lot!
I can not understand what 'demosaic RAW' is.
If you just need 'source' (unaltered) values from sensor/raw file, it is much better to access imgdata.rawdata.raw_image directly.
dcraw_process() means multiple processing stages. Your parameters looks like you need unaltered image.
Hi Alex,
Thank you for the quick reply! Appreciate it!
I understand there are several steps if dcraw_process () is called. Since I am interested in getting the image data that is very close to the "demosaic RAW", I manually set some parameter to "avoid" unnecessary processing on the RGB code values. For example, I did the following:
-----------------------------------------
use_camera_matrix = 0;
highlight = 0;
use_camera_wb = 0;
output_color = 0;
gamm[0] = 1.0; gamm[1] = 1.0;
no_auto_bright = 1;
user_mul[0] = 1.0; user_mul[1] = 1.0; user_mul[2] = 1.0;
-----------------------------------------
If the setting sounds reasonable, when I add "half_size=1", the converted image looks like a channel is missing.
Thanks a lot!
I did not understand exactly what you want
Standard raw processing sequence is (for decoded/linearized data) in dcraw_process is
- black subtraction
- white balance
- demosaic
- data scaling to use full range
- conversion to output color space
Than, on output
- brightness correction
- gamma curve
What stages do you need and what is not?
BTW, besides demosaic, all other steps are trivial and very easy to implement.
Thanks a lot for the quick reply!
I meant the "raw image data" that only has demosaic process. In this case, I may still need "dcraw_process", right? if it is, then when I use "output_color = 0" and "half_size = 1", the output seems like missing a channel.
Have a great day!
To get fully unprocessed raw data you may
1) Access imgdata.rawimage.raw_data array which stores raw values read from sensor as is
2) set params.half_size=1 and call raw2image() after unpack (instead of dcraw_process).
raw2image will arrange raw_data to imgdata.image[][4] array
Hi,
Thanks for the quick response!
I tried to use "output_color = 0" and "half_size = 1" at the same time, the output looks like a channel is missing.
Is there a way that I can have a unprocessed raw in half size? Perhaps I am unaware of something?
Thanks a lot,
We assume that someone who uses 'parts' of dcraw_process() will subclass LibRaw :)
Nice and thanks! I think the only issue for having this be a general solution (and not just having me rework the source a touch - fine for me, but...) is that scale_colors is protected rather than public.
unpack() is affected by camera_wb only in some (very rare) cases (I can not remember the details, it affects very small set of cameras, may be old Kodaks and/or foveon /old ones, before Sigma Merill).
For modern cameras unpack is not affected by color setting (but default for 'use_camera_matrix' for some cameras depends on wb settings)
subtract_black and scale_colors works with image[][4] array, so you need to call raw2image() before subtract_black().
Also, there is single call for raw2image and subtract_black:
int LibRaw::raw2image_ex(int do_subtract_black);
So:
open_file()
unpack();
raw2image_ex(1);
scale_colors();
will put black-subtracted and white-balanced image in image[][4]
Alex,
Thank you for all the details! I've been using:
RawProcessor.raw2image()
CFA data then from RawProcessor.imgdata.image[r*RAW_S.iwidth+c][RawProcessor.FC(r,c)]
in my code since ... well, a long time ago... to extract the unprocessed data for Bayer-matrix data. (The idea being, I do my own hot pixel / bad pixel mapping -- this is astrophotography work). When non-Bayer, I run:
RawProcessor.dcraw_process();
red data then from RawProcessor.imgdata.image[r*RAW_S.iwidth+c][0]
green from[1], blue from [2]
I poked around in the debugger and docs last night but still couldn't see the effect of use_camera_wb. The docs (http://www.libraw.org/docs/API-notes.html#imgdata_params) say that unpack() is affected by this but no matter what the setting, the output of raw2image() seems the same.
For Bayer matrices, is there a spot where I can pull off the still-CFA encoded data but having run say black level and color scaling? Or, should I just:
unpack()
subtract_black()
scale_colors()
raw2image()
and find CFA data then from RawProcessor.imgdata.image[r*RAW_S.iwidth+c][RawProcessor.FC(r,c)]
Craig
And second followup (several notes):
'real picture' is more complex than single raw_image array.
For non-bayer images, raw_image is NULL after unpack(), but color3_image or color4_image is not null (color4 image's 4'th component usually zero, but for 4-shot files from Leaf or Pentax it is not zero).
For floating point (DNGs) float_image, float3_image, float4_image pointers are not zero (bayer, 3-component, 4-component data).
Please note, that row pitch may be greater than raw_with*(element size). real pitch is stored in imgdata.rawdata.sizes.raw_pitch and it is always in bytes (divide by 2 for raw_image to get items, divide by 16 for float4_image, etc).
Also, rawdata.*image arrays contains 'black frame' pixels, so use rawdata.sizes: raw_width/height, top_/left_margin and width/height to access image part containing real image data.
the raw2image() call handles all specifics, so look into source for details :)
Followup:
dcraw_make_mem_image() will skip 4'th component from image[][4] array, so if you need to access full data for de-bayer you need to work with either raw_image or image[][4]
no_interpolation=1 will skip bayer interpolation pass, but all other processing to be done (data scaling, white balance, convert to output color space /useless and even wrong step for not interpolated data).
If you want to do your own data processing and use LibRaw only as data decoder (the way we use it in, for example, FastRawViewer) it may be better to access bayer data directly:
rawdata.raw_image contains pointer to bayer data array 'as decoded' (so, no black level subtracted, but unpacked and linearization curve applied).
If you prefer to use imgdata.image[][4] for demosaic you may use
raw2image() to copy raw_image in image[][4] components
and
subtract_black() to subtract black level
instead of dcraw_process()
I folllowed you instruction, and it works. I have LibRaw-0.17.2\lib\libraw.a
(996KB) and also have several .exe files at LibRaw-0.17.2\bin folder.
When I executed
simple_dcraw.exe -e myfile.raw
I could get myfile.thumb.jpg
So it works properly now. Thank you very much. As you indicated, I think the mistake I did was that I did not put needed compile options like -DLIBRAW_NODLL
-DLIBRAW_NOTHREADS.
ST
1) I've Installed Qt-5.6.2-mingw-492
2) Run Qt/Mingw prompt (Qt 5.6 desktop from Start menu), than bash in this window
3) cd /path/to/LibRaw-0.17.2
4) mingw-32-make -f Makefile.mingw (no need to run ./configure, but it does not change Makefile.mingw, so it does not matter).
several bin/*.exe created after that, so both library and samples compiles OK.
The proper command line for samples creation (from Makefile.mingw):
g++ -O4 -I. -w -DLIBRAW_NODLL -DLIBRAW_NOTHREADS -o bin/raw-identify samples/raw-identify.cpp -L./lib -lraw -lws2_32 -lm
(or change to -L../lib if you're compiling within samples folder).
Thank you for the response.
You may qt-opensource-windows-x86-mingw492-5.6.2.exe. It has mingw32-make.exe.
I installed it and installed MSYS 1.0.11 where I referenced mingw directory.
After setting the paths to mingw and MSYS, in windows 7 command prompt I compiled libraw by
sh ./configure
mingw32-make -f makefile.mingw
I could get libraw.a (994kb), but not sure whether it is properly compiled or
not.
Because the line
#include "libraw/libraw.h"
in simple_dcraw.cpp suggests that it would be better to put simple_dcraw.cpp to
the parent of samples (../samples), I copied simple_dcraw.cpp to the parent of
samples(../sample) and executed
g++ simple_dcraw.cpp -o simple.exe -Ilibraw -Llib -lraw
at there(../samples). So I think "-Ilibraw -Llib -lraw" seems OK.
Sorry, could not help
I've tried to install Qt+mingw package (Qt 5.8.0-mingw), it installed, but no make(.exe) in this package.
MSYS/mingw setup looks made for someone who is already 'in context' and know what to do to install it.
Your error messages looks like no libraw library is linked. This may be because you've specified wrong library or library path:
g++ simple_dcraw.cpp -o simple.exe -Ilibraw -Llib -lraw
I assume you're already in samples folder, so right path is -L../lib, not -Llib
To use .pro files you may need to edit .pro files to specify (or disable) jpeg library and rawspeed library
You'll get white balance (daylight, because of use_camera_wb=0), demosaic and output range scaling.
Pages