jonsneyers

8 ms·

61.
What Is JPEG XL?(jpegxl.info)
40 points by jonsneyers 4y ago|7 comments
62.
by jonsneyers 4y ago
Correct. Same for WebP. Both were enabled before their specs were even finalized.
63.
by jonsneyers 4y ago
The Chrome team did not create JPEG XL, that was a totally different team. The Chrome team did create WebP and was heavily involved in the creation of AVIF.
64.
by jonsneyers 4y ago
Note a small detail you left out: all this happened to AVIF _after_ it was enabled by default in Chrome...
65.
by jonsneyers 4y ago
JXL currently has two levels: Level 5 (intended for browsers), allows no CMYK, limits the number of channels to 7, limits the maximum lossless bitdepth to 14-bit or so (the actual criterion is that the intermediate buffers can be implemente
66.
by jonsneyers 4y ago
Then again, libjpeg-turbo could probably be dropped if we spend some effort on making libjxl also decode jpegs (and encode them, since browsers also need to do be able to do that for jpeg). I think that could reduce the net cost of adding j
67.
by jonsneyers 4y ago
I think you must be doing something very wrong if you measure less than 1 Mpx/s for fjxl. It should reach at least 50 Mpx/s or so, and of course more if you are using multiple threads. Anyway, yes, we should improve decode speed —
68.
by jonsneyers 4y ago
I don't particularly like the name either, but it already had a name before it existed — that's the way JPEG works, the ones who write the Call for Proposals give it a name, not the ones who actually bring the proposals and design
69.
by jonsneyers 4y ago
That's good to know, and nice that Mozilla did that!
70.
by jonsneyers 4y ago
Yes, that's a problem when a format is not standardized but controlled by a single entity. JPEG XL is standardized though, and backwards-incompatible changes are essentially impossible.
71.
by jonsneyers 4y ago
As one of the authors of the spec, I would be open to also publishing it with another standardization organization that makes specs publicly available, if the legal issues can somehow be sorted out. I think the other spec authors would also
72.
by jonsneyers 4y ago
That's a difference between AOM and ISO: ISO puts specs behind a paywall but anyone interested can participate in the actual standardization process through their national standardization body, AOM makes specs publicly available but pa
73.
by jonsneyers 4y ago
Recent drafts do tend to get circulated amongst the image compression community. For wide audiences I don't think this type of document is very readable nor relevant; the number of people who are going to make their own independent imp
74.
by jonsneyers 4y ago
Did you compile fjxl with or without SIMD? That makes a big difference. And yes, fpnge is slightly faster than fjxl but also compresses significantly worse. It is likely that you could make an even faster but slightly worse version of fjxl
75.
by jonsneyers 4y ago
Warning: this only works in nightly builds of firefox. In stable and beta they have the flag but they're not compiling the code, so it just doesn't work.
76.
by jonsneyers 4y ago
It was probably a bad idea to put such examples on twitter, since twitter recompression is quite aggressive and makes a big difference. I don't have the original decoded images nearby but it is best to do these kinds of comparisons wit
77.
by jonsneyers 4y ago
It hasn't received news or updates because it has been locked. Basically Mozilla's position seems to be that they're not going to do anything on this front until Chrome does it first. I can only assume the decision makers at
78.
by jonsneyers 4y ago
Firefox still doesn't support animated AVIF, or does it now?
79.
by jonsneyers 4y ago
Also libwebp reached 1.0 only about 8 years after it was added to Chrome. So I don't think this is a major criterion. That said, we are aiming to reach the libjxl 1.0 milestone within a reasonable timeframe, i.e. somewhere in 2023, pr
80.
by jonsneyers 4y ago
Lossless encoding can be done with various trade-offs between speed and compression density. At one extreme we have fjxl, see e.g. https://twitter.com/LucaVersari3/status/1485971553892323333?... . This is an extrem
81.
by jonsneyers 4y ago
If you want to wait for W3C to approve a new codec, good luck with that. Looking at https://www.w3.org/Graphics/ , I see only PNG, JPEG, GIF and SVG mentioned. For adding WebP and AVIF to Chrome this was not an issue. R
82.
by jonsneyers 4y ago
Do you sometimes go outdoors to an area that has poor connectivity? Not all of the modern world has the same kind of network speed. If all pages would always load in less than 0.1 seconds for every web user, I would agree with you. But this
83.
by jonsneyers 4y ago
Full JXL is not hardware-friendly enough to be used as-is in a video codec. A trimmed down subset of JXL could work, but I doubt they would accept it in AV2. Video-derived image formats like WebP, HEIC and AVIF all have issues in the high q
84.
by jonsneyers 4y ago
In terms of burning needs you could argue that AVIF and WebP also don't really fill those, since they are not _that_ much better than JPEG with a good encoder while they lack progressive decode.
85.
by jonsneyers 4y ago
Precision bounds are in 18181-3.
86.
by jonsneyers 4y ago
I doubt it's related to that. That patent is too recent to affect JPEG XL.
87.
by jonsneyers 4y ago
You need firefox nightly for that - they don't compile it into the main builds...
88.
by jonsneyers 4y ago
Highlights of what's new in this release: - Decode/encode api for metadata (Exif, XMP etc) - Decode api for getting separate layers and spot colors (by default, the decoder blends layers and spot colors automatically and only retu
89.
by jonsneyers 4y ago
You can probably learn something from what is available on jpeg.org and jpegxl.info, as well as looking at the libjxl or j40 implementations. Is there anything in particular you would like to know?
90.
by jonsneyers 4y ago
HEIF and in particular HEIC is a patent encumbered codec though...

More ›