I am trying to compress and resize DSLR camera photos. But my observation so far is that webp has noticeable degraded quality when webp file size is about 30% smaller than JPEG.
Command used to generate webp using imagemagick:
convert 1.JPG -strip -quality 80 -resize 800 -define
webp:method=6 1.webp
My goal is to get webp format that is at least 20% samller file size than JPEG while having virtually no difference in quality between JPEG and webp.
Is this achievable or again there is no such thing as free lunch?
Update Since the time of the original posting, I've discovered that using Google's cwebp compressor shows dramatically improved compression over ImageMagik 6.7.8, which is what powered my initial tests. This is especially true for images with transparency when compared to PNGs. Files using the mac version of the webp command (which uses cwebp under the hood) are about 1/4 of the size of the same file compressed with ImageMagik, and do provide a significant performance boost.
According to Google, "WebP typically acheives an average of 30% more compression than JPG" (source) with similar visual quality to a JPG. However, as you suggest, there in never such a thing as a free lunch.
Quality
Quality is largely a subjective measure, but keep in mind that you're comparing a file compressed at quality 80 with a file that doesn't have that level of compression (at least, this is what I understand from your question). Just running the default conversion without specifying a lower quality may give you slightly smaller files without loss of visible quality. 20% smaller might be a bit much of an ask, though, but it may be achievable for certain images.
convert 1.JPG 1.webp # do not specify quality
Size
In practice, it depends a lot on your settings and your source images. For example, I recently ran this command on all jpg images in a folder on a website "in the wild":
convert filename.jpg -quality 80 -strip -define webp:lossless=false -define webp:method=6 filename.webp
The convert command on this particular server is powered by ImageMagick 6.7.8. Some files were dramatically smaller compared to the original JPGs, while others were actually larger. Overall, after running that command, the total file sizes of all JPG images was 49MB, while the total file size of all WebP images was 29MB. That's a pretty good savings, however, when I ran ImageMagick's JPG compression, it was even better:
convert filename.jpg -sampling-factor 4:2:0 -strip -quality 80 -interlace JPEG filename-new.jpg;
The size of all new jpgs in the directory was 21MB. Both are set to compress at quality 80, but the jpg compression appears to be better. This may have to do with some compression already on my set of test images and how that interacts with the WebP conversion process.
As I found, file sizes can even grow, usually if you are converting between lossy and lossless images. On the FAQ page linked above, Google claims: "this is mainly due to the colorspace difference (YUV420 vs ARGB) and the conversion between these."
tl;dr: In the wild, it may or may not improve file size depending on the type of images, if/how the source file was compressed, and what quality you set for the WebP. Visible degradation is harder thing to measure, but try setting a higher quality, or without specifying a quality at all.
Just to add a side-comment to #Pwpwpw's excellent answer, webp is a good PNG replacement, but not great as a JPG replacement.
It beats PNG because it has better lossless compression algorithm than libpng, and it has the great feature of allowing different compression settings for different channels. You can do lossless on the alpha but lossy on the RGB, for example, which is fantastic for overlays.
Against JPG it does less well. It uses the VP8 codec for lossy, which is only somewhat better than JPG.
I would take a look at HEIC. It uses the much more modern h.265 for lossy compression and typically beats JPG by a factor of two at the same quality. It's the format Apple are using by default on iOS now.
libheif have a nice demo here:
https://strukturag.github.io/libheif/
That's libheif, compiled to javascript and running in your browser. You can upload .heic to it and download as jpg. libheif have some basic command-line tools to encode and decode images.
It does sadly have some patent issues, you might need to be a little cautious.
update Looking further out, the current hope is AVIF: it's the same container format as HEIC (called HEIF, confusingly), but swaps the problematic h.265 compressor for AV1. AV1 is roughly equivalent to h.265, but is patent-free.
update for 2022 AVIF seems to be too slow to be practical, so now hope rests on JXL. It's fast, patent free, supports HDR, transparency, etc., and compression is as good as HEIC. Chrome has support, though it's behind a flag for now.
You are re-encoding lossy compressed jpeg; if you have access to the original raw files you should use them as master. Currently you are compressing noise (and other artefacts) introduced by the jpeg encoder so the WebP codec does not have access to the same information that was already lost at the jpeg encoding. Of course it will look worse.
In other words; you should encode the original image data, if possible. I'm aware that some cameras and equipment only outputs HEIC / JPEG and not RAW so you might be out of options - the best thing to do is to keep the JPEGs as JPEGs.
Just did a quick test with a high-res JPG from my DSLR camera converting to a 410x800 background picture for mobile using Photoshop CC 2020 (and the WebPShop plugin).
Lossless:
PNG 100%: 680 KB
JPG 12 (max): 428 KB
WEBP 100%: 537 KB
50% quality:
JPG 6 (50%): 119KB
WEBP 50%: 45KB
At 50% JPG has more detail, but quite comparable quality.
0 quality:
JPG 0 (min): 51KB
WEBP 0%: 6KB
At 0% WEBP is horrible. But imagine the lowest quality JPG, and that's bad image quality and WEBP definitely beats it at 50%, while still being smaller in file size. So for me.. that's free lunch.
Related
I have certain png files. They are of size approx 1MB. I tried several command but they didn't work for me. Any suggestions. One is as below :
"C:\\Program Files\\ImageMagick-6.9.9-Q16\\mogrify.exe" -depth 8 -format png -define PNG:compression-strategy=2 -define PNG:compression-filter=0 test.png
Thanks,
As pointed out by #fmw42 in comments, your image may already be optimized. Also, #Mark's comment regarding reducing colors is true.
But apart from this, the important thing to know is that "there is no ideal command". You will have to figure out bit depth in your color channels and reduce them. There will always be a trade-off between reducing colors and quality you wish to pick.
Apart from that, there can also be other methods that you can use:
If opacity of PNG is fully opaque, you can strip alpha channel as it
makes no sense in that case. This can give you some file size savings.
If the image is visibly grayscale and still color type is
true-color, true-color-alpha or indexed-color, you can make significant savings by saving the image with a grayscale color space.
Retry optimizing PNG files using adaptive delta filtering and LZ77 Optimizations. This can be done easily using "optipng". But if the image is already optimized enough, this won't provide significant file sizes reduction. Moreover, choice of filtering depends upon png bit depths, so you would have to look up and understand PNG compression from various documentation available online regarding PNG compression.
The title pretty much sums up the question but I was wondering if JPG/PNG files have a notable difference in speed and performance when using CIFilters. Is using one type of file preferred over the other? Is there another file type that could be potentially faster than both JPG and PNG?
JPEG and PNG are storage mechanism. Filters have to be performed on uncompressed data, not on JPEG or PNG streams.
The speed difference between JPEG and PNG occurs reading or writing. PNG compression generally is slower than JPEG compression. PNG expansion is generally faster than JPEG.
JPEG is not suitable for images that have abrupt changes in color, e.g. drawings, cartoons.
JPEG is not suitable for images that are stored, retrieved, modified, stored . . . . Each cycle changes the image.
JPEG generally produces much smaller compressed streams than PNG.
It actually depends! PNG's are better if it is a smaller image, as it cuts away the white surrounding what is actually there. But, it does not compress at all to maintain quality. This could slow down performance. JPEG compresses, therefore cutting down file size, but also compromising quality to a point. I'd say go for JPEG if it is a huge image for the app, but go for PNG if you want quality.
Thanks for asking and hope this helps. If this answers your question, I'd love if you could just hit that check mark.
Cheers,
Theo
I have a bunch of images that I want to convert into a single PDF, the images are primarily images of text (similar to scanned images of a textbook). The image files are extremely large, I have no need for the amount of resolution that they offer.
So first, as a base file, I did a simple conversion of 26 of these "pages" to a single pdf, and the total filesize was 46MB for 26 pages. Viewing in page width mode resulted in a scale of 16% of the original image.
convert *.png kapittel1.pdf
The quality of the PDF pages was perfect, they were just too large. So I figure since 16% of the image is more than adequate for viewing the entire width of the page on my screen, I could reduce the image sizes to 20% of their original values and still maintain the same image quality. The quality of the images is visibly less than before reducing the size.
convert -resize 20% -quality 100% *.png 20percent.pdf
I believe I'm going to need to start looking into filters, but before I potentially waste my time converting using all of the filters then comparing to find the one I want to use, is there a better way to just reduce the size, maintain quality, then convert to PDF? I don't see why I would be losing pixels here.
Edit
I tried with -scale instead of -resize but am really not seeing a difference in the output. It pretty much seems that once I go below 40% I start losing pixel data.
The excellent ImageMagick Examples state that by default, no image compression is used when creating PDFs and suggest to use Zip (Deflate Compression):
convert *.png -compress Zip -quality 100 kapittel1.pdf
If your images are only black and white, you can try the -monochrome option and optionally Group4 (Fax) compression using -compress Group4.
Ok well I discovered that the size of the PDF once following Shawn Patrick Rice's suggestion for Optimizing Scanned PDFs and OCR+ClearText was fairly negligible between a -resize setting of 30-50%. The primary goal here is to reduce the size of the resulting PDF to under 45" in height as this is the threshold for Adobe's OCR. I found no benefit from converting each image individually to a PDF then resizing, or playing with the plethora of other settings in Adobe. The below process kept (as far as I can tell) all of the image quality and reduces the images to the smallest size PDF (at full quality).
My process was as follows:
convert *.png -resize 50% name.pdf
// resize amount dependent on original file dimensions, goal is document height < 45"
Adobe Acrobat => Document Processing => Optimize Scanned PDF (Edit => ClearScan output style) => OK
The size of the resulting PDF document is still quite large, however the size after reducing in Adobe goes down considerably (90MB => 4MB). If I first resized at 30% there would be noticeable image quality loss, however the amount of size I would save after optimizing would be around 800KB for the above file.
guys , can anyone explain me why when im converting my jpeg into new file with command line:
convert -quality 80 file.jpg file2.jpg
File size is 20Kb
But if i open this file with Gimp and just save is as file2.jpg with quality 80, i have 10Kb size.
The quality scales used by imagemagick and GIMP are probably different. JPEG is a fairly complex format, and it has more parameters than one simple "quality" setting. For example, the type of chroma sub-sampling (4:2:0 vs 4:2:2, etc).
Here's what the GIMP documentation says about this:
The JPEG algorithm is quite complex, and involves a bewildering number of options, whose meaning is beyond the scope of this documentation. Unless you are a JPEG expert, the Quality parameter is probably the only one you will need to adjust.
This is likely to be true for other applications (such as PhotoShop, etc) as well.
Play around with some of the other parameters in both GIMP and imageMagick and it is likely that you will get similar results. If you post your image, then people may be more inclined to play around with it.
convert -quality 80 -type palette -strip -depth 8 file.jpg file2.jpg
This solve the problem and the file size is very similar to gimp or photoshop.
For iPhone game development, I switched from PNG format to PVRTC format for the sake of performance. But PVRTC compression is creating files that are much bigger than the PNG files.. So a PNG of 140 KB (1024x1024) gets bloated to 512 KB or more in the PVRTC format.. I read somewhere that a PNG file of 50KB got compressed to some 10KB and all, in my case, its the other way around..
Any reason why it happens this way and how I can avoid this.. If PVRTC compression is blindly doing 4bpp conversion (1024x1024x0.5) irrespective of the transparencies in the PNG, then whats the compression we are achieving here..
I have 100s of these 1024x1024 images in my game as there are numerous characters each doing some complex animations.. so in this rate of 512KB per image, my app would get more than 50MB.. which is unacceptable for my customer.. ( with PNG, I could have got my app to 10MB)..
In general, uncompressed image data is either 24bpp (RGB) or 32bpp (RGBA) flatrate. PVRTC is 4bpp (or 2bpp) flatrate so there is a compression of 6 or 8 (12 or 16) times compared to this.
A requirement for graphics hardware to use textures natively is that the format of the texture must be random accessible for the hardware. PVRTC is this kind of format, PNG is not and this is why PNG can achieve greater compression ratios. PVRTC is a runtime, deployment format; PNG is a storage format.
PVRTC compression is carried out on 4x4 blocks of pixels at a time and at a flat bit rate so it is easy to calculate where in memory to retrieve the data required to derive a particular texel's value from and there is only one access to memory required. There is dedicated circuitry in the graphics core which will decode this 4x4 block and give the texel value to your shader/texture combiner etc.
PNG compression does not work at a flat bitrate and is more complicated to retrieve specific values from; memory needs to be accessed from multiple locations in order to retrieve a single colour value and far more memory and processing would be required every single time a texture read occurs. So it's not suitable for use as a native texture format and this is why your textures must be decompressed before the graphics hardware will use them. This increases bandwidth use when compared to PVRTC, which requires no decompression for use.
So for offline storage (the size of your application on disk), PNG is smaller than PVRTC which is smaller than completely uncompressed. For runtime memory footprint and performance, PVRTC is smaller and faster than PNG which, because it must be decompressed, is just as large and slow as uncompressed textures. You might gain some advantage with PNG at initialisation for disk access, but then you'd lose time for decompression.
If you want to reduce the storage footprint of PVRTC you could try zip-style compression on the texture files and expand these when you load from disk.
PVRTC (PowerVR Texture Compression) is a texture compression format. On devices using PowerVR e.g. most higher end mobile phones including the iPhone and other ARM-based gadgets like the iPod it is very fast to draw since drawing it is hardware accelerated. It also uses much less memory since images are represented in their compressed form and decoded each draw, whereas a PNG needs to be decompressed before being drawn.
PNG is lossless compression.
PVRTC is lossy compression meaning it approximates the image. It has a completely different design criteria.
PVRTC will 'compress' (by approximating) any type of artwork, giving a fixed bits per texel, including photographic images.
PNG does not approximate the image, so if the image contains little redundancy it will hardly compress at all. On the other hand, a uniform image e.g. an illustration will compress best with PNG.
Its apples and oranges.
Place more than one frame tiled onto a single image and blit the subrectangles of the texture. This will dramatically reduce your memory consumption.
If you images are, say, 64x64, then you can place 256 of them on a 1024x1024 texture in a 16x16 arrangement.
With a little effort, images do not need to be all the same size, just so long as you keep track in the code of the rectangle in the texture that each image is at.
This is how iPhone game developers do it.
I agree with Will. There is no point in the question. I read the question 3 times, but I still don't know what Sankar want to know. It's just a complain, no question.
The only thing I can advice, don't use PVRTC if you mind to use it. It offers performance gain and saves VRAM, but it won't help you in this case. Because what you want is just reducing game volume, not a consideration about trade-off between performance and quality.