JyrkiAlakuijala

10 ms·

91.
by JyrkiAlakuijala 3y ago
It was just easiest to develop in libjxl repo. All test workers etc. are already setup there. This was done by a very small team...
92.
by JyrkiAlakuijala 3y ago
We insert/extract about 2.5 bits more info from the 8 bit jpegs, leading to about 10.5 bits of precision. There is quite some handwaving necessary here. Basically it comes down to coefficient distributions where the distributions have
93.
by JyrkiAlakuijala 3y ago
Yes!
94.
by JyrkiAlakuijala 3y ago
I believe guetzli is slightly more robust around quality 94, but jpegli likely better at or equal at lower qualities like below 85. Jpegli is likely about 1000x faster and still good.
95.
by JyrkiAlakuijala 3y ago
The original names of the related tech was pik and huif. Also Guetzli, Brotli, Butteraugli, XYB, Brunsli, SSIMULACRA, FLIF, FUIF are related names.
96.
by JyrkiAlakuijala 3y ago
AVIF, AV1, WebP lossy and Opus use traditional arithmetic coding. JPEG XL, Brunsli, Draco 3D and ZStd use table-based arithmetic coding (ANS). JPEG, Deflate, Brotli, MP3, WebP lossless and the fastest mode of JPEG XL lossless use prefix cod
97.
by JyrkiAlakuijala 3y ago
Jpegli has the possibility of using XYB. By default as by being just a replacement of mozjpeg or libjpeg-turbo it doesn't. I believe Jon has compared jpegli without XYB. If you turn XYB on, you get about 10 % more compression. Jpegli i
98.
by JyrkiAlakuijala 3y ago
Yes, if local tone mapping is done by the operating system (windowing system or the monitor itself), then there is a chance that borders of windows are done appropriately within their spatial context.
99.
by JyrkiAlakuijala 3y ago
This depends on the quality you are aiming for. You just cannot reach the best quality with 8 bits, not in SDR, not in HDR, not with gainmap HDR. Sometimes you don't care for a particular use case, and then 8 bits becomes acceptable. M
100.
by JyrkiAlakuijala 3y ago
I think both approaches have advantages. Requiring every game, photo viewing app, drawing program, ... every application to decide how to do it's HDR->SDR seems unnecessary complication due to poor abstractions. The locality of loca
101.
by JyrkiAlakuijala 3y ago
I didn't try it out, but I don't see the 9 bit coming. I feel it gives about 7.5 bits. Mixing two independent quantization sources will lead to more error. Some decoding systems such as traditional jpeg does not specify results ex
102.
by JyrkiAlakuijala 3y ago
You could start with relatively good jpegli as a codec and then lossless recompress that with jpeg xl. Naturally some entity (server side, app, content encoding etc.) needs to unpack the jpeg xl jpeg into a usual jpeg before it can be consu
103.
by JyrkiAlakuijala 3y ago
It would be nice if everything was non tone-mapped HDR all the time for software, and the windowing system or the monitor would do the (local) tone mapping.
104.
by JyrkiAlakuijala 3y ago
Do you have a link? Or was it a private communication?
105.
by JyrkiAlakuijala 3y ago
Companies and economies who optimize the cost of clients as if their own can see diffuse benefits from it. Even if they consider 0.01 % of that cost it can lead to better decisions. If that will make the website load faster or allow for mor
106.
by JyrkiAlakuijala 3y ago
Another group of incompatibility with PNG was 16 bit coding. I had a plan to add it as simply sending two 8 bit images where the second image containing the 8 least significant bits would be predicted to be the same as the first. That way i
107.
by JyrkiAlakuijala 3y ago
We have been active on wasm implementations of jpeg xl but it doesn't really work with progressive rendering, HDR canvas was still not supported, threadpools and simd had hickups etc. etc. Browser wasn't and still isn't ready
108.
by JyrkiAlakuijala 3y ago
People don't use blurry low quality images in the web. These low qualities don't matter outside of compression research. Average/median quality of images is between 85 to 90 depending how you calculate it. There, users'
109.
by JyrkiAlakuijala 3y ago
I designed the WebP lossless format, wrote the spec, and implemented the first encoder. The constraint was in WebP lossy to facilitate exact compatibility with VP8 specification and hoping that it would allow hardware decoding and encoding
110.
by JyrkiAlakuijala 3y ago
I believe JPEG XL binary size is about one third of AVIF binary size. It is relatively compact. It is easy to write a small encoder: libjxl-tiny is just 7000 lines of code.
111.
by JyrkiAlakuijala 3y ago
Or replace/ldconfig the jpeg library with the jpegli library. It is API/ABI compatible with libjpeg-turbo and mozjpeg.
112.
by JyrkiAlakuijala 3y ago
https://opensource.googleblog.com/2021/09/using-saliency-in-... can be interesting
113.
by JyrkiAlakuijala 3y ago
That feels a little sad. If qoi had anything good (fast single-threaded decoding speed for photographic content) adding bz2 most certainly removed it. They could have just used WebP lossless and it would have been faster and smaller.
114.
by JyrkiAlakuijala 3y ago
No bitstream changes. In JPEG XL we have a 3-bit control field for each 8x8 square to guide which pixels participate in smoothing. The heuristics (here https://github.com/libjxl/libjxl/blob/main/lib/
115.
by JyrkiAlakuijala 3y ago
WebP near-lossless is very far in compression density against that kind of visually lossless. Still 2-3x more bits I think. No reason to compare. The near-lossless (at settings 60 and 80) is closer to pixel perfect no matter how much you zo
116.
by JyrkiAlakuijala 3y ago
Gainmaps don't solve 8-bit mach banding. If anything you get more banding: two bandings, one banding from each of the two 8-bit fields multiplied together. Gainmaps "solve" the problem of computing a local tone mapping by dec
117.
by JyrkiAlakuijala 3y ago
This limit didn't exist in my first version as well as the 4 GB limit. These were artificially introduced to "match" the properties of lossy WebP. We could have done better there.
118.
by JyrkiAlakuijala 3y ago
Also more savings will come for JPEG XL soon. Possibly mostly focused on medium and low quality.
119.
by JyrkiAlakuijala 3y ago
I plan to add 15–25 % more quality in the ugly lowest end quality in JPEG XL in the coming two months.
120.
by JyrkiAlakuijala 3y ago
* [...] monetary or hardware costs. We could perhaps create a GoFundMe page for making it cost neutral for Chrome's partners. Perhaps some industry partners would chime in. * Does JPEG XL work best for the web? Yes. * What is JPEG XL c

More ›