Explore more insightful benchmarking of the latest SVT-AV1 2.1.0 encoder and how it fares when encoding animation. The author, Trix, spared no expense in creating an incredible number of detailed graphs to support their conclusions about which settings are the best and why. Give it a read!
> Aviator has been migrated to use newer libadwaita widgets, 5.1(side) audio encoding is fixed, and variance boost updates and optimizations in SVT-AV1-PSY improve encoding efficiency, eliminate artifacts, and provide significant speed boosts across various presets.
I must say, I really like the QOI image codec despite its shortcomings for coding efficiency and flexibility - it is dead simple, easy to implement, and super effective for what it is! I'd be happy in a world where we used QOI instead of PNG for a lot of stuff. And I've already fallen in love with Zig, which I think is very easy :)
I've had a bit of trouble wrapping my head around color spaces since writing about XYB JPEG and discovering OKLAB and the world of perceptual color - these 3-D models do help a lot, though! Highly recommend reading!
Hey everyone - wanted to announce a nice Aviator update that happens to coincide with an SVT-AV1-PSY update that we pushed just yesterday.
Aviator 0.5.1 has a couple new features, but chief among them is a new Subjective Tuning toggle for enabling encoder changes that improve visual quality at the expense of metrics. This is powered by SVT-AV1-PSY's new Tune 3 authored by Clybius; it adds subjectively motivated optimization to the existing Tune 2's great performance for an incredible balance of retaining fine detail in videos while still preventing blocking.
Here's a comparison encoded with Aviator (both 10-second videos were 7.5MB, down from the lossless source's 732.8 MB): https://slow.pics/c/tdrO5dY4
(the source is Netflix's foodmarket at 1080p)
If you prefer the smoother-looking, more appeal-oriented shot here, that is OK too - Subjective Tuning is toggleable!
Aviator 0.5.1 should be available on Flathub pretty soon. Enjoy!
"... Interop 2024 omits JPEG XL, the most popular proposal as measured by community reactions (emojis added to proposal discussion threads). JPEG XL garnered 646 reactions, more than four times more than the second place finisher, which also wasn't included."
An unfortunate conclusion from a clearly biased group that is supposed to be unbiased. Unfortunate, unclear decision making from Interop this year.
I never said JXL is feature creep. I said the implementation of random codecs regardless of whether any are already in development is feature creep, thats a big difference.
> that's what the video-based codecs are.
How comes that implementing video-based image codecs is feature creep? Ok look, i never had something against JXL, thats your imagination playing you.
In fact, I am of the opinion that every halfway reasonable codec should be built into browsers, but only one after the other and not together in a random order for every browser.
> You're thinking from a purely web-based standpoint here.
Sure i do, the topic is literally codecs in browsers :blobcatgoogly:
> JXL would be the only promising image codec to hopefully not need to look at another one for a very long time.
I doupt it, the past has shown that new algorithms are built which are faster or make things smaller... All the time. But yes, currently JXL is a proper codec to store images.
> I can tell you right now that professional photography, medical imaging, astrophotography, etc are simply not interested in AVIF, while JXL has the features to make everyone happy across the Web and beyond
Since i like stuff to read, source please.
In my experience, codecs are used which are established in the broad masses. So here are my predictions: I have the feeling that the HEIF container will spread due to its support in common OSes, and because the operating systems do not support all codecs of the HEIF container, I think that HEIC will prevail for the time being.
But we will see
@Jain Implementing too many codecs at once can get messy, which is why a new video-based codec every couple of years is an unfortunate sight to see, in my opinion. Especially considering WebP's failure (except the lossless part).
The AVIF spec was actually submitted as a proposal for JXL, but was rejected. That should have been the sign to relinquish AVIF development, if implementing things "together in a random order" is bad for the Web since it was known it would overlap with JXL which was always supposed to be a superset of AVIF or something better.
Regarding interest from professional use cases, I've seen JPEG XL discussed for these use cases in the JXL Discord. The JPEG XL project itself touts features like wide dynamic range support, layers, excellent lossless compression, and an incredible number of possible channels. Aside from HDR, the above are missing from AVIF. So, while adoption is still early, there is excitement about having a modern codec that can handle specialized needs beyond what JPEG and PNG currently offer. More info on JXL: https://wiki.x266.mov/docs/images/JXL
HEIC is not supported pretty much at all on the Web due to licensing restrictions, which make it very difficult to ship HEIC images. I would say AVIF has the most momentum now, even moreso than HEIC, but JPEG-XL and other future formats could gain traction once native browser support spreads.
Apparently the #samsung Galaxy S24's "downloadable" Gallery app (not sure what this means) supports JPEG-XL compression in RAW images!
> Downlodable App
> 1. Expert RAW
> The basic resolution has been improved from 12MP to 24MP, and image quality and tone in low light have been improved through nightography technology collaboration.
> In addition, Digital ND filter, which was supported as beta in previous S23, is officially provided and Auto mode is provided for user convenience.
> Additionally, storage capacity has been reduced while maintaining image quality by providing JPEG XL format.