Alex,
Thanks for your reply. I will use the COLOR function to serve as an index into the cdesc.
I actually figured out what I was doing wrong. I got the bit order of the filters field wrong. It says that filters represents an 8x2 area with 2 bits per pixel. I assumed that bits 31-30 and 29-28 corresponds to the top two pixels in this 8x2 area. But it turns out that bits 0-1 and 2-3 correspond to the top two pixels in this 8x2 area. I tested this hypothesis for a bunch of files and it seems to hold. Hope my understanding this correct.
Also, what does the colors field in the libraw_iparams_t represent?
C-API getters/setters are indeed limited (to the ones that really used in real applications), your contributions are welcome (please use GitHub pull request for that).
Besides that, tiff/ppm writer is very limited, esp. in tiff part (no compression, no striping/tiling, etc, etc). It is not intended for use in any real application, this is just a placeholder, to allow LibRaw samples to write some files.
Use make_mem_image() and your preferred TIFF writer (e.g. libtiff) in real apps.
i am exactly stuck at the same spot as NicolasB although I am using VB.Net. but in the end there is no option to access the params.ouput_tiff from the DLLimport statements/ C API. so I can only create a ppm file and not a tiff
Alex i see that you point to some setters in your comment but i dont see any in the doc nor the source "libraw.h" file that could change the "output_tiff" value.
Note that the method posted above by NicolasB essentially lets libraw.dll do the whole work and no real object is passed back to the calling .NET program
The alternative would be to recreate the whole C++ class structure in VB (or C#) which is quite daunting just for this simple function.
To check color accuracy it is better to check something with known colors and even spectral response (e.g. color checker) and known light source, not wall with unknown dye used under unknown light
(guessing by filename) unit4.obj is (most likely) generated from unit4.cpp or unit4.c or something like that.
There is no file(s) with same or similar name(s) in LibRaw. So, unable to help.
Thank you, I think that got me closer! I'm still a little puzzled about how the white balance coefficients work (they appear to be relative, rather than absolute?) but I'll see if I can figure it out. Thanks again!
I'm wondering if each of the channels possible has a different white and black point, and I need to determine what the min and max value per channel is? I'm really baffled.
Hey Alex, thanks for the reply! I'm aware that I will have to adjust for the mask and for the low contrast in the negative. At this point I just want to get the inversion step right so that I can be a little more certain that my overall approach will work. I updated my code as you suggested, but I'm still getting an entirely magenta image. Here's my loop:
1st:
raw_image[] values are 'as decoded from RAW file', so black level is not subtracted.
If you're making 'in house' application, so the only camera you plan to use is A7R-4, the exact black level for this camera is 512.
so inverted_value = maximum - original_value + 512 (maximum is also has black level within it).
If you plan to use multiple cameras, look into src/preprocessing/subtract_black.cpp source for black subtraction code and into src/utils/utils_libraw.cpp:adjust_bl() function for additional details.
2nd: If you're processing color negatives, inversion in linear domain will not result in acceptable image color because of color masking used in that negatives ( http://www.brianpritchard.com/why_colour_negative_is_orange.htm )
Also, for both color and BW negatives you'll need to adjust contrast.
It works using your suggestion. Thank you. Do you happen to know what is the exact mathematical formula f(x) for the gamma correction and how the two following parameters are used ?
imgdata.params.gamm[0]
imgdata.params.gamm[1]
I reckon the first one is the power and the second one is the toe. I have no clues for the second one. Also I suppose that the variable x range should be between 0 and 1. I may have to reuse the gamma correction in a separate process later down the processing pipeline. Thank you very much.
This is for some special case, asked by our users (I can’t remember the specific details), not targeted for 'normal' use, so not documented in details.
The documentation could be better, it's true :)
P.S. Yes, scale_colors() do range scale and WB in single step.
I guess what confused me was that scale_colors() also includes (or rather excludes when disabled) white balance, which is usually important in exactly the advanced interpolation use case you described... no biggie, because the advanced user could easily do the white balance before their custom interpolation, it was just unexpected/undocumented, so at least making it somewhat more explicit in the API docs would help avoid having to find out the hard way ;)
image[][4] is used for both intermediate results and for final result.
After dcraw_proces() is called,
image[i][0..2] contains final image in 16-bit and in linear space for i-th pixel
image[i][3] contains some garbage (not used intermediate results, etc).
Also, image[] is not rotated (if rotation is set via metadata or via user_flip)
make_mem_image prepares final result: 3 components per pixel, gamma corrected (according to imgdata.params.gamm[]), 8 or 16 bit (according to params.output_bps)
Alex,
Thanks for your reply. I will use the COLOR function to serve as an index into the cdesc.
I actually figured out what I was doing wrong. I got the bit order of the filters field wrong. It says that filters represents an 8x2 area with 2 bits per pixel. I assumed that bits 31-30 and 29-28 corresponds to the top two pixels in this 8x2 area. But it turns out that bits 0-1 and 2-3 correspond to the top two pixels in this 8x2 area. I tested this hypothesis for a bunch of files and it seems to hold. Hope my understanding this correct.
Also, what does the colors field in the libraw_iparams_t represent?
Followup:
if you need to know *color* for given pixel, not 'color index', use value returned by COLOR() as index in cdesc.
DCRAW_VERBOSE has removed from current 'snapshot' when cleaning up (outdated) source code generation from (patched) dcraw.c
It is still available in 0.19-release
cdesc is not a pattern, it is just indication (RGB or CMYK or CMYG, etc), so for all four R-G-B-G2 orders possible cdesc will be set to RGBG
C-API getters/setters are indeed limited (to the ones that really used in real applications), your contributions are welcome (please use GitHub pull request for that).
Besides that, tiff/ppm writer is very limited, esp. in tiff part (no compression, no striping/tiling, etc, etc). It is not intended for use in any real application, this is just a placeholder, to allow LibRaw samples to write some files.
Use make_mem_image() and your preferred TIFF writer (e.g. libtiff) in real apps.
Hi,
i am exactly stuck at the same spot as NicolasB although I am using VB.Net. but in the end there is no option to access the params.ouput_tiff from the DLLimport statements/ C API. so I can only create a ppm file and not a tiff
Alex i see that you point to some setters in your comment but i dont see any in the doc nor the source "libraw.h" file that could change the "output_tiff" value.
Note that the method posted above by NicolasB essentially lets libraw.dll do the whole work and no real object is passed back to the calling .NET program
The alternative would be to recreate the whole C++ class structure in VB (or C#) which is quite daunting just for this simple function.
I do not see very big problem here.
To check color accuracy it is better to check something with known colors and even spectral response (e.g. color checker) and known light source, not wall with unknown dye used under unknown light
Yes, they are also wrong. Here's a link to the shots by both 1100D and 80D: https://drive.google.com/open?id=1WXae5dDIwxz77b2JD9cSPv-LXasytjN3
I used the following commands for dcraw_emu to get comparable-brightness results:
dcraw_emu -W -b 5 80D.CR2
dcraw_emu -W -b 3.5 1100D.CR2
I've not checked how accurate the 1100D colors are, but at least they seem more believable.
Just found libraw_dcraw_make_mem_thumb, which seems to be working...
I've made progress - I now have it building using the C api...
I'm puzzled by this, however.
This code works:
libraw_data_t * image = libraw_init(0);
libraw_open_file(image, "IMG_0174.cr2");
libraw_unpack_thumb(image);
libraw_dcraw_thumb_writer(image, "h:\\outcr2.jpg");
The return codes from all function calls is zero, and the output file is created ok.
Yet, when I examine the image->thumbnail properties, everything is zero and the thumbnail type is LIBRAW_THUMBNAIL_UNKNOWN
I'd like to be able to process the thumbnail data without wasting time writing to disk, but it doesn't seem to be there. Yet it writes to disk ok.
Is there some other step I need to take to get to the thumbnail/preview data?
Many thanks
Are colors generated by dcraw_emu are wrong? If so, could you please provide raw file sample?
(guessing by filename) unit4.obj is (most likely) generated from unit4.cpp or unit4.c or something like that.
There is no file(s) with same or similar name(s) in LibRaw. So, unable to help.
Thank you, I think that got me closer! I'm still a little puzzled about how the white balance coefficients work (they appear to be relative, rather than absolute?) but I'll see if I can figure it out. Thanks again!
Black point is same for all channels in Sony files (and, yes, it is 512 in the file you shared).
The problem is white balance. Here is your image in 'raw composite' view: https://www.dropbox.com/s/iowl9jkhgzhxqy0/screenshot%202020-04-22%2019.3... (not white balanced, green channel(s) is strongest as expected)
So, I see two possible ways:
1) If you'll go 'raw data inversion' way: Invert white balance coefficients too.
2) Generate proper negative image in linear space (so, no raw data inversion, normal processing with linear gamma output), than invert it.
Sure, no problem! Here's the file: http://ur.sine.com/temp/tether8387.dng
I'm wondering if each of the channels possible has a different white and black point, and I need to determine what the min and max value per channel is? I'm really baffled.
Could you please provide link to the RAW file too, it is very interesting to play w/ it.
Hey Alex, thanks for the reply! I'm aware that I will have to adjust for the mask and for the low contrast in the negative. At this point I just want to get the inversion step right so that I can be a little more certain that my overall approach will work. I updated my code as you suggested, but I'm still getting an entirely magenta image. Here's my loop:
for(int i = 0;i < ImageProcessor.imgdata.sizes.iwidth * ImageProcessor.imgdata.sizes.iheight; i++) { int inverted_value = ImageProcessor.imgdata.color.maximum - ImageProcessor.imgdata.rawdata.raw_image[i] + 512; ImageProcessor.imgdata.rawdata.raw_image[i] = inverted_value; }This is the original images: http://ur.sine.com/temp/original.png
And this is the output of that code: http://ur.sine.com/temp/output.png
1st:
raw_image[] values are 'as decoded from RAW file', so black level is not subtracted.
If you're making 'in house' application, so the only camera you plan to use is A7R-4, the exact black level for this camera is 512.
so inverted_value = maximum - original_value + 512 (maximum is also has black level within it).
If you plan to use multiple cameras, look into src/preprocessing/subtract_black.cpp source for black subtraction code and into src/utils/utils_libraw.cpp:adjust_bl() function for additional details.
2nd: If you're processing color negatives, inversion in linear domain will not result in acceptable image color because of color masking used in that negatives ( http://www.brianpritchard.com/why_colour_negative_is_orange.htm )
Also, for both color and BW negatives you'll need to adjust contrast.
Thanks. I was able to find the function in curves.cpp. Its more complicated that I thought.
I m guessing that gamma[0] is pwr and gamma[1] is ts. I don't know what mode is but 1 seems to work for me.
void LibRaw::gamma_curve(double pwr, double ts, int mode, int imax) { int i; double g[6], bnd[2] = {0, 0}, r; g[0] = pwr; g[1] = ts; g[2] = g[3] = g[4] = 0; bnd[g[1] >= 1] = 1; if (g[1] && (g[1] - 1) * (g[0] - 1) <= 0) { for (i = 0; i < 48; i++) { g[2] = (bnd[0] + bnd[1]) / 2; if (g[0]) bnd[(pow(g[2] / g[1], -g[0]) - 1) / g[0] - 1 / g[2] > -1] = g[2]; else bnd[g[2] / exp(1 - 1 / g[2]) < g[1]] = g[2]; } g[3] = g[2] / g[1]; if (g[0]) g[4] = g[2] * (1 / g[0] - 1); } if (g[0]) g[5] = 1 / (g[1] * SQR(g[3]) / 2 - g[4] * (1 - g[3]) + (1 - pow(g[3], 1 + g[0])) * (1 + g[4]) / (1 + g[0])) - 1; else g[5] = 1 / (g[1] * SQR(g[3]) / 2 + 1 - g[2] - g[3] - g[2] * g[3] * (log(g[3]) - 1)) - 1; if (!mode--) { memcpy(gamm, g, sizeof gamm); return; } for (i = 0; i < 0x10000; i++) { curve[i] = 0xffff; if ((r = (double)i / imax) < 1) curve[i] = 0x10000 * (mode ? (r < g[3] ? r * g[1] : (g[0] ? pow(r, g[0]) * (1 + g[4]) - g[4] : log(r) * g[2] + 1)) : (r < g[2] ? r / g[1] : (g[0] ? pow((r + g[4]) / (1 + g[4]), 1 / g[0]) : exp((r - 1) / g[2])))); } }Look into gamma_curve() code
It works using your suggestion. Thank you. Do you happen to know what is the exact mathematical formula f(x) for the gamma correction and how the two following parameters are used ?
I reckon the first one is the power and the second one is the toe. I have no clues for the second one. Also I suppose that the variable x range should be between 0 and 1. I may have to reuse the gamma correction in a separate process later down the processing pipeline. Thank you very much.
This is for some special case, asked by our users (I can’t remember the specific details), not targeted for 'normal' use, so not documented in details.
The documentation could be better, it's true :)
P.S. Yes, scale_colors() do range scale and WB in single step.
I guess what confused me was that scale_colors() also includes (or rather excludes when disabled) white balance, which is usually important in exactly the advanced interpolation use case you described... no biggie, because the advanced user could easily do the white balance before their custom interpolation, it was just unexpected/undocumented, so at least making it somewhat more explicit in the API docs would help avoid having to find out the hard way ;)
That's very useful. Thanks for the info.
image[][4] is used for both intermediate results and for final result.
After dcraw_proces() is called,
image[i][0..2] contains final image in 16-bit and in linear space for i-th pixel
image[i][3] contains some garbage (not used intermediate results, etc).
Also, image[] is not rotated (if rotation is set via metadata or via user_flip)
make_mem_image prepares final result: 3 components per pixel, gamma corrected (according to imgdata.params.gamm[]), 8 or 16 bit (according to params.output_bps)
Pages