cavif-rs
cavif-rs copied to clipboard
can we convert PNG with specified sampling format?
First,thank you for this very helpful tool ! In my case, convert the png file to avif ,I found that it will generate a pink stripe at the right edge of the png file. It is the same situation in AOMediaCodec/libavif when encoding with the " -y 444" option, but not with "-y 420" or "-y 422" So, i guess it (Chroma Subsampling) is the cause of this little problem.
CLI: cavif -Q 50 test.png
the original image for test:
after convert like this( a jpeg for just show what it looks like):
Thank U!
This crate always uses 444 (highest resolution) color sampling, so it isn't supposed to cause any distortions like this.
Do I understand correctly that you've encoded this image using a different tool and still saw the incorrect line? That would suggest it's a bug in the decoder, not the encoder.
I would prefer to kill chroma subsampling for good. AV1 handles color quite well, and doesn't need to continue the tradition of using a mathematically-dubious hack invented for an analog TV signal from more than a half century ago.
This crate always uses 444 (highest resolution) color sampling, so it isn't supposed to cause any distortions like this.
Do I understand correctly that you've encoded this image using a different tool and still saw the incorrect line? That would suggest it's a bug in the decoder, not the encoder.
I've encoded this image using "avifenc", the cli is "avifenc -y 444 tray.png tray_avifenc.avif", and using "cavif" with "cavif -Q 50 tray.png" . They both get the incorrect line at the right edge, but It is correct when I encode it with "avifenc -y 422 xxxx.png xxx.avif". I'm not familiar with "Chroma Subsampling", just a guess!
operating system: Windows 10 subsystem for linux
I've read in this blog that the vertical bar is an issue with Microsoft Photos, so might indeed be a decoder issue
Additionally, for avif images created by libavif, Microsoft Photos will have a strange vertical color bar on the right side of the images when the format is set to YUV444
Yup, I think it's a decoder issue.