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@xxxxxxxxxxxxxxxxxx> 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@xxxxxx> 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@xxxxxxxxx >>> https://mail.gnome.org/mailman/listinfo/gimp-developer-list >>> >> _______________________________________________ >> gimp-developer-list mailing list >> gimp-developer-list@xxxxxxxxx >> https://mail.gnome.org/mailman/listinfo/gimp-developer-list _______________________________________________ gimp-developer-list mailing list gimp-developer-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gimp-developer-list
