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

[Gilles Caulier]

Same here with MRW. At least, Blend method work in some situation.
Uclip give strange effect too, but work sometime. Rebuild give violet
colors...

It's typically LibRaw code. Nothing is done here in digiKam. To be
sure, try to use dcraw or better, libraw command line test programs
(generated with libkdcraw in test dir)

Gilles

2009/5/12 Paul Waldo <paul at waldoware.com>:
> Has anyone in the Digikam community had good results with Highlight Rebuild?  I just can't get it to work without destroying my image :-(
>
> Paul
> ----- "Paul Waldo" <paul at waldoware.com> wrote:
>
>> 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
>> _______________________________________________
>> Digikam-users mailing list
>> Digikam-users at kde.org
>> https://mail.kde.org/mailman/listinfo/digikam-users
> _______________________________________________
> Digikam-users mailing list
> Digikam-users at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-users
>