Progressive decoding doesn't help there, and doesn't jibe well with spatial prediction, which helps AV1 and other video codecs preserve sharp lines. AVIF is the format for AV1 video keyframes. Phones want the encode hardware anyway for video, and you can crunch a zillion megapixels down to a smaller file with AVIF before attention-grabbing artifacts crop up-at low bitrates AVIF seems good at preserving sharp lines and mostly blurring low-contrast details (compare Tiny images).įinally, worth noting the codecs are different due to a bunch of rational choices by their devs. I think those will give JPEG XL a niche on the Web. (I know the parent comment is from a JXL contributor, I'm saying this for other folks.) AVIF has a lossless mode too, but JPEG XL seems ahead here. JXL's lossless mode is the successor to FLIF/FUIF, is really good, and also has progressive decoding. jpg file can be recovered bit-for-bit.Ĥ) Lossless mode. jpg repacking: JPEG XL can pack a JPEG1 about 20% smaller without any additional loss the original. Facebook found encode/decode speed and progressive decoding to be points in favor of JPEG XL for their use: ģ). (Old demo from a JXL contributor at )Ģ) Fast conversion: JPEG XL encoding/decoding is fast without dedicated hardware. This can give JPEG XL the edge in perceived load speed even when the full. jxl can give you a low-quality image when a fraction of the file is loaded, then a decent-quality image, then the final image. Some notable features of JPEG XL that don't show up in side-by-sides:ġ) Progressive decoding. If you enjoy an image so much that you're willing to go to the effort to get the image, why not acquire the image throuh legit method? The group think is more of "I want what I want" vs consideration for what the artist's intentions are. I mean, an artist's work posted on the internet is not the cure for cancer, or basic information on algebra where the info should be evergreen. I get that info wants to be free blah blah, but I also understand that artists are in a difficult situation with the internet. I sympathize with both sides of this argument. Maybe one of the features of JXL would be a timebomb type of setting where after a certain date the data is no longer useable. Just because you have the technical know how to extract an image that is not readibly downloadable via the UI does not mean you should. Just like art moves from museum to museum, an artist can allow an image to be used within a pre-defined window. >And as long as websites tend to modify, delete, move, or otherwise play games with urls and content then perhaps it should not be published on the internet at all.Įxcept an artist can deliberately decide to only make an image publicly available for a limited time, and therefore taken the image down from the website. To mitigate that, I think it would help a lot of browsers would have a "Save As." dialog box on images that gives users the choice to save the actual image in whatever format it is in, or to convert it to PNG or JPEG. It is a fact that the release cycle of browsers is more suitable for innovation than that of most other software, so it does make sense to start there even when it will still cause things to break in software that doesn't support it yet. Design decisions like limiting the maximum dimensions and bit depth at the codec level "because that's all the web needs" plus limited attention/focus to adoption outside browsers does lead to the phenomenon you describe where "it doesn't work for everyone", causing the small gain of improved compression to be dwarfed by the huge inconvenience of breaking workflows.Īny new codec of course has this problem even if they do target wide adoption (like JPEG XL): adoption is never instantaneous. WebP in particular, as the name suggests, was conceived as an "image format for the web" and while I think it's good to have the web in mind when designing an image codec, I think it's a bad idea to limit the scope like that. ![]() I agree with this, and I think for this reason it is best if a new codec gets wide adoption also outside browsers, instead of having the approach of a "web codec" where it suffices that servers and browsers know about it but the wider ecosystem doesn't support it.
0 Comments
Leave a Reply. |