JXL: lossless decoding in threads from 512 KiB on

A second sweep on other content (a tiled screenshot, 64 colors, alpha
gradients at 1-4 megapixels; threads 1 vs the default rules) found one
case slower with threads: lossless JPEG XLs of few colors (2 MP: 78 ->
128 ms) decode faster than threads start. Lossless decoding takes about
as long as the file is large, so threads need 512 KiB too (photo 2 MP,
1.4 MB: 1.6x; screenshot 2 MP, 0.67 MB: 1.08x; few colors 0.17 MB: now
without). Every other case was faster with threads or the same (AVIF
4:4:4 decoding, within 3%).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BsU2GAqbnFSNaYDBGD1Km2

Author: matmen

CHANGELOG.md

@@ -32,7 +32,8 @@
   references stay on one thread.
 - The thresholds for threads were measured with 1 to 8 threads on 0.25 to 8 megapixels: lossy JPEG XL encoding at
   efforts 1 and 2 and AVIF encoding use 4 threads up to about 1-2 megapixels (more were slower there), JPEG XL at
-  effort 0 starts at 1.5 megapixels, lossless JPEG XL decoding at 1.5 instead of 4.
+  effort 0 starts at 1.5 megapixels, lossless JPEG XL decoding at 1.5 instead of 4 (and 512 KiB: smaller files, like
+  ones of few colors, decode faster than threads start). Checked on screenshots, few colors and alpha too.
 - AVIF decoding uses worker threads (`DecodeOptions.threads`) from 4 megapixels on: the conversion to RGB runs in
   bands of rows (started at the beginning, the threads load while the AV1 image is decoded) and the tiles of grids are
   decoded in parallel, with the same pixels. A 3840x2160 4:2:0 image decodes in 355 ms instead of 466 ms, a 6400x2880

src/codecs/jxl.ts

@@ -92,10 +92,11 @@ export async function* frames(data: Uint8Array, maxPixels = MAX_PIXELS, toneMapp
     };
     const a = image.animation, tick = a ? 1000 * a.tpsDenominator / a.tpsNumerator : 0;
     // (threads for the frames' groups and filters, see decodeFrame: at most one per 2 megapixels for XYB images (lossy),
-    // from 1.5 megapixels on one per 512K pixels for others (lossless), more take longer to start and warm up than they
-    // save; measured with 1-8 threads on 0.25-8 megapixels)
+    // from 1.5 megapixels and 512 KiB on one per 512K pixels for others (lossless: they take about as long as they're
+    // large, smaller ones like few colors' decode faster than threads start), more take longer to start and warm up
+    // than they save; measured with 1-8 threads on 0.25-8 megapixels of photos, screenshots and few colors)
     const pixels = image.width * image.height;
-    const n = Math.min(threads, image.xybEncoded ? Math.floor(pixels / (2 << 20)) : pixels >= 1536 << 10 ? Math.floor(pixels / (512 << 10)) : 1);
+    const n = Math.min(threads, image.xybEncoded ? Math.floor(pixels / (2 << 20)) : pixels >= 1536 << 10 && d.length >= 512 << 10 ? Math.floor(pixels / (512 << 10)) : 1);
     const pool: FrameThreads = { threads: n > 1 ? startThreads(n) : null, data: null };
     try {
         let shown = 0;

src/image.ts

@@ -221,8 +221,9 @@ export interface DecodeOptions {
     toneMapping?: ToneMapping;
     /**
      * At most this many worker threads decode in parallel (lossy JPEG XLs from 4 megapixels on, one per 2 megapixels
-     * at most, lossless ones from 1.5 megapixels on; AVIFs from 4 megapixels on: the conversion to RGB, one per
-     * megapixel, and the tiles of grids), `1` for none. Default: the processors available, at most 8 (1 where workers can't share memory)
+     * at most, lossless ones from 1.5 megapixels and 512 KiB on; AVIFs from 4 megapixels on: the conversion to RGB,
+     * one per megapixel, and the tiles of grids), `1` for none. Default: the processors available, at most 8 (1 where
+     * workers can't share memory)
      */
     threads?: number;
 }