I have this image (photo taken by me on SGS 9 plus): Uncompressed JPG image. Its size is 4032 x 3024 and its weight is around 3MB. I compressed it with TinyJPG Compressor and its weight was 1.3MB. For PNG images I used Online-Convert and I saw webp images much more smaller even than compressed with TinyPNG. I expected something similar, especially that I read an article JPG to WebP – Comparing Compression Sizes where WEBP is much smaller that compressed JPG.
But when I convert my JPG to WEBP format in various online image convertion tools, I see 1.5-2MB size, so file is bigger than my compressed JPG. Am I missing something? WEBP should not be much smaller than compressed JPG? Thank you in advance for every answer.
These are lossy codecs, so their file size mostly depends on quality setting used. Comparing just file sizes from various tools doesn't say anything without ensuring images have the same quality (otherwise they're incomparable).
There are a couple of possibilities:
JPEG may compress better than WebP. WebP has problems with blurring out of the details, low-resolution color, and using less than full 8 bits of the color space. In the higher end of quality range, a well-optimized JPEG can be similar or better than WebP.
However, most of file size differences in modern lossy codecs are due to difference in quality. The typical difference between JPEG and WebP at the same quality is 15%-25%, but file sizes produced by each codec can easily differ by 10× between low-quality and high-quality image. So most of the time when you see a huge difference in file sizes, it's probably because different tools have chosen different quality settings (and/or recompression has lost fine details in the image, which also greatly affects file sizes). Even visual difference too small for human eye to notice can cause noticeable difference in file size.
My experience is that lossy WebP is superior below quality 70 (in libjpeg terms) and JPEG is often better than WebP at quality 90 and above. In between these qualities it doesn't seem to matter much.
I believe WebP qualities are inflated about 7 points, i.e., to match JPEG quality 85 one needs to use WebP quality 92 (when using the cwebp tool). I didn't measure this well, this is based on rather ad hoc experiments and some butteraugli runs.
Lossy WebP has difficulties compressing complex textures such as leafs of trees densely, whereas JPEGs difficulties are with thin lines against flat borders, like a telephone line hanging against the sky or computer graphics.
I have a good understanding of pros and cons of different image formats for web use.
However, I'm trying to decide what format to use for a desktop application.
I have a potentially large number of high-resolution images (with no transparency) to deploy. I'm mainly weighing JPG vs. PNG, but am open to other formats.
My understanding:
JPG is more compressed, which means smaller file size, but probably lower image quality. Because they are more compressed, they take more time to decompress.
PNG files are larger, but maintain image quality. Because they are less compressed, they decompress faster.
Both occupy the same amount of RAM once loaded and decompressed.
Seems that PNG is a better option, given that HD space (i.e. application size) is not an issue, because it will decompress and appear on-screen faster, and maintain higher image quality.
Are my assumptions generally correct? Are there any nuances I'm overlooking? Any other image file formats worth considering?
Your assumptions are roughly correct.
Because [JPG] are more compressed, they take more time to decompress.
Not exactly, a JPG supports distinct levels of compression, the time to decompress depends on the algorithm itself, which is slighly more complex than PNG. However, decompression speed is rarely an issue. And, in any case, that depends wildly on the decoder implementation.
Seems that PNG is a better option, given that HD space (i.e. application size) is not an issue is not an issue, because it will decompress and appear on-screen faster, and maintain higher image quality.
May be. PNG is definitely better if your program is going to read-modify-write the images; JPG is not advisable in this scenario -unless you use lossless JPG. If, instead, the images are read only, the difference is less important. Notice that for high resolution photographic images, the compression ratio can be quite different; and, even if you are not worried about HD space, bigger files can be slower to read because of I/O performance.
I would go with Jpeg.
The size is small compared to other formats and you could compress it in high quality mode so it would be very hard to notice any Jpeg artifacts. Regarding decompression, since most of the decompression procedure is math and CPU runs much faster than memory you will be amazed to hear that in many cases decompressing a Jpeg is faster than reading a PNG from the disk and displaying it.
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.
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.