I appreciate your efforts to support GPR files in LibRaw. I followed the steps but after spending a few hours, was unable to get things working (I'm building on a Mac). I am wondering if you would consider posting a fork of the GPR SDK with the necessary modifications somewhere that people could build (with the correct Adobe 1.4 SDK if possible). Thank you for your consideration.

I've just created a pull request for this.

David

Definitely not 1-2 days, because we have some not fixed (yet) bugs.

Most likely one week or so.

Yes, manually changing imgdata.color.maximum after LibRaw::unpack() will effectively disable the scaling.

scale_colors per-channel multipliers are: (dmax is max(pre_mul[0...3], pre_mul is WB coeffs). <p> Final scaling is performed in copy_mem_image unless no_auto_bright is set: <ul> <li>histogram is analyzed (from right to left) to get level # where 1% of pixels are saturated <li>output curve will map 0...level# to full output range </ul>[/geshifilter-c]

Without auto-bright/auto-maximum, scaling scales (theoretical) maximum to 2^16-1.

This is somewhat tricky, for example for 14-bit canons maximum assumed 16383-black_value, while in reality data maximum is lower (as low as ~12000 for 5D Mark II at intermediate ISOs), that's why maximum adjustment was introduced (there is no way to determine real maximum value from metadata for these camera(s)).

For most other vendors, maximum is not that tricky.

Hi Alex,

Ok, thanks for that update. I wouldn't say it is useless though! For one, you don't actually get more precision by multiplying all values by a constant, unless you are talking about interpolation. Two: for scientific images count numbers are actually important. For example, if you have astronomy images with different exposures, it is nice to be able to scale them to the same level, based on exposure count.

As long as I can multiply each image output by its scaling value in my external program, that's ok. What I really need is for output_color=0 to work with scaling off.

Thanks!

Hi Alex,

Well, the only way I got user_mul to be applied was then no_auto_scale=0. I have always had no_auto_bright=1 and adjust_maximum_thr=0.0.

in Libraw::scale_colors() user_mul is copied to pre_mul if it is set. And then, I only see pre_mul used if use_auto_wb or use_camera_wb is set.

What I would need is to use the camera multipliers (i.e. 1.99,1.0,1.77,1.0, as defined by Canon for my camera), but no scaling done to the image.

Thanks

no_auto_scale is very special use parameter, quote from docs/API-datastruct.html:

Disables pixel values scaling (call to LibRaw::scale_colors()) in LibRaw::dcraw_process().
This is special use value because white balance is performed in scale_colors(), so skipping it will result in non-balanced image.
This setting is targeted to use with no_interpolation, or with own interpolation callback call.

For normal processing you probably need no_auto_bright=1 (and, may be, adjust_maximum_thr=0.0 too)

P.S. www.libraw.org/docs need update w/ actual LibRaw/doc/ contents (forgot to do it on LibRaw 0.20 release)

Hi Alex,

1) Ok, I'll check them out!
2) I found the problem by digging into the code. The values set in user_mul only get applied when no_autoscale is false, i.e. auto_scaling is applied. This is counterintuitive, as setting your own multipliers does not count as auto_scaling, in my opinion. I noticed the pixel values increasing by a lot more than the multipliers I entered though, and it seems to scale the image by a value determined from a sum. Is this ok? Is this consistent from image to image? I.e., if I take a 2x long exposure, will the values scale by a factor of 2 (if gammas=1.0). I will want to combine and do arithmetics with the images and I don't want artificial scales.
3) I see a change when setting output_color=0. That's great. I'll see if it helped with the interpolation.

Thanks again!

Just a correction. The code snippet I put there was incorrect.

Recasting should be simply

ushort *image = (ushort *) processed->data;

-A