[Digikam-users] Dark Images for 16-bit raw and reconstructed highlights

[Paul Waldo]

Hi Alex,

I'm a bit confused, but maybe I'm comparing apples to oranges.  Let's say that I have an image that covers the entire dynamic range of my camera; I've recorded pixels that are slightly too dark to register, slightly too bright to be accurately captured and all brightnesses in between.  I have a fully populated histogram that looks like this:

|
|   +---------------\
|  /                 \
| |                   +
|-/                    |
+----------------------

Sorry, my ASCII art skills are a bit rusty these days :-)

If I use UFRaw to convert this image, I get an image that has a fully populated histogram, and the slightly blown highlights are recovered.  If I use digikam, what I get is a dark image with much of its information gone.  The entire image has moved down to the left, so that the brightest pixel is around 127, like this:

|
|---------\
|          \
|           +
|            |
+----------------------


If I then manually shift the histogram back to the right (gamma?) all of the pixels that should be at 0-127 are gone, like this:

|
|          |--------\
|          |         \
|          |          +
|          |           |
+----------------------

I've lost about half of the image's data.

Hopefully I'm just doing something wrong, but it doesn't make sense that I have to give up half of my image just to recover a few blown highlights :-)

Thanks for your thoughts!

Paul

----- "Alex Tutubalin" <lexa at lexa.ru> wrote:

> Paul,
> 
> to be precise: all LibRaw postprocessing code is derived from dcraw 
> sources. The only change is an ability to produce 16-bit
> gamma-corrected 
> data (dcraw's 16 bit output is linear).
> 
>  From my point of view, this code is non-perfect in terms of image 
> quality. On the other side, LibRaw is focused on RAW/metadata
> extraction 
> and pre-processing (before demosaic stage), there is no (near) plans
> to 
> change postprocessing stage.
> 
> > Thanks for the reply, Alex.  So, as I understand your comment,
> Highlight Recovery shifts the entire histogram to the left, allowing
> extra capture data in the highlights to roll in.  
> Not so easy. Different color channels on (every) digikam have
> different 
> sensitivity. So, when green channel is already clipped, there is some
> 
> details in red/blue ones (for daylight and neutral highlights, just an
> 
> example). So highlight recovery tries to recover clipped green channel
> 
> data via correlation with other channels.
> 
> So, we need to rescale data (for example from 0...16383 to 0..8191 to
> 
> get 1 extra stop), then try to reconstruct green pixels above 8191.
> 
> > * What happens to the shadow data that was on the left?  Does it
> drop off and get clipped to 0?
> >   
> Shadows are compressed
> > * Why not fix the highlights and shift the histogram back to where
> it was?
> >   
> Imagine some clipped and unclipped highlights. E.g. clipped cloud part
> 
> in range 255-255 (8bit values) and unclipped in range, say, 240-254.
> If 
> you recover clipped part to, say, 245-255, you need to shift unclipped
> 
> part to something like 230-245. If not, you'll get incorrect tonal 
> relations.
> 
> > * In 16 bit mode, why do we need to shift and darken at all?  The
> image is 12 bits, so all operations can certainly be performed in a 16
> bit space.
> >   
> before any processing, RAW data converted to working RGB and scaled to
> 
> full range.
> 
> 
> -- 
> Alex Tutubalin
> Web: http://blog.lexa.ru
> mailto:lexa at lexa.ru