I have some images in .GIF format which i want to compress. But i am getting the output either same or hardly 2-5% compression.I need higher compression ratio so that the web pages can be loaded fastly. Currently i am using the gifsicle tool but hardly i am finding much difference in size of the generated gif images.
I opted this tool from yahoo smush it.
gifsicle -O3 gifimage1.gif -o new-gifimage1.gif
UPDATE:
The giflossy fork has been merged into gifsicle now, so you will be able to use the --lossy flag with gifsicle now (with the latest version), no need to install giflossy separately.
If you want to enable lossy compression which reduces the size considerably, you can use giflossy fork of gifsicle. Once you have installed it you can use the lossey option as below
gifsicle -O3 --lossy=80 gifimage1.gif -o new-gifimage1.gif
Installation:
On Mac : brew install giflossy
On Unix : Building Gifsicle on UNIX
You can use below command to tweak your compression options
gifsicle -O3 --colors=64 --use-col=web --lossy=100 --scale 0.8 gifimage1.gif -o new-gifimage1.gif
Gifsicle's --optimize option will only attempt lossless reduction of an image's file size. What you probably have* is an animated gif where each frame contains random dithering, so most of the pixels will change from one frame to the next.
If your original GIF image had used pattern dithering, you would be able to compress it a lot more. But if that's not an option, I suggest you try either reducing the dimensions of the image (e.g., --scale 0.5), or reducing the number of colours in it (e.g., --colors 16).
* (I'm only guessing, since you didn't bother to share your image)
Related
We have many square EPS images, which we would like to export via script to PNG at very specific formats/sizes, namely
8192x8192, greyscale, no alpha, no anti-aliasing
2048x2048,greyscale, no alpha, anti-aliased.
We have had no luck scripting the "professional" tools Photoshop or Illustrator to do this (although we can do so through the UI, their weak scripting support does not give control over alpha or precise image export size, so we either always get alpha in the large images, or we sometimes get slightly inaccurate image sizes which breaks subsequent algorithms.)
Our first attempt at doing the high resolution version of this was:
gs -sDEVICE=pnggray -o cover.png -dDEVICEWIDTHPOINTS=8192 -dDEVICEHEIGHTPOINTS=8192 -dGraphicsAlphaBits=1 -dPDFFitPage=true cover.eps
However, this does not seem to resize the image to fill the box as expected.
Is there a way, given a square EPS, to get Ghostscript to do what we want?
Your problem with EPS files is that they do not request a media size. That's because EPS files are intended to be included in other PostScript programs, so they need to be resized by the application generating the PostScript.
To that end, EPS files include comments (which are ignored by PostScript interpreters) which define the BoundingBox of the EPS. An application which places EPS can quickly scan the EPS to find this information, then it sets the CTM appropriately in the final PostScript program it is creating and inserts the content of the EPS.
The FitPage switch in Ghostscript relies on having a known media size (and you should set -dFIXEDMEDIA when using this) and a requested media size, figuring out what scale factor to apply to the request in order to make it fit the actual size, and setting up the CTM to apply that scaling.
If you don't ever get a media size request (which you won't with an EPS) then no scaling will take place.
Now Ghostscript does have a different switch, EPSCrop which picks up the comments from the EPS and uses that to set the media size (Ghostscript has mechanisms to permit processing of comments for this reason, amongst others). You could implement a similar mechanism to pick up the BoundingBox comments, and scale the EPS so that it fits a desired target media size.
I could probably knock something up, but I'd have to mess around creating an example file to work from.....
Do not accidentally specify PDFFitPage in the command line above. Specify EPSFitPage when dealing with EPS files. PDFFitPage will silently do nothing.
Is there a way to convert all TIFF images to PNG using windows console or any simple tool.
I renamed tags, but the problem now is file size. What are ways to compress files?
imagemagick, it's CLI tool for image manipulation available for most major operating systems including Windows http://www.imagemagick.org/script/download.php
It's very simple to use it
convert in.tiff out.png
To convert and scale by 50%:
convert in.tiff -resize 50% out.png
Here you can find full list of general commands
TinyPng is great to compress png files, you can try that.
www.tinypng.com
I am attempting to make a very simple label using Libreoffice Draw v 4.0.2.2. The label has not much more to it than regularly spaced lines of centered text
This image will be printed, and I have a fixed size/ppi requirement to ensure appropriate print quality.
I set the page size to my specs, and layout the text as I desire. The print shop takes several image formats including .tiff and .png. When I export the image, a dialog pops up that asks for the image size/ resolution. The given ppi is very low (~40) and I require a minimum of 180ppi. When I enter this, the image size adjusts itself and results in an image that is far too small.
The only solution that appears to be viable is to explode the page size and the drawing text size so it gets shrunk upon export. This is a very imprecise and illogical feature (bug?) of the program that I really wish is a result of my ignorance.
I found a thread in the mailing list which describes this issue exactly. The only answer that is given is essentially "yes, this is ridiculous and doesn't help anybody".
Can anyone give some advice to this? Or at least shed some light on who might need this "feature"?
There is something off about the Export tool of LibreOffice in general. It has been years since it is broken. Taking a screenshot is an alternative, but obviously you cannot control the resolution.
So, a better work around is exporting to SVG, and then convert the SVG to PNG with Inkscape. Once downloaded, convert the file with the following command:
inkscape -z -e out.png -w 1024 in.svg
If you are in Windows (x64), you will need to indicate the full path:
"C:/Program Files/Inkscape/inkscape.exe" -z -e out.png -w 1024 in.svg
If you install the 32 bit version, this should work:
"C:\Program Files (x86)/Inkscape/inkscape.exe" -z -e out.png -w 1024 in.svg
This can be done from inside Libre Office, there is no need to use any external tool. The Export dialog is very confusing, yes; you have to realize that both size and resolution can be set independently.
Select File -> Export -> choose the desired format. The export dialog should appear.
TAKE NOTE of Width and Height. Set the desired resolution; notice how Width and Height change (?). Don't worry, restore Width and Height to your saved values. And that's it. You get a high resolution image with the desired size and DPI.
Libre Draw (the one I'm using anyway) is a vector drawing app - have you asked the print shop if they can use vector formats like eps, pdf? Most should be able to in my experience. Then resolution becomes irrelevant.
-Terry
Currently I'm trying to use Perl/ImageMagick and/or Ghostscript to convert scanned text documents stored as TIFFs into an 8.5″×11″ (ANSI A “Letter” size) PDF file.
I've tried many of the ImageMagick filters with resize and still find that some files perfectly legible before are now illegible. Often these images are at 72 dpi and when converted to be 8.5″×11″, it ends up with something like 612×792 pixels. The original was 1700×2200; as you can see there are quite a bit of pixels lost in the re-size.
Should I be using something else besides resize? Could it be something like ImageMagick is reporting the image is 72 dpi when it's really something like 200 dpi? Would re-sampling the image into the highest dpi that would fit in the 8.5″×11″ area help?
Does anyone have any other options to ultimately create a PDF file with all pages being 8.5″×11″?
(Mantra: 'Use the right tool for the job...')
You possibly shouldn't use ImageMagick for the job, but rather LibTIFF's tiff2pdf commandline utility:
tiff2pdf \
-z \
-o output.pdf \
-p letter \
-F \
input.tiff
-z is for (lossless) Zip/Flate compression.
-o defines the output filename.
-p sets the media size.
-F fills the page.
I'm trying to use Ghostscript and/or ImageMagick to convert each page of a Postscript document into PNG images. The problem is that both produce images that are way too saturated (I think that's the right terminology).
Here are the commands I'm trying:
gs -dSAFER -dBATCH -dNOPAUSE -sDEVICE=png16m -dGraphicsAlphaBits=4 -sOutputFile=page_%02d.png brochure.ps
convert brochure.ps im_page_%02d.png
This is the input Postscript file (brochure.ps from above)
Here's a couple of the output images I'm getting:
Page 1
Page 6
As you can see (especially on the page with the big green map of New Hampshire), the colors of the output PNGs are too bright/saturated. How can I prevent the colors from being changed so much and get a more accurate conversion?
Preview in OS X 10.6 automatically does a very accurate conversion to PNG when you open a Postscript file in it. This leads me to believe there is just something screwy with the way ghostscript converts ps->png (I'm fairly confident ImageMagick is just a wrapper for ghostscript for this operation). Is there a tool besides ghostscript I should be using instead?
Note: As pipitas points out below, the visible difference of colors varies by OS. It is very obvious in OS X 10.6, but apparently not very noticeable in Windows XP.
You are right in assuming ImageMagick just being a wrapper for Ghostscript when converting from PostScript or PDF to an image format.
I think, this problem can only be solved to anybody's satisfaction once the efforts to add support for ICC profile handling and color management (currently underway) are completed for Ghostscript (design document as PDF). That point in time is close, however. If I understand recent commits to http://svn.ghostscript.com/trunk/ correctly, the next release (which will be dubbed 9.00 and out hopefully in August) will include support for color management via LittleCMS. Yay!
OSX 10.4 and up provide sips (scriptable image processing system) and it works well with PDF format. Perhaps it can be a temporary solution until Ghostscript supports color management.