Followup:

standard deviation value for black masked pixels is about 37 for this shot. So 5 lower bits (for 14-bit scale) are useless, difference between black at 2048 and 2044 to be masked under the noise.

Strange, that would explain why only I thought this was a problem. Here's the result from a burst I took (Canon G9 X II):

IMG_0293.CR2: black 2044, cblack 2 0 1 0
IMG_0294.CR2: black 2044, cblack 1 0 1 0
IMG_0295.CR2: black 2044, cblack 1 0 2 0
IMG_0296.CR2: black 2045, cblack 1 1 0 0
IMG_0297.CR2: black 2044, cblack 0 1 1 2
IMG_0298.CR2: black 2043, cblack 1 2 2 0
IMG_0299.CR2: black 2044, cblack 1 0 2 2
IMG_0300.CR2: black 2044, cblack 1 2 1 0
IMG_0301.CR2: black 2043, cblack 3 2 2 0
IMG_0302.CR2: black 2044, cblack 1 1 3 0
IMG_0303.CR2: black 2045, cblack 0 1 1 1
IMG_0304.CR2: black 2043, cblack 2 0 3 1
IMG_0305.CR2: black 2044, cblack 1 0 3 0
IMG_0306.CR2: black 2044, cblack 1 1 1 0
IMG_0307.CR2: black 2044, cblack 0 0 3 1
IMG_0308.CR2: black 2045, cblack 0 0 0 0
IMG_0309.CR2: black 2042, cblack 3 0 4 3
IMG_0310.CR2: black 2044, cblack 1 1 1 0
IMG_0311.CR2: black 2044, cblack 1 1 0 0
IMG_0312.CR2: black 2044, cblack 1 2 1 0
IMG_0313.CR2: black 2042, cblack 3 5 4 0

For what it's worth I took another burst just a couple of minutes later (same settings except higher ISO) and all these files in that burst have exactly "black 2049, cblack 0 0 0 0"

Here is IMG_0298.CR2 http://www.mediafire.com/file/b2xzd3tit3gww85/IMG_0298.CR2

All cameras, we're talking about all cameras, well at least the modern ones, or at the very least the ones that are supposed to have a known offset, like Canon and 2048. There must be a good reason why you chose one method over the other, right? On the 0.17 release notes you wrote "LibRaw do not rely on hardcoded black levels", well, why not? Is it because hardcoded black levels are unreliable or is it because they can't be found for all camera models? That's what I'm asking, why did you choose to do it this way and not the "it's close to 512 or 2048 so let's set it to 512 or 2048" way? I think that's a pretty fundamental question.

Right, but the question remains, which is closer to ideal, the fixed 2048 offset or the measured black levels? Seems to me like using the masked pixels makes it quite prone to noise mostly at high ISOs, and that they deviate from the fixed offset in statistically insignificant ways (while the ideal offset might well remain the same), which is why I'm thinking the measured black levels should probably be disregarded entirely, except maybe as a hint of what the true fixed offset should be.

But since you're using the measured black levels instead then you must think that logic is wrong, this is what I'm asking about.

LibRaw tries to extract as much as possible from RAW.
Other software (e.g. in-camera JPEG processor) may crop more or less (it also may depend on camera/raw processor settings, for example barrel distortion correction on/off).

So, pixel level RAW/JPEG match looks not possible in general case

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.

In last master snapshot (https://github.com/LibRaw/LibRaw) we've added open_bayer() call

Look into: https://github.com/LibRaw/LibRaw/blob/master/Changelog.txt for docs
and into https://github.com/LibRaw/LibRaw/blob/master/samples/openbayer_sample.cpp for usage sample

Awesome, thank you very much!

Jan

There is no -d/-D keys in dcraw_emu

Use unprocessed_raw sample instead.

Hi Alex,

From what you said, it seems like the "white balance" is necessary before normal demosaic. If a user want to supply her/his own white balance factors, it can still be done through "user_mul[i]", correct?

Also, when I use "output_color = 0" and "half_size = 1" together (regardless other parameter), the image seems to look strange. Can you take a look at it?

Thanks so much and have a nice day!

Hi Alex,

I would like to use the RAW data without calling "dcraw_mem_image()"; however, there is still a need for demosaic. Currently, I have to use "dcraw_mem_image()" with the parameters listed before to get it as close as possible.

If there is a function that I can call to get the image data that only goes through demosaic step (with no other adjustment), that would be great!

Thanks,