heya, some stuff interleaved below:
On Sat, Nov 2, 2013 at 1:33 AM, Moritz Moeller <virtualr...@gmail.com>wrote:
> On 1/11/13 12:55 PM, Robert William Hutton wrote:
> > Sounds to me like what you really want to do is raise the gamma
> > rather than raise the exposure.
>
> Gamma is a non-linear modification that has no equivalent in real world
> photography.
>
> Exposure is a well understood concept (multiplication with a fixed
> number) that maps directly to the real world.
> Then you want to manipulate the full tonal range of the resulting image,
> possibly bringing parts that were pushed >1.0 back into to 0..1 range to
> recover detail.
>
> Of course, you can partly express this with a gamma curve, that is:
> anything that was shifted outside 0..1 and the brought back into that
> range. But if you want to keep 5% of your pixels still overexposed gamma
> won't let you do this. Lastly, it is anything but intuitive, in the OP's
> use case.
>
> Furthermore, when you want to work on parts of the tonal range and leave
> the rest absolutely fixed, you need a lot of points on the tone curve
> and it becomes fiddly and unintuitive.
>
> I think the (between the lines) feature request of the OP is to extend
> the working tonal range of the highlights/shadows module, by a certain %
> or automagically, to the highest value present in the image.
>
> So for highlight recovery, there would be modes of working:
>
yes. highlight recovery, not shadows+highlights (just to be clear).
>
> - Normal (current code, clips at 1.0, no way to recover values pushed
> outside that range by previous modules in the pipe or present in the
> original image)
>
it currently clips at processed_maximum, which keeps track of earlier
modules. so if you push exposure to 2ev, it'll clip at 4.0, not 1.0.
> - Auto (highlight tonal region extends beyond 1.0, to highest value in
> image)
>
not sure i understand that correctly, but i think that's how it works
today. output values of the highlight recovery module can be way > 1.0 (as
for most other modules).
> - Extended (user defined % of values above 1.0 becomes part of
> highlights tonal range, i.e. 80% means highlights can go up to 1.8, etc.
> Maybe this needs to be a an exponential slider, instead of % though)
>
yeah, i don't get that. probably because 1.0 doesn't really have a
significance for the module itself, only for the srgb 8-bit output at the
very end of the pipe. you can always get your high values back through a
vignette or similar near the end of the pipe.
>
> Does that make sense.
>
probably i'm just missing something..
-jo
>
> .mm
>
>
>
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> _______________________________________________
> darktable-devel mailing list
> darktable-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/darktable-devel
>
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
darktable-devel mailing list
darktable-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/darktable-devel
