Legacy ImageMagick Discussions Archive

I upgraded from 6.8.0-6 2012-11-20 Q16 to 6.8.4-1 2013-03-25 Q16 and something went awry. It is near a -clut (image and lut are grayscale), or maybe a -channel -separate -combine sequence. I wasn't paying enough attention and lost both my exact original script and the previous install. Is there a way to download older binaries?

I only know about archives for source code. But you have not even identified what platform you are using and what version you want to back down to.

I am on Windows. I had version 6.8.0-6 2012-11-20 Q16. I did look in the ftp for old binaries with no luck. I also checked the changelog but didn't find a mention of -clut changing. I have only the weekend to explain how I was so sloppy with version control.

Isn't this what backups are for?

I put a Windows version 6.8.3-0 on Dropbox, https://www.dropbox.com/s/l7evmxggzij4f ... atic.exe?m , if that's any help.

Thank you snibgo, that version does fix my issue. And backups, yes, good idea... At least the issue wasn't all in my head, as I was beginning to worry. On to investigate what happened between 6.8.3-0 and 6.8.4-1.

There is definitely a large change in output between these two recent versions. Thanks to the old binary I was able to narrow down the problem. out_683.png is 16-bit x 1 channel and otherwise as I expect. out_684.png is 3 channel (with no apparent need) and too bright. In this example it appears to be caused by -clut, but somehow it may be change to how you treat colorspace.
Here is what I was doing. It was successful in the past, but maybe not the best method. I have a color image. I separate it into three channels, beginning with -set colorspace RGB to avoid the automatic linearization during grayscale conversion. I then use a 16-bit, 1-channel lookup table and -clut to apply a "curve" correction to each channel. This used to produce three 1-channel images I would combine back into a single 3-channel image. Now it produces three 3-channel images that are each brighter than expected. Is there a better way, or any ideas on what has changed recently that may catch others off guard?

Your clut file shouldn't do anything -- the output file should be the same as the input file. And that's what happens with 6.8.3. However, the output from your 6.8.4 is different; it is lighter.

I did read somewhere that 6.8.4 onwards did something different with RGB/sRGB on monochrome images. Sure enough, if we change your 6.8.4 command to ... ... the output is now visually the same as the 6.8.3 command.

I conclude that 6.8.4 tries to convert either the input file, or the clut file, or both, to RGB before applying the clut operation. This is despite both images being greyscale and (we are told) IM assumes greyscale images are RGB.

I feel I have a decent understanding of color spaces, gamma, profiles, etc, and am thankful they are supported. Yet I am constantly confused by the treatment of 1-channel images. I keep getting caught by automatic color space/gamma conversions and channels getting bumped back to 3. Maybe it is because I think of them as data sets to be mathematically operated on rather than gray-scale images, or maybe I am just inexperienced. Is there an ImageMagick primer on this somewhere?

There are no one channel images in IM 6. That will come in IM 7. Any grayscale image really has 3 equal channels in IM 6. As for the colorspace changes, see

http://www.imagemagick.org/script/forma ... colorspace
viewtopic.php?f=4&t=21269

fmw42 wrote:As for the colorspace changes, see
http://www.imagemagick.org/script/forma ... colorspace

The first sentence of that reference claims that PNG assumes sRGB. It doesn't.
If there is no colorspace information (gamma, chromaticity, ICC, sRGB chunk) PNG
assumes that the colorspace is undefined. Some applications (browsers)
might assume sRGB if the image isn't marked with colorspace information. I believe that
ImageMagick currently assumes that unmarked PNG images that contain any non-gray
color are sRGB and all-gray unmarked PNG images are linear.

The PNG spec doesn't have much to say about handling unmarked images except
for this: "When the incoming image has unknown gamma (gAMA, sRGB, and iCCP all
absent), choose a likely default gamma value, but allow the user to select a new one
if the result proves too dark or too light. The default gamma may depend on other
knowledge about the image, for example wheter it came from the Internet or from
the local system."

glennrp wrote:I believe that ImageMagick currently assumes that ... all-gray unmarked PNG images are linear.

However, in this example, IM knows the images are all-grey ("-verbose" says colorspace=gray and gamma=1), but we need "-set colorspace RGB" to prevent a conversion.

I think snibgo has confirmed my observation that there has been a recent change in behavior here, likely related to assumed colorspace. And the fact that my test script, the documentation, and glennrp's knowledgeable understanding are all in conflict only goes to show that I'm not the only one confused here.

Knowing that "Any grayscale image really has 3 equal channels in IM 6" helps me think about the problem. It is also a good suggestion to use -verbose and -print ("%r - %[colorspace] - %[channels]\n" or other escapes) to help see what is going on. Does -print only look at the first image in the sequence? With this help in hand I will attempt further experimenting today.

For me, I'm staying with 6.8.3-0 for now.

To restate, I give -clut two grayscale inputs. The output is:
v6.8.3: 1 channel .png, values as expected
v6.8.4: 3 channel .png, values too high

Can someone please check my understanding of these different fixes:

in_16bit-1chan.png lut_16bit-1chan.png -clut -colorspace RGB out1.png
MAE vs v6.8.3 = 0 (0) - Meaning this is what v6.8.3 is really doing?
Somewhere there is a colorspace conversion, so I convert back?

in_16bit-1chan.png lut_16bit-1chan.png -clut -type Grayscale out2.png
MAE vs v6.8.3 = 0.00465839 (7.10824e-008)
Somewhere there is a colorspace conversion, so I convert back?

in_16bit-1chan.png lut_16bit-1chan.png -set colorspace RGB -clut out3.png
MAE vs v6.8.3 = 0.226708 (3.45934e-006)
I prevent colorspace conversions in the first place, making this the most accurate result?

So v6.8.4 converts all 1-channel .png files to sRGB when read in? -clut fails me because both files are colorspace converted, effectively yielding a double conversion on the output?

We have a patch for the -clut grayscale problem in ImageMagick 6.8.4-6 Beta.

GreenKoopa wrote:So v6.8.4 converts all 1-channel .png files to sRGB when read in?

Not when read in, no. The conversion occurs when certain operators are executed. In this case, it is the "-clut" operator. IM says to itself, "This operator needs greyscale images to be in RGB space. It is currently sRGB, so I need to convert it."

Personally, I think the concept of treating greyscale differently to colour images is flakey. For example, if I have a low saturation colour image and some operation might eliminate the saturation, IM might realise the image is now greyscale and apply different processing. Different quantum-versions (Q8, Q16 or floating-point) will eliminate saturation at different levels, so will give different results.

I have to overcome this with "-set colorspace RGB" to prevent conversions, and should generally finish with "-set colorspace sRGB" before the final output so IM will write the correct metadata to the file.

GreenKoopa wrote:-clut fails me because both files are colorspace converted, effectively yielding a double conversion on the output?

I don't know which file (or both) are converted. I would need to experiment. I can't see any justification for ever converting the CLUT file. A "unity" clut file, such as your example, should result in the output being the same as the input, for all inputs.