Related
As a general rule of thumb when is it appropriate to make a gif interlaced, a png interlaced and a jpeg progressive?
Especially when publishing the image on the web.
JPEG: YES — use progressive scan. It makes files smaller (each pass gets its own Huffman table), and partial rendering looks quite good.
GIF: NO — it's unlikely to make the file smaller, partial rendering is poor, and it's pointless for animGIFs. It's best not to use GIF at all (yes, even for anims).
PNG: NO — it hurts compression (as data from each pass is statistically quite different). If the image is large, use high-quality JPEG or lossy PNG if possible, as these may load quicker than a pixelated preview of a large lossless PNG.
ImageOptim will automatically change progressive/interlaced formats when it makes files smaller.
Disclaimers for nitpickers:
In case of small and medium-sized images the progressive preview of each image is not going to be visible long enough for the user to appreciate it. Some browsers don't even bother rendering anything until the whole file is downloaded, so it's better to focus on saving bandwidth to get the whole page loaded ASAP.
Non-progressive JPEG is a bit more efficient when the files are tiny (small thumbnails), but then the savings are tiny, too.
iOS Safari has a higher maximum allowed image size for baseline JPEG than progressive, but the right solution there is to serve images at sizes reasonable for mobile in the first place.
My general rule of thumb: don't ever use interlacing. Interlaced formats typically occupy more space, have (slightly) more complexity and less support in decoders, and the alleged advantages for the user experience are at least debatable. Some arguments for PNG, and in general.
Some people like interlaced or "progressive" images, which load
gradually. The theory behind these formats is that the user can at
least look at a fuzzy full-size proxy for the image while all the bits
are loading. In practice, the user is forced to look at a fuzzy
full-size proxy for the image while all the bits are loading. Is it
done? Well, it looks kind of fuzzy. Oh wait, the top of the image
seems to be getting a little more detail. Maybe it is done now. It is
still kind of fuzzy, though. Maybe the photographer wasn't using a
tripod. Oh wait, it seems to be clearing up now ...
Interlaced images are slightly less efficient, but show up after shorter delay on the client side when transported over the network. IMHO they should be used when the expected download time for the image is long enough to be perceived by the user (say, above 1 second). The difference in file size is really quite small, so it's better to be too-cautious and use interlacing too much rather than too little.
In common broadband internet as of 2012, I'd just use it for every image > 100kb.
These points must be useful.
Interlacing (more generally, progressive display) is a method of displaying images on a monitor.
When to use it? Your decision should be base on these factors:
•> Non-interlaced images are smaller than interlaced images.
•> Interlaced images cause less flickering than non-interlaced ones
•> Interlaced images are much more easily view-able.
The interlace lets you see the picture before all the data has been transmitted (makes them appear faster and better-looking) and gives you the "feeling" that it is being downloaded faster.
TIP: Interlacing is not recommended for small images but is a must if
the viewer uses a slow connection
This is just a copy from Y answers i thought could help to understand.
Original answer could be find at: https://answers.yahoo.com/question/index?qid=20090211121956AAz7Xz8
Just to throw my twopenneth into the argument: Interlacing was introduced years ago when internet speeds were slow, the idea being that the image would present itself in a gradually more defined manner, still giving an overall look and feel to an image without having to wait for the entire thing to load.
Interlacing, today, is basically unnecessary and should be used based on the overall size of the image being transferred.
Progressive scans on JPEG images images do provide a more refined image while attempting to reduce the overall file size (i.e. is an actual compression mode rather than a streaming method for the bits making up the image).
PNGs use a more complex algorithm than GIF.
There is an interesting related post on webmasters
https://webmasters.stackexchange.com/questions/574/progressive-jpeg-why-do-many-web-sites-avoid-rendering-jpegs-that-way-pros
Untimately it depends on how they are going to be used.
The post suggests that there is limited - genuine - support for progressive images. And sometimes they may cause issues with plugins which don't support the progressive format.
Hope that helps.
I am building a map system that requires a large image (native 13K pixels wide by 20K pixels tall) to be overlayed onto an area of the US covering about 20 kilometers or so. I have the file size of the image in jpg format down to 23 MB and it loads onto the map fairly quickly. I can zoom in and out and it looks great. It's even located exactly where I need it to be (geographically). However, that 25 MB file is causing Firefox to consume an additional 1GB of memory!!! I am using Memory Restart extension on Firefox and without the image overlay, the memory usage is about 360 MB to 400 MB, which seems to be about the norm for regular usage, browsing other websites etc. But when I add the image layer, the memory usage jumps to 1.4 GB. I'm at a complete loss to explain WHY that is and how to fix it. Any ideas would be greatly appreciated.
Andrew
The file only takes up 23 MB as a JPEG. However, the JPEG format is compressed, and any program (such as FireFox) that wants to actually render the image has to uncompress it and store every pixel in memory. You have 13k by 20k pixels, which makes 260M pixels. Figure at least 3 bytes of color info per pixel, that's 780 MB. It might be using 4 bytes, to have each pixel aligned at a word boundary, which would be 1040 MB.
As for how to fix it, well, I don't know if you can, except by reducing the image size. If the image contains only a small number of colors (for instance, a simple diagram drawn in a few primary colors), you might be able to save it in some format that uses indexed colors, and then FireFox might be able to render it using less memory per pixel. It all depends on the rendering code.
Depending on what you're doing, perhaps you could set things up so that the whole image is at lower resolution, then when the user zooms in they get a higher-resolution image that covers less area.
Edit: to clarify that last bit: right now you have the entire photograph at full resolution, which is simple but needs a lot of memory. An alternative would be to have the entire photograph at reduced resolution (maximum expected screen resolution), which would take less memory; then when the user zooms in, you have the image at full resolution, but not the entire image - just the part that's been zoomed in (which likewise needs less memory).
I can think of two approaches: break up the big image into "tiles" and load the ones you need (not sure how well that would work), or use something like ImageMagick to construct the smaller image on-the-fly. You'd probably want to use caching if you do it that way, and you might need to code up a little "please wait" message to show while it's being constructed, since it could take several seconds to process such a large image.
hope this question is ok on stackoverflow. I want to use a photo as the background for the homepage of a website. The photo will be take up the entire page. However i don't know what resolution i should make the photo. I was thinking 1920 x 1200px so that people with 24 inch screen don't see the 'ends' of the photo. However is that big enough? I'm worried about the site looking ok on screens larger than 24 inches.
Also anyone know how i should optimize the photo so it loads as fast as possible? Thanks.
Overall, this seems to be a question of trade-offs. The better the resolution, the slower the page load for a do-nothing page. Is it worth the slow-down to have the better resolution and avoid pixellation?
Also, I think you're asking the wrong question, since a 24-inch screen can be in multiple resolutions.
I would approach this in the following manner:
what is the largest resolution you MUST have your photo look "good" on? Then make your photo that resolution. If 24" is your target, look at what resolutions this size monitor "typically" supports and target that.
What number of colors you want? (or perhaps b&w / grayscale). If you reduce the number of colors (preferably to "web-safe" colors), you can load faster with the same resolution.
A program like Photoshop (or Gimp) will probably give you the most power in tuning these parameters.
Do you care if only a portion of the photo displays when your viewer has a smaller window?
I know this isn't a cut and dried answer, but these things seldom are (IMHO).
For a solution that will work on most modern browsers, you will need to place the image in a div with a z-index less than the rest of your page (see: Stretch and scale CSS background)
As far as creating a 1920x1200 photo that will compress to a small size, I would recommend trying a smaller size (e.g. 960x600) and see if it looks okay on your 24-inch screen. There are many programs that will let you specify file size for your compression (e.g. FastStone Resizer) so you can experiment and see what is acceptable. In general, photos with less detail and/or color-depth will compress better.
Another problem you are going to run into is aspect ratio. Even assuming that your web-site is always opened in a full screen browser and not a window, sometimes that screen is going to be 16:9 ratio and sometimes 4:3. You could try to create an photo that has a nice 4:3 ratio "sweet-spot" in the center and adjust your div using some Javascript based on the current window aspect-ratio.
Consider an application handling uploading of potentially very large PNG files.
All uploaded files must be stored to disk for later retrieval. However, the PNG files can be up to 30 MB in size, but disk storage limitations gives a maximum per file size of 1 MB.
The problem is to take an input PNG of file size up to 30 MB and produce an output PNG of file size below 1 MB.
This operation will obviously be lossy - and reduction in image quality, colors, etc is not a problem. However, one thing that must not be changed is the image dimension. Hence, an input file of dimension 800x600 must produce an output file of dimension 800x600.
The above requirements outlined above are strict and cannot be changed.
Using ImageMagick (or some other open source tool) how would you go about reducing the file size of input PNG-files of size ~30 MB to a maximum of 1 MB per file, without changing image dimensions?
PNG is not a lossy image format, so you would likely need to convert the image into another format-- most likely JPEG. JPEG has a settable "quality" factor-- you could simply keep reducing the quality factor until you got an image that was small enough. All of this can be done without changing the image resolution.
Obviously, depending on the image, the loss of visual quality may be substantial. JPEG does best for "true life" images, such as pictures from cameras. It does not do as well for logos, screen shots, or other images with "sharp" transitions from light to dark. (PNG, on the other hand, has the opposite behavior-- it's best for logos, etc.)
However, at 800x600, it likely will be very easy to get a JPEG down under 1MB. (I would be very surprised to see a 30MB file at those smallish dimensions.) In fact, even uncompressed, the image would only be around 1.4MB:
800 pixels * 600 pixels * 3 Bytes / color = 1,440,000 Bytes = 1.4MB
Therefore, you only need a 1.4:1 compression ratio to get the image down to 1MB. Depending on the type of image, the PNG compression may very well provide that level of compression. If not, JPEG almost certainly could-- JPEG compression ratios on the order of 10:1 are not uncommon. Again, the quality / size of the output will depend on the type of image.
Finally, while I have not used ImageMagick in a little while, I'm almost certain there are options to re-compress an image using a specific quality factor. Read through the docs, and start experimenting!
EDIT: Looks like it should, indeed, be pretty easy with ImageMagick. From the docs:
$magick> convert input.png -quality 75 output.jpg
Just keep playing with the quality value until you get a suitable output.
Your example is troublesome because a 30MB image at 800x600 resolution is storing 500 bits per pixel. Clearly wildly unrealistic. Please give us real numbers.
Meanwhile, the "cheap and cheerful" approach I would try would be as follows: scale the image down by a factor of 6, then scale it back up by a factor of 6, then run it through PNG compression. If you get lucky, you'll reduce image size by a factor of 36. If you get unlucky the savings will be more like 6.
pngtopng big.png | pnmscale -reduce 6 | pnmscale 6 | pnmtopng > big.png
If that's not enough you can toss a ppmquant in the middle (on the small image) to reduce the number of colors. (The examples are netpbm/pbmplus, which I have always found easier to understand than ImageMagick.)
To know whether such a solution is reasonable, we have to know the true numbers of your problem.
Also, if you are really going to throw away the information permanently, you are almost certainly better off using JPEG compression, which is designed to lose information reasonably gracefully. Is there some reason JPEG is not appropriate for your application?
Since the size of an image file is directly related to the image dimensions and the number of colours, you seem to have only one choice: reduce the number of colours.
And ~30MB down to 1MB is a very large reduction.
It would be difficult to achieve this ratio with a conversion to monochrome.
It depends a lot on what you want at the end, I often like to reduce the number of colors while perserving the size. In many many cases the reduced colors does not matter. Here is an example of reducing the colors to 254.
convert -colors 254 in.png out.png
You can try the pngquant utility. It is very simple to install and to use. And it can compress your PNGs a lot without visible quality loss.
Once you install it try something like this:
pngquant yourfile.png
pngquant --quality=0-70 yourfile.png
For my demo image (generated by imagemagick) the first command reduces 350KB to 110KB, and the second one reduces it to 65KB.
Step 1: Decrease the image to 1/16 of its original size.
Step 2: Decrease the amount of colors.
Step 3: Increase the size of the image back to its original size.
I know you want to preserve the pixel size, but can you reduce the pixel size and adjust the DPI stored with the image so that the display size is preserved? It depends on what client you'll be using to view the images, but most should observe it. If you are using the images on the web, then you can just set the pixel size of the <img> tag.
It depends on they type of image, is it a real life picture or computer generated image,
for real life images png will do very little it might even not compress at all, use jpg for those images, it the image has a limited number of different colors (it can have a 24 bit image depth but the number of unique images will be low) png can compress quite nicely.
png is basicly an implementation of zip for images so if a lot of pixels are the same you can have a rather nice compression ratio, if you need lossless compression don't do resizing.
use optipng it reduce size without loss
http://optipng.sourceforge.net/
Try ImageOptim https://imageoptim.com/mac it is free and open source
If you want to modify the image size in ubuntu, you can try "gimp".
I have tried couple of image editing apps in ubuntu and this seemed to be the best among them.
Installation:
Open terminal
Type: sudo apt install gimp-plugin-registry
Give admin password. You'll need net connection for this.
Once installed, open the image with GIMP image editor. Then go to: File > Export as > Click on 'Export' button
You will get a small window, where check box on "Show preview in image window". Once you check this option, you will get to see the current size of the file along with Quality level.
Adjust the quality level to increase/decrease the file size.
Once adjusting is done, click on 'Export' button finally to save the file.
Right click on the image. Select open with paint. Click on resize. Click on pixel and change the horizontal to 250 or 200.
That's the only thing. It is the fastest way for those who are using Windows XP or Windows 7.
As probably many people around here I read a few webcomics. Drowtales is my favorite, but that's besides the point.
For a long time a thought has been nagging me at the back of my head: webcomics are drawn pictures. They are not photographs. There should be a lot of redundancy (less colors, more flat colored areas, etc.) and thus they should be easily compressible at quite high rates while still maintaining lossless quality. Still it seems that the best tool to compress them is the same old lossy JPEG.
How so? Are there not better things invented? I'm not an expert in data compression, so my own meager attempts at finding some better algorithm have been fruitless. Best I could find was Pngcrush, but it still is way behind JPEG in terms of compression.
I would like to hear an expert opinion on this. Is this idea of mine foolish and doomed to failure? Or is there perhaps some way that people have found or that I could look into?
This, of course, comes from the selfish desire to decrease load times. :)
Added: Some people seem to miss the point, so I'll clarify:
Webcomic images should have a lot of redundancy in them so they should be easily compressible. Is it not possible to somehow compress them so that they would be both lossless AND smaller than JPEG? Or at the very least compress them better than JPEG while still retaining the quality.
Since they would be for web the specialized compressor should still probably emit PNG or JPEG - just compressed with a modified algorithm for better results.
No question, it's a balancing act between appearance and performance. Barring a custom compression algorithm specifically for comics, I think the best you can do is experiment with JPEG compression levels until you get one that's a reasonable size, but still looks good for the particular comic.
From lbrandy.com
The problem with comics is that a lot of graduated colouring is used. A common technique when colouring a comic on computer using Photoshop, for example, is to start by blocking out areas in solid colour as you mentioned. However, these solid areas are then refined using various techniques, from hand touching using airbrush tools to overlaying graduated fills, dodging and burning tools, etc.
The result is an image which is more like a natural image - which is what comic artists are striving for of course - and thus it compresses better with a lossy algorithm such as that used by JPEG.
A completely different approach would be to render the comic images using a vector format like SVG. That would capture the essence of the drawing (fill here, arc here, line here, etc) without having to try to raster-compress the resulting images.
Your assumptions aren't borne out by my data. My favorite webcomic is already distributed as PNG. Converting a 167K PNG file to JPEG using the default compression quality yields a 199K JPEG file. Break-even is somewhere between -quality 60 and -quality 65, which is quite a low quality for a JPEG. So, Questionable Content is already compressed lossless and smaller than JPEG.
A few things I've picked up on doing images for web use -
Use jpegtran -optimise on JPEGs - it recompresses them losslessly and can shave a good few percent off poorly compressed images.
I run PNG files through pngnq (make them 8 bit) and then optipng -i0 (recompress and remove any interlacing). I know you said you don't like lossy, but pngnq does an amazingly good job of converting images to a palette - best thing to do is try it yourself and see if the output is good enough.
Under certain circumstances, JPEG images will be larger than PNG images.
For example, in cases where there is a very simple image, PNG may end up compressing the image better and giving better image quality.
Here's an example with some Java code:
public static void main(String[] args)
{
BufferedImage img = new BufferedImage(
256,
256,
BufferedImage.TYPE_INT_RGB
);
Graphics g = img.getGraphics();
g.setColor(Color.white);
g.fillRect(0, 0, 256, 256);
g.setColor(Color.black);
g.drawLine(0, 0, 255, 255);
g.drawLine(255, 0, 0, 255);
try
{
ImageIO.write(img, "jpg", new File("output.jpg"));
ImageIO.write(img, "png", new File("output.png"));
}
catch (IOException e) {} // Don't usually ignore exceptions!
g.dispose();
}
The above code produces an image with the dimensions of 256 x 256 pixels, and draws two intersecting diagonal lines in the form on an "X".
The 256 x 256 image was used to keep the image size to an multiple of 8, as JPEG compression performs a 2D DCT transform on 8 x 8 pixel sections of the image. By keeping the image size and location of the line to align within the 8 x 8 pixel section, it will reduce the amount of compression artifacts and improve the quality of the image.
(Choosing 256 x 256 was empirical -- I at first used 100 x 100 and noticed that the JPEG image was horrible, so I tried 64 x 64 and it looked better, so I made it larger to simulate a more realistic image size.)
After drawing the image, the program generate a JPEG file and a PNG file. (The Java ImageIO library uses the default compression ratio of 0.75f for the compression quality of the JPEG.)
Results:
output.png : 1,308 bytes
output.jpg : 3,049 bytes
Taking a look at the image itself, the JPEG has a little bit of artifacting, but it wasn't very noticeable until I zoomed in with an image editor. Of course, the PNG image is lossless, so it was an exact representation of the original.
To conclude, whether an image is smaller with PNG or JPEG is really up to the source -- there are cases where JPEG can be larger than a PNG and yet the PNG can be better quality. Of course, in practice, generally PNG will be larger than JPEG for a given image.
You may want to cut down on how many colours you are encoding in your image. Try saving your comic with only 256 colours and watch the size decrease a lot. Depending on your specific drawing style, that me be enough.
I've drawn a number of large hand-illustrated circuit diagrams which I scan in as grayscale for use in computerized documents; LZW-compressed TIFF always wins hand over JPEG, both in viewable quality and file size, I think because TIFF can take advantages of RLE encoding for whitespace. I'm not sure whether PNG can do this too, or whether RLE can be extended for multicolor images & not just black/white.
edit: I just tried one of my grayscale hand drawings; TIFF can beat PNG by about 2:1 (43K vs. 83K using ImageMagick convert to go from original TIFF -> PNG -> TIFF again to double-check that ImageMagick is producing both file formats and ensure that my original program didn't do a bad job producing the TIFF) but only because TIFF uses 8bits/pixel (grayscale) and PNG uses 24bits/pixel (RGB).
edit 2: never mind, I just was able to use pngcrush -c 0 to ensure the image is grayscale. PNGcrush got the RGB version down to 67K and the grayscale down to 34K. Nice!
edit 3: Just a point of procedure: It seems to me that it would make a heck of a lot more sense to pick a number of different images of this type to choose as standard benchmarks, and just try different techniques across the benchmark set, rather than just a bunch of stack-overfloids pontificating. This seems like a problem that needs a well-tested empirical solution.
No matter how great a lossless compression is, a loss compression will always be better, because it just has fewer limitations.
Imagine that one day they invent some lossless compression better than jpeg for comics, obviously the next day someone will modify it to compress more, even, and probably, if it means that some info is lost.
Between anti-aliasing and gradients, there are probably more colors in the image than you think.
Drawn vs. not drawn, web comics vs. any other type of image... that's not relevant. The specifics of how web comics are drawn or the colors are laid out or whatever is something you're perceiving as different. But you can bet that decades of graphics research and development have that fully taken into account, and the people that do graphics optimizations for a living have pushed the envelope.
If there was a better compression algorithm than JPEG, GIF, PNG, etc. then don't you think it would be in wide-spread use? If you're looking for fairly recent breakthroughs then I think you're probably wasting your time, as 1) you'd have to expend quite a bit of effort to make your front-end compression compatible with whatever viewer people use (like browsers) and 2) if it had significant gains from current formats then it would become wide-spread fairly quickly.
If I'm getting down-voted I must not have explained myself very well.
Thinking that web comics are in some special domain because they're hand-drawn or have lots of color repetition is a bit silly. Finding large blocks of the same color is one of the absolute basics of image compression.
Get yourself a good graphics program, and using your specific image, see which of its export formats yields the smallest image size while retaining the quality you desire. It is going to be different for different images.
For pen-and-inkish images, the compression scheme in GIF can work wonders.
JPEG compression is ill-suited to that kind of image.
As someone who has done a lot of colouring work for cartoons, as well as photo-manipulation work I can safely say that there is often a lot going on inside the average web-comic when compared to a normal photo.
Assuming that the image is done in Photoshop or Painter (usually from a Tablet) there are often a number of filters or layers at work in the average web-comic. Shading, reflection, opacity, background images and far more come into the equation and with many of these being straight from filters or layer overlays there are often many colours in place.
A lot of the time you have to think of your audience. It is really worth optimising your images if you get 20 visitors a day? I'd probably argue that it is completely down to the size and content of your web-comic. If you can get away with PNG then I'd stick with it. More often than not in web-comics there is little going on to warrant using JPG.
I use OPTIPNG to get the best filter (with a sane level) and then I run ADVDEF -4 -z
http://advancemame.sourceforge.net/comp-readme.html (Not Advpng because Advpng removes the filters) to optimize the deflate.
Also you can try pngout http://www.advsys.net/ken/utils.htm
Has a plugin for Irfanview.
It uses the same deflate implementation of Kzip, which is usually even better than 7-zip but much slower.
EDIT:
okcancel20031003.gif What's your favorite "programmer" cartoon? 256 colors 147KB
PNG (Paint) 126KB
PNG (Irfanview) 120 KB
PNG (Irfanview) +
Optipng -o5 120KB (525 bytes smaller) 9s
Optipng + ADVDEF 114 KB 9s+0.9s
PngOut 114 KB 6s
BMP 273 KB
BMP +
7z (LZMA -fb 273) 107 KB
RAR (Best) 116 KB
BMF -S 90 KB 0.3s
Paq8o10t -4 79 KB 35s
I think the missing piece of information here is Image Compression is Tied to the Format. It's certainly possible that someone could come up with a compression algorithm that was/is well suited for the kind of images that web cartoonists create. However, once you took the new uber-comic-image format and emitted a PNG, JPG or GIF, the color information would be subject to the rules of the PNG, JPG or GIF compression mechanism and you'd lose all the benefit of your new image format.
Here's another way to think about it.
Save a photo as a low quality JPEG
Note the file size
Take that low quality jpeg and save-as a 24/32 bit PNG
Note the larger file size
The same thing would happen to this mythical uber-comic-image format.
The alternative would be getting the major browser vendors to support uber-comic-image nativity. I'll leave the reasons behind that not working as an exercise to the viewer.