siiptuo / pio Goto Github PK

Some images like graphics, for example this are actually much smaller as lossless WebP than a lossy WebP at any quality. So it might be a good idea to try to compress the WebP as lossless first and then try the different quality settings.

I tried to optimize a webp image, here's the output:

|                 [--O-] |  85 quality  0.007544 SSIM  113 % of original
|                    [O] |  90 quality  0.007544 SSIM  113 % of original
|                     [O |  93 quality  0.007544 SSIM  113 % of original
|                      O |  94 quality  0.007544 SSIM  113 % of original
|                      O |  95 quality  0.007544 SSIM  113 % of original
Failed to optimize the input image, copying the input image to output...

and the command is:

./pio-x86_64-unknown-linux-musl xxx.webp --output output.png

Because DSSIM uses an average error when calculating dissimilarity, images with large flat colored areas are compressed too much. It would be useful to use approach like Butteraugli which calculates the worst error instead of average error. This could be done for example by calculating the 75th percentile error with DSSIM.

Example image 1

Pio selects image quality 88. So far so good.

Example image 2

Pio selects quality 49. Image turns into blurry mess :(

Automatic --min calculation does remedy this somewhat but it's a bit of a band-aid fix

Rotate the image data accordingly.

While testing out pio I realized that discarding transparency from my PNG images when converting with cwebp using -noalpha substantially decreased the size of the output images, surpassing pio's output with the same quality settings.

The PNG's of my source are just screenshots, where alpha/transparency information is useless.

Would love to convert my images using pio and use a similar --no-alpha option!

Thank you for your fine work!

Important especially when overwriting files: see https://lwn.net/Articles/457667/. Maybe add --in-place option and also check if input and output files are the same.

Would be a convenient feature. This could also make correct usage easier i.e. no lossy intermediate image.

Hi, I would like to test this tool, but I can't use it 🤷🏽‍♂️

It could be cool to have lossless compression for PNG (using OxiPNG or something) and WebP. I know lossless compression isn't the main point of pio but it would be useful to have benefits provided by pio such as sRBG conversion and rotation when dealing with lossless images.

Convert input to sRGB using Little CMS and embed TINYsRGB, sRGBz or Compact ICC Profiles to the output.

If the source is baseline JPEG and resulting encoded JPEG would be larger, losslessly convert image to progressive JPEG instead of copying.

Like jpegran does.

This is more a question than a true feature request, but the issues seemed the only place to ask it. Pio is a really useful stand-alone utility, but I have on a few occasions wanted to use it within other rust applications as the processing step for images. Zola (or other static site generators) in particular springs to mind, but many other projects would likely benefit from being able to encode images as small as possible, while still retaining quality.

Is there any possibility in the future of making pio's functionality available as part of a crate? Something with a limited api that would allow calling it within other rust code. E.g. something along the lines of pio(format: Jpeg, quality: 80) perhaps?

Because WebP Q settings are not identical to JPEG Q settings, it’s not 100% correct to set the min and max quality based on the JPEG SSIM table.

Maybe we should generate another table for WebP and use that to set WebP min and max quality values based in the JPEG equivalent SSIM?

As noted in the readme

The input image should preferably be PNG or lossless WebP, or alternatively JPEG or lossy WebP stored with a high-quality setting (95-100). pio will make already lossy compressed images look worse.

It could be useful if pio could automatically estimate the quality and if it falls below target quality, prevent double compressing the image. Something like this or this could be used to estimate the quality.

Image quality target could also be scaled depending on the compression of the original. For example, if the original image quality is lossless/100 and the target is 80, compression would be applied normally. But if the original image quality is 90 and the target is 80, less compression would be applied to keep the end result similar and not degraded because the original image quality is lower.

This needs some testing. I think in some extreme cases double compression is avoided because the file size of the double compressed image would be larger than the original.

There shouldn't be any need to try 4:4:4 chroma subsampling on 4:2:0 input, for instance. Though in practice, this might prevent generation loss.

In addition to 444, 422 and 420 add automatic subsampling. Generate 3 variants of the optimized image and pick the smallest.

Original image straight from an iPhone in p3 color space

Image converted by ImageMagick w/ convert -profile sRGB2014.icc IMG_1706.jpg IMG_1706_imagick.jpg

Image converted by Photoshop to sRGB

Image optimized by pio from the original

Colors shift to less saturated / more bluish