Legacy ImageMagick Discussions Archive

I have a strange ImageMagick (6.7.4) bug on Lion server that is converting some PDF's to a black jpeg while converting other PDF's to jpeg without incident. I am using the following script in my PHP code.
I also get the same results in Terminal on Lion Server when I manually issue the "convert" command.

The script works fine on my Linux server which is running Image Magick 6.3.7.2-6.1

I setup MySQL,PHP, and Apache on a Lion Server via this tutorial:

http://akrabat.com/php/setting-up-php-m ... 10-7-lion/

I then installed ImageMagick 6.7.4 via MacPorts.

I also noticed that if I remove the "-resize" option from the script on my Lion server I do not get the black jpeg. But I need the "-resize" option.

Does anyone know why I am experiencing this "black" jpeg conversion on Lion server but not on my Linux server? I would prefer to run my PHP application on Lion Server. Thanks.

can you post a link to one of the PDF files that causes trouble?

Note jpg does not support transparency. Perhaps your pdf has transparency and jpg will make it the background color under the transparency which is usually black.

Also check if your PDF is in CMYK rather than RGB colorspace. It is possible that -resize may have problems with CMYK, though I am just guessing here.

best if you post a link to your PDF file so we can check its verbose info

I am noticing the black converted jpeg is common with PDF's exported from Preview. This is the convert command I use in my PHP script. I ran this manually in Terminal with the same results.
Let me know if you can download the "apple.pdf" file. If not can you recommend where I can upload the PDF file for you? Flick, Photobucket, and Imgur do not allow me to upload PDF files. I am puzzled why I am not having an issue on my Linux server. Thanks.

Original PDF (apple.pdf)
https://viewer.zoho.com/docs/bnblK


Converted JPG File on Linux Server (Image Magick 6.4.3.6-9.1)




Converted JPG File on Lion Server (Image Magick 6.7.4)

I have downloaded it. I will try to work on it later today. I don't have time this morning. I don't know why you need the -append as there is only one page.

Your pdf has transparency, so you probably need to flatten it against a white background.

I use the "-append" because I run my PHP script against several documents directories and the majority of them have many PDF files. I am just using one PDF file for testing purposes.

