I'm using ImageMagick's convert to resize some .png files, the problem is that convert seems to be writing some extra info to the .png:
EXtdate:create 2012-11-26T19:50:31-08:001
The problem is that if the source image didn't change, a new scaled down image is produced that is identical to the old one, but it has this extra time/date info and it's causing git to think all the files have changed.
Is there a way to keep convert from writing out this addition meta info so subsequent resizing won't show the files as changed is the source image didn't change?
You're searching for the -strip parameter, ie:
convert infile.png -resize 100x100 -strip outfile.png
I found the solution to this problem was adding:
+set date:create +set date:modify
The -strip option was not removing the embedded data, but this does.
Related
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 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.
A JPEG image can be reduced in quality and, thus, in file size using ImageMagick in a way such as the following:
convert -quality 85% image.jpg image_small.jpg
How can the quality of an image be reduced such that the resulting image is below a certain file size (e.g. 3 MB)? A scenario in which this would be useful would be preparing a large number of images for upload to a site like Imgur.
I thought there was a post about this last week but can not find it. There was another here: ImageMagick: scale JPEG image with a maximum file-size
Anyway you want to use: -define jpeg:extent=400KB https://www.imagemagick.org/script/command-line-options.php#define
Out of interest your code is wrong as the input comes after convert and your quality goes before the output image.
So you want something like this:
convert image.jpg -define jpeg:extent=3000KB image_small.jpg
If you have an old version of Imagemagick it may not work that is why it is always good to include your imagemagick version in your question.
The results are a bit hit and miss on exact filesize.
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'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.