3 ms·

JXL dev here. Thanks for raising these points. Indeed regrettable we have to have a bunch of boilerplate. FYI we actually do support hooks for malloc (JpegxlMe

• jiggawatts 7y ago
  > Indeed regrettable we have to have a bunch of boilerplate. Just to clarify: I'm not criticising the JPEG XL code, it seems to be quite clean at first glance! I was merely making a general observation that would apply to practically all portable C-interface libraries, such as ZStandard, libpng, etc... PS: I wonder if it would be possible to make a "portable library header" that all such similar libraries could share to avoid the rework on both ends (library authors and library consumers)... > Windows hasn't been our focus yet. That's a real worry. Not just because of the word "Windows", but what else it implies. To provide some constructive feedback: JPEG XL will be yet another failure thrown on the trash heap of similarly well-intentioned formats. It'll die along with JPEG 2000, JPEG EXR, and all of the others. Don't be so arrogant to think that somehow your format will be special and adopted by the masses. The others were just as technically advanced for their time and they all failed. Please, please, please learn this lesson, because this history of failure saddens me. The lack of a capable image formats compatible with all client platforms is what stops me as a photographer from sharing my images in full quality. In 2020, still, it is effectively impossible to share images in any other format than 8-bit sRGB JPEG across platforms. You can't email a HDR, 10-bit, or wide gamut picture to anyone and expect them to be able to open it and have it look even vaguely right. You can't post such an image on any website you don't control yourself. Even if you control the website, it will look wrong for 99.9% of users OR they'll just see the 8-bit sRGB version anyway, even if they have 10-bit HDR display. It is literally only the walled garden of the Apple ecosystem that gets this right. Microsoft and Google most certainly doesn't. As an iPhone user, I can share a wide-gamut HEIF picture and 100% of the time it will look correct for other iPhone users. However, Apple "cheated" a little bit. When you send one of their HEIFs to any non-Apple-controlled app, it's silently converted to... 8-bit sRGB JPEG. It's just sad. What everyone gets wrong with new image formats is this: They think that the problem that needs solving is the encoder/decoder. That's step one of many problems that users need solved. Image format developers assume their format will be "adopted", but there's no network effect. Why would anyone use a format they can't email, can't open on Windows 7, and can't edit in Photoshop? If you stop with the JPEG XL library, with Windows compilation an afterthought, I absolutely guarantee that you will fail to gain traction and the entire effort will be essentially wasted. To get actual adoption, you would need to: * Most importantly, develop an image decoder plugin for Windows. * Help Firefox, Safari, and other less common browsers merge support. * Ensure that Chromium gets support, but I assume that's a given. * Send pull requests to add JPEG XL support for all major open source libraries that perform image processing, such as WordPress plugins and server-side image processing utilities for websites. * Develop a plugin for all major image editing tools such as Photoshop. * Work with Adobe on Lightroom export support. * Contact Sony, Nikon, and Canon and help them with in-body encoding support. But even that's not enough. If you want 10-bit and the wide gamut (let alone HDR), you have to take steps to force support, or it won't magically materialise. You'll end up with two JPEG XL formats: The 8-bit SDR sRGB variety with 99.9999% adoption and the "fancy" JPEG XL that nobody uses and looks wrong if they try. IMHO the only way to do this is to forcibly break applications that aren't processing the ICC profiles properly. Much like Google's Chrome experiment with randomising some TLS header fields to occasionally break middle boxes written by idiots that think version numbers are checked with equality, not inequality operators. You'd have to do something drastic, like leaving the image planes unnamed and randomised so that literally the only way to decode the image correctly is via a compliant colour space transformation. It sounds drastic, but other people have tried the easy way and failed. As I said: It's 2020!!! Email me a non-sRGB image that I can view in my mail client...
  • janwas 7y ago
    > 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.