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.
after updating the ImageMagick version (6.9.1-4 -> 7.0.1-5) the output of certain image files is .. different. As far as I could narrow it down it affects PNG images using transparency. The newly created image's transparency has been replaced by a solid black.
This can be reproduced with this picture https://upload.wikimedia.org/wikipedia/ ... tion_1.png and the following conjure/msl-code (the actual code in use is different, but in my tests it did occur using this minimalistic version as well):
I am using the ImageMagick-7.0.1-5-portable-Q16-x64 build for Windows (Win 8.1, Win Server 2008R2).
Any information on why this is happening and / or a way to solve this will be greatly appreciated.
I can't reproduce this problem on my platform (Ubuntu 14.04, IM-7.0.1-6-Q16). I get the same transparent image out. IM does add some ancillary chunks, including a white bKGD chunk, but those are OK. Can you post the result of
File: PNG_transparency_demonstration_1_why_black.png (235187 bytes)
chunk IHDR at offset 0x0000c, length 13
800 x 600 image, 32-bit RGB+alpha, non-interlaced
chunk gAMA at offset 0x00025, length 4: 0.45455
chunk cHRM at offset 0x00035, length 32
White x = 0.3127 y = 0.329, Red x = 0.64 y = 0.33
Green x = 0.3 y = 0.6, Blue x = 0.15 y = 0.06
chunk bKGD at offset 0x00061, length 6
red = 0x00ff, green = 0x00ff, blue = 0x00ff
chunk IDAT at offset 0x00073, length 32768
zlib: deflated, 32K window, maximum compression
chunk IDAT at offset 0x0807f, length 32768
chunk IDAT at offset 0x1008b, length 32768
chunk IDAT at offset 0x18097, length 32768
chunk IDAT at offset 0x200a3, length 32768
chunk IDAT at offset 0x280af, length 32768
chunk IDAT at offset 0x300bb, length 32768
chunk IDAT at offset 0x380c7, length 5494
chunk tEXt at offset 0x39649, length 37, keyword: date:create
chunk tEXt at offset 0x3967a, length 37, keyword: date:modify
chunk IEND at offset 0x396ab, length 0
No errors detected in PNG_transparency_demonstration_1_why_black.png (15 chunks, 87.8% compression).
Compared to the original
File: PNG_transparency_demonstration_1.png (218144 bytes)
chunk IHDR at offset 0x0000c, length 13
800 x 600 image, 32-bit RGB+alpha, non-interlaced
chunk IDAT at offset 0x00025, length 218087
zlib: deflated, 32K window, superfast compression
chunk IEND at offset 0x35418, length 0
No errors detected in PNG_transparency_demonstration_1.png (3 chunks, 88.6% compression).
Edit: there was rubbish. Of course I should expect the transparency to change when transforming an image from png to jpg.. .but I was expecting it to be a white background instead (like in the older version I was using). So more fitting questions would have been:
* has there been any change to the default transparency fill color between versions and
* is there any way to define such a color using conjure.
Both do not qualify as bugs to me.. I am going to check the docs regarding these topics. Sorry again.