Crop the centre first for fit=cover (closes #282)

libvips' thumbnail with a centre crop scales the whole source to cover
the requested size and copies that into memory before it crops: 8192x64
at 8192x8192 made it allocate about 24 GiB, and 8192x1 failed with 500.
resize now cuts the centre of the source to the requested size's
proportions first and resizes that, so no image larger than the source
or the output is made. The crop is the same centre as before. TODO.md
says so.

Model: opus-5-5
This commit is contained in:
2026-10-15 23:39:24 +00:00
parent fb33a3bb34
commit 96d5ccf5cc
2 changed files with 43 additions and 2 deletions
+10
View File
@@ -46,6 +46,16 @@ P2: security: per-origin rate limiting
way, and so is an IPv6 address without brackets, which needed a signature
before. Underscores are kept because `allowlist_hosts` accepts host names
holding them.
- 2026-10-15 a thin source requested with `fit=cover` no longer makes libvips
build a huge image (closes #282): libvips scaled the whole source to cover the
requested size and copied that into memory before it cut out the centre, so an
8192x64 source at 8192x8192 made it allocate about 24 GiB, and an 8192x1
source answered 500. The image processor now cuts the centre of the source to
the requested size's proportions first and resizes that, so no image larger
than the source or the output is made; the crop is the same centre as before.
With the runtime image's libvips and JPEG output at 8192x8192, resident memory
peaked at about 44 MiB for the 8192x64 source, 40 MiB for the 8192x1 one, and
117 MiB for a 4000x3000 one, which took 373 MiB before.
- 2026-10-15 the README says how a source URL with a query is written into an
image URL, and the image route accepts it (closes #255): the query follows the
source path after `%3F`. pixa now reads the image URL's path decoded once, so