Recently I have started to review and compare the way the curves tool works in various packages, particularly in Photoshop, GIMP and my own PhotoFlow.
I personally think that there should be some harmonisation in the way the curve points are interpolated by the different softwares, so that for example a sentence like “pull the mid point 1/4 upwards” would produce the same result independently of the software being used.
Currently this seems not to be the case. Here are three examples of a curve obtained by inserting a point at the (57/255, 101/255) coordinate:
As one can see, the interpolations in the different softwares do not really match.
The interpolation done by PS and PhF seem to be quite similar, while the GIMP curve is much more straight, with a stronger curvature around the control point…
I need to do some more experimenting, but this should already give the general idea of what I am talking about.
I guess it will be very difficult to change the way the GIMP curves are defined, on the other hand I believe that a more standard curves behaviour would simplify the exchange of tutorials from one software to the other…
Yes…
But with Gimp you can enlarge the curves windows and get a far better control, even if necessary with more points: try to move your cursor exactly one pixel… take your glasses and greet Parkinson!
True… but with PS (and PhF) one can adjust the points both horizontally and vertically with the keyboard arrows (as far as I can see, GIMP only allows vertical adjustment, at least under OSX), as well as set the precise point position numerically.
Anyway, my post is not about accuracy of curve points placement, but consistency in the points interpolation. As a user, I do not want to add >10 control points in GIMP to reproduce a PS curve, I just want to set the same points and get the same curve…
And I think this might represent a limitation for people coming from the PS world and trying to include GIMP in their workflows.
Yep, I found that in choosing a spline algorithm for my stuff. Since I’m math-challenged, I went with the easiest to use, a simple cubic spline class: http://kluge.in-chemnitz.de/opensource/spline/. The way I have it set up, it doesn’t behave symmetrically intersecting 0,0 vs 255,255, but I’m leaving that rumination for when I have more time, e.g., in retirement, probably…
My priority has been on insuring the displayed spline accurately represents the lookup application to the pixels. So, in old rawproc I use the same spline algorithm to build the LUT, in new rawproc I look up the spline interpolation for each pixel tone since the image data is float.
So, I think interpolation consistency between softwares is only realistic if we discuss the spline algorithms…
Perfectly exact…
But how many PS users are concerned?
Most of them dont even know curves and use only levels…
2% of the 5% which use curves?
As a gimp user I am considered as a martian by the most photographers I know…
Getting the same results would require not only having a curve which behaves the same way, but also using the same math under the hood in the same colorspace.
The underlying math is almost trivial, as the tool simply maps input to output channel values…
As for the color space, you are right. But the same ambiguity exists when trying to reproduce a PS tutorial with PS itself. The right thing to do would be to specify the color space for which the curves adjustments are valid. In lack of this information, I think one can assume sRGB and be right in 99.999% of the cases…
Not understood the colorspace question…
Curves modify the values of the pixel, not the way the pixel values are showed or printed through the color space? or am I missing something?
That’s a tricky point… as soon as you apply non-linear adjustments to the RGB values, the resulting color depends on the colorspace in which the RGB values are defined.
In other words, the same curve gives a different output depending if the RGB values are, say, in sRGB or ProPhoto colorspace. This is both due to the different gamma encoding (ProPhoto has a simple gamma=1.8 TRC, while the sRGB TRC is more complex and is only approximately gamma=2.2) and the different primaries that define the colors that the colorspace can encode…
This is particularly true when curves are applied to individual RGB channels. Here is an example (the image data is in linear encoding just to remove the effect of the different gamma-encoding between sRGB and ProPhoto):
I don’t know how G’MIC Curves [interactive] will behave. But if you want to compare G’MIC Curves also, then the following is handy:
You can lock movement of control points on the curves in one direction:
Shift-left mouse button, only movement in y direction possible
Ctrl-left mouse button , only movement in x direction possible
(In Windows, I don’t know if it is the same on Mac)
I asked David for this months ago. Ten minutes later on, this functionality was existing. But the descriptions of these interactions weren’t updated, so maybe some people here don’t know this functionality.
