Replies: 1 comment
-
You can extend the image encoding with an external decoder, the upcoming release will make that even easier. Mentioned an example in #177. In case of enquiries feel free to reach out |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Some days ago we migrated our project from image-rs to zune-image and we are all amazed by the great performance of zune-image in encoding/decoding JPEG and doing basic image ops. Now in another project, as much as we would like to stick with zune-image, we are facing a new challenge: we need a blazingly fast lossy codec that supports opacity.
It seems currently the only possible candidate zune-image supports is JPEG-XL. However, the current decoding implementation is extremely slow that we didn't even bother to check if it really lossily compressed - in a benchmark, the result image size is 258KiB, far bigger than the 41KiB size of JPEG (both using default quality setting).
We certainly have the choice of separating the alpha channel manually, compress the RGB channels and the alpha channel individually as JPEG blah blah, but that's too much hassle to deal with.
Other than that I guess we could try WEBP, but zune-image does not support it so we need another crate for the codec, but ideally we would like to keep it simple. We'd be much appreciated if someone can shed some light on the format choice (within or without zune-image, and an apology in advance if this violates some rules here).
Beta Was this translation helpful? Give feedback.
All reactions