> I'm not criticising the JPEG XL code, it seems to be quite clean at first glance! Thanks, I understood your point about each project including its own definit

> I'm not criticising the JPEG XL code, it seems to be quite clean at first glance! Thanks, I understood your point about each project including its own definitions. At one point there was http://www.bookofhook.com/poshlib/ http://www.bookofhook.com/poshlib/, but I'm not aware of anything similar that's maintained, complete enough but still small. > That's a real worry. Not just because of the word "Windows", but what else it implies. We have put a great deal of thought into an adoption plan. "This time is different" because we actually provide value to existing clients/servers with JPEG, rather than giving them yet another bitstream to store, or lossy transcoding that just adds more artifacts. The lossless JPEG transcoding is a game-changer, as is the feasibility nowadays of decoding via WebAssembly - even with SIMD for speed. > If you stop with the JPEG XL library, with Windows compilation an afterthought Good news, we are absolutely not stopping there. The project started in 2015. We're now moving out of the research phase and into productionizing, with integrations and plugins underway. Investing in such things too early would have meant less R&D. > You'd have to do something drastic, like leaving the image planes unnamed and randomised Interesting idea, thanks for this suggestion.