Recent comments

Reply to: XYZ of the camera primaries.   4 days 23 hours ago

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.

Reply to: XYZ of the camera primaries.   5 days 16 min ago

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.

Reply to: XYZ of the camera primaries.   5 days 1 hour ago

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'.

Reply to: Demosaic raw without any other post-processing   1 week 17 hours ago

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.

Reply to: Demosaic raw without any other post-processing   1 week 1 day ago

So calling dcraw_process() with just the settings written above will create a RGB image without any further kind of processing? Thanks!

Reply to: Demosaic raw without any other post-processing   1 week 1 day ago

noise reduction and highlight recovery are not enabled by default

Reply to: sample images of 2x2meshes and or mazes (non-libraw question)   1 week 2 days ago

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.

Reply to: LibRaw Visual Studio Problem   2 weeks 1 day ago

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

Reply to: Problems with msvc 2015 x64 build   3 weeks 1 day ago

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! :)

Reply to: Problems with msvc 2015 x64 build   3 weeks 1 day ago

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.

Reply to: Problems with msvc 2015 x64 build   3 weeks 1 day ago

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

Reply to: LibRaw 0.18 released   3 weeks 1 day ago

Sure! Thanks

Reply to: LibRaw 0.18 released   3 weeks 1 day ago

http://www.libraw.org/docs should be updated then to remove the LibRaw license.

Reply to: LibRaw 0.18 released   3 weeks 2 days ago

Thanks!

Reply to: Using Magenta Filter for Shooting With a dSLR Camera Under the Daylight   1 month 4 days ago

WB settings does not change raw data, so you may use any in-camera setting.

Reply to: Using Magenta Filter for Shooting With a dSLR Camera Under the Daylight   1 month 4 days ago

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.

Reply to: Maximum/saturation pixel value   1 month 2 weeks ago

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'

Reply to: Maximum/saturation pixel value   1 month 2 weeks ago

Not so. It looks like you've divided data by 256 (than recover it back?). This step is missing
In your code:

unsigned int luminosity = ((unsigned int)iProcessor.imgdata.image[i][0] * 2 + (unsigned int)iProcessor.imgdata.image[i][1] * 3 + (unsigned int)iProcessor.imgdata.image[i][2])/6;
		data[i] = luminosity;

data should be in 16bit (64k) range.
Next step:

jpegData[i] = unsigned char((data[i]*255)/iProcessor.imgdata.color.maximum);

Data is upscaled to 24 bit?

Reply to: Maximum/saturation pixel value   1 month 2 weeks ago

The data array is set in my first example. It is just an approximation of the luminosity of each pixel. (2*red+3*green_blue)/6.

This link should show you the output of the above as jpeg files. You can see the integer overflow in the overexposed clouds https://1drv.ms/f/s!AgLCmsxNxVV_jelOf_MIR7MeGcsXvQ

Reply to: Maximum/saturation pixel value   1 month 2 weeks ago

imgdata.image is indeed scaled in LibRaw::scale_colors() call

For your test: what contained in data array?

Reply to: Maximum/saturation pixel value   1 month 2 weeks ago

Hmm, It seems to me that processed data are not being scaled to the 0-65535 range. In fact the data that are not saturated fall into the range 0 - colour.maximum, only saturated values are larger than color.maximum.

Is there a way I can upload an image to the forum? I have generated a greyscale jpeg from the data vector in my code above using

std::vector<unsigned char> jpegData(data.size());
for(size_t i=0; i<data.size(); ++i)
	jpegData[i] = unsigned char((data[i]*255)/iProcessor.imgdata.color.maximum);

The ouput shows the buffer overrun from conversion to unsigned char very clearly.

Phil

Reply to: Maximum/saturation pixel value   1 month 2 weeks ago

color.maximum is 'maximum data value permitted by data format'.
In some cases, real maximum is smaller.
There is color.data_maximum field, but it is filled /based on real data/ on raw2image (or dcraw_process) stage, so not available just after unpack().

In your example you compare raw data maximum (so, data range of raw data) with processed values.
This is not correct, because output data are scaled to use full data range (16 bit).

Reply to: Get White balance multipliers   1 month 2 weeks ago

Thank-you Alex
I have just loaded up an image and I see the WB_Coeffs array. Elements 1, 3, 4, 10, 11 and 14 are filled, which presumably correspond to the 6 options of my EOS 40D (daylight, cloudy, shade, tungsten, fluorescent, flash). That's everything I needed.

Thanks for the excellent info.

Phil

Reply to: Get White balance multipliers   1 month 2 weeks ago

1st:

With LibRaw 0.18 (currently in Beta1, Beta2 to be published soon),
in-camera WB multipliers are extracted into
imgdata.color.WB_Coeffs[256][4];
and
imgdata.colr.WBCT_Coeffs[64][5];

This extraction is made for all RAWs with embedded color presets, not only Canons.

1st array (WB_Coeffs) is indexed with EXIF Colorsource, so to get, for example, D65 preset, you need to inspect WB_Coeffs[21] for non-zero values.
2nd array (WBCT_Coeffs) is filled from 0 to 63:
WBCT_Coeffs[i][0] is color temperature (from camera settings)
and
WBCT_Coeffs[i][1..4] are WB coeffs.

There is no automated procedure to copy these values into processing, so one needs to examine array data (or, simply, fill WB drop-down with these values), than copy needed WB Coeffs into
imgdata.params.user_mul[] to use on dcraw_process() stage.
So, processing sequence is
LibRaw::open_file();
LibRaw::unpack();
... examine WB_Coeffs/WBCT_Coeffs
.. copy needed into user_mul
LibRaw::dcraw_process();

(and, sure, you may call dcraw_process() multiple times without unpack() of same file)

2nd:
WB Coeffs to CCT and back is not very complex (look into Adobe DNG SDK sources for sample code), but results of this procedure depends on color profile and camera calibration data used.
So, calculated CCT/Tint will, most likely, not compatible with other programs (or, even, with in-camera WB setting by CCT).

Pages