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

Post any defects you find in the released or beta versions of the ImageMagick software here. Include the ImageMagick version, OS, and any command-line required to reproduce the problem. Got a patch for a bug? Post it here.

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

Postby fmw42 » 2013-07-05T17:14:18+00:00

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
Image

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
Image
Last edited by fmw42 on 2013-07-09T21:58:08+00:00, edited 1 time in total.
User avatar
fmw42
 
Posts: 14904
Joined: 2007-07-02T17:14:51+00:00
Location: Sunnyvale, California, USA

Re: possible bug -poly IM 6.8.6.3 Q16 Mac OSX

Postby magick » 2013-07-05T18:27:32+00:00

    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.
User avatar
magick
Site Admin
 
Posts: 9665
Joined: 2003-05-31T11:32:55+00:00

Re: possible bug -poly IM 6.8.6.3 Q16 Mac OSX

Postby fmw42 » 2013-07-05T18:54:24+00:00

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
User avatar
fmw42
 
Posts: 14904
Joined: 2007-07-02T17:14:51+00:00
Location: Sunnyvale, California, USA

Re: possible bug -poly IM 6.8.6.3 Q16 Mac OSX

Postby magick » 2013-07-06T05:40:23+00:00

Upgrade your release of libpng and its likely the problem will resolve itself. Otherwise, Glenn care to comment?
User avatar
magick
Site Admin
 
Posts: 9665
Joined: 2003-05-31T11:32:55+00:00

Re: possible bug -poly IM 6.8.6.3 Q16 Mac OSX

Postby fmw42 » 2013-07-06T07:04:11+00:00

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.
User avatar
fmw42
 
Posts: 14904
Joined: 2007-07-02T17:14:51+00:00
Location: Sunnyvale, California, USA

Re: possible bug -poly IM 6.8.6.3 Q16 Mac OSX

Postby fmw42 » 2013-07-06T07:43:05+00:00

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.
User avatar
fmw42
 
Posts: 14904
Joined: 2007-07-02T17:14:51+00:00
Location: Sunnyvale, California, USA

Re: possible bug -poly IM 6.8.6.3 Q16 Mac OSX

Postby glennrp » 2013-07-06T13:36:24+00:00

magick wrote: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.
User avatar
glennrp
 
Posts: 826
Joined: 2006-04-01T08:16:32+00:00
Location: Maryland 39.26.30N 76.16.01W

Re: possible bug -poly IM 6.8.6.3 Q16 Mac OSX

Postby glennrp » 2013-07-06T14:26:37+00:00

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.
Last edited by glennrp on 2013-07-06T14:52:40+00:00, edited 1 time in total.
User avatar
glennrp
 
Posts: 826
Joined: 2006-04-01T08:16:32+00:00
Location: Maryland 39.26.30N 76.16.01W

Re: possible bug -poly IM 6.8.6.3 Q16 Mac OSX

Postby fmw42 » 2013-07-06T14:45:49+00:00

glennrp wrote:
magick wrote: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)
User avatar
fmw42
 
Posts: 14904
Joined: 2007-07-02T17:14:51+00:00
Location: Sunnyvale, California, USA

Re: possible bug -poly IM 6.8.6.3 Q16 Mac OSX

Postby magick » 2013-07-06T15:31:22+00:00

Glenn we'll fix colorspace-private.h per your recommendation. Thanks.
User avatar
magick
Site Admin
 
Posts: 9665
Joined: 2003-05-31T11:32:55+00:00

Re: possible bug -poly IM 6.8.6.3 Q16 Mac OSX

Postby fmw42 » 2013-07-06T17:04:25+00:00

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.
User avatar
fmw42
 
Posts: 14904
Joined: 2007-07-02T17:14:51+00:00
Location: Sunnyvale, California, USA


Return to Bugs

Who is online

Users browsing this forum: No registered users and 10 guests