I would like to know which image format inside PDF's is rendered fastest. I tested mupdf code and I figured out that image decoding takes an important part in rendering time. So I would like to know if there are image formats that would not impact very much on cpu load.
I dont think this is really a question of what is best simply within PDFs, however:
As a general rule, I have always found that pre-rendering the image's size to the actual size you wish to present on screen is the best way to get both size and rendering speed to what you want them to be. Simply dragging an image into a document doesnt bring the pixel count (thus size) down as most document types simply put a display size tag around the full image. This causes the display program to have to real-time resize the image for display. The less the display program has to real-time resize the image the faster it will display.
As for file types:
Bitmaps are generally considered the fastest to display as they (for the most part) are copy and paste the color for each pixel onto the screen pixel. They are generally considered the biggest file. Depending on your images, if they aren't noisy (have a lot of solid runs of the same color) then they can be RLE encoded. I have seen many RLE encoded images that are indeed even smaller than JPEG images, but it is very situational.
JPEGs tend to be the smallest for transfer and also generally display decently quick. As an opinion they are also the lowest quality images (look close, if you started with a perfectly clean image, JPEG compression will add noise to it unless using lossless compression)
PNGs tend to be my favorite. They can be lossless compressed, can be fairly small if using flattened PNGs (i.e. NOT ADOBE FIREWORKS PNGs) and do produce crisp images that render fairly quickly.
So to sum up: I would probably recommend flattened PNGs that have been pre-sized and saved to the size you wish to display on screen.
Platform I am using is java applet, and I want to know whether I should use jpg, gif, png
jpg tends to slow down the game,
gif flickers too much
do not have much hope with png in speed
One large image is generally a bad idea for performance and memory consumption.
You want to split it in smaller chunks and load/unload them when not in use.
In java2D I always used PNG.
In other libraries it may not be important since they convert the image format to something more GPU friendly.
On the other hand, bmp is the faster thing to load (you don't need to process -i.e. decompress- the image), but it may increase your overall game size.
I am working on an iPad application which has hundreds of photo-quality images. I would have naturally assumed to store these images as JPEGs so as to optimize the app file size. However, Apple's guidelines state:
Use the PNG format for images. The PNG format provides lossless image content, meaning that saving image data to a PNG format and then reading it back results in the exact same pixel values. PNG also has an optimized storage format designed for faster reading of the image data. It is the preferred image format for iOS.
However, if I store the same images as JPEGs at 100% quality, the size of them drops to about half that of the PNG lossless versions.
Is there really that much of a performance hit to use JPEG instead of PNG? If I am viewing these images in a carousel or gallery style, do I really need to worry about the performance and use PNGs instead?
Thanks!
Regarding the quality PNG is good for application kind of images, but JPEG is preferred for photos. Choose the lowest JPEG quality that gives good enough quality for your images.
Regarding speed, size also matters. I have no IPad to test with, but the smaller file size to read from flash or network might very well out weight any additional decompression cost. The only way to find out is to measure on your actual device.
There is a performance consideration but while PNG is preferred for quality, given your application, I'd suggest JPEG would be preferable.
Pure performance isn't the only factor of interest or concern; an iPad has only a finite space available to it, and filling that up with image data that most users are not going to need or want seems preferable to using more computational power for most cases.
One other thing to consider - on a gallery, you are strongly recommended to generate thumbnails which give you the best of both worlds: the smaller, more accessible image for general use and the full original image for 'best'.
If in doubt, benchmark with both and see how big the difference is in your application - and if the difference is something you can live with versus the space saving, go with JPEG.
I have a small script that I use to resize all of the images in a directory. I run this script in cygwin and it uses "convert" to do the image resizing. The images change their resolution just fine, but I am having problems with file sizes after the script is run.
I typically use this script to resize images dumped out from a Powerpoint presentation to use in a little web presentation app that I wrote. When I dump out gif's and run the script, the files more than double in size (ex. 8KB to 18KB; 14KB to 50KB)
The pertinent lines of the script are as follows:
/usr/bin/convert $holdfile -thumbnail x480 temp.GIF
mv temp.GIF $i
Is there a switch to prevent the file sizes from growing so much? I know that the file sizes are not huge, but when I have a good number of people connecting to a presentation or the unavoidable dialup users, I just want to make their experience as nice as possible.
Edit: I should have specified that the files start at a 960px x 720px resolution and are being resized to 640px x 480px.
Well, this can happen if convert compresses worse than the input files. Since the exact same compression scheme might yield different results depending how good the compressing code is this can happen.
Another, more likely option here would probably be that you are resizing the images which will probably be done with bicubic resizing. This causes the edges of text or drawings to become a little bit blurry. This means they use up more colors and compress worse.
Also likely would be that your original images use an optimized color palette, maybe just with a few colors and after resizing they need the full 256 colors which are supported by a single GIF frame, due to smoothing done by the resizing.
In any case, you probably should see better performance using PNG instead of GIF. PNG was designed as a modern replacement for GIF and no (graphical) browser in use today has problems displaying PNGs (without an alpha channel). PNG compresses much better than GIF, and allows more colors at the same time. Also there are tools like optipng which will compress PNG images even further.
Convert automatically optimizes the palette however the palette might be growing due to colors being blended during resize. You should be able to inspect the source and resultant images in a graphics program and see the number of colors.
GIF only supports LZW compression but due to patent restraints that have since expired (the last was 2004) it was once necessary to manually enable LZW compression. I'm not sure if that is still the case however it's worth looking into.
If LZW compression is specified but
LZW compression has not been enabled,
the image data is written in an
uncompressed LZW format that can be
read by LZW decoders. This may result
in larger-than-expected GIF files.
- imagemagick.org
I have a very large background image (about 940x940 pixels) and I'm wondering if anyone has tips for compressing a file this large further than Photoshop can handle? The best compression without serious loss of quality from Photoshop is PNG 8 (250 KB); does anyone know of a way to compress an image down further than this (maybe compress a PNG after it's been saved)?
I don't normally deal with optimizing images this large, so I was hoping someone would have some pointers.
It will first depend on what kind of image you are trying to compress. The two basic categories are:
Picture
Illustration
For pictures (such as photographs), a lossy compression format like JPEG will be best, as it will remove details that aren't easily noticed by human visual perception. This will allow very high compression rates for the quality. The downside is that excessive compression will result in very noticeable compression artifacts.
For illustrations that contain large areas of the same color, using a lossless compression format like PNG or GIF will be the best approach. Although not technically correct, you can think of PNG and GIF will compress repetitions the same color very well, similar to run-length encoding (RLE).
Now, as you've mentioned PNG specifically, I'll go into that discussion from my experience of using PNGs.
First, compressing a PNG further is not a viable option, as it's not possible to compress data that has already been compressed. This is true with any data compression; removing the entropy from the source data (basically, repeating patterns which can be represented in more compact ways) leads to the decrease in the amount of space needed to store the information. PNG already employs methods to efficiently compress images in a lossless fashion.
That said, there is at least one possible way to drop the size of a PNG further: by reducing the number of colors stored in the image. By using "indexed colors" (basically embedding a custom palette in the image itself), you may be able to reduce the size of the file. However, if the image has many colors to begin with (such as having color gradients or a photographic image) then you may not be able to reduce the number of colors used in a image without perceptible loss of quality.
Basically it will come down to some trial-and-error to see if the changes to the image will cause any change in image quailty and file size.
The comment by Paul Fisher reminded me that I also probably wouldn't recommend using GIF either. Paul points out that PNG compresses static line art better than GIF for nearly every situation.
I'd also point out that GIF only supports 8-bit images, so if an image has more than 256 colors, you'll have to reduce the colors used.
Also, Kent Fredric's comment about reducing the color depth has, in some situtations, caused a increase in file size. Although this is speculation, it may be possible that dithering is causing the image to become less compressible (as dithering introduces pixels with different color to simulate a certain other color, kind of like mixing pigment of different color paint to end up with another color) by introducing more entropy into the image.
Have a look at http://www.irfanview.com/, is an oldy but a goody.
Have found this is able to do multipass png compression pretty well, and does batch processing way faster than PS.
There is also PNGOUT available here http://advsys.net/ken/utils.htm, which is apparently very good.
Heres a point the other posters may not have noticed that I found out experimentally:
On some installations, the default behaviour is to save a full copy of the images colour profile along with the image.
That is, the device calibration map, usually SRGB or something similar, that tells using agents how to best map the colour to real world-colours instead of device independant ones.
This image profile is however quite large, and can make some of the files you would expect to be very small to be very large, for instance, a 1px by 1px image consuming a massive 25kb. Even a pure BMP format ( uncompressed ) can represent 1 pixel in less.
This profile is generally not needed for the web, so, when saving your photoshop images, make sure to export them without this profile, and you'll notice a marked size improvement.
You can strip this data using another tool such as gimp, but it can be a little time consuming if there are many files.
pngcrush can further compress PNG files without any data loss, it applies different combinations of the encoding and compression options to see which one works best.
If the image is photographic in nature, JPEG will compress it far better than PNG8 for the same loss in quality.
Smush.It claims to go "beyond the limitations of Photoshop". And it's free and web-based.
It depends a lot on the type of image. If it has a lot of solid colors and patterns, then PNG or GIF are probably your best bet. But if it's a photo-realistic image then JPG will be better - and you can crank down the quality of JPG to the point where you get the compression / quality tradeoff you're looking for (Photoshop is very good at showing you a preview of the final image as you adjust the quality).
The "compress a PNG after it's been saved" part looks like a deep misunderstanding to me. You cannot magically compress beyond a certain point without information loss.
First point to consider is whether the resolution has to be this big. Reducing the resolution by 10% in both directions reduces the file size by 19%.
Next, try several different compression algorithms with different grades of compression versus information/quality loss. If the image is sketchy, you might get away with quite rigorous JPEG compression.
I would tile it, Unless you are absolutely sure that you audience has bandwidth.
next is jpeg2k.
To get more out of a JPEG file you can use the 'Modified Quality Setting' of the "Save as Web" dialog.
Create a mask/selection that contains white where you want to keep the most detail, eq around Text. You can use Quick-Mask to draw the mask with a brush. It helps to Feather the selection, this results in a nice white to black transition in the next step.
save this mask/selection as a channel and give the channel a name
Use File->Save as Web
Select JPEG as file format
Next to the Quality box there is a small button with a circle on it. Click that. Select the saved channel in step 2 and play with the quality setting for the white and black part of the channel content.
http://www.jpegmini.com is a new service that creates standard jpgs with an impressively small filesize. I've had good success with it.
For best quality single images, I highly recommend RIOT. You can see the original image, aside from the changed one.
The tool is free and really worth trying out.
JPEG2000 gives compression ratios on photographic quality images that are significantly higher than JPEG (or PNG). Also, JPEG2000 has both "lossy" and "lossless" compression options that can be tuned quite nicely to your individual needs.
I've always had great luck with jpeg. Make sure to configure photoshop to not automatically save thumbnails in jpegs. In my experience I get the greatest bang/buck ratio by using 3 pass progressive compression, though baseline optimized works pretty well. Choose very low quality levels (e.g. 2 or 3) and experiment until you've found a good trade off.
PNG images are already compressed internally, in a manner that doesn't benefit from more compression much (and may actually expand if you try to compress it).
You can:
Reduce the resolution from 940x940 to something smaller like 470x470.
Reduce the color depth
Compress using a lossy compression tool like JPEG
edit: Of course 250KB is large for a web background. You might also want to rethink the graphic design that requires this.
Caesium is the best tool i have ever seen.