I want to convert multi page pdfs into single page images efficiently.
I already know how to do this one page at a time with imagemagick. For example,
convert x.pdf[2] x3.jpg
will give me the 3rd page of the pdf as an image. So if I figure out how many pages are in the pdf using identify then I can loop through and convert all pages in the pdf to images. This method can however take a while. For example a 15 page pdf could take anywhere between 15-30 seconds.
According to answers that I have seen elsewhere (also on the imagemagick forums) the following imagemagick command should split a pdf into multiple images.
convert x.pdf x-%0d.jpg
but all this ends up doing is creating the first page named x-0.jpg
As an alternative I have tried using pdftk with the burst capability. The problem I faced there is that burst does not work in all cases. It does for some pdf's and does not for some others.
Any suggestions on how to improve things would help.
My OS is Mac OSX Lion but I do need this working on CentOS 6 as well.
You're missing the quantity of digits. Use:
convert x.pdf x-%04d.jpg
Where 4 means 4 digits will be show on the page count.
If you use Graphicsmagick on Debian or ImageMagick on macOS you probably have to add ADJOIN to your command.
So it should look like
convert x.pdf +adjoin x-%04d.jpg
When I tried to convert my multi-page pdf, the resulting image files had a gray background despite the pdf having a white background. (#John P commented on it on the accepted answer, but I couldn't get his comment to directly work for me.)
Here's what worked for me to make the background white:
convert -authenticate yourpassword -background white -alpha remove -alpha off -density 300 -quality 80 -verbose "Your file.pdf" "Your file.png"
My pdf had a password hence the authenticate.
You can see a summary of the options here:
-authenticate value decipher image with this password
-background color background color
-alpha on, activate, off, deactivate, set, opaque, copy", transparent, extract, background, or shape the alpha channel
-density geometry horizontal and vertical density of the image
-quality value JPEG/MIFF/PNG compression level
-verbose print detailed information about the image
More detail: https://imagemagick.org/script/convert.php
And the alpha remove option: http://www.imagemagick.org/Usage/masking/#alpha_remove
Ran into the same issue. Reinstall Imagemagick to work in Mountain Lion. If you use brew the simply
$brew unlink imagemagick
$brew install imagemagick
Related
I am using this command to convert pages from a pdf to jpeg images:
magick convert -density 300 sample.pdf output.jpeg
I see a white background and the content of the PDF appears as a smaller image stuck to the bottom left corner of the white "canvas". Can anyone help with why this might be happening and how to prevent this "shrinking"?
My PDF has 14 pages. Here is the metadata for a few of those pages:
>magick identify sample.pdf
sample.pdf[0] PDF 2286x3600 2286x3600+0+0 16-bit sRGB 6458B 0.016u 0:00.017
sample.pdf[1] PDF 2286x3600 2286x3600+0+0 16-bit sRGB 6018B 0.016u 0:00.020
sample.pdf[2] PDF 2286x3600 2286x3600+0+0 16-bit sRGB 5732B 0.016u 0:00.023
And here are the actual and expected outputs for one of the pages:
actual output:
expected output:
edit: here is a sample PDF:
https://www.dropbox.com/s/0bzu5brfzbedd7i/sample.pdf?dl=0
I am not sure why you have that behavior. There is something in the PDF, perhaps a crop box, that Imagemagick/Ghostscript is not picking up. But you can get rid of the excess white using -trim
magick sample.pdf -trim sample_%d.jpg
Thanks for the example
> magick identify sample.pdf
> sample.pdf[0] PDF 2286x3600
Apears to be wrong as there is no match
from the PDF contents
/Width 1531
/Im0
/Height 2454
/MediaBox [0 0 1531 2454]
on
Page Size:
/CropBox [0 0 919 1473]
919 pt x 1473 pt
32.42 x 51.96 cm
12.76 x 20.45 inches
Therefore no problems when the images were inserted as # 120 dpi
We can check the image by copy when zoom to 100% in a viewer and paste into say paint, which agrees the image is 1531 x 2454 pixels.
As a result of comments with #fmw42, it was decided to see if GhostScript (which ImageMagick depends on for PDF handling) was having an affect, and certainly processing that PDF using GS v 9.55 without any special switches gave warnings and produced the output below left So the issue seems to be caused by recent GhostScript method of calling/scaling. since using simple GhostScript based image apps (Irfanview using GS plugin on the left) behave the same whilst other viewers have less of a problem even sister product MuPDF as previewed on the right. So the file Media Box as seen and probably used for scaling by Ghostscript seems to be the culprit, but was processed by two other PDF handlers during generation.
One solution would be to use a simpler method of extracting images as PNG thus look at Xpdf command line tools "pdftopng" which gives a good result but you need to calculate that the optimum resolution in this case is 120 (or 240), Typical windows command line does not need .exe but its best to use that when prefixing with a path for use from another location.
pdftopng.exe -r 120 -f 1 -l 1 sample.pdf
I want to overlay multiple PNG images of different sizes on a transparent canvas using ImageMagick. First I create a transparent canvas of some fixed size, say like
convert -size 1500x1000 canvas:transparent PNG32:canvas.png
Then I loop over my images in order to add each image to the canvas
convert canvas.png nthimage.png -gravity Center -geometry xResxYres+xcoord+ycoord -composite canvas.png
This works fine, but I may overlay as many as 10 pictures and I do this for thousands of n-tuples of images, so a faster solution would be appreciated. So my question: Can I also do this in one step instead of creating the canvas first and then adding a single image at a time?
Edit: I use ImageMagick 7.0.11-13 on macOS 10.15.7. I run ImageMagick from within a python script, so a file containing a list of input files can be generated if needed. For concreteness, say my input files are file_1.png up to file_n.png with sizes A1xB1 up to AnxBn and should be placed at coordinates +X1+Y1 up to +Xn+Yn with respect to the center of the canvas and the output file is output.png and should have size 1500x1000.
I really wouldn't recommend shelling out subprocesses from Python to call ImageMagick thousands of times. You'll just end up including too much process creation overhead per image, which is pointless if you are already running Python which can do the image processing "in house".
I would suggest you use PIL, or OpenCV directly from Python, and as your Mac is certainly multi-core, I would suggest you use multi-processing too since the task of doing thousands of images is trivially parallelisable.
As you haven't really given any indication of what your tuples actually look like, nor how to determine the output filename, I can only point you to methods 7 & 8 in this answer.
Your processing function for each image will want to create a new transparent image then open and paste other images with:
from PIL import Image
canvas = Image.new('RGBA', SOMETHING)
for overlay in overlays:
im = Image.open(overlay)
canvas.paste(im, (SOMEWHERE))
canvas.save(something)
Documentation here.
Using this code
mogrify -format gif *.webp
that I found in another forum
https://superuser.com/questions/1506337/batch-convert-webp-files-to-gif-files-offline/1506428 to convert a webp file, to an animated gif...
I was wondering if anyone else experienced patches of black and/or white "dropouts", when using this method? With many files, it works without incident, but with others, such as the attached, I have to use an online converter, to avoid this issue. Are there additional filters that I could apply, or other CLI methods for this type of conversion?
Some of your webp frames have transparency and others do not. The fix seems to be to set the dispose method to none. So this works for me on IM 6.9.10.90 Q16 Mac OSX Sierra using convert. I suggest you use the more flexible convert rather than mogrify. I am not sure you can do what you want with mogrify as it wants one output per one input. Here is my command:
convert -delay 10 -dispose none tumblr_e573d6d767dd3d65d21de47fa7d16d13_4d26286c_400.webp -loop 0 animation.gif
or better
convert -delay 10 -dispose none tumblr_e573d6d767dd3d65d21de47fa7d16d13_4d26286c_400.webp -coalesce -loop 0 -layers optimize animation.gif
Give that a try and let me know if it works for you. The file is too large to upload directly. If you need to see it and my command does not work for you, then I will post it elsewhere and put a link here.
I'm am trying to generate test images with ImageMagick. The image needs to only contain text. Bluntly using the example on the IM site doesn't work:
convert -background lightblue -fill blue -font Roboto -pointsize 72 label:Anthony label.gif
Yields:
convert.im6: unable to read font `Roboto' # warning/annotate.c/RenderType/853.
convert.im6: no images defined `label.gif' # error/convert.c/ConvertImageCommand/3044.
So 1) what is required to be able to use font names (my whole desktop uses Roboto, so I assume it is properly installed, and other fonts names don't work either) and 2) if I remove the font spec I still get the second line and no output.
Am I missing something?
Using ImageMagick 6.7.7-10 2016-11-29 Q16 on Ubuntu 14.04.
It's a bug in the particular version of ImageMagick you are using, resulting from a incorrect backport of a bugfix patch.
The problematic patch is Debian patch 0161-Do-not-ignore-SetImageBias-bias-value. I can't tell if that was included in the 14-November-2016 security update to 8:6.7.7.10-6ubuntu3.2 or the 29-November-2016 security patch to 8:6.7.7.10-6ubuntu3.3 (or, at least, I didn't bother trying to figure it out, since it's not that important.) The patch was created as a backport of this security patch, but because of a reorganization of the logic in the file coders/label.c, the correction ended up being inserted in the wrong place.
In essence, the logic of label.c is as follows:
if the image's size or pointsize is not specified, work out the best fit
if the image's width was not specified, copy it from the computed width
if the image's height was not specified, copy it from the computed height
if the image's pointsize was not specified, copy it from the computed pointsize
make some other relevant settings to image parameters
Render the text into the image.
The security patch was intended to avoid step 6 if the resulting image size could not be used. This avoids a possible Denial of Service attack when ImageMagick is being used on a web back-end (which is common). It adds:
3a. If the image dimensions are unusable, immediately fail.
Unfortunately, in the version to which to patch is applied, the above steps were in a different order, with the third step being intermingled with step 5. (This made no real difference, as far as I can see, but it was a bit disorganized, which is probably why it was subsequently fixed.) The result is that the added step 3a is inserted before the image's height has been copied from the computed height. This causes the check to fail if the image did not originally have a height, even though a correct height had been computed at that point.
The instructions clearly indicate that a label: source does not require a -size (or -pointsize) parameter. But with the misplaced patch, this turns out to be incorrect; unless a height is specified in the geometry, the label will not be generated.
I haven't generated a bug report for this because it only applies to an outdated version of ImageMagic on an outdated version of Ubuntu (and possibly of Debian). It happens that I and OP are both using this outdated version of Ubuntu on some machine, and my recommendation to both of us is to upgrade. But in case anyone else has this problem, I'm answering the question (which I found when trying to research the identical problem on my machine.)
Eventually got it to work using -size instead of -pointsize, and switched to caption since I can better control the position:
convert -background transparent -fill darkblue -font Roboto-Regular -size 200x100 -gravity center 'caption:Test' out.png
convert -background lightblue -fill blue -font Arial -pointsize 72 label:"Anthony" label.gif
The above works fine for me on IM 6.9.7.0 Q16 Mac OSX
Worked OK for me on a windows setup version 7 apart from the font error as I do not have that font installed. Setting it to arial removed the font error.
Try this to see if Imagemagick can see your font:
identify -list type
Otherwise I would try linking directly to your font with the path and putting the .ttf on the end. I assume your font is a .ttf one as Imagemagick supports that type and one other that I can not remember.
Out of interest your version is 4.5 years old.
I'm using ImageMagick to convert PDF files to PNGs. (Lots of text, so I'd rather use PNG over JPEG.) I'm doing this on OS X, 10.8.2.
I tried using Ghostscript, then ImageMagick, as was done here and I got a gray background. I shortened it to one line, since ImageMagick can work with PDFs and tried this:
convert -background transparent -transparent white \
Background-Page01.pdf TestClearX1.png
I've tried that with PNG files and JPEG files. (And with and without -transparent white as well.)
If it's a JPEG, I can get a white background (which is probably clear, but in my viewer, I can't tell), but with a PNG, I always get a dark background. I thought about, as a test, trying to generate a BMP, then converting that to PNG, but it won't generate BMP files.
How can I get a transparent background for a PNG file?
And if that's not possible, since JPEG files are not good for text, is there a better alternative?
This isn't an answer, but the format of the comment section doesn't allow sensible formatting, so I am offering it here instead.
You alluded to the fact that Preview in OS X doesn't show transparency properly, and that is correct. To get around that, I made the following script, which overlays the files you want to view onto a checkerboard pattern like Photoshop does. I save it as preview and then use chmod +x preview on it to make it executable. Here is the script:
#!/bin/bash
################################################################################
# preview
# Preview images using OSX "open" but overlay images on top of checkerboard
# first so you can see transparency/transparent pixels, since Preview renders
# them grey :-(
################################################################################
for f in "$#"
do
base=$(basename "$f")
composite -compose Dst_Over -tile pattern:checkerboard "$f" "/tmp/$base"
open -g "/tmp/$base"
done
That enables you to do:
/.preview file1.png file2.gif
and the -g option also means Preview doesn't steal focus too :-)
So, instead of looking like this:
it looks like this:
There's two ways to export a PDF in LibreOffice, and one way does not provide any warnings. The other way provides a warning that PDF/A cannot have transparent objects. The problem is you're using PDF/A files that don't support transparent objects—this results in your PNG always having a background colour.