feat(backend): generate thumbnails/previews via vipsthumbnail
Use vipsthumbnail as the primary still-image path for both thumbnails and previews (shared serveGenerated), falling back to the pure-Go imaging pipeline when vips isn't on PATH. vips shrinks on load (e.g. JPEG DCT scaling), so a 200+ Mpx photo is resized in a fraction of the memory and CPU of a full in-process decode and no longer exceeds the decode cap — the source that previously got only a placeholder now gets a real thumbnail and preview. The output JPEG is written straight to the cache (atomic temp→rename), fit within the target box and never upscaled. The in-process pixel cap now guards only the pure-Go fallback. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
@@ -35,9 +35,10 @@ type Config struct {
|
||||
ThumbHeight int
|
||||
PreviewWidth int
|
||||
PreviewHeight int
|
||||
// ThumbMaxPixels caps the pixel count of a source image we will decode into
|
||||
// memory to generate a thumbnail/preview (a decode bombs guard, and a memory
|
||||
// bound). Larger images fall back to a placeholder.
|
||||
// ThumbMaxPixels caps the pixel count of a source image decoded in-process by
|
||||
// the pure-Go fallback (a decompression-bomb guard and memory bound); larger
|
||||
// images then get a placeholder. It does not apply when vipsthumbnail is
|
||||
// installed, which shrinks on load regardless of source size.
|
||||
ThumbMaxPixels int
|
||||
// ThumbConcurrency bounds how many thumbnails/previews are generated at once,
|
||||
// so a burst of large images can't saturate every core or exhaust RAM. 0 =
|
||||
|
||||
Reference in New Issue
Block a user