'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
If you want to get unprocessed RAW values, it is better to use:
- either imgdata.rawdata.raw_image array (complete unprocessed data)
- or use raw2image() call and use imgdata.image[] array (for bayer images, only one component of 4 will be non-zero)
output_color=0 does not disables white balance and auto-bright
Confirmed.
It looks like VS2013 (in my case) changes the order of execution in this line:
imgdata.makernotes.fuji.FujiExpoMidPointShift = ((short)get2()) / fMAX(1.0f, get2());
Replacing it with
float val0 = get2();
float val1 = get2();
imgdata.makernotes.fuji.FujiExpoMidPointShift = ((short)val0) / fMAX(1.0f,val1);
fixes the problem.
Is divide args should be evaluated left to right or not?
CFA does not define the response. The product of CFA transmission spectra, silicon response, and in-camera raw data processing does. pinv is a very useful tool if you need just a matrix. or going to overload a matrix with curves. Conversion from camera RGB to XYZ is not useful however. There is no need in intermediate steps.
I think I figured it out: it makes physically more sense to express the XYZ primaries in terms of the primaries of the CFA. The best you can then do in the colors from the CFA to XYZ, is to minimize the error made. This is what is implemented in the pseudoinverse() function, as described here: http://www.sci.utah.edu/~gerig/CS6640-F2012/Materials/pseudoinverse-cis61009sl10.pdf
This is done by minimizing the squared error of an overconditioned system of equations.
I'm not excellent in color theory, but in general:
- camera responds to any visible spectrum signal
- and, also, on UV and IR wavelenghts too.
So, triangle angles (bayer primaries) may reside outside of 'human eye locus' on xy 'visible colors' diagram (to include as much as possible colors into triangle).
The values you calculate from camera color profile data to be derived from profile creator's intention (color gamut, etc), not real 'bayer primaries'.
I know this is old, but 17barski, do you know what specifically you changed or set things to? I'm having the same basic problem where I set dcraw_emu to "Set as Startup Project", compiled everything, saw that dcraw_emu.exe and libraw.dll are in the debug folder, and still get errors saying that the files don't exist. Thanks
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.
Thanks for the quick reply!
With the following setting:
OUT.use_camera_matrix = 0;
OUT.output_color = 0;
OUT.highlight = 0;
OUT.use_camera_wb = 0;
OUT.gamm[0] = 1.0;
OUT.gamm[1] = 1.0;
OUT.no_auto_bright = 1;
Will I get a demosaic raw without any post-processing?
If you want to get unprocessed RAW values, it is better to use:
- either imgdata.rawdata.raw_image array (complete unprocessed data)
- or use raw2image() call and use imgdata.image[] array (for bayer images, only one component of 4 will be non-zero)
output_color=0 does not disables white balance and auto-bright
the patch above contains typo (missing bracket)
latest one correct this: https://github.com/LibRaw/LibRaw/commit/e818b3a0f75c6c4d1c18a2b003b54e25...
Hi Alex,
Thanks for the quick fix!
Use this patch: https://github.com/LibRaw/LibRaw/commit/b622cddaebfb749cad42b66f03838592...
Fortunately, it looks like this is only single problem point, no more 'two getN() divided in one statement' (sum and multiply will work OK)
Confirmed.
It looks like VS2013 (in my case) changes the order of execution in this line:
imgdata.makernotes.fuji.FujiExpoMidPointShift = ((short)get2()) / fMAX(1.0f, get2());
Replacing it with
float val0 = get2();
float val1 = get2();
imgdata.makernotes.fuji.FujiExpoMidPointShift = ((short)val0) / fMAX(1.0f,val1);
fixes the problem.
Is divide args should be evaluated left to right or not?
CFA does not define the response. The product of CFA transmission spectra, silicon response, and in-camera raw data processing does. pinv is a very useful tool if you need just a matrix. or going to overload a matrix with curves. Conversion from camera RGB to XYZ is not useful however. There is no need in intermediate steps.
I think I figured it out: it makes physically more sense to express the XYZ primaries in terms of the primaries of the CFA. The best you can then do in the colors from the CFA to XYZ, is to minimize the error made. This is what is implemented in the pseudoinverse() function, as described here:
http://www.sci.utah.edu/~gerig/CS6640-F2012/Materials/pseudoinverse-cis61009sl10.pdf
This is done by minimizing the squared error of an overconditioned system of equations.
I'm not excellent in color theory, but in general:
- camera responds to any visible spectrum signal
- and, also, on UV and IR wavelenghts too.
So, triangle angles (bayer primaries) may reside outside of 'human eye locus' on xy 'visible colors' diagram (to include as much as possible colors into triangle).
The values you calculate from camera color profile data to be derived from profile creator's intention (color gamut, etc), not real 'bayer primaries'.
if you do not want any color profile, you need to set params.output_color=0
With this setting image to be white balanced, demosaiced and scaled to fill 16-bit range.
So calling dcraw_process() with just the settings written above will create a RGB image without any further kind of processing? Thanks!
noise reduction and highlight recovery are not enabled by default
thanks
Here is the sample of AHD maze: https://picturecode.cachefly.net/photoninja/images/demosaic_before.jpg
Your blue dot artifacts are very different from that.
I know this is old, but 17barski, do you know what specifically you changed or set things to? I'm having the same basic problem where I set dcraw_emu to "Set as Startup Project", compiled everything, saw that dcraw_emu.exe and libraw.dll are in the debug folder, and still get errors saying that the files don't exist. Thanks
Found it. Mea culpa.
I've added the path to the old libraw 0.17 include files. Removed it and it now works.
But awsome how fast you did reply! :)
Yeah. I've also did your test (same image), it produces a 16bit ppm.
I guess I need to clean up my code and see where this behaviour comes from.
Pages