Legacy ImageMagick Discussions Archive

Hello all--

I am using ImageMagick to convert tif files with clipping paths to png files. Here is the command that I have been using, and it generally works fine:

convert testfile_01.tif -alpha transparent -clip -alpha opaque -strip -format png -quiet testfile_01.png

The idea is to preserve the transparencies in the tif input when converting to the png format. I am finding that some areas are being converted to white backgrounds instead of transparent backgrounds. The problem is not consistent, but there is a common thread. If the transparent area is completely surrounded by opaque image, it may or may not convert properly. I also find that the same areas in a given image fail every time. Some images exhibit the problem while others do not.

Here is an example:


As you can see, the area outside of the bag handles is transparent, but the area inside the handles is not, and it should be.

The original tif file can be found here: https://dl.dropboxusercontent.com/u/354 ... ile_01.tif

I am using the following version on Red Hat Enterprise Linux Server release 6.5:
Version: ImageMagick 6.5.4-7 2012-04-10 Q16 OpenMP http://www.imagemagick.org

Any suggestions are welcome. Thank you very much for your help.

The "holes" in the path need to be described in the opposite direction to the outer path nodes.

For example, if the main outline of the suitcase is listed with the nodes clockwise, then the nodes that describe the gaps under the handle should be listed anti-clockwise.

This is probably why some of your tiffs convert well but others don't.

Thanks very much for your reply. This may be the clue we've been looking for.

A followup question on this subject:

Can ImageMagick detect the paths that are incorrectly listed? Is there any way to get an error message when the problem occurs?

Many thanks.

IM can't tell you directly.

You can extract the path with "identify -verbose testfile_01.tif". This has a single path with various sections. Each "z" means close the section. See http://www.w3.org/TR/SVG/paths.html#Pat ... toCommands for "M", "C" etc.

There is an algorithm that you can feed a cyclic set of coordinates in, and it tells you if the points go clockwise or anti-clockwise. From vague memory, it's easy to implement, but I can't remember even the name. Sorry.

Then you might check that a long path goes in one direction while all the others go the opposite way. You could even check that they don't intersect, all the small paths are within the large one, etc.

Your next question is: Can we automatically reverse the problem sections? Answer: you could write the revised path to a text file, but I don't know how to get the path back into the image file. IM can't do it. I don't think exiftool can do it. My best guess is Gimp. Possibly a Python script can both extract a path and replace it.

The question (putting a path into a raster image file) often comes up, so if you find an answer, please share here.

On automatically catching the problem: Your result images probably should not contain many pixels that are exactly white. If a large proportion of pixels are white, the file probably has this problem.

We can find the proportion that are exactly white, using the image in the OP: 9.1% of pixels are white, which is very high. Good quality photos have no more than 0.1% of pixels white.

Thanks for this, snibgo. I will look at some of our results to see if looking at the percentage of pure white pixels is a good predictor. At least it gives me an avenue to explore.