Legacy ImageMagick Discussions Archive

(see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642098)

convert -density 300 test.pdf -colorspace RGB -resize 900 test.jpg lead to incorrect background color.

It is a regression.

Not tested with lasted upstream imagemagick but do not see solved in changelog

Bastien

Not a bug. Recent versions of ImageMagick use the Ghostscript pngalpha device to render PDF. The pngalpha device includes an alpha channel. To get the desired results, flatten the image:

• convert -density 300 -colorspace RGB test.pdf -flatten -resize 900 test.jpg

Sorry but jpeg has no alpha channel. Why not flatten by default ?

At least warning.

Bastien

Here, the flatten is required before the image is delivered to the JPEG coder. The resize algorithm considers alpha when resizing the RGB channels. Note, the user can change pngalpha to pnmraw in the delegates.xml configuration file and PDF's will always render without an alpha channel.

I understand but without flatten
pdf to png will be correct thanks to alpha channel whereas convertion from pdf to jpg with resize will be not correct.

magick wrote:Not a bug. Recent versions of ImageMagick use the Ghostscript pngalpha device to render PDF. The pngalpha device includes an alpha channel. To get the desired results, flatten the image:

• convert -density 300 -colorspace RGB test.pdf -flatten -resize 900 test.jpg

With more recent versions of IM (v6.7.5 onward), especially if multiple images are involved, use -alpha remove (default background color is white so the -background isn't really needed in this case)

See IM Examples, "Removing transparency form images"
http://www.imagemagick.org/Usage/masking/#remove
This also shows why you should remove alpha, BEFORE saving to JPEG...

broucaries wrote:I understand but without flatten
pdf to png will be correct thanks to alpha channel whereas conversion from pdf to jpg with resize will be not correct.

It is actually 'correct'. But transparenct colours are undefined. You just need to define what they should be.

However I agree that perhaps JPEG saving should apply a '-alpha remove' automatically as part of its coding sequence (especially now a memory efficient operator is available). I would think this should be a IMv7 coder change (in development), and NOT a IMv6 change. JPG transparency problem has been a well known IMv6 thing for far too long.

Note that this assumes that 'background' is actually set correctly (default is white). Who is to say that it is correct in all situations?

I do not think it should be automatic, since there is no universal background color. The background color is specific to the user's application and/or desires.