[FIXED] possible bug -poly IM 6.8.6.3 Q16 Mac OSX

[fmw42]

Seems like -poly has a colorspace management issue when processing grayscale images.

If I convert rose: to grayscale and then use -poly with equal weights, it should look like the original, but it is lighter.

convert rose: -colorspace rec709luma rose_rec709.png


convert rose_rec709.png rose_rec709.png rose_rec709.png rose_rec709.png -poly ".25,1 .25,1 .25,1 .25,1" rose_rec709_polyequal.png

[magick]

• convert rose: -colorspace rec709luma rose_rec709.png
  convert rose_rec709.png rose_rec709.png rose_rec709.png rose_rec709.png -poly ".25,1 .25,1 .25,1 .25,1" rose_rec709_polyequal.png
  compare -metric rmse rose_rec709_polyequal.png rose_rec709.png null:
  0 (0)

A distortion of 0 means that rose_rec709.png has the same exact pixel values as rose_rec709_polyequal.png.

[fmw42]

This appears to be a problem only with the viewing of the PNG files. I see the same thing after processing with -enhance and -despeckle.

But if I save to jpg. They both view the same as the darker version.

I looked at the verbose information for the two png files and do not see anything different in the PNG properties. Both show as grayscale and gamma=1. Yet, they display

1) as above in my Mac Safari and Mac Preview -- before processing is dark and after processing with -poly is light (as if gamma=0.4545)
2) both view as the dark version in IM show: -- probably since the gamma=1
3) both view as the light version in Mac Firefox, Opera and Chrome -- perhaps assumes gamma=0.4545

I am using libpng 1.4.11

[magick]

Upgrade your release of libpng and its likely the problem will resolve itself. Otherwise, Glenn care to comment?

[fmw42]

Magick and Glenn

The real issue is that -colorspace rec709luma produces gamma=1 for output to PNG, but for JPG or by using -grayscale rec709luma for PNG, I get gamma=0.4545 as it should currently be for rec709luma (whereas rec709luminance should be gamma=1)


convert rose: -colorspace rec709luma rose1.png
Image: rose1.png
Class: PseudoClass
Colorspace: Gray
Type: Grayscale
Depth: 8-bit
Alpha: False
Channels: srgb
Rendering intent: Perceptual
Gamma: 1


convert rose: -colorspace rec709luma rose1.jpg
Image: rose1.jpg
Class: PseudoClass
Colorspace: Gray
Type: Grayscale
Depth: 8-bit
Alpha: False
Channels: gray
Rendering intent: Perceptual
Gamma: 0.454545


convert rose: -grayscale rec709luma rose2.png
Image: rose2.png
Class: PseudoClass
Colorspace: Gray
Type: Grayscale
Depth: 8-bit
Alpha: False
Channels: srgb
Rendering intent: Undefined
Gamma: 0.45455


Even adding -intensity before -colorspace does not help
convert rose: -intensity rec709luma -colorspace rec709luma rose3.png
Image: rose3.png
Class: PseudoClass
Colorspace: Gray
Type: Grayscale
Depth: 8-bit
Alpha: False
Channels: srgb
Rendering intent: Perceptual
Gamma: 1

But I would not think it should even be required to add -intensity before -colorspace, even though it does not work.

[fmw42]

Under libpng @1.5.13_0, it works fine for png.


convert rose: -colorspace rec709luma rose4.png
Image: rose4.png
Class: DirectClass
Colorspace: Gray
Type: Grayscale
Depth: 8-bit
Alpha: False
Channels: srgb
Rendering intent: Perceptual
Gamma: 0.454545


My problem is that I have many old releases that I use for testing changes in IM that do not work with this more current libpng.

[glennrp]

Upgrade your release of libpng and its likely the problem will resolve itself. Otherwise, Glenn care to comment?

I doubt that the libpng version bears on this problem.

[glennrp]

At line 8173 in coders/png.c we have

Code: Select all

  if (IssRGBCompatibleColorspace(image->colorspace) == MagickFalse)
    (void) TransformImageColorspace(image,sRGBColorspace);

-colorspace rec709luma does not get transformed to sRGB (gamma remains 1.0)
-grayscale rec709luma gets transformed. (gamma is transformed to 1/2.2)

Whether they look the same or different depends upon whether the viewing application
handles the PNG gAMA chunk.

In magick/colorspace-private.h we have

Code: Select all

static inline MagickBooleanType IssRGBCompatibleColorspace(
  const ColorspaceType colorspace)
{
  if ((colorspace == sRGBColorspace) || (colorspace == RGBColorspace) ||
      (colorspace == scRGBColorspace) || (colorspace == GRAYColorspace) ||
      (colorspace == TransparentColorspace))
    return(MagickTrue);
  return(MagickFalse);
}

If rec709luma is sRGB compatible, then "(colorspace == Rec709LumaColorspace) ||" should be added to this test.
Probably Rec601LumaColorspace as well.

[fmw42]

Upgrade your release of libpng and its likely the problem will resolve itself. Otherwise, Glenn care to comment?

I doubt that the libpng version bears on this problem.

Oddly, it does seem to work for libpng @1.5.13_0 if I have not made a mistake. See above

Fred

P.S. It also fails for -colorspace rec601luma with libpng 1.4.11 (gamma=1), but works fine for libpng 1.5.13 (gamma=0.4545)

[magick]

Glenn we'll fix colorspace-private.h per your recommendation. Thanks.

[fmw42]

In the latest 6.8.6.4 beta it works correctly now with libpng 1.4.11. -colorspace with either rec709luma or rec601luma now produce gamma=0.4545


imb convert rose: -colorspace rec709luma rose1.png
Image: rose1.png
Class: PseudoClass
Colorspace: Gray
Type: Grayscale
Depth: 8-bit
Alpha: False
Channels: srgb
Rendering intent: Undefined
Gamma: 0.45455

imb convert rose: -colorspace rec601luma rose2.png
Image: rose2.png
Class: PseudoClass
Colorspace: Gray
Type: Grayscale
Depth: 8-bit
Alpha: False
Channels: srgb
Rendering intent: Undefined
Gamma: 0.45455


Thanks, guys.