Scale both sides of a fit=cover image by the same amount (part of #282)
check / check (push) Canceled after 0s

cropCentreAndResize cut the centre to whole source pixels and forced
that to the requested size, so the two sides were scaled by different
amounts: a 16x16 source at 100x60 came out squashed by 4%. It now
widens the centre to whole source pixels and lets thumbnail with a
centre crop scale that by the one amount next uses and cut the output
from it. thumbnail copies the scaled image into memory, which is larger
than the output by less than one scaled source pixel on each side.
TODO.md says so.

Model: opus-5-5
This commit is contained in:
2026-10-15 23:36:42 +00:00
parent aa05436869
commit 9a97dfc299
2 changed files with 29 additions and 26 deletions
+11 -9
View File
@@ -31,15 +31,17 @@ P2: security: per-origin rate limiting
# Completed Steps
- 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.
build a huge image (closes #282): libvips' thumbnail 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 first cuts the centre
of the source, widened to whole source pixels, and thumbnail scales and cuts
only that, by the same amount on both sides as before. What it copies into
memory is then larger than the output by less than one scaled source pixel on
each side. With the runtime image's libvips and JPEG output at 8192x8192,
resident memory peaked at about 242 MiB for the 8192x64 source and 431 MiB for
the 8192x1 one. The output can sit a fraction of an output pixel from where it
was.
- 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