JyrkiAlakuijala

6 ms·

1.
by JyrkiAlakuijala 21d ago
Depends on the user. Some users are more sensitive for flashing images. Some users have very slow or unreliable network connection. Some sites have bigger images. Some sites (such as ecommerce) have higher quality and resolution needs. Some
2.
by JyrkiAlakuijala 4mo ago
I made that AI rendering and consider it demonstrates the conceptual discussions we had likely better than what an actual whiteboard drawing would look like. An actual whiteboard drawing from our day to day work would be very confusing with
3.
by JyrkiAlakuijala 4mo ago
Parent comment says I should not be known and my picture should not be on the blog post. I just want to disagree with that. In my opinion JPEG XL is a notable success and it is also ok to celebrate us, its makers.
4.
by JyrkiAlakuijala 4mo ago
No it would not, qoi falls behind even my 2011 WebP lossless design. Also, it is not a competition for the shortest specification. If it was, still good. Jpeg xl spec is about half the size of the original jpeg spec.
5.
by JyrkiAlakuijala 4mo ago
I wrote it, with some help from Gemini as my own English is clumsy and expensive to correct manually, and created the "photo" and the "chart". I am to blame. I thought the story of a 10+ year running OSS project with int
6.
by JyrkiAlakuijala 4mo ago
Thank you. Jpegli is still a hidden gem. People don't yet understand how great it is.
7.
by JyrkiAlakuijala 4mo ago
We (Google) built JPEG XL (together with Cloudinary). The main photography mode and the JPEG compatibility mode is from Google. Chrome decided not to be an early adopter for good reasons that they have publicly documented, but that did noth
8.
by JyrkiAlakuijala 4mo ago
No, it is normal. Similarly Jon's blog post does not name any of us by name.
9.
by JyrkiAlakuijala 4mo ago
Two reasons: The people in the pic look more or less like our real ourselves. The synthesized photo shows the process of discussing highly conceptual approaches, which was our everyday for 10 years or so.
10.
by JyrkiAlakuijala 4mo ago
This was not a factor. It was either staging the photograph or AI. Photographing inside the office can be a complex process with seeking appropriate permissions, and I didn't have an alternative space to do the photography. AI felt lik
11.
by JyrkiAlakuijala 4mo ago
True, no one can understand my whiteboard drawings the next day, not even I.
12.
by JyrkiAlakuijala 4mo ago
This discussion happened in a chat window in reality, but is based on a real discussion between me and Luca, leading to reversing the order of "ac strategy" from splitting to joining.
13.
by JyrkiAlakuijala 4mo ago
I spent 10+ years in building JPEG XL and I'm proud of the result. It wasn't always easy times. It is not so bad people can see what I look like and take a peek what the process was to get there. This article is not about the entr
14.
by JyrkiAlakuijala 9mo ago
I designed the lossless format and its initial encoder. Zoltán Szabadka wrote the initial lossless decoder. On2 Technologies had designed the lossy format and its initial encoder/decoder. Skal improved on the encoder (rewriting it for
15.
by JyrkiAlakuijala 9mo ago
Disclaimer: As a manager I led the JPEG XL design, implementation and standardization effort at Google, and as an IC I was responsible for lossy format, encoding heuristics and image quality. JPEG XL is not that massive. JPEG XL spec is sli
16.
by JyrkiAlakuijala 10mo ago
Thank you! I designed WebP lossless alone. The rest of the WebP folks added a RIFF header and an artificial size limitation (16383x16383) to match with the size limitation of lossy WebP. In JPEG XL I believe I had more influence on the loss
17.
by JyrkiAlakuijala 10mo ago
Not really. FLIF is too slow to decode, about 20x slower than WebP lossless. JPEG XL modular mode uses a similar static context modeling with WebP lossless and Brotli and likely LZHAM where all the entropy codes are generated at decoding ti
18.
by JyrkiAlakuijala 10mo ago
When I built WebP lossless format I kept testing design decisions against PNG. The average gain against my Internet PNG test corpus was 42 % and 26.5 % if I optimized the PNGs with pngcrush and pngout (kzip). I had not yet come up with Zopf
19.
by JyrkiAlakuijala 10mo ago
the article includes test code and encoder code, that is not the way how we compute the decoder size the decoder is something around 30 kloc
20.
by JyrkiAlakuijala 10mo ago
This is some strange misinformation. The C++ JPEG XL decoder is ~30'000 lines, i.e., 3000x smaller than you claim. A non-multithreaded, non-simdified code would be much simpler, around 8000 to 10000 lines of code. It is not difficult t
21.
by JyrkiAlakuijala 11mo ago
JPEG XL supports UltraHDR. JPEG XL's normal HDR capabilities were not harmed in the process when UltraHDR was added. It was added for reaching parity with JPEG1 and HEIF/AVIF for the needs of UltraHDR developers and believers.
22.
by JyrkiAlakuijala 11mo ago
Brotli decompresses 3-5x faster than LZMA2 and is within 0.6 % of the compression density, and much better for short documents. ZStandard decompresses ~2x faster than Brotli but is 5 % less dense in compression density, and even less dense
23.
by JyrkiAlakuijala 11mo ago
Would PDF 2.0 (which also depends JPEG XL and Brotli) put pressure on Firefox and Windows to add more easy to use support?
24.
by JyrkiAlakuijala 11mo ago
Zstd decompresses faster, perhaps 2x faster, but Brotli is fast enough. Often a little faster than gzip/deflate. Brotli can compress more because of context modeling, about 5% more without the static dictionary and even more with it. B
25.
by JyrkiAlakuijala 11mo ago
The original JPEG XL requirements were relational colors, where colors are an issue external to the codec. I was able to sufficiently convince the rest of the jpeg committee that we can achieve similar interoperability with absolute color,
26.
by JyrkiAlakuijala 1y ago
Seeing JPEG XL integrated into the DICOM standard was a particularly proud moment for me as the manager of the effort at Google. It felt like closing a major circle in my career, because I spent the first 16 years of my career in the medica
27.
by JyrkiAlakuijala 1y ago
zstd compresses less, so you wait a bit more for your data
28.
by JyrkiAlakuijala 1y ago
except DNG, ProRAW, DICOM, GDAL, TIFF, Apple's and Microsoft's operating systems, Linux distros, and Windows support JPEG XL otherwise the same
29.
by JyrkiAlakuijala 1y ago
PNG with ZStandard or Brotli is much worse than WebP lossless.
30.
by JyrkiAlakuijala 1y ago
Thank you. I agree with the sentiment that WebP lossless has stand the test of time better than WebP lossy. In some comparisons even Jpegli is more attractive from compression density point view than WebP lossy. Disclaimer: I am the designe

More ›