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
Sorry, no MSVC 2015 on hands, just tried with MSVC 2013:
call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x64
nmake -f Makefile.msvc
After that:
mem-image -4 -6 filename.cr2
filename.cr2.ppm (16 bit, linear) was produced, looks OK
what if a manual WB is chosen and a -magenta is entered (i don't think most of calibrated in CC)? will this give a similar result?
for example, Sony will allow such a compensation. i have already, through my raw processing, set this as my standard, as i shot at one temperature with -magenta, and then adjust the proper temperature during raw processing.
At a first glance, presuming the filter blocks only the green channel, this means that the red and the blue channels should be exposed one stop better. However, the blue and red channels are sensitive to a pretty wide range of spectrum. That's why the actual per channel exposures were changed less than that, as it is obvious when looking at the white balance coefficients.
And if data is scaled to 8 bit somewhere, your result looks correct.
coloir.maximum is in RAW data domain, so for 14-bit camera it is about 16000.
imgdata.image[], after processing, is in 0..64k range.
your luminocity calculation, in first assumption, is in same range as imdata.image, so 64k.
So your jpeg generation code will show upper two stops of image as 'overflow'
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.
Sorry, no MSVC 2015 on hands, just tried with MSVC 2013:
call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x64
nmake -f Makefile.msvc
After that:
mem-image -4 -6 filename.cr2
filename.cr2.ppm (16 bit, linear) was produced, looks OK
Sure! Thanks
http://www.libraw.org/docs should be updated then to remove the LibRaw license.
Thanks!
WB settings does not change raw data, so you may use any in-camera setting.
what if a manual WB is chosen and a -magenta is entered (i don't think most of calibrated in CC)? will this give a similar result?
for example, Sony will allow such a compensation. i have already, through my raw processing, set this as my standard, as i shot at one temperature with -magenta, and then adjust the proper temperature during raw processing.
At a first glance, presuming the filter blocks only the green channel, this means that the red and the blue channels should be exposed one stop better. However, the blue and red channels are sensitive to a pretty wide range of spectrum. That's why the actual per channel exposures were changed less than that, as it is obvious when looking at the white balance coefficients.
And if data is scaled to 8 bit somewhere, your result looks correct.
coloir.maximum is in RAW data domain, so for 14-bit camera it is about 16000.
imgdata.image[], after processing, is in 0..64k range.
your luminocity calculation, in first assumption, is in same range as imdata.image, so 64k.
So your jpeg generation code will show upper two stops of image as 'overflow'
Not so. It looks like you've divided data by 256 (than recover it back?). This step is missing
In your code:
data should be in 16bit (64k) range.
Next step:
Data is upscaled to 24 bit?
Pages