Fred's ImageMagick Curves script to duplicate PS curves

[fmw42]

I used this set of break points in my curves script and in PS.

curves -s 255,255 "0,18 31,19 64,62 86,100 110,139 124,159 142,181 161,200 194,223 250,255 255,255" wedding.jpg wedding_curves.png

Since your input image has no profile, but is marked sRGB, when I imported it into PS, I told PS to not add any color management. I then input those same breakpoints into PS curves and saved the image as wedding_ps_curves.png

Then I ran IM compare

compare -metric rmse wedding_curves.png wedding_ps_curves.png null:
1255.87 (0.0191634

This shows about 1.9% rmse difference.

Here are the two images for visual comparison.

My curves script


PS Curves


The main difference I see is that PS whites are oversaturated and show less detail in the wedding dress.

[jkeilson]

Ah ok that makes sense. I will give this a shot as well and compare with hald.

[michael.huber.1841]

Sorry for replying to this old thread. But this could be interesting for anybody that wants to emulate/duplicate photoshop curves within ImageMagick:

I developed an own method that does not need any crypted spline-methods, weird linux-scripts or some other difficult stuff. Just download the following grayscale-gradient (256x1 pixel) which is in fact just a perfect gradient from black to white):

http://s13.postimg.org/6z26t56av/grayscale_gradient.png

Then apply your curves in photoshop to that image. This will shift the grayscale values perfectly and uses the interpolation photoshop uses internally. Save the result to "grayscale-gradient-curve.png". In fact, this is a clut (color lookup table) that holds the information of shifting the values from x to f(x). Exactly like curves works in general.

To apply the curves-effect, use ImageMagick:

Code: Select all

convert original.png grayscale-gradient-curve.png -clut output.png

(If you would take the "grayscale_gradient.png" as clut, this wouldn't have any effect. It's neutral, shifting 0=>0, 1=>1 etc.)

Don't use "-haldclut" here! We have to use "-clut" here because of shifting every channel (red, green, blue => in fact grayscale images) separately.

Hope that helps! It was a lot of energy to solve this kind of problem for me. And it is much faster than "fx" or any polynomial function ("-function polynomial").

[fmw42]

Thanks for posting your method.

The equivalent process using a HALD image and -hald-clut works just a well.

[michael.huber.1841]

Of course it does. But if I understand "-hald-clut" correctly it does shift whole color-values (so all 3 components of a pixel) and interpolates between them if one color isn't found directly in the lookup-table. But "clut" works on one component separetly - exactly like curves on single channels work (e.g. red).

[fmw42]

clut applies whatever -interpolate setting you specify. The default is probably bilinear. You would need to use nearest-neighbor to avoid the effect you mention. I do not know, but expect that -hald-clut uses the -interpolate setting as well. I would be surprised if PS did not interpolate via the spline it does to fill in the control points on its curve.

You can process each channel separately in PS on either a gradient or a HALD image.

I think you get better color matching with an appropriate size HALD image than with a linear gradient, since the HALD image has more possible color values than any reasonable size linear gradient. If you make your HALD image big enough, it will cover every possible color for R, G, B with 8-bits color each. So then there is no need to interpolate.

[michael.huber.1841]

The curves that I want to simulate from photoshop have about 13 control points in each channel. There are no adjustments in the curves-dialog on the "rgb"-channel. In my opinion a grayscale-clut is the perfect solution because it covers all possible shiftings. In every channel, there are max. 256 possible shiftings. So total: 3*256 = 768 key/value-pairs.

The result proof my considerations: I can't see any visual difference from photoshop to imagemagick applying these kind of curves.

I just wanted to show an interactive way in photoshop of solving this problem. It's much easier than doing some complicated math.

[michael.huber.1841]

Or in other words: why trying to replicate the interpolation of photoshop when it's easier to use photoshop itself.

[snibgo]

I don't use Photoshop, but do use Gimp.

