Legacy ImageMagick Discussions Archive

Here's the image I'm working on:

http://i421.photobucket.com/albums/pp29 ... roblem.png

Here's the MS_DOS command line:

convert "IM_Effect_Smoke_problem.png" -background transparent -crop 64x64+0+64! "IM_Effect_Smoke_problem_crop.png"

The problem is that ImageMagick reduces the color depth to 8 bits and ignores or destroys the alpha channel.

Can anyone tell me how to fix this? Thanks!!!

leave off the -background transparent and that works fine for me on IM 6.7.6.9 Q16 Mac OSX Snow Leopard.

convert IM_Effect_Smoke_problem.png -crop 64x64+0+64\! result.png


I am not sure -- on windows you may need to escape the ! differently. See http://www.imagemagick.org/Usage/windows/


You did not say what version of IM you are using. If old, it may be time for an upgrade.

Background is just a setting (which is often saved with some image file formats like GIF), But you are not using it for the image processing operation!

I see you using a 'viewport' crop, which if the crop is inside the image, eliminates the need for +repage.
Note however that if part of the crop is beyond image bounds, a viewport produces a layer image of the crop area, needing a -flatten or other 'fill' virtual canvas operation to fill in the missing part of the viewport.


You command works find for me, with the latest IM. Transparency is preserved!

fmw42 wrote:leave off the -background transparent and that works fine for me on IM 6.7.6.9 Q16 Mac OSX Snow Leopard.

convert IM_Effect_Smoke_problem.png -crop 64x64+0+64\! result.png


I am not sure -- on windows you may need to escape the ! differently. See http://www.imagemagick.org/Usage/windows/


You did not say what version of IM you are using. If old, it may be time for an upgrade.

I am using ImageMagick-6.7.6-9-Q16-windows-dll. Removing the "-background" flag does not fix the problem. The Resulting image is still 8 bits instead of 32. Can someone with Windows test this?

[edit]
Never mind! The problem is with XnView. It thinks the cropped image is 8 bits. Every other viewer I just tried displays the image properly.

See here: http://newsgroup.xnview.com/viewtopic.p ... 15#p103215

I would still like to know why this occurs only with some images and not with all, as well as a way to disable this behavior. Why is IM converting the image into a grayscale PNG instead of the full 32bit RGBA format?

Post an image and the command line that fails. Also look at the input and output image formats to see what depth they are. My test on your earlier image, showed that both were 1-bit images with 8-bit alpha and not 32-bits. Perhaps I misunderstand your problem. So please explain a bit more clearly.

For example from your first post:


identify -verbose IM_Effect_Smoke_problem.png
Image: IM_Effect_Smoke_problem.png
Format: PNG (Portable Network Graphics)
Class: DirectClass
Geometry: 64x128+0+0
Resolution: 28.34x28.34
Print size: 2.25829x4.51658
Units: PixelsPerCentimeter
Type: Bilevel
Base type: Bilevel
Endianess: Undefined
Colorspace: sRGB
Depth: 8-bit
Channel depth:
gray: 1-bit
alpha: 8-bit
Channel statistics:
Gray:
min: 0 (0)
max: 0 (0)
mean: 0 (0)
standard deviation: 0 (0)
kurtosis: 0
skewness: 0
Alpha:
min: 0 (0)
max: 252 (0.988235)
mean: 40.0162 (0.156926)
standard deviation: 64.4649 (0.252804)
kurtosis: 2.18834
skewness: -1.77857
Alpha: none #00000000
Colors: 253
Histogram:
4095: ( 0, 0, 0, 0) #00000000 none
107: ( 0, 0, 0, 3) #00000003 srgba(0,0,0,0.0117647)
99: ( 0, 0, 0, 2) #00000002 srgba(0,0,0,0.00784314)
71: ( 0, 0, 0, 1) #00000001 srgba(0,0,0,0.00392157)
61: ( 0, 0, 0, 4) #00000004 srgba(0,0,0,0.0156863)
...

So this image is completely black with an 8-bit alpha channel. Thus to be exact bilevel matte. Though I don't think IM labels the matte even though it is there.

After cropping, the result was exactly the same.

Neither image was 32-bit as png. Note IM will automatically reduce the image format to the minimum type upon output (as I understand it).

fmw42 wrote:Post an image and the command line that fails. Also look at the input and output image formats to see what depth they are. My test on your earlier image, showed that both were 8/1-bit images and not 32 or 24 bit. Perhaps I misunderstand your problem. So please explain a bit more clearly.

Sorry I edited my previous post while you were responding. Please refer to it again. Also, a sample image and command line are given in my first post.

Here's what I think is happening:

1. All my input images are 32 bit RGBA.
2. When using the command line in my first post, the resulting files are all 32 bit RGBA, as they should be, except for the example I provided.
3. The example image is instead outputted (I assume, based on the response I've gotten over at the XnView forums) as 8 bit grayscale plus 8 bit transparency, for a total of 16 bits instead of 32.
4. XnView can't render this odd format properly.

[edit]

fmw42 wrote:Neither image was 32-bit as png.

You mean, neither the input nor the output images are 32 bits? This is odd because XnView properly displays the input image and reports it as 32 bits. If the input and output images were identical then wouldn't I be experiencing the same problem in both cases?

fmw42 wrote:Note IM will automatically reduce the image format to the minimum type upon output (as I understand it).

How do I disable this?

posfan12 wrote:

fmw42 wrote:Neither image was 32-bit as png.

You mean, neither the input nor the output images are 32 bits? This is odd because XnView properly displays the input image and reports it as 32 bits. If the input and output images were identical then wouldn't I be experiencing the same problem in both cases?

fmw42 wrote:Note IM will automatically reduce the image format to the minimum type upon output (as I understand it).

How do I disable this?

Yes, both the input and output images that I tested above show 1-bit bilevel with 8-bit alpha according to the IM verbose info. See the info above.

As far as I know, you cannot force it to 32-bits. You can try either or both -type truecolormatte or PNG32:output. But neither seem to work for me.

convert input -crop ... -type truecolormatte PNG32:output



You need to hear back from the PNG developer, glennrp, and see what he says. He may know of a way around it.

posfan12 wrote:The Resulting image is still 8 bits instead of 32. Can someone with Windows test this?

[edit]
Never mind! The problem is with XnView. It thinks the cropped image is 8 bits. Every other viewer I just tried displays the image properly.

IM may actually save it using indexing, as all the colors are black, and it is just 8bit alpha, making a total of 256 posible colors for depth 8, even in 32 bit (3 color channels + alpha) But I did not think IM PNG coder did this. But then again their has been quite a bit of work on the coder in the last few month.

I just ran into the same problem, but with "ImageMagick 6.7.5-10 2012-05-23 Q16" adding -type truecolormatte PNG32:output worked perfectly. Thank you!

Edit: It worked when scaling to 32x32 pixels, but not when scaling to 16x16 pixels. How odd.

Works:
find . -iname '*.png' -execdir convert "{}" -type truecolormatte PNG32:output -resize 32x32 "size32/{}" \;
Doesn't work:
find . -iname '*.png' -execdir convert "{}" -type truecolormatte PNG32:output -resize 16x16 "size16/{}" \;
Source and resulting files are all here: http://www.robotplanet.dk/f/imagick/death_note.rar