av1gpu v0.11.0

Linux x86_64 and Windows x64 binaries for NVIDIA GPUs from Turing (RTX 20, T4) to Blackwell (RTX 50). They need only the NVIDIA driver; the Windows zips include nvJPEG's DLL. See the README for usage, or run av1gpu --help.

Which download

Take the CUDA 13 build unless your driver is older than 580. Both builds give the same files: the published Linux tarballs wrote 311 of 311 test outputs identical to each other and to the tested build, on an L4.

File	Built with	NVIDIA driver
av1gpu-0.11.0-linux-x86_64.tar.gz	CUDA 13.4	580 or newer
av1gpu-0.11.0-linux-x86_64-cuda12.tar.gz	CUDA 12.9	525 or newer
av1gpu-0.11.0-windows-x86_64.zip	CUDA 13.4	580 or newer
av1gpu-0.11.0-windows-x86_64-cuda12.zip	CUDA 12.9	528 or newer

New: ImageMagick-style operations on the GPU (pickae, #65)

pickae wrote these for their comic-scan converter: the trim box used to need an ImageMagick decode per page on the CPU, and now the card finds it. Every option is opt-in; without them the output is byte-identical to v0.10.0 and the speed is the same (figures below). The rules are ImageMagick 7's, reimplemented — no ImageMagick code, and ImageMagick isn't needed.

• --trim / --fuzz D%: ImageMagick's -trim box. Conditions for scans: --trim-margin N|N%, --trim-limits MIN%,MAX%, --trim-lightness L, --skip-blank P.
• --resize GEOMETRY: ImageMagick's -resize geometry (W, xH, WxH, ^, !, >, <, N%, N%xM%, @AREA, AREA@), also as resize= on batch-list lines. Lanczos to shrink, Mitchell to enlarge and for images with alpha.
• --auto-level, --level B,W[,G], --gamma G, --negate: tone operators per RGB channel.
• --grayscale METHOD, --colorspace Gray: monochrome output.

They run in a fixed order: crop, trim, tone, resize, gray.

How close to ImageMagick, measured on an L4 against ImageMagick 7.1.2-18 (RESULTS.md):

• --trim: at --yuv 444 the box equals magick -fuzz F -trim's on 555 of 555 runs (185 comic pages and photos, 0, 3 and 10 % fuzz). At the default 4:2:0 it equals it on all 144 JPEGs coded 4:2:0.
• --resize: 870 of 880 output sizes equal magick -resize's; in the other 10, magick itself fails. With EXIF rotations, 224 of 224. The pixels are within 0.25–0.31 of a step on average.
• Tone and gray: with 8-bit --lossless, exactly ImageMagick's output. Lossy at --yuv 444, the decoded luma is on average within a step of ImageMagick's and rarely more than two steps off.
• At the default 4:2:0, 4:2:0 JPEGs follow ImageMagick's decode; PNG, WebP and other JPEGs differ at saturated colour edges (Known limitations).

New: --help

av1gpu --help prints every option to stdout (the usage text on a bad command line still goes to stderr).

New: a refused image says what to do

An image over the --max-mp limit (35.6 MP by default, AV1 level 6.3) is now refused with the value that would encode it: larger than 35.6 megapixels; add --max-mp 46 to encode it anyway. It counts the crop and resize, and names --max-input-mp when that is the limit. The default stays 35.6 MP, so that files keep a level hardware decoders accept.

Fixed

• Images wider or taller than 65,536 pixels (PNG and WebP, which have no default size limit) were written as AVIF files no decoder reads. AV1 can't code more than 65,536 per side; they are now refused with a message, and a batch carries on.
• A crop or shrink taller than 65,472 rows stopped with a CUDA error and lost the whole batch. It is now refused for that image only.
• --cpu-entropy now accepts 65,536 pixels per side, with the same bytes as the GPU coder.

Without the new options, everything else is byte-identical to v0.10.0: 22,231 outputs compared on an L4.

Speed

On an NVIDIA L4, timed against the v0.10.0 code:

• Without the new options, the same speed:
  • batch throughput within 0.4 % on every set (photos, thumbnails, comic pages, PNG and WebP, 4:4:4 10-bit, --crop, --max-size), and every 95 % interval contains 1;
  • single-image start within 4 ms;
  • the same memory.
• With them (measured on #65 as submitted):
  • --trim costs up to 1.4 % to measure, and saves about as much when it cuts;
  • --negate, --gamma and --auto-level cost up to 1.9 %;
  • --level costs 3–6 %, since the stretched picture takes more bytes. Up to 20 % on small photos when the curve makes them look like screen content and the palette search runs;
  • --grayscale takes 16–44 % less time.

Details: RESULTS.md, raw results.

Known limitations

• At 4:2:0, PNG, WebP and JPEGs not coded 4:2:0: --trim, the tone operators and --grayscale see av1gpu's 2 × 2 mean of the chroma.

  • A trim box can differ from ImageMagick's by a few pixels at colour edges.
  • --auto-level can take its range from one such edge and shift the whole picture: by 4.6 steps on average over 6 comic PNG pages, against 0.6 at --yuv 444.

  Use --yuv 444 when that matters. 4:2:0 JPEGs follow ImageMagick's decode.

• Crop, then --grayscale, on a 4:2:0 JPEG: the crop's outermost rows and columns can differ from ImageMagick's by up to 16 steps; inside, by at most 1.

• Alpha is left alone by the tone operators, as ImageMagick's -channel RGB (plain ImageMagick 7 changes it too).

• Fixed order: the operations always run in the order above; ImageMagick follows its command line.

• Not implemented: intra block copy, loop restoration, superres, film grain. Lossy frames use luma palettes only.

• Windows: speed was last measured with v0.5.0 (67–83 % of Linux), and start-up since v0.9.0 hasn't been timed there. CPU limits set by job objects or containers aren't read; the thread count follows the process's CPU affinity. The tests run on Linux only.

• GPUs newer than Blackwell first compile the code from PTX, which took over ten minutes in a test. Give av1gpu its own compute cache so the compiled code is kept (README, Download).

• PNG and WebP metadata: ICC profiles and EXIF orientation are not read yet. JPEG profiles are kept, and JPEG orientation is signalled in the AVIF (irot / imir).

• compute-sanitizer on Blackwell: memcheck on the CUDA 13 build needs compute-sanitizer 2026.3 (CUDA 13.4) or newer.