I have a PHP web application that stores documents (the majority being PDF's). Users will scan a document to PDF via Preview (now they have Macs) then upload the PDF to the documents directory of my PHP application. Do they need to do something differently when scanning now? That is really going to throw a monkey wrench in the work flow they have established.

The bigger mystery is why this is not an issue on the Linux Server (Image Magick 6.4.3.6-9.1) while it is an issue on Lion Server (Image Magick 6.7.4)

Thanks for looking into this.

Magick, see below if you read this. Fred

__________________________________________________________

The append should not hurt if only one image.

As I said your image is grayscalematte meaning that it is grayscale but has an alpha channel that is similar to the background image, but it has lots of black areas that you seem to be getting when converting. The alpha channel seems to be doing antialiasing.

If I repeat your command, I get results like you on my Mac OSX Snow Leopard and IM 6.7.4.9 Q16.

However, you can flatten the alpha channel against a white background, since jpg does not support alpha channels and is likely putting black where the alpha is transparent.

This seems to work fine for me, except that no matter how I process your image, I get the right side cut off. I cannot explain that. I don't know why you are getting different results on different computers, but it could be the version of IM or Ghostscript and the ghostscript device set in your delegates.xml file. Ghostscript can handle one or the other of the following: either 1 page with transparency or multiply pages without transparency. You have to set the device in the delegates.xml file for whichever you want. I believe it should be set to pngalpha if you want one page with transparency.

Try this.


convert -density 200 apple.pdf -append -resize 850 -background white -flatten apple.jpg

or even this

convert -density 200 apple.pdf -background white -flatten apple.jpg


Then you can see what I mean about your alpha channel doing both of these:

convert apple.pdf -alpha off apple_aoff.png

convert apple.pdf -alpha extract apple_alpha.png


I don't know why your pdfs are being generated with alpha channels. But you can do the flatten against white to make it look right. It won't hurt if there is no alpha channel.

Anything further I would have to defer to the IM developers.


With regard to the cutoff right side, I see that PREVIEW reports it as 11x8.5 inches with a media and crop box of 792x612, but IM sees it as 8.5x11 inches and size 612x792 . Something is wrong (backwards) here and this probably is the cause of my cutoff result. Looks like IM is reading the width and height related parameters backwards from Preview.


Image: apple.pdf
Format: PDF (Portable Document Format)
Class: DirectClass
Geometry: 612x792+0+0
Resolution: 72x72
Print size: 8.5x11
Units: Undefined
Type: GrayscaleMatte
Base type: GrayscaleMatte
Endianess: Undefined
Colorspace: RGB


Magick -- if you see this, can you verify if this is an IM bug or not.

Fred

This command works:

• convert -size 2200x1700 xc:white -density 200 -page 792x612 apple.pdf -flatten -resize 850 apple_converted.jpg

ImageMagick produces a transparent rendering if the PDF includes a transparent component and you need -flatten to remove the transparency. You can modify the delegates.xml configuration file and change the ps:alpha delegate to use the pnmraw device to render all PDF's without transparency.

The apple.pdf file includes two media boxes and chooses the second 612x792 rather than the first @ 792x612. We added a patch to ImageMagick 6.7.5-0 Beta to choose the correct media box. In the mean-time you can force the correct media box with the -page option.

Magick --- thanks for looking into this. It had me puzzled.

So this works as an interim solution but is image dependent:

convert -density 200 -page 792x612 apple.pdf -append -resize 850 -background white -flatten apple.jpg


and the error is that the file has two media boxes with conflicting sizes! So that points to a bad PDF in some sense. However, if I understand what you are saying, you have a patch for IM for the next version to somehow determine which is the correct value.

Thanks

Fred

I also wanted to add that I accessed the Apple PDF via Safari at this link.

http://www.apple.com/pr/library/2012/01 ... sults.html

I then opened it from Safari to Preview and then exported to my desktop.

I am going to try those "convert" commands that you posted. I also have a few TIFFS I need to convert from time to time.

Thanks.

P.S. - Do you recommend that I continue to use Mac Ports for Image Magick or the binary?

P.S. - Do you recommend that I continue to use Mac Ports for Image Magick or the binary?

If you do not need to have the very most latest release of IM, then use MacPorts as it will allow you to add more delegates than the IM binary. Adding delegates manually is a real pain with some delegates as each delegate may need other support delegates. So using MacPorts makes it easy as they know all the support delegates that are needed for each delegate and load them automatically.

I personally use Macports to get all the delegates I want and compile IM from source so that I can have the most recent version of IM right away. But you have to modify the ./configure command to link IM to the Macports directory /opt.

P.S. The latest release of IM, 6.7.4.10 does not include the proposed fix for the cropping problem. I just tested it. So I presume it will be in the next release.

In the next point release of ImageMagick, use this command to flatten transparent PDF's:

• convert -density 200 apple.pdf -alpha flatten apple.jpg

Update by Anthony... now called -alpha remove (as in remove transparency).

Confirmed!

This correctly works in IM 6.7.5.0 Q16 Mac OSX Snow Leopard

convert apple.pdf -background white -flatten apple.jpg

Will a fix be in place so that the "-alpha flatten" parameter will not be needed allowing me to leave my original PHP code intact?
I have my PHP application running on two different machines right now ( Linux and OSX) and would prefer to keep the code consistent.

My original script has no issues on my Linux server which is running Image Magick 6.3.7.2-6.1

Galactica-Actual wrote:Will a fix be in place so that the "-alpha flatten" parameter will not be needed allowing me to leave my original PHP code intact?

It is my understanding that there is no bug in that regard. The issue is whether you have transparency in your pdf. If any image has transparency and you need that transparency to do anti-aliasing or other things and want to convert to an image format that does not support transparency such as jpg, then you need to flatten the image, otherwise, you may get black from the conversion in places where the alpha channel is black.

If the image does not have transparency then adding the -flatten code should not affect the result. It would be the same as if you did not add the code.

So for a more general solution, I would suggest you just modify your code to add that in case you have PDFs with transparency.

However, I will defer to the IM developers, if this is a wrong assumption.

Fred

P.S. I am not sure what the difference is between -alpha flatten and -background somecolor -flatten. Perhaps the former just flattens the alpha channel agains the background image and so does not need any -background color.

fmw42 wrote:P.S. I am not sure what the difference is between -alpha flatten and -background somecolor -flatten. Perhaps the former just flattens the alpha channel agains the background image and so does not need any -background color.

-alpha remove (as it should now be called as it removes alpha transparency) does exactly the same thing as... or and so on.

However it does not look at 'vitural canvas' or merge multiple images as -flatten can.
Also it uses 'background' not 'bordercolor' as the -border equivalent does.

The BIG plus however (after looking at code) is it does NOT actually generate a extra 'canvas' image for the composition
as the all other 'composition' transparency removal methods do. What it does is directly compose each pixel against the background color (over method). No extra image (and memory) needed internally.

Basically -alpha remove does a over compose against the background color, without any of the side effects all the other 'equivalent' methods have! It just does the task, simply without complications.

Note it also does not actually 'turn off' alpha As such after this operation against a fully-opaque background color, the alpha channel will also be fully-opaque.

ASIDE: alpha channel at this time is never destroyed, only turned off, unless a new image is created. In future a '-alpha Destroy' option may be added to actually completely delete the alpha channel form an iamge and save memory but so far their has been no need for that.