Skip to content

Bypass Sharp for animated GIFs in DocImage and ImageGallery#417

Merged
vvlladd28 merged 1 commit into
mainfrom
fix/gif-sharp-pixel-limit
May 25, 2026
Merged

Bypass Sharp for animated GIFs in DocImage and ImageGallery#417
vvlladd28 merged 1 commit into
mainfrom
fix/gif-sharp-pixel-limit

Conversation

@vvlladd28
Copy link
Copy Markdown
Member

@vvlladd28 vvlladd28 commented May 25, 2026

Summary

  • pnpm build fails with Input image exceeds pixel limit on src/assets/images/docs/mqtt-broker/user-guide/shared-subscription-demo.gif (1846×1004 × 317 frames ≈ 588M px). Astro's Sharp service reads GIFs with pages: -1 (all frames) and Sharp's default limitInputPixels is ~268M, so the metadata read throws before any transform runs.
  • DocImage and ImageGallery now skip getImage for .gif, the same way they already do for .svg, and serve the original Vite asset. Astro was already passing animated GIFs through unchanged on the happy path (verified in dist/ — file is byte-identical to source with all frames preserved), so no visual or animation regression for the other 8 GIFs in the repo — only the build failure is removed.

The default Sharp pipeline re-encodes GIFs to WebP, which drops every
frame after the first (losing animation) and also blows past Sharp's
default pixel limit on large multi-frame GIFs — e.g.
shared-subscription-demo.gif (1846x1004, 317 frames) fails the build
with "Input image exceeds pixel limit". GIFs now skip raster processing
and are served as-is, the same way SVGs already are.
@vvlladd28 vvlladd28 merged commit 67ca7db into main May 25, 2026
4 checks passed
@vvlladd28 vvlladd28 deleted the fix/gif-sharp-pixel-limit branch May 25, 2026 12:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant