Re: [Gimp-developer] Exposure Operation

[Felix Ulber <f ulber web de>]

To be honest - for the first step I was only thinking about getting the
compiler to autovectorize that stuff (or at least parts of it). This is
the first time I mess around with that so I have to see what is possible.

Any other thoughts on the whole hdr and negative values topic?

Cheers
Felix (kjaft on irc)

Am 19.12.2012 09:33, schrieb Ville Sokk:
> 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