Hi Alex,
For the image data generated from "dcraw_make_mem_image()", I see it is of "uchar" type according to the documentation:
"
unsigned char data[] Data array itself.
Should be interpreted as RGB triplets for bitmap type and as JPEG file for JPEG type.
"
For 16-bit image, when I need to convert "uchar" data array to "float" data array, the "original" values won't stay so the image won't convert correctly.
I am just wondering are there any functions that return "floating-point" data array after "dcraw_process()" is called.
I am aware that in dcraw, it has something like "ushort curve[ ]" and a function of "write_ppm_tiff()" to handle the difference between 8-bit and 16-bit output, specifically the section of code from line#19365 to line#19374 in "LibRaw/dcraw.c"
Thanks,
Mio
LibRaw is internally 16-bit
LibRaw is internally 16-bit unsigned int, so float conversion looks useless.
For 16-bit output just use explicit type conversion to (ushort*) for libraw_processed_image_t->data.
-- Alex Tutubalin @LibRaw LLC
Hi Alex,
Hi Alex,
Thanks for replying!
I actually used the conversion to "ushort *" right after posting the question. It seemed to work fine.
Have a nice day!
Mio
Hi,
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?
Merope
Well, I hacked the code and
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.
Merope
libraw_processed_image_t.data
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.
-- Alex Tutubalin @LibRaw LLC
Hi Alex,
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!
Merope
Yes, data member is [1] in
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)
-- Alex Tutubalin @LibRaw LLC
Hi Alex,
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!
Merope
LibRaw::dcraw_process() (plus
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()
-- Alex Tutubalin @LibRaw LLC
Hi Alex!
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!
Merope
Hi Alex,
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
Merope
wrong, before
Just a correction. The code snippet I put there was incorrect.
Recasting should be simply
ushort *image = (ushort *) processed->data;
-A
Merope