DEV Community: Calvin

How OmniGIF Removes GIF Backgrounds Entirely in the Browser

Calvin — Fri, 25 Sep 2026 01:57:19 +0000

Most "remove GIF background" tools upload your animation to a server, run a keying model, and send back a file. OmniGIF's Remove Background from GIF never uploads the GIF. Decoding, color keying, edge cleanup, and re-encoding all happen in the browser with Canvas ImageData and a GIF encoder Worker.

This post walks through that pipeline — from solid-color detection, through connected flood fill, to transparent GIF export.

The GIF background problem

A still photo background remover can lean on neural matting. An animated GIF is different:

Many frames — the same key must stay stable across dozens or hundreds of frames, or the subject "flickers"
256 colors max per frame — soft alpha edges do not survive GIF encoding the way PNG does
Solid or near-solid backgrounds are the common case — white product shots, black meme templates, classic green screen stickers
Subjects often share background hues — a white logo on a white backdrop must not punch holes in the subject

OmniGIF targets chroma-style removal (match a target RGB within tolerance), not full semantic segmentation. That keeps the tool fast, deterministic, and fully local — and matches what most GIF makers actually need.

High-level architecture

User drops a GIF
        ↓
Browser: decode with gifuct-js → GIFFrame[] (ImageData + delay)
        ↓
Auto-detect / pick / preset target RGB
        ↓
Per-frame keying (connected flood fill or all matching pixels)
   + optional edge feather + green spill reduction
   + optional solid / gradient fill under transparency
        ↓
Live preview on desktop (debounced) · Encode on demand
        ↓
gif.js encode (preserve transparency) → optional gifsicle optimize → download

Stack choices:

Concern	Choice
App shell	Next.js 15 (SSG) + React 19
GIF decode	gifuct-js via shared `GifSession`
Pixel math	Canvas `ImageData` on the main thread (chunked yields)
Connectivity	Iterative BFS flood fill from canvas edges
GIF encode	gif.js / shared `encodeFramesToGifBlob`
Optimize	gifsicle-wasm-browser (preserve transparency)
Analytics	PostHog (tool id, mode, errors — not pixels)

No server receives the file. After the page loads, removal is local compute.

Stage 1 — Decode once, mutate copies

Upload validates MIME/extension, file size (soft 10 MB cap), and decoded limits (edge length, pixels × frames). A GifSession expands disposal/composite frames into full-canvas ImageData so every frame is independent for keying.

Source frames stay immutable in a ref. Preview and export always operate on clones — so resetting settings or aborting mid-job never corrupts the original decode.

Processing stages the UI reports:

decoding → analyzing → removing → encoding

Stage 2 — Finding the background color

Three ways to set the target RGB:

Auto-detect

detectBackgroundColor samples the edges and four corners of the first frame (every ~6 px), quantizes colors into coarse bins, and picks the dominant bin. Confidence is high when that bin dominates (≥ ~35% of samples) and the palette of edge colors is small; otherwise the UI warns and suggests picking manually.

Why edges? Backgrounds usually touch the canvas border. Sampling only the top-left pixel fails when a subject or watermark sits there.

Presets

