JPEG Committee releases a call for evidence for image compression based on AI
I&#x27;ve been in the C#, Java, and Rust world for so long that every time I come across C&#x2F;C++ library source it <i>cracks me up</i> that an image compressor has to have functions to redefine basic concepts like memory allocation, assertions, and threading.<p>Reminds me of a &quot;lightweight&quot; zip compression library that I recently used that was literally 98% overhead and 2% actual compression code. It had its own definitions of <i>everything</i>: integers, integer properties, memory allocation, streams (as in sequences of memory blocks, not even real I&#x2F;O!), error handling, progress notifications, etc... Pages and pages of conditional macros and compiler-specific hacks. Just to call a single a function that took an array and returned an array. Ridiculous.<p><a href="https:&#x2F;&#x2F;gitlab.com&#x2F;wg1&#x2F;jpeg-xl&#x2F;-&#x2F;blob&#x2F;master&#x2F;include&#x2F;jpegxl&#x2F;memory_manager.h" rel="nofollow">https:&#x2F;&#x2F;gitlab.com&#x2F;wg1&#x2F;jpeg-xl&#x2F;-&#x2F;blob&#x2F;master&#x2F;include&#x2F;jpegxl&#x2F;...</a><p><a href="https:&#x2F;&#x2F;gitlab.com&#x2F;wg1&#x2F;jpeg-xl&#x2F;-&#x2F;blob&#x2F;master&#x2F;include&#x2F;jpegxl&#x2F;parallel_runner.h" rel="nofollow">https:&#x2F;&#x2F;gitlab.com&#x2F;wg1&#x2F;jpeg-xl&#x2F;-&#x2F;blob&#x2F;master&#x2F;include&#x2F;jpegxl&#x2F;...</a><p><a href="https:&#x2F;&#x2F;gitlab.com&#x2F;wg1&#x2F;jpeg-xl&#x2F;-&#x2F;blob&#x2F;master&#x2F;jxl&#x2F;base&#x2F;compiler_specific.h" rel="nofollow">https:&#x2F;&#x2F;gitlab.com&#x2F;wg1&#x2F;jpeg-xl&#x2F;-&#x2F;blob&#x2F;master&#x2F;jxl&#x2F;base&#x2F;compil...</a><p><a href="https:&#x2F;&#x2F;gitlab.com&#x2F;wg1&#x2F;jpeg-xl&#x2F;-&#x2F;blob&#x2F;master&#x2F;jxl&#x2F;base&#x2F;os_specific.h" rel="nofollow">https:&#x2F;&#x2F;gitlab.com&#x2F;wg1&#x2F;jpeg-xl&#x2F;-&#x2F;blob&#x2F;master&#x2F;jxl&#x2F;base&#x2F;os_spe...</a><p><a href="https:&#x2F;&#x2F;gitlab.com&#x2F;wg1&#x2F;jpeg-xl&#x2F;-&#x2F;blob&#x2F;master&#x2F;jxl&#x2F;base&#x2F;arch_specific.h" rel="nofollow">https:&#x2F;&#x2F;gitlab.com&#x2F;wg1&#x2F;jpeg-xl&#x2F;-&#x2F;blob&#x2F;master&#x2F;jxl&#x2F;base&#x2F;arch_s...</a><p>That last one is trying to work out the NUMA topology in a portable way... good luck with that! That&#x27;s not something I expected from a JPEG library. Like memory management, they&#x27;d actually be better off requesting thread-management function pointers from the hosting application. Otherwise, this would not be a &quot;good citizen&quot; in constrained environments such as embedded in a web server or database engine.<p>Random examples of silliness from just this one file:<p>They ignore the first 2 cores on 3+ core systems: <a href="https:&#x2F;&#x2F;gitlab.com&#x2F;wg1&#x2F;jpeg-xl&#x2F;-&#x2F;blob&#x2F;master&#x2F;jxl&#x2F;base&#x2F;os_specific.cc#L266" rel="nofollow">https:&#x2F;&#x2F;gitlab.com&#x2F;wg1&#x2F;jpeg-xl&#x2F;-&#x2F;blob&#x2F;master&#x2F;jxl&#x2F;base&#x2F;os_spe...</a><p>They&#x27;ll be limited max 64 threads (<i>Half</i> the threads on the larger single-socket AMD EPYC 2 CPUs!): <a href="https:&#x2F;&#x2F;gitlab.com&#x2F;wg1&#x2F;jpeg-xl&#x2F;-&#x2F;blob&#x2F;master&#x2F;jxl&#x2F;base&#x2F;os_specific.cc#L211" rel="nofollow">https:&#x2F;&#x2F;gitlab.com&#x2F;wg1&#x2F;jpeg-xl&#x2F;-&#x2F;blob&#x2F;master&#x2F;jxl&#x2F;base&#x2F;os_spe...</a> because they&#x27;re not using the Processor Group Aware API: <a href="https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;windows&#x2F;win32&#x2F;procthread&#x2F;processor-groups" rel="nofollow">https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;windows&#x2F;win32&#x2F;procthread&#x2F;pr...</a><p>Sure, 64-core monsters are still somewhat rare <i>today</i>, but 16-core&#x2F;32-thread desktops CPUs are now affordable and the TSMC 5nm process will likely result in 96-128 core monstrosities <i>this year</i>. That&#x27;s 384-512 threads for a dual-socket server or workstation! If you&#x27;re making an image codec library &quot;for the next decade&quot;, a little future-proofing might go a long way. Look at it this way: Image decoding throughput is one of the main performance issues I have right now with Lightroom and I work with &quot;only&quot; 36 Mpx images. There are 80 Mpx cameras just around the corner...<p>For example, there was a blog article a couple of years ago basically saying that <i>the</i> major Amdahl&#x27;s law limitation to decoding formats like JPEG is the Huffman bitstream decoding, which is Step #1 in the process. The author pointed out that simply <i>restarting</i> the Huffman bitstream a few times for a typical PNG or JPEG file would increase the size less than 1%, but would allow truly parallel decoding for every step.<p>For all the apparent effort to make JPEG-XL parallelised by default, it seems odd that there doesn&#x27;t appear to be any mention of parallelising the ANS bitstream decoding...