Fix inverted AVIF quality on imagick, and quality being ignored by base64() on gd and vips

[NickBevers]

Started out as the AVIF quality inversion on the Imagick driver, and grew to cover two related quality bugs found while adding test coverage.

1. AVIF quality is inverted on the imagick driver

Asking for quality 20 gives you a quality 80 image, and asking for 80 gives you a quality 20 one.

Measured on main, encoding the test JPEG to AVIF:

call	file size	what you actually get
quality(20)	4467 bytes	the quality 80 image
quality(80)	2287 bytes	the quality 20 image

Exactly swapped.

Why

Imagick reads the compression quality from two different setters depending on the output format:

• setImageCompressionQuality() — read by JPEG and WebP
• setCompressionQuality() — read by PNG and AVIF

The driver set the second one to 100 - $quality, with a // For PNGs comment:

$this->image->setImageCompressionQuality($quality);
$this->image->setCompressionQuality(100 - $quality); // For PNGs

The inversion is correct for PNG. PNG is lossless, so its "quality" is really a zlib compression level where a higher number means a smaller file — inverting keeps the library's "higher quality = bigger file" contract. Verified: every PNG quality value produces byte-identical pixels, and raw Q=0 → 36182 bytes vs Q=90 → 35654 bytes.

AVIF reads that same setter but treats it as a normal quality, so it silently inherited PNG's inversion. JPEG and WebP were never affected, because they read the other setter.

Fix

Store the requested quality and only invert it for PNG, resolved right before the image is written, once the target format is known. Applied on both save() and base64(), since each resolves its own format — removing either call flips PNG back the wrong way.

2. GdDriver::base64() ignored the quality for webp and avif

It called \imagewebp($this->image, null) and \imageavif($this->image, null) with no quality argument, and skipped the imagepalettetotruecolor() call that save() does. On main, GD base64('webp') returns 10792 bytes at both quality 10 and 90.

3. VipsDriver::base64() ignored the quality entirely

It called writeToBuffer() with no options at all, while save() builds a Q / compression save property. On main, vips base64('webp') returns 10204 bytes and base64('jpeg') 27680 bytes at both quality 10 and 90. The property-building logic is now shared between the two paths.

Verification

Every format, both write paths, imagick driver:

format	q10	q50	q90
jpg	7332	15665	28673	✅
avif	2072	2819	7014	✅ (was inverted)
webp	4202	6404	11224	✅
png	35667	37283	42790	✅ (inversion preserved)

After the fix, quality(20) on AVIF produces a file byte-identical to raw Imagick at Q=20.

All three bugs were confirmed against the pre-fix code before being fixed, and the new tests were checked against that same pre-fix code to make sure they actually fail without these changes — the avif inversion and the dropped quality each fail the suite there.

Tests and CI

The existing quality test only covered jpg and png through save(), which is why all of this went unnoticed. This PR adds a regression test for the AVIF inversion, and base64() coverage across drivers and formats.

avifIsSupported() previously returned false whenever GITHUB_ACTIONS was set, so no AVIF test had ever run on CI. It also hard-coded false for the vips driver, which does support AVIF. It now probes a driver by actually encoding a small image — reporting the format as available is not sufficient, since a driver can be built against a libheif without an AVIF encoder and only fail at encode time.

The workflow now installs libheif1 + libheif-plugin-aomenc and prints the detected AVIF support per driver. On the runners this reports gd imageavif(): yes and imagick AVIF formats: AVIF, so the avif tests now genuinely run in CI.

One caveat worth recording: the imagick build on the runners returns identical webp bytes for quality 10 and 90, which is outside this package's control. The per-format base64 test therefore only asserts that quality is never applied in reverse, which is what the avif bug did. A separate test asserts strictly on jpeg — the one format every driver reliably varies — so a driver dropping the quality entirely still gets caught.

PHPStan

Also fixed, since it would otherwise keep this PR red. It was failing on a stale baseline count, not on a new error: the baseline records 4 occurrences of the GdImage|false assignment, but the exif orientation handling has grown to 7 imagerotate() calls since it was written. This has been failing on main on every run since at least March 2026.

[freekmurze]

Thanks!