[Gimp-developer] Exposure Operation

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:



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:


thanks for your interest
Felix (aka. kjaft)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]