Burned highlights is bad, because it means that information is lost. There
are methods for reconstructing that information back. Rawtherapee, which I
just installed to test this, has a method called "Color propagation". From
what I understand, it uses surounding pixels in the burned area to
reconstruct the burned components.

For example, this is a sample picture I tested with. Opened in rawtherapee,
enabled highlight reconstruction, and set exposure to -1.
In darktable, enable highlight reconstruction LCh, threshold of 0,830.
Exposure to -1. Enabled velvia to get similar saturation result.

You can see that a lot of detail is recovered. There's still some magenta
there, but I'm sure that on less extreme burns, it would get it right.

CR2: https://www.dropbox.com/s/fkzymeor14ypmfx/IMG_0450.CR2
Darktable: https://www.dropbox.com/s/z3cbbgvf848sdhc/IMG_0450_Darktable.jpg
Rawtherapee:
https://www.dropbox.com/s/cf1p8nfxmo3l36s/IMG_0450_Rawtherapee.jpg

I wonder how hard it could be to port that recovery method into Darktable.

Julian.



On Thu, Jun 6, 2013 at 5:17 PM, Chris Siebenmann <c...@cs.toronto.edu> wrote:

> | Something that I now find that is more effective is the use of the
> | channel-mixer along with blentif. I also am using the lightness tab to
> | select the brightest pixels and then I pull the red values slightly
> | back which gives the blue values a chance to be seen.
> |
> | I have however become a lot more cognicent of the problem during the
> | shooting session in an effort not to have to deal with this situation
> | later on.
>
>  As far as I can see the only real way to deal with this during the
> shooting session is to underexpose significantly[*], unless I'm missing
> something. The current state of affairs really seems to be that
> bright but unclipped highlights will be shoved into over-exposure by
> darktable's base curves (and sometimes other processing); to avoid this
> you must avoid bright highlights in the RAW, ergo underexposure.
>
> (It is easy enough to see this happen by turning on overexposure markers
> and then flipping back and forth in the initial history stack between
> 'sharpen' and 'base curve'. The difference in my sample NEF is quite
> striking.)
>
>  If I had a suitable step wedge test chart, I would actually do the
> experiment to find the first stop of highlights that darktable's Nikon
> base curves push into blown highlights. Someone familiar with the code
> and the base curves wouldn't even need to do any tests. My guess is that
> the important thing to know is the L level that is effectively blown;
> base curves themselves are relatively readable in src/iop/basecurve.c.
>
>         - cks
> [*: here I mean 'underexpose well beyond the point needed to avoid
>     hard clipping'.]
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> Darktable-users mailing list
> Darktable-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/darktable-users
>



-- 
http://www.julianmenendez.es
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
Darktable-users mailing list
Darktable-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/darktable-users

Reply via email to