About clipping and dcraw_process() stretching to 65535

Submitted by Sylvain on

Hi.

You've already explained that clipping in raw data was difficult to detect (has different forms), and that clipping values may even depend on the color channel.

Imagine a theoretical picture, with, after pre_mul or cam_mul applied, has:
red clipping to 60000.
green clipping to 40000 (I consider g and g2 to have the same behavior).
blue not clipping, climbing up to 50000.

How does dcraw_process() -no_auto_bright=1- stretch this result to 65535?

I guess it can't stretch each channel independently, since this would mess the white balance.

Does it stretch 40000 to 65535, applying a multiplicator of 53535/40000 to each channel, and so adding some artificial clipping to red and blue?

Or does it stretch 60000 to 65535, applying a multiplicator of 65535/60000 to each channel?
In that case, there is no artificial clipping, and no data lost, but the information that green is clipping does not appear clearly to the library user...

Last hypothesis, it applies the 65535/60000 multiplicator to each channel, except for the blue values of 40000 which are artificially put to 65535?

Or anything I've not thought of?

Thanks again...
Sylvain.

Forums: 

То avoid colored highlights,

Submitted by lexa on

То avoid colored highlights, you need to clip all channels at same level (after wb applied).

So, if red clips at 60000 and green at 40000 (as in your example values), you need to clip all three channels at green clip level.
Without it you'll get colored (magenta in this case) highlights (and we *frequenly* see it in video, even in high-level, such as Formula-1 translation)

-- Alex Tutubalin @LibRaw LLC

So that's how cdraw_process()

Submitted by Sylvain on

So that's how dcraw_process() works in that case: clipping everybody to 40000, and stretching that from 40000 to 65535?