We are migrating from ImageMagick 6 to ImageMagick 7, but using the same command line option used in version 6 is now giving a blank image in version 7. The command used is
convert "C:\Imagemagick\beige.png" -alpha Activate -scale 640x640
"C:\Imagemagick\Out\Zoom.jpg"
The input "beige.png" does not have an alpha channel. But if I input an image with alpha channel, it creates a file with valid results. Also, if I set the option "-alpha Activate" after scale operation it gives a valid result. Do we need to consider any order while setting the alpha for ImageMagick 7 version?
Related
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 trying to convert an not-optimized PNG to an optimized version using ImageMagick's convert command:
convert -colors 40 test.png test-optimized.png
The problem is however that the convert operation adds weird noise. I want multiple levels of alpha transparency in my export, which convert seems to offer, but without all the noise, and the file size should stay low. I wouldn't expect to need more than 16 different colors to optimize the original image with some levels of anti-aliasing in both the blue area and the transparent area. Any idea's? It almost looks like it is adding something like a JPEG compression or something (which of course doesn't add transparency). I tried already with different -anti-aliasing and -alpha options.
Source
Optimized
This question can be closed: the problem was a version issue.
The problem occurs with:
ImageMagick 6.9.0-0 (as reported by Mark Scetchell in the comments)
ImageMagick 6.9.1-0 Q16 x86_64 2015-04-06
But no longer with:
ImageMagick 6.9.3-0 Q16 x86_64 2016-01-31
Thanks to Mark Scetchel and Glenn Randers-Pehrson for their input.
I have some PNG images with transparency. However, whenever I do any operations with ImageMagick on the image (e.g. cropping), it changes some of the images to be "indexed" color instead of RGB. The images that change are ones where there happens to be fewer than 256 colors, but the conversion ruins the transparency.
From some research I found you can prepend a filename with png32: to force RGB, but that only works when using the convert command, not mogrify.
I can add -format png32 with mogrify, but that renames all the images to *.png32.
Supposedly you can do this:
mogrify -define png:format=png32 -format png *.png
But it doesn't work, the images are still indexed color not RGB. How do I force PNG32 with mogrify?
Your command should have worked, if you are using a recent version of ImageMagick (6.9.1-3 or later).
Earlier versions will work if you use the -format png32 option as you did, then run a script to rename them back to *.png.
According to the ImageMagick 6 change log, the "-define png:format=png32" option was added to ImageMagick at version 6.7.3-0, but a bug was introduced at version 6.8.9-0 that caused it to be ignored in certain circumstances; that bug was fixed in version 6.9.1-3.
So the answer to your question is to either work around the problem by letting mogrify rename your input files to *.png32, or to upgrade your ImageMagick to 6.9.1-3 or later.
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
Here's the image I'm working on:
Here's the MS_DOS command line:
convert "IM_Effect_Smoke_problem.png" -background transparent -crop 64x64+0+64! "IM_Effect_Smoke_problem_crop.png"
The problem is that ImageMagick reduces the color depth to 8 bits and ignores or destroys the alpha channel.
Can anyone tell me how to fix this? Thanks!!!
Testing the command with ImageMagick 6.6.9-7, on Ubuntu, preserves the alpha channel. Maybe there the issue is with the version of ImageMagick you're using if you're sure the alpha channel is removed.