I tried converting an image that did not saturate anywhere. The maximum values I get in the image are lower that 2^16. So, I am actually not certain that the procedure really does scale to the full range. I'd really like to understand what the scaling does, as it also does not seem to be just the multiplication factors. Something else is going on.
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.
There is no standard way to avoid full range (0..65535) scaling in LibRaw::scale_colors (not to scale is useless because of limited ushort precision).
Possible workaround:
params.no_auto_scale = 1 to avoid LibRaw::scale_colors() call
implement own scale_colors replacement (use scale_colors() source as a reference) and provide it via callbacks.pre_preinterpolate_cb
(you'll need to subclass LibRaw and implement the callback in the subclass to allow access to internal data fields)
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)
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.
1st: We do not have donation link (yet). One could buy our software (RawDigger or FastRawVewer or bundle)
2nd: does dcraw_emu -r 2 1 3 1 results in different WB? If so, please start with samples/half_mt.c sample (it also uses C-API) with this additional lines below line ~80:
Ok, I think the issue was the gamma correction. Setting both gamm parameters to 1.0 solved it. Now it seems like I am getting color separated and interpolated raw values!
Interpolation I would like to have, for sure, and color conversion to a single G value is also appreciated. Data scaling only if the ratios between the colors are kept. White balance is probably something I would play with to see what works better, although I probably want that as it has been calibrated by the camera company. Gamma is a no however. So, I would want processed data.
BTW, I also noticed that the final image was mirrored vertically; I had to place a flip switch in there.
LibRaw::dcraw_process() (plus dcraw_make_mem_image()) do full processing steps that include
- white balance
- interpolation
- data scaling to full range (assuming maximum value scaled to 65535 if auto-bright is turned off)
- color conversion
- gamma conversion (on make_mem_image step)
What data you want to use, processed one or original raw values? If you need raw values, you do not need processing step, just use imgdata.rawdata...image pointers to access unprocessed/unaltered raw values after LibRaw::unpack()
Thanks again for the quick response. I am not using men_image_sample, so that's ok. I am converting the data array into a fits image for astronomical image processing. And I saw the malloc also.
I also managed to get it to work now as, example
rgb[0] = (ushort)img->data[i]
This is why you should not code when exhausted!
Additional Qs:
1)The peak intensities are near ~36000 in all three color channels, while I know that the detector in the Canon Rp is only 14 bit. So something is scaling the images. I don't believe I have any options enabled that would scale the image (wb=1, no auto brightening, etc). What could it be? When converting to DNG with Lightroom peak intensities are saturated at 16384 correctly.
2) I tried all interpolation methods and I am still getting some pixels with values of zero. Why is that?
Yes, data member is [1] in size just to make it an array.
In real code output is allocated via malloc(sizeof(libraw_processed_image_t)+widh*height*bytes-per-pixel, so it is possible to access data[] beyond data[0]).
mem_image sample supports 16-bit output for ppm files, but please note that ppm format is recorded in 'network byte order', so byte swap is used (not needed for internal access to data casted to ushort)
Thanks for the response, much appreciated. I read this above and tried the explicit recast, but it did not work. I noticed that it is a single element point array to its first element. I am certain that I am being the idiot here. Could you give a concrete syntax example? It would be nice if this were documented in the libraw description; most people that want to work with raw data do so because they want the full 16 bit data range. Thanks!
libraw_processed_image_t.data (char [1] array) is just a pointer to actual data (to avoid pointer here plus additional allocation). One need to recast it to uint16_t to use w/ 16-bit output.
Well, I hacked the code and rewrote the structure to define the "data" variable as ushort (libraw/libraw_types.h lines #177: "unsigned char" changed to "unsigned short"). The only other mod I had to do was to rewrite one of the sample programs (men_image_sample.cpp line #69) to recast row_pointer[0] to be = (uchar *) &img->data ... The entire package compiles perfectly fine and works as intended now.
I may be misunderstanding something here. An unsigned character, by def is 1 byte and can only take values between 0 and 255. Even if you recast the output to be ushort, the procedure placed only an unsigned character into the processed_image_t->data array, as its type is cast in the header to be only an unsigned char. How do we actually get 16 bit outputs from this function?
I post an example code snippet here. It is hard to find an example online for me:
void exif_callback(void *context, int tag, int type, int len, unsigned int ord, void *ifp) {
LibRaw_abstract_datastream* data = static_cast(ifp);
MyContext *mycontext = static_cast(context);
// read noiseProfile tag as an example
tag &= 0x0fffff; // Undo (ifdN + 1) << 20)
if (tag == 0xc761) {
double values[2];
data->read(values, sizeof(double), 2);
std::cout << values[0] << " " << values[1] << std::endl;
// store values into MyContext if you need
}
}
static LibRaw lr;
lr.open_file(filename);
MyContext context; // a custom struct just to save data
lr.set_exifparser_handler(exif_callback, &context);
lr.unpack();
... something to add here.
I tried converting an image that did not saturate anywhere. The maximum values I get in the image are lower that 2^16. So, I am actually not certain that the procedure really does scale to the full range. I'd really like to understand what the scaling does, as it also does not seem to be just the multiplication factors. Something else is going on.
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!
There is no standard way to avoid full range (0..65535) scaling in LibRaw::scale_colors (not to scale is useless because of limited ushort precision).
Possible workaround:
params.no_auto_scale = 1 to avoid LibRaw::scale_colors() call
implement own scale_colors replacement (use scale_colors() source as a reference) and provide it via callbacks.pre_preinterpolate_cb
(you'll need to subclass LibRaw and implement the callback in the subclass to allow access to internal data fields)
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
BTW, postprocessing in LibRaw is (very) similar to dcraw.c one, so 'dcraw annotated' may help too: https://ninedegreesbelow.com/files/dcraw-c-code-annotated-code.html
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)
Oh, F'in aces! The interpolation is nice now. The output_color=0 helped!
All I need to know now is the scaling to the images when using user_mul.
Thanks!
-A
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!
1st: We do not have donation link (yet). One could buy our software (RawDigger or FastRawVewer or bundle)
2nd: does dcraw_emu -r 2 1 3 1 results in different WB? If so, please start with samples/half_mt.c sample (it also uses C-API) with this additional lines below line ~80:
iprc->params.user_mul[0] = 2;
iprc->params.user_mul[2] = 3;
iprc->params.user_mul[1] =
iprc->params.user_mul[3] = 1;
This should result into bluish output.
(Note: you do not need libraw_raw2image if libraw_dcraw_process is used)
3rd: to use 'raw colors' set params.output_color to 0, this will disable camera color matrix use.
Just a correction. The code snippet I put there was incorrect.
Recasting should be simply
ushort *image = (ushort *) processed->data;
-A
Yes, (good) color profiles created for specific light source works better than generic (D65 or D50) ones.
These files are floating-point DNG files compressed with deflate compression.
To decode such files by LibRaw (without DNG SDK) you need to build LibRaw with USE_ZLIB defined and libz linked.
Here is tiff file produced from your sample by dcraw_emu -T (built w/ options mentioned above): https://www.dropbox.com/s/b2tpar7n395ee2j/_1010194-hdr.dng.tiff?dl=0
Hi Alex,
Ok, I think the issue was the gamma correction. Setting both gamm parameters to 1.0 solved it. Now it seems like I am getting color separated and interpolated raw values!
Thanks
Hi Alex!
You are fantastic for responding so quickly!
Interpolation I would like to have, for sure, and color conversion to a single G value is also appreciated. Data scaling only if the ratios between the colors are kept. White balance is probably something I would play with to see what works better, although I probably want that as it has been calibrated by the camera company. Gamma is a no however. So, I would want processed data.
BTW, I also noticed that the final image was mirrored vertically; I had to place a flip switch in there.
Thanks again!
LibRaw::dcraw_process() (plus dcraw_make_mem_image()) do full processing steps that include
- white balance
- interpolation
- data scaling to full range (assuming maximum value scaled to 65535 if auto-bright is turned off)
- color conversion
- gamma conversion (on make_mem_image step)
What data you want to use, processed one or original raw values? If you need raw values, you do not need processing step, just use imgdata.rawdata...image pointers to access unprocessed/unaltered raw values after LibRaw::unpack()
Hi Alex,
Thanks again for the quick response. I am not using men_image_sample, so that's ok. I am converting the data array into a fits image for astronomical image processing. And I saw the malloc also.
I also managed to get it to work now as, example
rgb[0] = (ushort)img->data[i]
This is why you should not code when exhausted!
Additional Qs:
1)The peak intensities are near ~36000 in all three color channels, while I know that the detector in the Canon Rp is only 14 bit. So something is scaling the images. I don't believe I have any options enabled that would scale the image (wb=1, no auto brightening, etc). What could it be? When converting to DNG with Lightroom peak intensities are saturated at 16384 correctly.
2) I tried all interpolation methods and I am still getting some pixels with values of zero. Why is that?
Thanks!
Yes, data member is [1] in size just to make it an array.
In real code output is allocated via malloc(sizeof(libraw_processed_image_t)+widh*height*bytes-per-pixel, so it is possible to access data[] beyond data[0]).
mem_image sample supports 16-bit output for ppm files, but please note that ppm format is recorded in 'network byte order', so byte swap is used (not needed for internal access to data casted to ushort)
Hi Alex,
Thanks for the response, much appreciated. I read this above and tried the explicit recast, but it did not work. I noticed that it is a single element point array to its first element. I am certain that I am being the idiot here. Could you give a concrete syntax example? It would be nice if this were documented in the libraw description; most people that want to work with raw data do so because they want the full 16 bit data range. Thanks!
Could you please check with dcraw_emu -6 -T ?
libraw_processed_image_t.data (char [1] array) is just a pointer to actual data (to avoid pointer here plus additional allocation). One need to recast it to uint16_t to use w/ 16-bit output.
Well, I hacked the code and rewrote the structure to define the "data" variable as ushort (libraw/libraw_types.h lines #177: "unsigned char" changed to "unsigned short"). The only other mod I had to do was to rewrite one of the sample programs (men_image_sample.cpp line #69) to recast row_pointer[0] to be = (uchar *) &img->data ... The entire package compiles perfectly fine and works as intended now.
Hi,
I may be misunderstanding something here. An unsigned character, by def is 1 byte and can only take values between 0 and 255. Even if you recast the output to be ushort, the procedure placed only an unsigned character into the processed_image_t->data array, as its type is cast in the header to be only an unsigned char. How do we actually get 16 bit outputs from this function?
Hi Alex,
I'd like to say thank you, my program is now generating the correct colour based on your suggestion.
I'm moving forward to understand the tonal curves, hopefully I can reproduce the same results as "copy_mem_image".
Hi there,
Nikon Z cameras present themselves as Z 7, Z 6, Z 5, Z 50, not Z7, Z6, ...
Regards
Klaus
I post an example code snippet here. It is hard to find an example online for me:
void exif_callback(void *context, int tag, int type, int len, unsigned int ord, void *ifp) {
LibRaw_abstract_datastream* data = static_cast(ifp);
MyContext *mycontext = static_cast(context);
// read noiseProfile tag as an example
tag &= 0x0fffff; // Undo (ifdN + 1) << 20)
if (tag == 0xc761) {
double values[2];
data->read(values, sizeof(double), 2);
std::cout << values[0] << " " << values[1] << std::endl;
// store values into MyContext if you need
}
}
static LibRaw lr;
lr.open_file(filename);
MyContext context; // a custom struct just to save data
lr.set_exifparser_handler(exif_callback, &context);
lr.unpack();
Pages