Closed rodsotdia closed 1 year ago
Oh interesting! YOu are right that has probably to do with colorspaces. On the web we rely on canvas to convert to sRGB, on the CLI I just take what the decoder gives me.
@surma Probably is something with the decoder, the results are different and distinguishable between each version (web and CLI).
I get particularly bad results trying to compress an image to webp using the CLI. Online the result is fine, but offline it does not seem the encoder options are being respected. I get potato quality regardless of the options I pass to the CLI. Tried copy/pasting the CLI from the webapp too, to no avail.
Yup, can confirm and reproduce. Looking into this.
I figured out the potato quality on WebP. Seems like I bundled an old version of the WebP Wasm binary by accident. I fixed that and published @squoosh/cli@0.6.1
.
I still see some minor file size difference, even when I use a PNG source file, which is very surprising to me. I’ll look at that another time.
@surma Thanks for look into this. What about the color space with both formats?
@rodsotdia From what I can tell, the MozJPEG decoder does indeed decode to sRGB. Do you see color issues?
I'm having the same quality issues on v0.6.1 (possible duplicate of https://github.com/GoogleChromeLabs/squoosh/issues/898). Output size is the same (and very aggressively compressed) regardless of the chosen value of --optimizer-butteraugli-target
.
@surma Yes, I think the color space is different: Left: Original Center: Processed through app. Right: Processed through cli.
The original is a jpeg processed to mozjpeg. I'm using the following parameters in both app and cli:
squoosh-cli --mozjpeg '{"quality":75,"baseline":false,"arithmetic":false,"progressive":true,"optimize_coding":true,"smoothing":0,"color _space":3,"quant_table":3,"trellis_multipass":false,"trellis_opt_zero":false,"trellis_opt_table":false,"trellis_loops":1,"auto_subsample" :true,"chroma_subsample":2,"separate_chroma_quality":false,"chroma_quality":75}' -d out image.jpg
I am also experiencing problems where WebP images are dismissed as invalid in the CLI, but are decoded correctly in the browser. It sounds pretty reasonable to me that it is because the CLI relies on a different decoder, so I haven't spend much more time on it. Let me know if you want a complete bug report with sample images.
Got same problem with oxipng
, from web I got this command :
npx @squoosh/cli --quant '{"enabled":true,"zx":0,"maxNumColors":16,"dither":1}' --oxipng '{"level":3,"interlace":false}'
The working command:
npx @squoosh/cli --quant '{"enabled":true,"zx":0,"numColors":16,"dither":1}' --oxipng '{"level":"3","interlace":false}'
We need to use numColors
with cli, not maxNumColors
. And we can use level: 6
with the cli.
Unfortunately, due to a few people leaving the team, and staffing issues resulting from the current economic climate (ugh), the CLI and libsquoosh packages are no longer actively maintained. I know that sucks, but there simply isn't the time & people to work on this. If anyone from the community wants to fork it, you have my blessing. The squoosh.app web app will continue to be supported and improved.
I used the CLI to output a
jpg
using--mozjpeg
and--webp
, but using the same options given on the tool based on the web, the output given to me is different.Output on the web: mozjpeg -> 92.4kb webp -> 51.6kb
Output using the CLI: mozjpeg -> 84.9kb webp -> 13.2kb
Also, CLI affects the space color of the image and gives a bad compression, resulting in a worst processed image, comparing with the tool based on the web. I used the same
.jpg
source for this test, and the same options (I copied the same code that offers the web, the npx command).I used on the CLI:
webp version
mozjpeg version