jonsneyers

14 ms·

31.
by jonsneyers 3y ago
I agree that subjective (human) testing is better than comparing using metrics, but the downside is that you can only look at so many images, and it depends quite a lot on the image content how the various codecs perform. When doing a visua
32.
by jonsneyers 3y ago
We may have to wait for hw jxl encoders for that. Which is likely to happen, but it will definitely take time. Meanwhile there will be software options for authoring, e.g. Adobe Camera Raw. For the web, the trade-offs between encode speed,
33.
by jonsneyers 3y ago
I am not sure how exactly the "progressive avif" works, but it looks like basically something optional that comes at a cost in the final file size, whereas in jxl some basic progressive encoding is always available (at least for l
34.
by jonsneyers 3y ago
Here's a summary of the main points: https://jpegxl.info/why-jxl.html Basically lossy WebP and AVIF are video codecs, which are designed for the kind of quality you want when you can only see an image for 40 millisecon
35.
by jonsneyers 4y ago
See also: https://www.theregister.com/2021/07/31/iso_paywall_battle/
36.
by jonsneyers 4y ago
The number of implementations was not considered a criterion for Chrome, or at least they didn't mention it. For WebP, they didn't seem to care much about it. I agree that it's a good criterion, as it is a good way to ensure
37.
by jonsneyers 4y ago
Defensive license termination is actually a good thing. It is how you can keep a codec royalty-free. Without defensive termination, it is way too easy in the current patent system for patent trolls to make bogus claims and bully companies i
38.
by jonsneyers 4y ago
I can think of a few aspects where avif is limited. 12-bit is fine for delivery, but it's not enough for authoring. Cameras are typically 14-bit and during authoring you'll want some footroom on top of that. Also avif is not usabl
39.
by jonsneyers 4y ago
It isn't. The baseline profile is limited to 9 megapixels, the advanced profile is limited to 36 megapixels, but you can also have a valid avif file that doesn't conform to any profile and that is larger. For software decoders tha
40.
by jonsneyers 4y ago
WebP was supported in Chrome about a decade before it became widely used. It was even already supported before the format was even finalized: lossless and animation were added after the first (lossy-still-only) WebP support was enabled in C
41.
by jonsneyers 4y ago
The whole point of lossy compression is to lose numerical information in a way that doesn't lose visual information. Computing the amplitude of the numerical loss is not very relevant, since it's the visual loss that matters (and
42.
by jonsneyers 4y ago
Actually, the results of the AVIF team's comparison do show the value of JPEG XL, if you look a bit further than the main page and dig into the actual plots. E.g. according to this plot, JXL is about 15% better than AVIF for 'web
43.
by jonsneyers 4y ago
Ultimately, 'real lossless' does not exist since all raster image data (or audio data) consists of quantized samples with a limited spatial (or temporal) resolution (and in case it was captured, as opposed to synthesized, there wi
44.
by jonsneyers 4y ago
Have you signed this open letter already? https://www.theregister.com/2021/07/31/iso_paywall_battle/
45.
by jonsneyers 4y ago
This "two for one" reasoning does have some downsides though. Here I listed ten of them: https://twitter.com/jonsneyers/status/1596965036131426304?s=...
46.
by jonsneyers 4y ago
Where did you get the information that Apple will never support JPEG XL? I haven't heard or seen anything from Apple, neither in favor nor against JPEG XL. I would assume though that when Adobe and Serif (and their open source alternat
47.
by jonsneyers 4y ago
I agree that such comments are not useful. I can understand the frustration people may feel (very well actually), but it is not productive to express it in such ways. I don't encourage such reactions, but I do think they are understand
48.
by jonsneyers 4y ago
I think the way to go for browsers is to support new codecs (as long as they're plausibly useful for the web, royalty-free, etc), but to avoid getting stuck with them by having web devs assume they can use codecs without content negoti
49.
by jonsneyers 4y ago
Have you heard about AVIF?
50.
by jonsneyers 4y ago
I don't think it's a niche use case. The amount of existing JPEG files is huge. Having a way to compress them better without having to worry about introducing additional loss, is a "nobrainer" type of improvement.
51.
by jonsneyers 4y ago
Which google group are you referring to? The bugtracker? Some of the comments there are useful imo, e.g. when image experts from various companies bring their views. Others are basically just "+1", which is better done by just sta
52.
by jonsneyers 4y ago
Some people don't like Google or Chrome in general, for various reasons (valid or not), and they'll use any opportunity to criticize them. JPEG XL was made in the JPEG committee and the two main proponents were Google and Cloudina
53.
by jonsneyers 4y ago
I can assure you that for anyone dealing with large volumes of storage and/or bandwidth of still images (i.e. pretty much any high-traffic website), where costs directly related to storage/bandwidth are measured in millions of dol
54.
by jonsneyers 4y ago
Do you have any sources on that? And who would be the one making any claims relevant to JPEG XL or asking for royalties? Because I have not seen anyone other than Cloudinary and Google declare to have patents relevant to JPEG XL, and those
55.
by jonsneyers 4y ago
As an editor of the JPEG XL spec, I fully agree that ISO's paywall policy is bad in many ways. But I wouldn't say it's a "closed" standard. Not any more closed than, say, the C++ standard or the Unicode standard. Wh
56.
by jonsneyers 4y ago
JPEG XL is an approved international standard: ISO/IEC 18181 https://www.iso.org/standard/77977.html Anyone interested in doing an independent implementation can use this specification (or a recent draft of the up
57.
by jonsneyers 4y ago
Here is some basic info on jxl: https://jpegxl.info/why-jxl.html
58.
by jonsneyers 4y ago
Well but you cannot have a 5-10 times smaller WebP at a quality comparable to JPEG. If low quality is good enough for you, then you can get maybe a 10-20% saving compared to JPEG (not 80-90% as you are claiming, that is ridiculous). At high
59.
by jonsneyers 4y ago
Most cameras produce 4:4:4 JPEGs at a high quality (something around q96 or more, on the libjpeg scale). WebP cannot do that kind of quality: it uses forced 4:2:0 and not full-range 8-bit YCbCr like JPEG but tv-range 8-bit, which effectivel
60.
by jonsneyers 4y ago
It's scroll-snapping, but it looks like it does more harm than good on some browsers so I just removed it. Please refresh :)

More ›