Keep WebP, AVIF and JPEG XL encodes at the limits under 40 seconds (closes #272)
check / check (push) Waiting to run

WebP is saved at effort 2 and JPEG XL at effort 4, and an AVIF output of
more than 16,777,216 pixels is refused with 400 before anything is
decoded, as AVIF is already at the lowest effort govips can set. With
one libvips thread, at any quality, 8192x8192 random pixels with an
alpha channel take up to about 23 seconds as WebP and 27 as JPEG XL, and
4096x4096, 8192x2048 or 2048x8192 up to about 34 as AVIF. Resizing with
fit=cover already decodes the input, so the output's dimensions are now
worked out before resizing, in outputDimensions. Reading the input moves
into readInput to keep Process within the linter's limits.
TestImageProcessor_WebPAtDefaultEffort becomes TestImageProcessor_WebPAtEffort2, as #280 (comment) allows.

Model: opus-5-5
This commit was merged in pull request #278.
This commit is contained in:
2026-10-20 15:19:07 +02:00
parent 4fb6350aa1
commit 989da78681
8 changed files with 360 additions and 102 deletions
+12
View File
@@ -30,6 +30,18 @@ P2: security: per-origin rate limiting
# Completed Steps
- 2026-10-20 a WebP, AVIF or JPEG XL encode at the limits takes at most about 34
seconds (closes #272): with one libvips thread, 8192x8192 random pixels with
an alpha channel took about 61 seconds to encode as WebP, 81 as JPEG XL and,
at quality 85, 96 as AVIF, so with the default `downstream_timeout` of 60
seconds such an image was never delivered, yet its encode held a processing
slot to the end. WebP is now saved at effort 2 and JPEG XL at effort 4, which
take up to about 23 and 27 seconds at any quality. AVIF was already at the
lowest effort govips can set, so an AVIF output of more than 16,777,216 pixels
is refused with 400 before anything is decoded; 4096x4096, 8192x2048 or
2048x8192 takes up to about 34 seconds at any quality. Resizing with
`fit=cover` already decodes the input, so the output's dimensions are worked
out before resizing. `README.md` gives the limit and the new times.
- 2026-10-20 a source whose first bytes do not match its `Content-Type` answers
415 (closes #253): a body whose first bytes are not those of the format its
`Content-Type` names, such as a JPEG sent as `image/png`, text, or a body