Re: [Gimp-developer] Exposure Operation

[Ville Sokk <ville sokk gmail com>]

If you want to vectorize code you should maybe also look at liborc.
Nicolas introduced it in IRC. The VIPS library uses it and VIPS's main
developer seemed very happy with it.

On Wed, Dec 19, 2012 at 4:47 AM, Michael Henning
<drawoc darkrefraction com> wrote:
> This looks good.
>
> The meta-op isn't really the right way to do things like this, so feel
> free to trash that.
>
> As for the point filter, you should make a git commit, and then use
> git format-patch to make a patch.
> Then, you can get your patch included in GEGL by either bothering
> people on irc to review the patch (that's the fastest), or filing a
> bug report.
>
> The gamma value thing is just a matter of convention - if you apply a
> gamma of x, then applying a gamma of 1/x will undo the change. I'm not
> sure which is preferred (avoiding taking the reciprocal should have
> slightly more numerical precision, and avoid dividing by zero.)
>
> You might want to discuss vectorizing your ops with mitch or pippin
> before you put a lot of work into it. If it decreases portability, it
> might be better to leave the code as is and hope the compiler
> autovectorizes.
>
> If you have any questions/comments, feel free to hop on IRC and ask.
>
>   -- drawoc
>
> On Tue, Dec 18, 2012 at 3:03 PM, Felix Ulber <f ulber web de> wrote:
>> Hi all,
>> I post this at the gimp-dev list cause I think more people read here and
>> this is closely related to the progression of the Gimp Application itself,
>> even if the core of all is GEGL.
>>
>> Being excited about the new high-bit depth capability I wrote an exposure
>> operation. It is somehow inspired by the equal-named photoshop operation. A
>> short explanation for anyone not that familiar with the use of it: This
>> operation is mainly important for manipulating hdr images, i.e. floating
>> point images containing values > 1. Working with such images, most of the
>> well-known operations (e.g. curves) doesn't work at all or at least don't
>> really make sense as they are based on the assumption the image is in an
>> absolute 0..1/black-white domain.
>>
>> The "exposure" operation has three components, that are applied in the
>> following order:
>>
>> Exposure:   a multiplier, the usual way to manipulate a hdr images'
>> brightness. This is implemented as a relative change, i.e. in a logarithmic
>> way (like f-stops)
>> Offset:     a constant value added, this can be used to shift the
>> black-level
>> Gamma:      gamma-correction. In this case used to influence the mid-range
>> values
>>
>> To summarize the components of the operation:
>>
>> out_val = in_val * (2^exposure)
>> out_val += offset
>> (clamp value to 0.0 because might have become negative)
>> out_val = out_val^(1/gamma)
>>
>> Some more reading:
>>
>> http://www.earthboundlight.com/phototips/photoshop-cs2-exposure-adjustments.html
>> http://www.francois-tarlier.com/blog/exposureoffsetgamma-photoshop-tool-to-shaders/
>>
>>
>> This is one of my first things in gegl, so some questions came up, also some
>> issues ihmo worth a discussion:
>>
>> As result values are not clamped in the positive direction, some thoughts
>> about the parameters that are worth thinking about:
>>
>> Gamma parameter is restricted to a range of 0.01 to 10 for now. Some
>> confusion came up about gamma calculation, cause I am sure gamma is
>> pow(value, 1/gamma), but e.g. gegl:gamma operation use it without the
>> inversion, also some other applications.
>>
>> Gain is not restricted for now, but cause it's exponential values get pretty
>> high, soon exceeding MAX_FLOAT. In Photoshop, pixel values seem to be
>> generally clamped to a value of 20 (or is just the palette no able to
>> display more?) which seem a little bit to restricted to me. Especially in
>> case of sunny day images (e.g. HDRI Sphere for cgi rendering).
>>
>> With negative offset values, negative pixel values may occur. This is
>> normally not wanted and in some cases the reason certain filters are not
>> suited well for hdr images. Values are getting clamped at 0.0 atm, but I
>> cannot say that I am glad with that. Any suggestions on that?
>>
>> For my own interest I implemented this thing both as a gegl meta-operation
>> and as a GeglOperationPointFilter operation. Apart from the fact, that doing
>> things like pow(2, value) is already kinda wicked in a GEGL graph, I was
>> really asking myself if the meta operation makes any sense at all
>> speed-wise. Because this contains 5 to 6 nodes (without i/o).
>>
>> Next thing for me is to make the main code use vectorization.
>>
>>
>> Code is here:
>>
>> http://pastebin.com/xYQYYXqX
>> http://pastebin.com/Rq5HWhbF
>>
>>
>> thanks for your interest
>> Felix (aka. kjaft)
>>
>>
>>
>> _______________________________________________
>> gimp-developer-list mailing list
>> gimp-developer-list gnome org
>> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
>>
> _______________________________________________
> gimp-developer-list mailing list
> gimp-developer-list gnome org
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list