Legacy ImageMagick Discussions Archive

$ convert -version
Version: ImageMagick 6.7.1-0 2011-08-03 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2011 ImageMagick Studio LLC
Features: OpenMP

$ uname -a
Darwin Mactop.local 11.0.0 Darwin Kernel Version 11.0.0: Sat Jun 18 12:56:35 PDT 2011; root:xnu-1699.22.73~1/RELEASE_X86_64 x86_64

$ port installed | grep libpng
libpng @1.4.8_0

The file in question can be found at http://insidesystems.net/images/ribbon.png

The following command will cause part of the file to be blacked out in a strange way.
convert -background none ribbon.png -resize "x16" -colors 255 -depth 8 -type palettematte -gravity center -extent x48 -strip ribbon_out.png

Yet this command, which does nothing but change the resize and extents works ok
/opt/local/bin/convert -background none ribbon.png -resize "x22" -colors 255 -depth 8 -type palettematte -gravity center -extent x67 -strip ribbon.png

No amount of exporting to/from other formats appears to make a difference.

Your alpha channel which is almost pure opaque is needless and causing some of the problem.


The following seems to me to be a bug as I cannot get the transparency to show: Hopefully the PNG developer can comment further.


convert ribbon.png -strip -alpha off -resize x16 -colors 254 \
-background none -gravity center -extent x48 \
-depth 8 -type palettematte PNG8:ribbon_out.png


But this works fine as PNG32:


convert ribbon.png -strip -alpha off -resize x16 -colors 255 \
-background none -gravity center -extent x48 \
-depth 8 PNG32:ribbon_out.png

Code: Select all

convert ribbon.png -strip -alpha off -resize x16 -colors 254 \
-background none -gravity center -extent x48 \
-depth 8 -type palettematte PNG8:ribbon_out.png

You turned off alpha channel, and then expect IM to save an image containing actual transparency?

That does not seem right to me!

You turned off alpha channel, and then expect IM to save an image containing actual transparency?

That does not seem right to me!

It works fine when saving as PNG32 as noted above. Note that that a transparent border/extent is added to an opaque image and that generally works fine.

For example this works just fine:
convert rose: -alpha off -background none -gravity center -extent 100x100 rose_tmp.png

The issue seems to be with transparency in palettematte for PNG8.

But alpha channel will need to be enabled (or at least set to -alpha opaque) before you use -extent. If you don't there should not be a alpha channel for the transparency to use.

If the PNG32 output is working, then it is wrong, as far as I can see! Probably a bug in the PNG coder!
A image with alpha disabled should not save alpha, or if it does alpha should be fully opaque! -- it is disabled after all!

Not unless -extent has an auto-enable-alpha which it shouldn't.

Only a few operations has auto-enable-alpha, and these has special handling for that situation. Specifically -compose CopyOpacity, -clut (when -channel A is set and the clut image has alpha), and -transparent, and some animation specific operations.

Not unless -extent has an auto-enable-alpha which it shouldn't.

Seems to me that -border, -extent and -transparent all appear to have an auto-transparency enable when the background color is none. I have been working on that assumption for a long time and seems like it has worked that way as long as I have been using IM.

I think the thing that confuses me the most and indicates that this is a bug is that the result is not consistent (I think alpha or not is a red herring). Just changing how big the extents are shouldn't lead to the kinds of corruption that this appears to cause.



No amount of changing extents or resizing should cause this result, it's clearly wonky.

It does look like that is what is happening. Hmmm even flatten is now doing this... I used a display pipeline so as to avoid a possible PNG coder issue.

Hmm even border and frame is this way
convert rose: -alpha off -page 100x100+20+20 -gravity center -bordercolor none -border 10 miff:- | display -
convert rose: -alpha off -page 100x100+20+20 -gravity center -mattecolor "#8888" -frame 20x20+6+6 miff:- | display -


Seems to be a result of using commands that actually create a background canvas on which to overlay the source images! In other words canvas composition commands where the canvas color has alpha appear to be now auto-enable-alpha!

I think I would regard this as a good thing! Just wonder when the change happened! Looks like I have many warnings to remove, and extra notes to add.

I can tell you that this was NOT the case in older versions of IMv6! I had to add many warnings due to this those IM example commands!


So we are back to the PNG8 not preserving transparency.

kreynolds wrote:I think the thing that confuses me the most and indicates that this is a bug is that the result is not consistent (I think alpha or not is a red herring). Just changing how big the extents are shouldn't lead to the kinds of corruption that this appears to cause.



No amount of changing extents or resizing should cause this result, it's clearly wonky.

It has something to do with your non-constant, non-full opaque alpha channel. When made into palettematte it should only support binary transparency (either on or off). So what is happening is that the alpha channel is getting changed when resized and made into a palette with binary transparency. That was why I turned it off as it was essentially nearly fully transparent. Thus there was no need for the alpha channel and any conversion to binary transparency would not cause such an effect of masking out some of your image, which was replace with black rather than fully transparent by the apparent bug.

The corruption however appears to caused by -colors 255 as it is at that point the the right half of ribbon does black!

For example this is also 'corrupt' and is probably what should have been originally reported!!! input:
output:

This I would regard as a major bug, and has nothing to do with resize, extent, transparency, png coder, or other operators!

convert ribbon.png -colors 255 ribbon_bad.png

Can you really have 255 colors when there is a grayscale (non-binary) alpha channel? Do you have to reserve room for those alpha values from the 255 colors?

It seems to work fine if you turn off alpha.

This works just fine:

convert ribbon.png -alpha off -colors 255 ribbon_test.png

The save is nothing to do with pusedo color, or output.

-colors is suposed to just reduce the number of colors in an image (including transparent or semi-transparent colors).. Not that in the original there was any alpha channel!

This has nothing to do with transparency.

StarTrek NG, Data's Day wrote:Data: "I could be chasing an untamed ornithoid without just cause!"
Dr Crusher: "Errr... A wild goose chase?"

produces the same signature whether the output is png, png32, txt, or miff.
So I don't think it's a PNG bug. If you convert it to PNG8 then the
transparency naturally disappears because PNG8 thresholds the
transparency and in this image they are all nearly opaque so they
get thresholded to opaque.

glennrp wrote:

Code: Select all

convert ribbon.png -colors 255 output

produces the same signature whether the output is png, png32, txt, or miff.
So I don't think it's a PNG bug. If you convert it to PNG8 then the
transparency naturally disappears because PNG8 thresholds the
transparency and in this image they are all nearly opaque so they
get thresholded to opaque.

Glenn,

Try

convert ribbon.png -alpha off -colors 255 \
-background none -gravity center -extent x48 \
-depth 8 -type palettematte ribbon_out.png

or

convert ribbon.png -channel rgb -separate -combine -colors 255 \
-background none -gravity center -extent x48 \
-depth 8 -type palettematte ribbon_out.png

the output has black instead of transparent on the top and bottom.


Fred

The reason I did not report just -colors 255 as the bug was because changing the resize/extent made the image properly (though kinda ugly) appear again. It seemed a useful place to start a diagnostic process but it looks like we're narrowing down the cause regardless.