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.
Related
I wanted to batch-convert some JPG images to PNG, so I used the following ImageMagick command:
convert before.jpg after.png
However, things didn't go as smooth as I planned. See two images below - first is before.jpg, second is after.png:
You can see that the second one is quite darker than the original.
I'm using ImageMagick 6.9.9-19.
Opening JPEG image in GIMP and exporting it as PNG gives expected result - output image is identical to original.
What am I doing wrong?
Edit: re-saving after.png with GIMP also makes the image identical to original.
Edit: even after I saved after.png with GIMP, re-converting with ImageMagick breaks colors again (convert after-gimp.png after-gimp-and-im.png).
Edit: converting to sRGB or CMYK TIFF, or even again to JPG, does not give this problem. However, I still need PNG.
The two images you posted are identical according to IM 6.9.9.20 Q16 Mac OSX compare -metric rmse GBooF.jpg geDxn.png null: Which produces: 0 (0). It is possible your viewers may display jpg and png differently, since neither have an sRGB profile. Though, png is usually assumed to be sRGB.
Also my viewer shows both of your images as the same --- no difference, in your post on Mac Safari and using Mac Preview.
Try adding an sRGB profile to your jpg. Then convert.
convert GBooF.jpg -profile path2/sRGB.icc GBooF2.jpg
convert GBooF2.jpg GBooF2.png
See if those view the same.
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
ImageMagick splits the gif into jpgs but some of them have white pixels and others do not.
convert -strip tree.gif tree.jpg
Splits the gif into 86 jpgs. Here are #68 and #69.
#68
and #69
and the gif in question:
about 1/3 have a similar encoding issue.
convert -version
Version: ImageMagick 6.6.9-7 2012-08-17 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2011 ImageMagick Studio LLC
Features: OpenMP
uname -a
Linux paul-Pangolin-Performance 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
In animated GIF images, each new frame is drawn on top of the previous one, which means any pixels that are identical to the previous frame can be represented by transparent pixels. (Actually, this is only true for "Dispose None" animations, but that's what you have here. See here for details on the three kinds of disposal methods.)
Animated GIF optimizer tools take advantage of this, by looking for long runs of pixels that can be converted to transparent (so they can then be compressed more efficiently). So, that's why you probably have transparent pixels in the original image.
When those frames are converted to JPG, the transparent pixels are being converted to the background color, white.
See here for a description of how to fix it—you first want to convert your "Overlay Animation" into a "Coalesced Animation", and then you can convert that to a series of JPG files. It should look something like this:
convert tree.gif -coalesce -set dispose previous tree2.gif
Then verify that the animation looks identical, and then:
convert -strip tree2.gif tree.jpg
I haven't looked at the gif_anim_montage script linked from there that generated all the nice frame-by-frame images. I'm guessing it'll be doing effectively the same thing (plus more stuff), but maybe it has some neat tricks that will help you out, so I'd take a look.
PS, are you sure you want JPG output instead of, say, PNG, or even GIF? JPG is guaranteed to lose quality, while PNG is guaranteed not to. And, given the source data (256-color GIF images), PNG is likely to compress at least as well, or even better. A quick test shows it's 1980K vs. 1916K with the default settings, and with some trivial optimizing the PNGs come down to 1888K.
I'm running Embedded Linux on an evaluation kit (Zoom OMAP35x Torpedo Development Kit). The board has an LCD and I would like to be able to take screen shots convert them into a gif or png. I can get the raw data by doing the following: "cp /dev/fb0 screen.raw", but I am stumped on how to convert the image into a gif or png format.
I played around with convert from ImageMagick (example: "convert -depth 8 -size 240x320 rgb:./screen.raw -swap 0,2 -separate -combine screen.png"), but have been unable to get an image that looks right.
Does anyone know of any other tools that I could try out? Or does anyone have tips for using ImageMagick?
Take a look at fbgrab, an application that does just that (it saves the framebuffer content as a png).
You can simply capture the framebuffer to a file and open it in any raw image viewer or try online eg: https://rawpixels.net/
cat /dev/fb0 > fbdump
It might not be possible / easy to do it directly with ImageMagick.
The Linux kernel 4.2 documentation https://github.com/torvalds/linux/blob/v4.2/Documentation/fb/api.txt#45 says:
Pixels are stored in memory in hardware-dependent formats. Applications need
to be aware of the pixel storage format in order to write image data to the
frame buffer memory in the format expected by the hardware.
Formats are described by frame buffer types and visuals. Some visuals require
additional information, which are stored in the variable screen information
bits_per_pixel, grayscale, red, green, blue and transp fields.
Visuals describe how color information is encoded and assembled to create
macropixels. Types describe how macropixels are stored in memory. The following types and visuals are supported.
A list of visuals and types follows, but the description is not enough for me to understand the exact formats immediately.
But it seems likely that it might not be a format that ImageMagick will understand directly, or at least you'd have to find out the used format to decide the ImageMagick options.