Crazy background color change for different crop sizes

[jaciones@gmail.com]

Confirmed on:

Mac OSX:
Ubuntu 14:04:

Version: ImageMagick 6.9.2-6 Q16 x86_64 2015-11-22 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2015 ImageMagick Studio LLC
License: http://www.imagemagick.org/script/license.php
Features: Cipher DPC OpenMP
Delegates (built-in): fontconfig freetype jbig jng jpeg lzma openexr pangocairo png tiff webp x xml zlib

Repro:
Download source "png" from [https://s3.amazonaws.com/boregon/weird_example.png][/https://s3.amazonaws.com/boregon/weird_example.png]. This PNG has a transparent background.

now run:

convert weird_example.png -resize "1028x1028" output.jpg

Output has white background

run:

convert weird_example.png -resize "1200x1200" output.jpg

Output has black background.

Background color seems to be dependent on resize params?

[fmw42]

JPG does not support transparency. You need to specify the background that the image should be flattened against.

try

Code: Select all

convert weird_example.png -resize "1028x1028" -background white -flatten output.jpg

convert weird_example.png -resize "1200x1200" -background white -flatten output.jpg

[jaciones@gmail.com]

Sure, but it is expected behavior that different size constraints have different color outputs?

I was surprised that happened and found it unintuitive and took me quite some time to debug and distill down to the simple example above. Felt like a bug (perhaps a minor one).

[fmw42]

I do not know why it happens without -background ... -flatten. One of the IM developers would have to comment.

[geitda]

I noticed the same thing when I was converting a PNG to a 1:1 size JPEG as well as a resized version.
Windows 7 64-bit; Version: ImageMagick 6.9.3-0 Q16 x64 2016-01-02

Code: Select all

convert example.png example.jpg                          //white background, via automatic flattening?
convert example.png -resize 200x200 example.jpg          //black background, via ???
convert example.png -resize 200x200 -flatten example.jpg //white background, via "-flatten" work-around

This happens either with my own PNG, as well as OP's "weird_example.png"
The first command gives me a white background just as I expected, but the second gives me black.
Adding "-flatten" works fine ("-background white" is redundant because that's what the default is anyway) as a work-around, but I wouldn't expect different results just because I added "-resize 200x200"
I think that the apparent automatic flattening from PNG to JPEG in the first command should apply all of the time, or maybe even none of the time, but it should be consistent, as it's the inconsistency that bit me.
Also, it looks like OP didn't really find "different size constraints" because 1028x1028 isn't a resize, as it's a match to the original file's dimensions. I would guess IM optimized the resize out of that command, making it equivalent to my first example above. Hope this observation helps track down the difference.

[snibgo]

I don't know why the behaviour is inconsistent.

weird_example.png from the OP has transparent black pixels. When resized, they remain transparent black. When saved as a JPEG, I would hope IM would simply ignore the alpha channel, and save those pixels as opaque black. I don't know why the unsized save results in white.

[geitda]

I'm not sure why you think the weird_example.png file has transparent black pixels, because it definitely has has transparent white pixels, as reported by

Code: Select all

identify -verbose weird_example.png

Code: Select all

    611753: (131,195, 65,255) #83C341FF srgba(131,195,65,1)
--snip--
    312316: (255,255,255,  0) #FFFFFF00 srgba(255,255,255,0)
    120004: (255,255,255,255) #FFFFFFFF white

There is no #00000000 in the histogram, therefore there are no transparent black pixels. The background is the #FFFFFF00 (white, alpha 00).

I can confirm that convert is simply dropping the alpha in the non-resizing invocation as I changed the transparent white to transparent grey in the original (the PNG format that uses the PLTE palette chunk makes this change trivial, thankfully) and tried again with the background coming out the correct grey. This means the bug is definitely related to the -resize operator ignoring transparent pixels and sending them to black.

[snibgo]

I used Gimp eyedropper on weird_example.png, which reported the pixels outside the circle as being transparent black. However, "unerase" in Gimp turns them white. I've never seen that happen before.

[geitda]

To save someone else lots of testing time, I ran the basic convert command 48 ways with combinations

Code: Select all

convert [-background color] [-alpha Mode] [-flatten] [-resize wxh] weird_example.png weird_example.jpg

For -background, I tried leaving it out and using "white" and "#FFFFFF00"
For -alpha, I tried leaving it out and using "Background", "Opaque", and "Remove"
For -flatten it was either included or omitted
For -resize it was either included or omitted

Code: Select all

-background      -alpha  -flatten  -resize      Result
         No          No        No       No  Underlying
      white          No        No       No  Underlying
  #FFFFFF00          No        No       No  Underlying
         No          No        No      Yes       Black
      white          No        No      Yes       Black
  #FFFFFF00          No        No      Yes       Black
         No  Background        No       No  Underlying
      white  Background        No       No       White
  #FFFFFF00  Background        No       No       White
         No  Background        No      Yes       Black
      white  Background        No      Yes       Black
  #FFFFFF00  Background        No      Yes       Black
         No      Opaque        No       No  Underlying
      white      Opaque        No       No  Underlying
  #FFFFFF00      Opaque        No       No  Underlying
         No      Opaque        No      Yes  Underlying
      white      Opaque        No      Yes  Underlying
  #FFFFFF00      Opaque        No      Yes  Underlying
         No      Remove        No       No  Underlying
      white      Remove        No       No       White
  #FFFFFF00      Remove        No       No       Black
         No      Remove        No      Yes  Underlying
      white      Remove        No      Yes       White
  #FFFFFF00      Remove        No      Yes       Black
         No          No       Yes       No  Underlying
      white          No       Yes       No       White
  #FFFFFF00          No       Yes       No       Black
         No          No       Yes      Yes  Underlying
      white          No       Yes      Yes       White
  #FFFFFF00          No       Yes      Yes       Black
         No  Background       Yes       No  Underlying
      white  Background       Yes       No       White
  #FFFFFF00  Background       Yes       No       Black
         No  Background       Yes      Yes  Underlying
      white  Background       Yes      Yes       White
  #FFFFFF00  Background       Yes      Yes       Black
         No      Opaque       Yes       No  Underlying
      white      Opaque       Yes       No  Underlying
  #FFFFFF00      Opaque       Yes       No  Underlying
         No      Opaque       Yes      Yes  Underlying
      white      Opaque       Yes      Yes  Underlying
  #FFFFFF00      Opaque       Yes      Yes  Underlying
         No      Remove       Yes       No  Underlying
      white      Remove       Yes       No       White
  #FFFFFF00      Remove       Yes       No       Black
         No      Remove       Yes      Yes  Underlying
      white      Remove       Yes      Yes       White
  #FFFFFF00      Remove       Yes      Yes       Black

I don't really know what this means, other than to say that the only sure-fire way to get the underlying color is to use "-alpha Opaque" and to get the color you ask for you will have to specify "-background color" and use "-flatten" so that it will work regardless of the "-resize" parameter.