Legacy ImageMagick Discussions Archive

Hi everyone,

perhaps my problem will eventually dissolve into thin air once a more recent version of IM gets available through the Debian repositories (I'm on 6.7.7-10 2012-11-06 for Sid), but I keep wondering about a certain aspect of colorspace handling.

Apparently, many of you already have encountered the problem that grayscale images, which are -- according to identify output -- in sRGB, turn out too dark when converting them and saving them as png. The commonly found explanation is that IM is so smart that it assumes grayscale images to be intended to be linear, even though they were initially non-linearly encoded. Depending on the IM version in question, various combinations of colorspace settings or operations have been proposed to circumvent this problem, and with the IM version I'm stuck with setting the "working colorspace" to RGB seems to do the trick.

Alas, when doing something like "convert -set colorspace RGB in.png out.png" on a non-grayscale sRGB image, out.png turns out too light!

Of course, it would be possible to force a linear RGB working colorspace only for grayscale input images, but that would require determining whether in.png is grayscale or not before applying the actual conversion -- something I find kinda clumsy and which I'd seriously like to avoid.

So the question is: Is there (or will there be) a way to treat sRGB input png images so that their conversion results will *never* be too dark or too light and *always* be sRGB, no matter if the input is grayscale or not?

Curious about your opinions --

tcrass

I never liked the way grey images were treated radically diffferent to nearly-gray images. The problem seems to be resolved in v6.8.5.

For v6.7.9 onwards, but before 6.8.5, the general technique was: I don't know if this was the case in 6.7.7.

color space changes started at about 6.7.6.6 until about 6.7.7.7. grayscale changes started at 6.7.8.3 until about 6.8.4.0

snibgo wrote:I never liked the way grey images were treated radically diffferent to nearly-gray images. The problem seems to be resolved in v6.8.5.

I sure hope it is! (Or, at least, the treat-grayscale-as-linear smartness should be only optional.)

snibgo wrote:For v6.7.9 onwards, but before 6.8.5, the general technique was:

Code: Select all

convert input -set colorspace RGB {do the processing} -set colorspace sRGB output

I don't know if this was the case in 6.7.7.

Nope, it doesn't. Grayscale images still turn out too dark using the above command structure.

Anyway, I wonder where to put those colorspace settings (and how many of them) in more complex cases of image processing, possibly involving nested image sequences. I mean, IM command lines quite easily get really long and complex, and the requirement to sprinkle them with additional colorspace settings would not exactly help to improve their readability...

fmw42 wrote:color space changes started at about 6.7.6.6 until about 6.7.7.7. grayscale changes started at 6.7.8.3 until about 6.8.4.0

<sigh/>I really do hope that Debian will soon switch to the 6.8 branch...

Regards --

tcrass

I can't advise on 6.7.7 as I don't have it.

For 6.8.5, it seems that the general command ... ... where input is sRGB (grayscale or colour), and {some-processing} might or might not strip colour but doesn't include the word "colorspace" ...

... then the output will be sRGB, and IM will not convert pixel values from sRGB to RGB, or vice versa.

We can deliberately create an RGB greyscale image, eg: This will convert pixel values (lowering them), and mark the file as RGB. IMdisplay displays this correctly. Other viewers and image editors (eg Microsoft Photo Viewer and Gimp) ignore the RGB setting, assume the file is sRGB, and display it too dark.

Post a link to your image and your command line, so we can test with it.

• glenn.rp> pngcrush -n -v r1.png
  Reading IHDR chunk, length = 13.
  Reading gAMA chunk, length = 4.
  Reading bKGD chunk, length = 2.
  Reading IDAT chunk, length = 397.
  Reading tEXt chunk, length = 37.
  Reading tEXt chunk, length = 37.
  Reading IEND chunk, length = 0.
  
  IHDR chunk data:
  Width=100, height=100
  Bit depth =16
  gamma=1.000000

Using Version: ImageMagick 6.8.5-6 2013-05-14 Q16
Looks OK to me. It's properly marked with a
gamma=1.0 chunk to indicate that it's linear RGB. It's true that some
applications ignore the gAMA chunk; you can complain to their maintainers
about that.

Yes, that's exactly what I was saying.