構建 VisualFormat 瀏覽器 GIF 編輯器：影格記憶體限制比檔案大小更重要

I built VisualFormat, a free set of browser GIF tools. The files are processed locally, with no account required. One practical constraint shaped the implementation: a small GIF file can still be expensive to decode.

Start with decoded pixels

A 1,000 × 1,000 animation with 100 frames represents 100 million frame pixels. At four bytes per RGBA pixel, keeping a full decoded copy of every frame would already take roughly 400 MB, before working canvases and encoding buffers. The compressed download size does not describe that cost.

VisualFormat scans GIF blocks before allocating decoded frames. It checks dimensions, frame count and the total canvas pixels across the animation. The current GIF input limits are 20 MB, 500 frames, 4,096 pixels per dimension and 40 million total frame pixels. These are guardrails, not a guarantee that every device can process every accepted file.

A frame is not always a complete picture

Some frames update only a rectangle of the canvas. Transparency, local palettes and disposal instructions affect the image that should actually appear. A crop or frame extractor needs the composited result, rather than treating each stored rectangle as a standalone image.

Useful test cases include a partial update over a transparent canvas, restore-to-previous disposal, changing frame delays, local palettes and animations that do not loop. For this project, output samples were compared with independently decoded Pillow results, including disposal and timing cases. A preview that looks right on the first frame is only the beginning of validation.

Move work away from the interface

The GIF processing paths use Web Workers and report progress back to the page. Output buffers are transferred back when processing finishes. This keeps heavy processing away from the main interface, but it does not remove memory limits: a worker still uses memory on the same device. Errors need a useful recovery path, such as trying a shorter animation or smaller dimensions.

Be clear about the tradeoffs

Reducing dimensions and frame count can make a GIF much smaller. Reducing colors can also affect gradients and fine detail, so checking the exported animation remains important. The background remover uses solid-color matching; it does not provide semantic subject segmentation for complex scenes.

You can try the GIF cropper or the frame extractor. I would be interested in examples where disposal, transparency or browser memory makes a GIF unexpectedly difficult to edit.

Disclosure: I am the maker of VisualFormat. This article was prepared with AI assistance and checked against the project implementation.