Exposure Operation
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
| Exposure Operation | Felix Ulber | 18 Dec 20:03 |
| Exposure Operation | Michael Henning | 19 Dec 02:47 |
| Exposure Operation | Ville Sokk | 19 Dec 08:33 |
| Exposure Operation | Felix Ulber | 19 Dec 18:34 |
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:
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 parametersthat 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 senseat 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.
Codeis here:
http://pastebin.com/xYQYYXqX http://pastebin.com/Rq5HWhbF
thanks for your interest Felix(aka. kjaft)
Exposure Operation
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 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 valuesTo 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
Exposure Operation
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 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 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 valuesTo 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
Exposure Operation
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 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 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 valuesTo 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
