Closed tomByrer closed 3 years ago
I'm not seeing any shift at all. Maybe it's something caused by color profile processing?
I'll have to try it on Cloudflare Workers sometime ;)
BTW, Cloudflare uses this encoder internally: https://developers.cloudflare.com/images/resizing-with-workers
color profile processing
That could be, I'm on Win10, but happens on both monitors. There is a bug linked in the Squoosh thread I linked to Firefox. I'll test on another machine with Chrome & Manjaro; have a test suite of images?
On my macOS it looks the same in Firefox nightly and Chrome canary. There is a little bit of posterization in the gradient on gray background, but that is just a compression artifact.
Solid backgrounds on both source & rendered.
Can you add a screenshot of a decoded image? I'm not sure if we're looking at the same image and disagreeing what a color shift is, or whether it's a decoder-specific issue.
Might be ChromaSubsampling not being 444; something I found testing other AVIF tools.
I'm not sure how to config ChromaSubsampling : 444; not in your readme & I can't read Rust that well now. (Though I understand the filesize will increase; I'm trying to isolate browser bugs, so perhaps CS444 is not good for production.)
It's definitely 444, and I'd never use anything less with AVIF.
File size does not increase with 444 in AV1. AV1 has chroma-from-luma. OTOH 420 is a total mistake, because chroma upsampling algorithm has been left undefined, so there's large error that can't be avoided.
I would assume a large area would not color shift at all (aside from edges perhaps), but unfortunately it does. I can test on what ever test images you want.
Good news: not as bad as Squoosh, which uses their own WASM version of
libavif
.Thanks for for your tool! I'll have to try it on Cloudflare Workers sometime ;)
source:
cavif.exe -Q 80 -s 8