Dark Images for 16-bit raw and reconstructed highlights

[Paul Waldo]

Hi all,

I have been trying to figure out why my 16-bit raw image conversions are going dark on me: if I use "Highlights: Solid White", I get a decent image.  If I use "Highlights: Reconstruct", the image is significantly darker and the details are not as sharp.

I have looked at the dcraw man page, Digikam documentation and the Oracle of Google, but I can't find any mention of why highlights would cause an image to be dark.  If this is documented somewhere, please help me with a link.  How do you process raw files where you want to rebuild the highlights?  Any help would be appreciated!

Paul

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

This is a technical question for libraw athor. I CC him (:=)))

Paul please, you forget to mention which camera raw file you use...

Gilles Caulier

2009/5/6 Paul Waldo <[hidden email]>:

> Hi all,
>
> I have been trying to figure out why my 16-bit raw image conversions are
> going dark on me: if I use "Highlights: Solid White", I get a decent image.
>  If I use "Highlights: Reconstruct", the image is significantly darker and
> the details are not as sharp.
>
> I have looked at the dcraw man page, Digikam documentation and the Oracle of
> Google, but I can't find any mention of why highlights would cause an image
> to be dark.  If this is documented somewhere, please help me with a link.
> How do you process raw files where you want to rebuild the highlights?  Any
> help would be appreciated!
>
> Paul
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Paul Waldo]

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.  At that point it is up to the user to decide what to do with the extra data.  This brings up some questions:

* What happens to the shadow data that was on the left?  Does it drop off and get clipped to 0?
* Why not fix the highlights and shift the histogram back to where it was?
* 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.

The second question is the key, I suppose.  Maybe I have unrealistic expectations, but I would have thought that the extra highlight data would be used to figure out what to do with 8 bit highlights that would have been blown out.  By having a little more data above the 255 brightness level, one could apply a bit of a film-like shoulder to the highlights to keep them from blowing out.  This, I believe is what UFRaw does.

Gilles, the technical stuff is fun, but the bottom line is that when I use Highlight Restoration in 16 or 8 bit mode, I get a dark image.  I have tried to take this dark image and apply any number of Digikam tools to get it back to where it looks OK, but it always looks significantly worse that if I had done no highlight restoration.  Maybe you can shed some light on a good workflow for Resoration and raw files?

BTW, I am using Digikam and ShowFoto 0.10.0, trying to convert a raw file from my Digital Rebel.  Thanks for any help!

Paul

PS
I have confirmed that in Digikam, in an 8 bit mode conversion, the shadows do get clipped to 0, which is probably one of the reasons I am having trouble.  I took a well-toned raw image and 8-bit converted with no Highlight Recovery.  The resulting histogram looks good from 0-255.  When I return to the raw, but choose Highlight Recovery and convert to 8 bit, only approximately half of the histogram is there! 0-128 (approx.) has good values, but 126-255 is all zero!!!
 
----- "Alex Tutubalin" <[hidden email]> wrote:

> Hi,
>
> I'm not  digikam-users@ member, so this message will be rejected from
>
> list. Hope, you'll receive personal copies.
>
> LibRaw do _all_ processing in 16 bit. 16->8-bit conversion is made on
>
> final output stage. So, you should not see any difference (plus-minus
>
> 8/16 bit quality issues) for 8/16 bit modes.
>
> On the other side, highlights recovery WILL darker entire image:  you
>
> lower highlights values (to see details instead of clipped pixels), so
>
> you need to lower all other tones to preserve tonal correlations
>
>
> Gilles Caulier wrote:
> > This is a technical question for libraw athor. I CC him (:=)))
> >
> > Paul please, you forget to mention which camera raw file you use...
> >
> > Gilles Caulier
> >
> > 2009/5/6 Paul Waldo <[hidden email]>:
> >  
> >> Hi all,
> >>
> >> I have been trying to figure out why my 16-bit raw image
> conversions are
> >> going dark on me: if I use "Highlights: Solid White", I get a
> decent image.
> >>  If I use "Highlights: Reconstruct", the image is significantly
> darker and
> >> the details are not as sharp.
> >>
> >> I have looked at the dcraw man page, Digikam documentation and the
> Oracle of
> >> Google, but I can't find any mention of why highlights would cause
> an image
> >> to be dark.  If this is documented somewhere, please help me with a
> link.
> >> How do you process raw files where you want to rebuild the
> highlights?  Any
> >> help would be appreciated!
> >>
> >> Paul
> >>
> >> _______________________________________________
> >> Digikam-users mailing list
> >> [hidden email]
> >> https://mail.kde.org/mailman/listinfo/digikam-users
> >>
> >>
> >>    
> >
> >
> >
> >  
>
>
> --
> Alex Tutubalin
> Web: http://blog.lexa.ru
> mailto:[hidden email]

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

---------- Forwarded message ----------
From: Alex Tutubalin <[hidden email]>
Date: 2009/5/7
Subject: Re: [Digikam-users] Dark Images for 16-bit raw and
reconstructed highlights
To: Paul Waldo <[hidden email]>
Cc : digiKam - Home Manage your photographs as a professional with the
power of open source <[hidden email]>, Gilles Caulier
<[hidden email]>


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:[hidden email]
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[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" <[hidden email]> 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:[hidden email]

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Paul Waldo]

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" <[hidden email]> 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" <[hidden email]> 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:[hidden email]
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

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 <[hidden email]>:

