imgdata.image[] is processing array. After dcraw_process() it contains 16-bit linear data in [0..2] components and some garbabe in [3]
To implement exposure correction one may use params settings as described in library manual
-- Alex Tutubalin
Yes, I know there are some processing tools alredy...
Exposure was just an example. And I allready found other programs using LibRaw for opening raws for postprocessing. But I couldn't figure out wich data they use to process yet. Because using the final RGB data gives just limited processing possibilities. That was the reason for extracting all these values to an xls.
Or in other words to make it maybe more clear for me:
When I use the PS/LR sliders for exposre, shadows, highlights, sharpness, etc, which is the "corresponding LibRaw data" they "would" use for processing? Does that question make sense to you? Do these sliders use the final RGB values you helped me with, or do they use other data, like the .imgdata.image?
So the .image->data[] is the final RGB array, with the selected WB.
But, then I still don't get what imgdata.image[][] is for?
To wich of these fields do I have to apply my exposure compensation "pixel *= 2^EV"?
Or, in other words, wich of these two fileds do I have to apply my processing?
I tested both samples now.
They work both, but have the same heavy yellow shift when opend in PS. (It's an old Canon 7D cr2 by the way.) The exported thumbnail had not.
And, even with the heavy yellow shift, the values do not match... In 8 and 16 bit mode....
The first pixel of the ppm file in PS has RGB(54, 64, 14).
The first pixel of my xls has
RGBG2(542,1052,418,874) from .imgdata.image[pos][], or
RGB(22,34,18) from image->data[]
And also:
data field in libraw_processed_image_t is 'unsigned char', while you're using 16-bit output.
So you dump 8-bit wise pieces, not real 16-bit values.
Well, I loaded the image as shown in my code. I know, PS/LR have some hidden adjustments.
The first 100x100 pixel in the image, listed in the xls, are supposed to be some kind of green. Leaves and treetops.
But all data listed is not near the RGB values for green. And furthermore these values are supposed be in a neare range of greens. But all listed data seem to jump all over the place.
I tried both, 8 and 16 bits for the output, and other different modes in the params. But nothing worked for me.
Yes, I know that the rawdata has a larger field then the final RGB values. This is just some kind of "test" to see a reason for that jumping values.
The fixed vs variable contrast indeed seems to be the major contributing factor to the difference. I'm not familiar with that terminology; could you explain what variable contrast mode does? Can LibRaw emulate it?
I think you need to build LibRaw with
-DUSE_JPEG (to handle jpeg-compressed files, like 'fast load DNG' and some old Kodaks)
-DUSE_ZLIB (to handle deflate-compressed floating point DNG files)
These settings will handle "99%" of today RAW files.
So libjpeg and libz to be distributed with libraw(.dll)
Sorry, you allready did. But it did not show up on the page. :)
imgdata.image[] is processing array. After dcraw_process() it contains 16-bit linear data in [0..2] components and some garbabe in [3]
To implement exposure correction one may use params settings as described in library manual
-- Alex Tutubalin
Yes, I know there are some processing tools alredy...
Exposure was just an example. And I allready found other programs using LibRaw for opening raws for postprocessing. But I couldn't figure out wich data they use to process yet. Because using the final RGB data gives just limited processing possibilities. That was the reason for extracting all these values to an xls.
Or in other words to make it maybe more clear for me:
When I use the PS/LR sliders for exposre, shadows, highlights, sharpness, etc, which is the "corresponding LibRaw data" they "would" use for processing? Does that question make sense to you? Do these sliders use the final RGB values you helped me with, or do they use other data, like the .imgdata.image?
Regards.
>>> Can you help me with the first RGBG values? What are they for then?
Sorry, could not understand this question.
imgdata.image[] is processing array. After dcraw_process() it contains 16-bit linear data in [0..2] components and some garbabe in [3]
To implement exposure correction one may use params settings as described in library manual
Ahh, thanks.
So, I assume I use the wrong settings.... When I just use the camera WB, I should get the same as PS with camera WB, right?
Can you help me with the first RGBG values? What are they for then?
Regards.
Also I've modified your sample with commenting out params settings section, from
to (including) custom gamma section.
After that, 1st line of output is:
Same 54,64,14, as expected (if compiled with -std=c++17)
Thank you very much!!!!
So the .image->data[] is the final RGB array, with the selected WB.
But, then I still don't get what imgdata.image[][] is for?
To wich of these fields do I have to apply my exposure compensation "pixel *= 2^EV"?
Or, in other words, wich of these two fileds do I have to apply my processing?
Regards.
Thanks.
I've added this to the mem_image sample:
printf("PIX0: image: %d/%d/%d mem_image: %d/%d/%d\n", RawProcessor.imgdata.image[0][0], RawProcessor.imgdata.image[0][1], RawProcessor.imgdata.image[0][2], image->data[0], image->data[1], image->data[2]);just after these lines:
libraw_processed_image_t *image = RawProcessor.dcraw_make_mem_image(&ret); if (image) {Output: PIX0: image: 1603/2064/330 mem_image: 54/64/14
The last triple is similar with your Photoshop numbers. So, it looks like your printing code is wrong.
Yellow cast is because Daylight WB is used (unless use_camera_wb is not set)
Sure, here you are:
https://filebin.net/jw2qi5a46ybu5cny/Bild.cr2?t=expg9qj0
Regards.
RAW file, of course. It looks like I need to repeat your experiment with your input data.
Which file do you mean? The Source or resulting images?
And I'm using C++17 in VS2019 Community.
Could you please share the sample file?
I tested both samples now.
They work both, but have the same heavy yellow shift when opend in PS. (It's an old Canon 7D cr2 by the way.) The exported thumbnail had not.
And, even with the heavy yellow shift, the values do not match... In 8 and 16 bit mode....
The first pixel of the ppm file in PS has RGB(54, 64, 14).
The first pixel of my xls has
RGBG2(542,1052,418,874) from .imgdata.image[pos][], or
RGB(22,34,18) from image->data[]
Regards.
Samples are in samples/*.cpp in LibRaw distribution.
BTW, in this piece of code
"," << (int) image->data[rgb_pos++] << "," << (int) image->data[rgb_pos++] << "," << (int) image->data[rgb_pos++]Execution order is not specified (before C++17, AFAIK), that may explain garbage output.
Yes, please start from samples. If LibRaw's samples provides expected (visually correct) results that mean that the problem is not within LibRaw.....
Yes, I know, but even in 8 bit mode it did not match. The values seem random to me.
You mean from the samples page? no, not yet. I'll try this and copy this code.
Regards.
And also:
data field in libraw_processed_image_t is 'unsigned char', while you're using 16-bit output.
So you dump 8-bit wise pieces, not real 16-bit values.
Let's start from the beginning.
Have you tried dcraw_emu sample? If so, are results 'expected' or not?
Same question with mem_image sample.....
Thanks for your fast response.
Well, I loaded the image as shown in my code. I know, PS/LR have some hidden adjustments.
The first 100x100 pixel in the image, listed in the xls, are supposed to be some kind of green. Leaves and treetops.
But all data listed is not near the RGB values for green. And furthermore these values are supposed be in a neare range of greens. But all listed data seem to jump all over the place.
I tried both, 8 and 16 bits for the output, and other different modes in the params. But nothing worked for me.
Yes, I know that the rawdata has a larger field then the final RGB values. This is just some kind of "test" to see a reason for that jumping values.
Regards.
You can always double-check what your libraw.dll links against at runtime using the Dependency Walker: https://www.dependencywalker.com/
dcraw.c's postprocessing (LibRaw::dcraw_process is derived from it) do not have contrast controls.
Thanks for the quick reply, Alex.
The fixed vs variable contrast indeed seems to be the major contributing factor to the difference. I'm not familiar with that terminology; could you explain what variable contrast mode does? Can LibRaw emulate it?
I think you need to build LibRaw with
-DUSE_JPEG (to handle jpeg-compressed files, like 'fast load DNG' and some old Kodaks)
-DUSE_ZLIB (to handle deflate-compressed floating point DNG files)
These settings will handle "99%" of today RAW files.
So libjpeg and libz to be distributed with libraw(.dll)
LibRaw::dcraw_process output is close (enough) to FastRawViewer in fixed contrast + auto ETTR mode.
Pages