Legacy ImageMagick Discussions Archive

I can confirm that the current beta fixes this problem for us. Thanks.

The cause here is apparently that the builtin svg renderer assumes that x==y if y is not specified in e.g. transform="translate(-168)". If I expand that to transform="translate(-168, 0)" the image looks perfectly fine. According to https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/transform ...

We're indeed using the "builtin" SVG coder, and not rsvg or Inkscape, since those have way too many dependencies for our taste. Actually the Image as rendered by ImageMagick 7.0.8 is a marked improvement over 7.0.7, in that the `<use transform=` statements have an effect at all, it's just that the ...

I'm afraid I can't provide a simple command line (i've tried various mixes of -stip, png:include-chunk and png:exnclude-chunk with a few test images, but none show the undesired behaviour) or even program code to reproduce, but we've noticed that in ImageMagick 7.0.7-3, sometimes the iCCP chunk is ...

It doesn't surprise me that the image is not according to spec, however I'd prefer if Imagemagick were able to handle these Images more gracefully. My primary problem is that at the moment, this kind of error is not detectable with PHP/imagick, and I've filed a separate bug report at https://bugs ...

convert -debug mentions: Coder (GIF) generated an image despite an error (425), notify the developers 2016-10-06T12:06:42+02:00 0:00.000 0.000u 7.0.2 Configure convert[3933]: utility.c/ExpandFilenames/943/Configure Command line: convert {/tmp/pages.gif} {-debug} {all} {-} 2016-10-06T12:06:42+02:00 0 ...

While the usual browsers display a transparent background for the GIF image http://canavan.de/imbugs/pages.gif , imagemagick displays (or generates an output image with) a black background. Additionally, convert (tested with 6.8.9-9 and 7.0.2-9) complains: convert: invalid colormap index `/tmp/pages ...

I'd prefer it to round to 1 instead of 0. Throwing an exception is still OK if the user explicitly specifies a width or height of 0.

This behaviour was considered a bug in the past, for example in viewtopic.php?t=9082

convert with -resize / -scale aborts with a NegativeOrZeroImageSize error if an image is reduced in size and one dimension is rounded down to zero. I'm using ImageMagick 7.0.2-6 on Ubuntu x64 16.04. Examples: $ convert -size 1000x1 xc:red -resize 49% /tmp/r.png convert: NegativeOrZeroImageSize `red ...

Thanks. I've verified that your patch fixes the issue I've described here.

That patch works for me. Any chance to get it into future ImageMagick releases?

As I understand it (I could be wrong), MagickWandGenesis() and MagickWandTerminus() should be called only once per program. Calling those just once doesn't change the behaviour for me. Does that change have any measurable results for you? If the API is sane, it shouldn't matter how often ...

For PNGs with palette and alpha, the reuslt of MagickIdentifyImageType() randomly varies between 5 and 7. Tested with ImageMagick 7.0.1-3 and ImageMagick 7.0.1-6. A small test program is below, it fails with any image (with alpha) generated by pngquant; the image of a motorcycle on the right on ...

Please, always mention your IM version and platform.

I did build the current release (6.9.3-7) just to verify, the problem exists at least since 6.8.9-9 as shipped with Ubuntu 15.10.

While -scale and -size both produce images that have the problem, an image created with -xc:red[16x16] does not.

Creating a monochrome image with xc, scaling it to an arbitrary size and saving as an XPM results in an output file with as many palette / colormap entries as pixels, each used only once in the image. As an example, a 16x16 image scaled from a 1x1 'red' xc: canvas would have 256 colormap entries ...