Recent comments

Reply to: Access raw color data   1 year 8 months ago

Depending of file internals type (bayer, or full color), only one pointer in imgdata.rawdata is non-NULL:
raw_image - for bayer or X-Trans (color filter array) images
color3_image - for full-color (Foveon, linear DNG) images if 3-channel data extractor was used
color4_image - for full-color images with 4-channel data extractor
(if color4_image is not-NULL, this does not always mean you have 4-channel input, it could-be 3-channeld and zeroes in 4th channel, inspect imgdata.idata.colors for that).

And similar three pointers for floating point input: float_image, float3_image, float4_image.

So, your code should check all six pointers (or only three if floating point input is not expected) and select image type based on 'what pointer is non-NULL'

Reply to: Color calibration and white balance   1 year 8 months ago

LibRaw (post)processing is very similar to dcraw.c postprocessing.

In order not to rewrite the same thing many times, this post-processing is explaned in detail here: https://ninedegreesbelow.com/files/dcraw-c-code-annotated-code.html

Reply to: Postprocessing like raw viewers   1 year 8 months ago

Thanks for your help, Alex. We'll try to figure out how to apply such a variable contrast transformation ourselves then.

Reply to: Dependency for distriubtion   1 year 8 months ago

Thank you. I have checked and the options are already set in the actual make file, so it should work.

Reply to: Image data does not match   1 year 8 months ago

Adobe uses own raw processing engine, different from LibRaw. There is no known rule(s) to convert Adobe sliders into LibRaw's imgdata.params

Also, I do not think that altering imgdata.image values without some knowledge of LibRaw::dcraw_process internals is a good idea. You may either study it (it is opensource, so it is possible), or create own raw processing.

LibRaw's dcraw_process() is very similar to dcraw.c processing, so you may find this link useful: https://ninedegreesbelow.com/files/dcraw-c-code-annotated-code.html

Reply to: Image data does not match   1 year 8 months ago

Thank you!!!

Sure, they have their own engine. ;)
But childish me thought just use the expousre-algorithm 2^exp on the imgdata.image values and done...
Phew.... thats a lot of text. I'll have to read it in a quite moment.

But never the less you helped me a lot.
Thank you very much, Alex!!!

Reply to: Image data does not match   1 year 8 months ago

Sorry, you allready did. But it did not show up on the page. :)

Reply to: Image data does not match   1 year 8 months ago

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.

Reply to: Image data does not match   1 year 8 months ago

>>> Can you help me with the first RGBG values? What are they for then?

Sorry, could not understand this question.

Reply to: Image data does not match   1 year 8 months ago

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

Reply to: Image data does not match   1 year 8 months ago

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.

Reply to: Image data does not match   1 year 8 months ago

Also I've modified your sample with commenting out params settings section, from

    Proc.imgdata.params.shot_select         = 0;        // Select first RAW, in case there are more

to (including) custom gamma section.

After that, 1st line of output is:

0,0,0,1603,2064,330,1630,1,54,64,14,16383

Same 54,64,14, as expected (if compiled with -std=c++17)

Reply to: Image data does not match   1 year 8 months ago

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.

Reply to: Image data does not match   1 year 8 months ago

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)

Reply to: Image data does not match   1 year 8 months ago

RAW file, of course. It looks like I need to repeat your experiment with your input data.

Reply to: Image data does not match   1 year 8 months ago

Which file do you mean? The Source or resulting images?

And I'm using C++17 in VS2019 Community.

Reply to: Image data does not match   1 year 8 months ago

Could you please share the sample file?

Reply to: Image data does not match   1 year 8 months ago

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.

Reply to: Image data does not match   1 year 8 months ago

Samples are in samples/*.cpp in LibRaw distribution.

Reply to: Image data does not match   1 year 8 months ago

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.

Reply to: Image data does not match   1 year 8 months ago

Yes, please start from samples. If LibRaw's samples provides expected (visually correct) results that mean that the problem is not within LibRaw.....

Reply to: Image data does not match   1 year 8 months ago

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.

Reply to: Image data does not match   1 year 8 months ago

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.

Reply to: Image data does not match   1 year 8 months ago

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.....

Pages