White (#ffffff), black (#000000), and green screen (#00b140-class) cover the majority of sticker and meme workflows.

Eyedropper

"Pick from GIF" maps a click on the preview to pixel coordinates, reads RGB from the original frame (not the keyed preview), and locks that hex as the target. Auto-detect turns off so later preview rebuilds do not overwrite the pick.

Stage 3 — Color match with tolerance

Matching uses RGB Euclidean distance, not HSL hue alone:

distance = √(ΔR² + ΔG² + ΔB²)
maxDistance = (tolerance / 100) × √(3 × 255²)

Tolerance defaults to a conservative 18 / 100. At 0, only exact RGB equals the target. Higher values swallow compression banding and slight green-screen unevenness.

GIF compression often spreads a "white" background across #fefefe–#f5f5f5. Without a distance band, keyed holes appear as speckles.

Stage 4 — Connected mode vs all matching pixels

This is the main product decision.

Connected background only (default)

buildConnectedBackgroundMask runs an iterative BFS from every edge pixel that matches the target within tolerance, then expands to 4-neighbors that also match. The result is a Uint8Array mask: 1 = remove.

Effects:

White text inside a dark subject is kept (not connected to the edge)
Logo fills that share the background color but are enclosed by the subject stay intact
Open holes in the subject that connect to the edge will be keyed — correct for true background peek-through

Queue + visited arrays avoid recursive stack overflow on large canvases (important at 1080p).

All matching pixels

Every pixel within tolerance is keyed, regardless of connectivity. Faster mentally to reason about, but dangerous when the subject contains the same color (white eyes, black clothing, green clothing on green screen).

SEO copy on the tool page leans on connected mode as the reason OmniGIF does not "eat" interior colors the way naive global replace does.

Stage 5 — Edge feather and color spill

Edge softness

When feather > 0, pixels near the distance threshold get partial alpha proportional to how close they are to the max distance. That softens the preview against a checkerboard.

Important GIF caveat: GIF89a transparency is binary (a color index is transparent or not). Soft edges in preview may look slightly stepped after export. The encode path uses transparencyMode: "preserve" with a matte color for residual fringing — same contract as other transparent GIF tools on the site.

Remove color spill

For green-screen targets (high G relative to R/B), a light pass reduces green excess on near-key opaque pixels (spill = max(0, G − max(R, B))). It is not a full chroma spill matte from After Effects — just enough to cut the classic green halo around stickers.

Stage 6 — What replaces the background?

After keying, optional post-removal backgrounds composite under transparent pixels:

Mode	Behavior
Transparent	Leave alpha for GIF/APNG/WebP export
Solid	Alpha-composite a hex color
Linear / radial gradient	Rasterize gradient to `ImageData`, then composite

Gradients are baked opaque into each frame before encode, so the GIF does not need multi-level alpha. The encode layer then uses solid transparency mode with the gradient's "from" color as a safety matte for any leftover translucent pixels.

Frame range is supported: apply keying only to frames start…end, clone the rest unchanged — useful when only part of a loop has a solid backdrop.

Stage 7 — Staying responsive without a Worker (yet)

Per-frame keying is pure JS over Uint8ClampedArray. For long GIFs that can block the UI. The job helper:

Yields to the main thread every 2 frames via setTimeout(0)
Honors AbortSignal so changing settings or cancelling aborts the current generation
Uses a generation counter for desktop live preview so stale jobs cannot overwrite newer results

Desktop live preview debounces panel changes (~300 ms), runs the same processBackgroundRemovalJob as export, and feeds GifLivePreview. Mobile skips the heavy live path and shows before/after after generate — battery and screen space.

Export then calls encodeFramesToGifBlob (global palette, preserve transparency when appropriate) and optimizeGifBlob with preserveTransparency: true. Users can also download APNG / animated WebP from the same processed frames when they need softer edges than GIF allows.

UX details that matter for keying

Live preview + magnifier. Seeing connected vs all mode update in place beats guessing tolerance values. Pixel pick with a magnifier makes green-screen sampling accurate on phones.

Low-confidence detect. When edge colors are messy, the UI says so instead of silently keying the wrong color.

Settings groups. Removal options stay expanded; shared GIF encode settings (quality, loop, frame delay, transparency matte) sit in a collapsed group — same pattern as other OmniGIF tool pages.

Result scroll. After encode, the result scrolls into view; download / share / re-edit actions stay consistent with the rest of the toolkit.

Privacy analytics. Events carry tool name, removal mode, and completion — not filenames or image bytes.

Why not upload to a cloud matting API?

Server-side AI matting wins on complex hair and busy photos. For the GIF use cases OmniGIF optimizes for — stickers, green screen takes, white/black product loops — chroma keying is enough, and the tradeoffs favor local compute:

No retention policy for meme faces or branded assets
No GDPR transfer of the media itself
Works offline after first load
Deterministic results you can tune with tolerance and mode
Same decode/encode stack as crop, trim, overlay, and compress tools

When users need a new backdrop instead of transparency, the companion Add Background to GIF tool picks up from a transparent GIF — often after this remover.

Try it

Tool: https://www.omnigif.com/gif-tools/remove-background-from-gif
Related: Add Background to GIF
GIF transparency basics: MDN GIF
Flood-fill concept: Wikipedia — Flood fill

Built as part of OmniGIF — a client-side GIF toolkit. Feedback welcome via Contact.

How OmniGIF converts Live Photos to GIF entirely in the Browser

Calvin — Sun, 13 Sep 2026 14:38:58 +0000

iPhone Live Photos are not a single GIF-ready file. They are a still image plus a short video clip. Most "Live Photo to GIF" tools ask you to upload that clip to a server. OmniGIF's Live Photo to GIF converter does the opposite: the MOV/MP4 never leaves the device.

This post walks through how that pipeline is built — from Apple's export format, through engine selection, to palette-based GIF encoding.

The Live Photo input problem

A Live Photo in the Photos library is typically a HEIC + paired video. Browsers cannot reliably ingest that pair as one drop. Apple's supported path is:

Open the Live Photo
Share → Save as Video
Upload the exported MOV or MP4

That export is usually ~1.5–3 seconds of motion — short enough for a GIF, long enough to feel "alive." OmniGIF accepts .mov / .mp4 (and the matching MIME types) and rejects raw HEIC Live Photo pairs on purpose. Forcing a clean video export keeps decoding deterministic across Chrome, Safari, and Firefox.

On mobile, first-time users often try to pick the Live Photo still instead of the video. The page intercepts the file picker on narrow viewports and shows a short "Save as Video" guide GIF before opening the picker — same user gesture, so iOS Safari still allows the file dialog.

High-level architecture

User exports Live Photo as MOV/MP4
        ↓
Browser: analyze container + duration + resolution
        ↓
Preview + crop + timeline trim (client UI)
        ↓
selectConversionEngine()
   ├─ WebCodecs path (Mediabunny decode → gif.js encode)
   └─ FFmpeg.wasm path (Worker + palettegen/paletteuse)
        ↓
GIF Blob → object URL → download

The Live Photo page is a thin specialization of a shared media converter used by Video to GIF, MOV to GIF, MP4 to GIF, and related tools. Same options model (VideoToGifOptions), same analytics, same UI shell — different accept list and copy.

Stack choices:

Concern	Choice
App shell	Next.js 15 (SSG) + React 19
Fast path	Mediabunny + WebCodecs + Canvas
Compatible path	ffmpeg.wasm in a Web Worker
GIF encode (fast path)	gif.js / shared `encodeFramesToGifBlob`
Hosting	Cloudflare (OpenNext)

No server receives the file. After the page loads, conversion is local compute.

Dual engines, one contract

Every converter implements the same interface:

canHandle(input, options)
convert(file, options, callbacks)
cancel() / dispose()

Callbacks report stage (loading-engine → decoding → processing → encoding → completed) and a progress ratio, so the UI can show meaningful feedback even when WASM does not emit smooth progress events.

Engine A — WebCodecs + Mediabunny (preferred)

When the browser can decode the container (MOV/MP4/WebM/MKV-like) and is not Safari-preferring-FFmpeg:

Open the file with Mediabunny Input + BlobSource
Take the primary video track; verify canDecode()
Sample frames at the target FPS between startSeconds and endSeconds via CanvasSink
Apply crop / circular mask in Canvas → ImageData
Encode frames to GIF with palette quality derived from the color budget

This path stays on the main thread for canvas work but avoids downloading a multi‑MB Wasm binary when hardware decoding works. Frame count is capped (order of hundreds) so a mis-set FPS cannot OOM a phone.

Engine B — FFmpeg.wasm in a Worker (fallback / Safari / hard cases)

FFmpeg runs in a module Worker with the single-thread @ffmpeg/core build. That avoids requiring SharedArrayBuffer / cross-origin isolation, which would conflict with many third-party scripts on a marketing site.

Flow inside the worker:

Lazy-load ffmpeg-core.js + .wasm from a CDN into Blob URLs
Write the uploaded buffer to the virtual FS as input.mov / input.mp4 / …
exec a carefully built argv list
Read output.gif, transfer the ArrayBuffer back to the UI thread
Delete temp files; support cancel via terminate() + generation tokens

Palette filters often report progress ≈ 0. The main-thread engine layers a soft asymptotic progress ticker, overridden whenever real FFmpeg time/progress arrives — so the bar still moves on phones.

How the engine is chosen

Selection is capability-driven, not page-driven. Live Photo → GIF uses the same rules as other video→GIF pages:

AVI or containers that do not prefer WebCodecs → FFmpeg
Safari (weaker WebCodecs reliability) → prefer FFmpeg
Missing VideoDecoder or unknown width/height from header probe → FFmpeg
Otherwise try WebCodecs; if canHandle fails → FFmpeg

If WebCodecs starts and throws a recoverable error (unsupported codec, empty frames, canvas failure), the conversion hook automatically falls back to a fresh FFmpeg engine and marks usedFallback: true for analytics. Users see a short "compatible mode" state instead of a hard failure.

Building a good GIF from video

GIF is at most 256 colors per frame. Naïve frame dumps look posterized. OmniGIF uses two complementary strategies.

Fast path: per-frame quantize + optional dither

Decoded canvases become GIFFrame[] with delay 1000 / fps. Encoder quality is mapped from the colors setting. Circular crop reserves transparency so the GIF can be a round sticker-style clip.

FFmpeg path: two-pass palette

Args are built in pure TypeScript (no string-interpolated user paths). Conceptually:

[0:v] crop?, fps, scale=lanczos, (optional circle alpha)
  → split
  → palettegen (max_colors, stats_mode=diff)
  → paletteuse (dither=bayer|floyd_steinberg|sierra2_4a|…)

Also supported in the filter chain:

Trim via -ss / -t after -i (more reliable on awkward containers)
Speed by adjusting effective FPS (fps / speed)
Loop count (-loop)
Even dimensions (encoder-friendly)
Aspect-preserving scale (scale=W:-1) so crop regions are not stretched

Presets (small / balanced / high) set default width, FPS, colors, and dither. Live Photos default to a centered square crop because vertical phone footage rarely needs full frame for a chat GIF.

UX details that matter for Live Photos

Preview before convert. After upload, metadata analysis fills duration and resolution; the UI shows a video preview with crop handles and a timeline. Estimated output size updates as options change — important because GIF size grows roughly with frames × resolution × color complexity.

Mobile guide. Phones get a one-shot modal explaining "Save as Video," with optional "don't show again today" via localStorage keyed by local date. Confirming the modal must call the file picker in the same tap or Safari will block it.

Privacy analytics. PostHog events carry tool id, engine id, duration, and error codes — not filenames or pixel data.

Soft limits. Duration, resolution, and file size caps fail early with clear errors rather than mid-encode OOMs.

Why not upload to a server?

Client-side conversion is slower than a beefy GPU box for long 4K clips — but Live Photos are short. The tradeoffs win:

No retention policy for intimate phone videos
No GDPR transfer of the media itself
Works after first load with cached Wasm / scripts
Same codebase for Live Photo, MOV, and MP4 tools

When WebCodecs wins, first conversion can feel near-instant. When FFmpeg loads, idle-time preload (requestIdleCallback) on related pages softens the cold start.

Try it

Tool: https://www.omnigif.com/live-to-gif
Apple's Live Photo help: Take and edit Live Photos
GIF format background: MDN image types
YouTube video: https://www.youtube.com/watch?v=7LSQiUI4J_M

Built as part of OmniGIF — a client-side GIF toolkit. Feedback welcome via Contact.

Building OmniGIF: A Client-Side GIF Toolkit with WebAssembly (No Server Uploads)

Calvin — Wed, 26 Aug 2026 01:30:38 +0000

Most online GIF tools send your file to a remote server. I built OmniGIF to prove that's unnecessary — modern browsers can decode, encode, and transform GIFs entirely on the client.

The architecture problem

Traditional flow:

User → Upload to server → Process → Download result

OmniGIF flow:

User → Load page → Process in browser (JS + WASM) → Download result

The file never hits our infrastructure. From a privacy and latency perspective, this changes the product entirely.

Tech stack

Layer	Choice
Framework	Next.js 15 (SSG)
Language	TypeScript
Styling	Tailwind CSS 4
i18n	next-intl (EN + ZH)
Hosting	Cloudflare (OpenNext)
Analytics	PostHog

The site is statically generated. There's no server-side file processing — which is intentional.

Client-side libraries

GIF work on the web is surprisingly mature. OmniGIF relies on:

gifuct-js — GIF89a decoder; parses frames and delay metadata locally
gif.js — GIF encoder running in a Web Worker
ffmpeg.wasm — FFmpeg compiled to WebAssembly for Live Photo / video → GIF
UPNG.js — PNG/APNG encode/decode for high-color animated workflows
gifsicle-wasm-browser — GIF optimization in the browser
JSZip — bundling extracted frames into ZIP downloads

Per MDN's WebAssembly docs, Wasm brings near-native performance to the web — which matters when you're encoding 30 frames at 1080p.

What the toolkit includes

31 tools across four categories:

GIF Converter

GIF to PNG / WebP / APNG
PNG to GIF, APNG to GIF
Live Photo to GIF — MOV/MP4 → GIF with quality/FPS controls

GIF Tools

Frame inspection, crop, trim, reverse, compress, compress to target size, text/watermark overlay, GIF overlay, watermark removal.

GIF Maker

Intensify, shake, fire text, vinyl spin.

GIF Effects

B&W, border, confetti, dither (Floyd–Steinberg, Bayer, Atkinson), pixelate, fade, speed, glitch.

Full list: llms.txt (machine-readable sitemap for tools).

Design decisions

Why SSG, not SSR?

All parameters are client-side. No need for server rendering of user files. Faster cold loads, simpler deployment on Cloudflare.

Why Web Workers?

GIF encoding blocks the main thread. gif.js and heavy transforms run off-thread so the UI stays responsive.

Why per-tool pages instead of one mega-app?

SEO, shareability, and focused UX. Each tool has its own URL, metadata, FAQ, and structured data. Users land on exactly what they need.

Real-time preview on desktop

For tools with tunable parameters (crop, effects, compression), the right panel shows a live preview on PC. Mobile gets before/after after generation — saves battery and screen space.

Chrome extension

The OmniGIF extension bridges web → tool: right-click any image, pick a destination tool, and the image is passed via URL params / clipboard. Offline install package available for environments that need it.

Challenges

Memory — Large GIFs (many frames × high resolution) can OOM on mobile. We enforce file size limits and warn early.
GIF color depth — GIF is 256 colors max. Converting from APNG/PNG requires palette reduction; dithering quality varies by algorithm.
ffmpeg.wasm bundle size — First load downloads a sizable Wasm binary. Lazy-loading FFmpeg only on video tools helps.
Cross-browser APNG — APNG support is uneven; we document browser compatibility on converter pages.

Privacy as a feature, not a footnote

The W3C GIF89a spec hasn't changed much in decades, but how we process GIFs can change. Client-side tooling means:

No file retention policies to worry about
No GDPR data-transfer questions for the image itself
Works offline after first page load (extension + cached assets)

Try it / feedback

Live at https://www.omnigif.com — free, no account.

More background: About OmniGIF

Questions: FAQ | Contact

Built by Calvin Sun as an indie project. Feedback welcome.