av1gpu v0.12.0

What's new

About 14 % faster than v0.11.1 on an L4 at default settings (265.4 → 303.4 MP/s median, 3 encoders, 2,867 MP, paired runs +12.1 to +15.2 %) and about 16 % faster with one encoder (156.8 → 181.8 MP/s), measured with the published CUDA 13 package. Output is byte-identical to v0.11.1 for the same input and options.

• Analysis stage (#70): per-shape register budgets, an in-place transform for 64x64 and 32x64 blocks, and pruned flat areas no longer occupy GPU lanes in the small-block kernels.
• Reconstruction (#71): shorter serial path per superblock — chroma SATD spread over threads, two candidate evaluations per warp for small transforms, longest superblocks dispatched first in each wavefront step.
• Entropy stage (#72): reuses the records the closed loop already computed instead of re-deriving them (entropy GPU time −12 %).

Fixed

• CfL parameter sums and large-block chroma SATD are now accumulated in a fixed order. Before, the result could in principle depend on GPU thread scheduling (never observed on real images).

CPU use is unchanged within about 0.03 cores.

av1gpu v0.11.1

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.

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

Fixed

• A JPEG's ICC profile doubled or cut short (#67, #68). av1gpu sorted the APP2 ICC_PROFILE segments and joined them without checking their numbers.

  • A segment written twice (which an editor did in a real photo) gave the profile twice over: 1,176 bytes, while its header still said 588.
  • A missing segment left a truncated profile that colour-managed decoders can't use.

  The profile is now read by libjpeg-turbo's own reader, as djpeg and avifenc read it. Every segment must give the same count N, with the numbers 1..N appearing once each, in any order; otherwise the AVIF has no profile. Correctly split profiles, in or out of order, are kept as before.

Nothing else changed: both published Linux packages give the same bytes as v0.11.0 on all 311 outputs of tools/sanity.py (checked on an RTX PRO 2000 Blackwell).

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: --crop, --trim, the tone operators, --resize and --grayscale always run in that order; 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.

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.

av1gpu v0.10.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.

Which download

Take the CUDA 13 build unless your driver is older than 580. Both builds give the same files: v0.10.0 writes the same files as v0.9.0 with either build, and v0.9.0's CUDA 13 and CUDA 12 Linux builds gave identical output for all 1,220 test files compared on an L4 and on an RTX PRO 4500.

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

New: one image starts 150 ms sooner on Blackwell, same files

v0.9.0 loaded all four variants of the reconstruction kernel when it started, though an image uses only one. On Blackwell each variant is 39 MB of GPU code. v0.10.0 loads each variant the first time an image needs it (#63). Only the host code changed.

One image as its own process, CUDA start-up included (Linux, driver 595, median of 12 cold runs, alternating with v0.9.0):

Input	RTX PRO 4500, v0.9.0	RTX PRO 4500, v0.10.0	L4, v0.9.0	L4, v0.10.0
2.5 MP JPEG	0.49 s	0.34 s	0.36 s	0.35 s
10.5 MP JPEG	0.57 s	0.42 s	0.47 s	0.47 s
512 × 384 thumbnail	0.49 s	0.34 s	0.35 s	0.34 s
683 × 1024 RGBA PNG	0.61 s	0.46 s	0.48 s	0.46 s

• The RTX PRO 4500 now starts a single image as quickly as the L4.
• The L4 gains little, because its reconstruction kernels are 7–8 MB.
• --batch runs are unchanged. Batch mode still loads every kernel at start, so a load mid-run can't stall the other encoders.

Every output file is byte-identical to v0.9.0's: 1,155 of 1,155 on an L4 and on an RTX PRO 4500. The tests covered:

• batch mode at 4:2:0 and 4:4:4, 8 and 10 bits;
• monochrome, RGBA and lossless;
• single-file mode;
• the case where a second reconstruction variant loads mid-encode (a grayscale JPEG with --yuv 444);
• the CUDA 12 build.

Details: RESULTS.md, raw results.

Known limitations

• 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. Version 2026.1 reports a false error inside CUB's scan kernel there, for v0.8.0 too.

av1gpu v0.9.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.

Which download

Take the CUDA 13 build unless your driver is older than 580. Both builds give the same files: on an L4 and on an RTX PRO 4500, the CUDA 13 and CUDA 12 Linux builds gave identical output for all 1,220 test files compared.

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

New: one image 2–3× faster, batches 5–11 % faster, same files

Every output file is byte-identical to v0.8.0's. Across 103 test runs (5,679 files: every preset, quality 30–95, 4:4:4, 10-bit, monochrome, lossless, alpha, palette mode, odd sizes, thumbnails, short batch lists and single-file mode) there were 0 differences, on an NVIDIA L4 and on an RTX PRO 4500 Blackwell. The two GPUs also wrote the same bytes as each other.

One image as its own process, CUDA start-up included (Linux, driver 595, median of 12 cold runs):

Input	L4, v0.8.0	L4, v0.9.0	RTX PRO 4500, v0.8.0	RTX PRO 4500, v0.9.0
2.5 MP JPEG	1.06 s	0.36 s	1.03 s	0.51 s
10.5 MP JPEG	1.21 s	0.47 s	1.14 s	0.58 s
512 × 384 thumbnail	1.06 s	0.35 s	1.04 s	0.50 s
a photo and its thumbnail as one --batch	1.24 s	0.58 s	1.19 s	0.68 s

Converting an upload (a photo and its thumbnail) as two processes now takes 0.71 s instead of 2.12 s on the L4. If you set GP_MAX_CONNECTIONS=1 to speed up v0.8.0, you can drop it: v0.9.0 asks for one hardware queue by itself for a single image and for lists of up to 8 encodes.

Batch mode (MP/s, or images/s for the thumbnails; median of 6 runs, with v0.8.0 alternating in the same session; v0.8.0 against a second copy of itself moved by 0.7 % at most):

Set	L4, v0.8.0	L4, v0.9.0		RTX PRO 4500, v0.8.0	RTX PRO 4500, v0.9.0
Photos 0.2–24 MP, default	236	257	+9.1 %	406	434	+6.9 %
~1 MP photos, default	76.4	81.1	+6.2 %	141	148	+4.9 %
Thumbnails, images/s	416	450	+8.1 %	776	831	+7.1 %
Photos, --yuv 444 --depth 10	170	190	+11.4 %	293	325	+10.9 %

With GP_ENCODERS=4 the L4 does 261 MP/s on the photos (v0.8.0: 236), 420 with --preset turbo3 --small-preset none (377), and 645 Kodak images per second (585). It runs at its 72 W cap with either version, so energy per megapixel drops from 0.29 to 0.27 J. At the same file size, one L4 is now 9.1× libaom speed 6 on all 16 CPU threads (was 8.0×) and 17× NVENC AV1 on the same card (was 15×).

Where it came from:

• Start-up (#56): one hardware queue instead of 32 for short runs, the JPEG decoded while the encoder sets up, the pinned staging buffer allocated only when a JPEG needs the CPU decoder, and a plain exit once the output is written (Linux).
• Pipeline (#56): no CDEF apply and no reconstruction download when nothing reads them, and one variance-boost table row per encoder instead of all of them.
• Reconstruction (#57): 32-bit inverse transforms and unrolled forward-transform loops.
• Analysis (#58): a warp-parallel intra edge filter and less shared memory.
• Entropy coding (#59): the window coder split across three warps, and a single image uploaded without a host copy.

Every test output decodes exactly in dav1d and aomdec (691/691 encodes and 35/35 alpha items, on both GPUs), and compute-sanitizer memcheck, racecheck and synccheck are clean. Details: RESULTS.md, raw results.

Known limitations

• Not implemented: intra block copy, loop restoration, superres, film grain. Lossy frames use luma palettes only.
• Start-up on Blackwell takes about 0.15 s longer than on an L4. Most of that is loading the sm_120 reconstruction kernels, 38 MB each: av1gpu loads all four variants at start, though an image uses one.
• Windows: its speed was measured with v0.5.0 (67–83 % of Linux), and v0.9.0's start-up 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), and 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 it is kept (README, Download).
• PNG and WebP metadata: their 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. 2026.1 reports a false error inside CUB's scan kernel there, for v0.8.0 too.

av1gpu v0.8.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.

Which download

Take the CUDA 13 build unless your driver is older than 580. Both builds give the same files: on an L4, the two Linux builds gave identical output for all 817 test encodes, palette, 10-bit, 4:4:4 and lossless included.

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

New: palette mode for screenshots, charts and flat-colour art

AV1's palette mode codes a block as a few exact colours and an index per pixel, which suits text, UI and flat fills. av1gpu now uses it on images that pass a screen-content detection (#54).

• Photos are unchanged. None of 244 test photos and none of the test JPEGs pass the detection, so their files are byte-identical to v0.7.1's, at the same speed. The detection costs 0.09 ms of a 64 ms photo encode.
• Screen content (40 charts, screenshots and web pages) is 23.6 % smaller at equal SSIMULACRA2 (median BD-rate; 19.5 % in 10-bit 4:4:4). At the default quality a 2 MP Wikipedia page screenshot goes from 130 KB to 102 KB, with a slightly higher SSIMULACRA2 score (79.1 → 81.3).
  • Against libaom speed 6: 9.5 % smaller than libaom with palette mode. libaom with palette and intra block copy is still 3.3 % smaller (12.8 % on real screenshots, where intra block copy helps; av1gpu is 3.9 % smaller on charts).
• Flat-colour PNG art: the 11 of 24 test images that pass the detection are 22.3 % smaller. The rest are unchanged.
• Lossless: the 23 graphics of the lossless comparison are about 10 % smaller (GBR and --ycgco-re).
• Speed: images that use palette mode encode at about 0.37× the speed without it (57 against 153 MP/s on an L4) because of the palette search.
• --palette auto|on|off: auto is the default. off gives v0.7.1's output; on tries palettes on every image: flat-colour JPEGs about 6 % smaller, and slower still (0.25× on the screen set).

Every test output decodes exactly in dav1d and aomdec, including 4:4:4, 10-bit, lossless and tiled images. Details: RESULTS.md, design and the libaom study: PALETTE.md.

Known limitations

• Not implemented: intra block copy, loop restoration, superres, film grain. Lossy frames use luma palettes only.
• Windows: its speed was measured with v0.5.0 (67–83 % of Linux) and hasn't been re-run. CPU limits set by job objects or containers aren't read (the thread count follows the process's CPU affinity), and 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 it is kept (README, Download).
• PNG and WebP metadata: their ICC profiles and EXIF orientation are not read yet. JPEG profiles are kept, and JPEG orientation is signalled in the AVIF (irot / imir).

av1gpu v0.7.1

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.

Which download

From this release there are two builds per system. Take the CUDA 13 one unless your driver is older than 580.

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

Both builds give the same files: cmp on 324 outputs on an L4, and the Windows zips match the Linux tarballs.

Fixed

• Slow start-up on Blackwell with driver 615 or newer (#49, #51). From R615 the driver recompiles every Blackwell kernel built by nvcc older than 13.2.2 when it loads, to fix a reconvergence bug (615.71.09 notes). Earlier releases were built with CUDA 12.9, so every start without a warm CUDA compute cache paid for it: 9.3–9.7 s for one JPEG on an RTX PRO 4500, 17 s in the report.
  • The CUDA 13.4 build starts in 1.2–1.4 s on that GPU in every cache state, on drivers 595 and 615.
  • It is also faster on Blackwell: 404–407 MP/s against 351–353 (+14–16 %). On an L4 it is +1–5 %.
  • The -cuda12 builds still get the recompile on Blackwell with 615+. Keep a warm compute cache for them (README, Download).
• JPEGs whose luma has smaller sampling factors than a chroma component (for example Y 1×1 with Cb / Cr 2×2). Luma was repeated instead of upsampled the way libjpeg-turbo does it. It now equals libjpeg-turbo's decode exactly, in 4:2:0 and 4:4:4; on a test photo the AVIF's luma PSNR went from 32.2 to 43.0 dB. JPEGs whose luma has the largest factors, which is nearly all of them, are unchanged: 0 differences on the test sets. (#50, follow-up to #44)

Known limitations

• Windows: its speed was measured with v0.5.0 (67–83 % of Linux) and hasn't been re-run. CPU limits set by job objects or containers aren't read (the thread count follows the process's CPU affinity), and the tests run on Linux only. The CUDA 13 zip was tested on an L4; Windows on Blackwell with driver 615 wasn't (no such driver on AWS).
• 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 it is kept (README, Download).
• PNG and WebP metadata: their ICC profiles and EXIF orientation are not read yet. JPEG profiles are kept, and JPEG orientation is signalled in the AVIF (irot / imir).

av1gpu v0.7.0

Linux x86_64 and Windows x64 binaries for NVIDIA GPUs from Turing (RTX 20, T4) to Blackwell (RTX 50). Linux needs only the NVIDIA driver (525 or newer); Windows needs the driver (528 or newer) and the nvjpeg64_12.dll that comes in the zip. See the README for usage.

New: crop and resize on the GPU

Contributed by @pickae (#47, from discussion #16). All of it is opt-in. Without the new options every output is byte-identical to v0.6.0's: 29 test runs, 1,748 files.

• --crop WxH+X+Y (or X,Y,W,H): crops the decoded image at any pixel offset. A crop outside the image is an error, or a skip in batch mode. With --lossless the crop is exact.
• --max-size WxH / --max-height H: shrinks to fit inside a box and never enlarges. It uses ImageMagick's -resize 'WxH>' geometry and Lanczos filter, on the GPU, with no intermediate file and no second round of JPEG loss.
  • Transparent images are filtered with alpha-weighted colour, so there are no dark fringes.
  • From the same source, the planes are within about 0.2 of a 10-bit step of magick -resize (67 dB).
• --max-mp MP / --max-input-mp MP: allow pictures above the 35.6 MP default (written with AV1 level 31), or decode a bigger source that a crop or --max-size brings under the limit.
• Batch lists: a line may add TAB-separated crop= and max-size= options for its image.
• Speed: shrinking 3840 × 5586 pages to 2960 rows runs at 169 MP/s of output on an L4, against 195 MP/s for pages shrunk beforehand.

Details.

Fixed

• Grayscale JPEGs with sampling factors other than 1×1 (2×2, 2×1, 1×2 on their single component) came out scrambled on the hardware JPEG path, with no error. The factors are legal and libjpeg-turbo ignores them; nvJPEG doesn't. Such files now decode exactly like libjpeg-turbo on every path, in batch and single-file mode. A regression test covers them. (#44, #48)
• compute-sanitizer racecheck no longer reports a hazard in the reconstruction kernel (since v0.6.0). The value involved was never used, so no output changes. (#43)

Known limitations

• Windows: its speed was measured with v0.5.0 (67–83 % of Linux) and hasn't been re-run. CPU limits set by job objects or containers aren't read (the thread count follows the process's CPU affinity), and the tests run on Linux only.
• PNG and WebP metadata: their ICC profiles and EXIF orientation are not read yet. JPEG profiles are kept, and JPEG orientation is signalled in the AVIF (irot / imir).

av1gpu v0.6.0

Linux x86_64 and Windows x64 binaries for NVIDIA GPUs from Turing (RTX 20, T4) to Blackwell (RTX 50). Linux needs only the NVIDIA driver (525 or newer); Windows needs the driver (528 or newer) and the nvjpeg64_12.dll that comes in the zip. See the README for usage.

New: about 1.8–1.9× faster, same output

Every output file is byte-identical to v0.5.0's. On 66 test runs (4,698 files: every preset, quality 30–95, 4:4:4, 10-bit, monochrome, lossless, alpha, odd sizes, thumbnails, single-file mode, 1 to 6 encoders) there were 0 differences. The decoder gate (676/676 encodes and 38/38 alpha items in dav1d and aomdec) and the tests pass.

Measured on an NVIDIA L4 (AWS g6.4xlarge), with v0.5.0 alternating in the same session (MP/s, median of 6 runs):

Set	v0.5.0	v0.6.0
Photos 0.2–24 MP, default	121	225	×1.86
Same, counting CUDA start-up	112	195	×1.75
Same, GP_ENCODERS=4	120	230	×1.91
--small-preset none	142	272	×1.91
--preset turbo3 --small-preset none	210	367	×1.75
~1 MP photos, default	38	72	×1.89
4:4:4 / 10-bit / 4:4:4 10-bit	98 / 120 / 95	170 / 230 / 166	×1.73–1.91
Thumbnails (512 × 384 and smaller), images/s	214	393	×1.84
Kodak PNGs (768 × 512), default / turbo3 --small-preset none, images/s	78 / 329	138 / 557	×1.7
Transparent PNGs, default	27	44	×1.63
Lossless			+9–11 %

The L4 runs at its 72 W cap with either version, so energy per image drops by about the same factor: 0.57 → 0.30 J/MP. At the same file size, av1gpu on one L4 is now 8.0× libaom speed 6 on all 16 CPU threads (was 4.4×) and 15× NVENC AV1 on the same card. Details and raw results.

Where it came from:

• Analysis (#35): integer SATD with warp shuffles instead of shared-memory atomics, faster 4 × 4 prediction, warp-wide transforms and top-K selection.
• Reconstruction (#37): U and V chroma finished concurrently on two halves of the block, plus a faster critical path.
• Batch mode (#36): CUDA modules loaded up front, the kernel stack reserved once, pinned-memory frees moved off the hot path, and a huge-page ingest buffer.
• Loop filters (#32, #39, #40): CDEF applied per 64 × 64 tile in shared memory, a templated deblocking filter, and the loop-filter search's maps reused by the pipeline.
• Entropy coding (#33, #34, #38): coefficient symbols, contexts and coding windows reworked.

Known limitations

• Windows: its speed was measured with v0.5.0 (67–83 % of Linux) and hasn't been re-run. CPU limits set by job objects or containers aren't read (the thread count follows the process's CPU affinity), and the tests run on Linux only.
• ICC profiles: profiles in PNG and WebP inputs are not read yet; JPEG profiles are kept.
• EXIF orientation is ignored.

av1gpu v0.5.0

Linux x86_64 and Windows x64 binaries for NVIDIA GPUs from Turing (RTX 20, T4) to Blackwell (RTX 50). Linux needs only the NVIDIA driver (525 or newer); Windows needs the driver (528 or newer) and the nvjpeg64_12.dll that comes in the zip. See the README for usage.

New: Windows

• Windows x64 zip: av1gpu.exe with the C++ runtime and image libraries linked in, plus nvjpeg64_12.dll. Unzip it anywhere; the options are the same as on Linux. (#29)
• Paths: they may use \ or /, and file names may be non-ASCII (Windows 10 1903 or newer, Windows Server 2022). Batch list files may have a UTF-8 BOM and Windows line ends.
• Same output: on an L4 under Windows Server 2022, every output of 30 test runs (1,226 files) and of the decoder-gate encodes (2,125 files) was byte-identical to the Linux build's.
• Slower than Linux: on the same machine type, Windows ran at 67–83 % of the Linux speed with hardware-accelerated GPU scheduling on (JPEG: 86 against 128 MP/s), and slower with it off. Details.
• WDDM mode only: GeForce and RTX cards always run in it. TCC mode, the default for data-centre GPUs under NVIDIA's data-centre driver, has no CUDA memory pools, so av1gpu stops at start-up with a message saying so.
• Building from source: tools\windows\build.ps1 with Visual Studio 2022 (or its Build Tools). It fetches the CUDA 12.9 parts av1gpu needs and builds the image libraries with vcpkg.

On Linux nothing changes: its outputs are byte-identical to v0.4.0's.

Known limitations

• Windows: CPU limits set by job objects or containers aren't read (the thread count follows the process's CPU affinity), and the tests run on Linux only.
• ICC profiles: profiles in PNG and WebP inputs are not read yet; JPEG profiles are kept.
• EXIF orientation is ignored.