In Gimp, the Curves tool can't do any more than IM's "-clut". Gimp is only 8-bit/channel. So a grayscale clut can be attached to an image (say, along the bottom). Then the entire image manipulated with Gimp curves. Then IM extracts the clut, and applies it to the full-size 16-bit or 32-bit image.

To me, the point of scripts like Fred's isn't to force me to think about polynomials. It is because 95% of my cluts are created automatically.

Hald-cluts can do things that ordinary cluts, and curve tools, can't do. For example, changing one hue to another while leaving others alone.

[fmw42]

The purpose of my script was simply a way for others who do not have PS to do something similar to what curves does in PS. Of course, if you have PS and want to duplicate the results as closely as possible in IM the clut or hald-clut is the way to go.

With regard to the clut approach, if you only have a 256 pixel 1D gradient/clut, then you only have 256 possible colors. The rest have to be interpolated. That would be true even if you had a several thousand pixel 1D gradient. With a hald image and hald-clut, you can have 256*256*256 colors, which then covers every possible color in a 24 bit color image. So no interpolation is needed.

But usually a clut is visually adequate and using Snibgo's method of attaching a gradient to the bottom of the image is a clever way to process the image once without having to reprocess the clut separately. I suppose one could do the same by appending a HALD image to the image and processing it once in PS, so long as the appended image was PNG and not JPG. However, that would increase the size of the image to process considerably, whereas using a 1D gradient takes much less space.

[fmw42]

P.S. I believe that snibgo has a way to extract the clut directly from GIMP and apply it (perhaps after some massaging) in IM. Perhaps he can comment.

[snibgo]

I wrote an (unpublished) C program that reads Gimp's data file of curves. This is easy as the file is text. It then creates channel curves of any Nx1 size in memory from these points using linear segment, linear regression, polynomial or Bezier spline. Then it writes the channel curves as a PPM file, which IM can use directly or convert to PNG or whatever.

I find cluts intuitive. They are easy to convert to or from graphs. After a little experience it is easy to look at a curve and visualise the effect on an image.

Cluts are closely related to histograms, which are the same Nx1 data structure, and can easily be derived from them. The algebra of cluts is straightforward (identity cluts, cluts of cluts, making inverse cluts, and so on).

Cluts are also closely related to some forms of displacement maps, and the same processing applies to both.

Cluts are one-dimensional structures. Hald-cluts have three-dimensions. (IM stores them as 2D images, but they are really 3D.) I can't look at a hald-clut and visualise the effect on an image. They are more difficult to make automatically.

Given a hald-clut that will transform image A into image B, it should be possible to create the inverse hald-clut that transforms B into A, but I haven't figured out how.

Given two versions of the same image, created using colour manipulations, it should be possible to create a hald-clut that transforms either into the other, but again I haven't figured out how.

Hald-cluts are also bigger, of cousre. An 8-bit clut needs 256x1 = 256 pixels but the hald-clut needs 256x256x256 = 16m pixels. For 16 bits, the numbers are 65536 for the clut, and 281 tera pixels for the hald-clut.

Part of my problem with hald-cluts is that I don't know how to fill in holes. If we know only a few points on an ordinary clut, we can complete the curve using splines or whatever, and these are easily implemented in scripts or C. But if we know only a few points on a hald-clut, I don't know how to fill in the gaps.

[michael.huber.1841]

Thanks a bunch for all the great responses!

Is there any speed benefit to use "clut" instead of "hald-clut"? What's the faster way?

[fmw42]

I would not know without testing. So try testing yourself and let us know.

My guess would be that if there is any difference, it would be in favor of clut simply because the lut is smaller and reading it is faster. But that is just a guess.

[snibgo]

A quick test:

Code: Select all

convert large.tiff -size 1x65000 gradient: -clut h.tiff
convert large.tiff hald:6 -hald-clut h.tiff

The clut is much faster, even though hald:6 is smaller than the clut. I don't know why hald is much slower.