> 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" <[hidden email]> 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" <[hidden email]> 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:[hidden email]
>> _______________________________________________
>> Digikam-users mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-users
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

On Tuesday 12 May 2009 15:20:25 Paul Waldo wrote:
> 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

I used HR successfully in the past, didn't use recently being more careful
when shooting. Could you post somewhere your RAW for testing?

m.
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[david-vj]

CONTENTS DELETED

The author has deleted this message.

[Paul Waldo]

Hi Mikolaj,

Sorry it took solong to respond, but I had hosting issues...
The original raw file can be found here:
http://www.waldoware.com/photo2009-02-26_18-52-30-000034.crw

I did a conversion using the defaults plus setting Highlights to Rebuild which is viewable here:
http://www.waldoware.com/photo2009-02-26_18-52-30-000034_highlights_rebuild.png

BTW, only two out of the four Highlights options cause this truncation of pixels.  Any ideas you have would be greatly appreciated!

Paul

----- "Mikolaj Machowski" <[hidden email]> wrote:

> On Tuesday 12 May 2009 15:20:25 Paul Waldo wrote:
> > 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
>
> I used HR successfully in the past, didn't use recently being more
> careful
> when shooting. Could you post somewhere your RAW for testing?
>
> m.
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[david-vj]

CONTENTS DELETED

The author has deleted this message.

[Paul Waldo]

Hi David,

Thanks for having a look.  I find that "Solid White" and "Blend" produce good results.  I get the dark image in "Unclip" and "Rebuild" mode.  Do you get the same results?

Paul
----- "davidvincentjones" <[hidden email]> wrote:

> Taking your raw data ... I applied my usual 'blend' plus 'auto
> brightness'
> and found the image anything but dark.
>
> My reading of the image indicated slightly blown highlights but a good
> black
> range. I do not by the way think that my process lost the highlight
> detail.
>
> Without using the 'auto brightness', and simply manually opening up
> the data
> provides a very similar result.
>
> Are you perhaps using an icc that is totally incompatible?
>
> David
>
>
> Bugzilla from [hidden email] wrote:
> >
> > Hi Mikolaj,
> >
> > Sorry it took solong to respond, but I had hosting issues...
> > The original raw file can be found here:
> > http://www.waldoware.com/photo2009-02-26_18-52-30-000034.crw
> >
> > I did a conversion using the defaults plus setting Highlights to
> Rebuild
> > which is viewable here:
> >
> http://www.waldoware.com/photo2009-02-26_18-52-30-000034_highlights_rebuild.png
> >
> > BTW, only two out of the four Highlights options cause this
> truncation of
> > pixels.  Any ideas you have would be greatly appreciated!
> >
> > Paul
> >
> > ----- "Mikolaj Machowski" <[hidden email]> wrote:
> >
> >> On Tuesday 12 May 2009 15:20:25 Paul Waldo wrote:
> >> > 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
> >>
> >> I used HR successfully in the past, didn't use recently being more
> >> careful
> >> when shooting. Could you post somewhere your RAW for testing?
> >>
> >> m.
> >> _______________________________________________
> >> Digikam-users mailing list
> >> [hidden email]
> >> https://mail.kde.org/mailman/listinfo/digikam-users
> > _______________________________________________
> > Digikam-users mailing list
> > [hidden email]
> > https://mail.kde.org/mailman/listinfo/digikam-users
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Dark-Images-for-16-bit-raw-and-reconstructed-highlights-tp23414351p23556239.html
> Sent from the digikam-users mailing list archive at Nabble.com.
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[gerlos]

On venerdì 15 maggio 2009 22:05:12, Paul Waldo wrote:
: > Hi David,
>
> Thanks for having a look.  I find that "Solid White" and "Blend" produce good results.  I get the dark image in "Unclip" and "Rebuild" mode.  Do you get the same results?

Just started playing with RAW data. I experimented on some of my shots and found the same thing, "unclip" and "rebuild" modes gave me dark images too.

regards,
gerlos

--
"Life is pretty simple: You do some stuff. Most fails. Some works. You do more
of what works. If it works big, others quickly copy it. Then you do something
else. The trick is the doing something else."
           < http://gerlos.altervista.org >
 gerlos  +- - - >  gnu/linux registred user #311588
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

2009/5/28 gerlos <[hidden email]>:
> On venerdì 15 maggio 2009 22:05:12, Paul Waldo wrote:
> : > Hi David,
>>
>> Thanks for having a look.  I find that "Solid White" and "Blend" produce good results.  I get the dark image in "Unclip" and "Rebuild" mode.  Do you get the same results?
>
> Just started playing with RAW data. I experimented on some of my shots and found the same thing, "unclip" and "rebuild" modes gave me dark images too.

As i said previously, i don't think it's a digiKam problem. We use
libraw (code based on dcraw) and i think that something is wrong in
post processing code from dcraw.

Can you reproduce this problem too if you use dcraw command line tool
with your raw picture ?

Gilles Caulier
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users