Viewing profile — JyrkiAlakuijala

[dead]

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 d…

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 als…

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…

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…

Thank you. Jpegli is still a hidden gem. People don't yet understand how great it is.

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 r…

No, it is normal. Similarly Jon's blog post does not name any of us by name.

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 ever…

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 …

True, no one can understand my whiteboard drawings the next day, not even I.

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 joini…

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 wa…

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/d…

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 ima…

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…

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 LZ…

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…

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

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, ar…

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 t…

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…

Would PDF 2.0 (which also depends JPEG XL and Brotli) put pressure on Firefox and Windows to add more easy to use support?

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…

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 w…