DEV Community: Holomatar

I Built a Browser Gallery for Every MP4 Frame

Holomatar — Sat, 29 Aug 2026 18:08:57 +0000

I thought the feature was finished when FFmpeg.wasm could turn an MP4 into a ZIP of PNG files. The conversion worked, but the workflow did not: users still had to download and unpack everything before they could find one useful frame.

So I moved the missing step into the browser. Video Frame Tool now extracts every frame, renders the complete gallery, tracks a selection, and exports one PNG, a selected ZIP, or the entire sequence. The source MP4 stays on the device.

Live demo: https://holometer.net/video-frame-tool/en/

This post covers the implementation choices that mattered most: numbered FFmpeg output, Blob URL lifecycles, selection state, memory costs, and browser-safe downloads.

Why a ZIP-only workflow was not enough

The first version converted an MP4 and returned a ZIP. Technically, that solved frame extraction. In practice, it moved the real work somewhere else: users still had to download the archive, extract it, open a file browser, change to thumbnail view, and search through hundreds of nearly identical images.

The useful workflow is closer to a contact sheet:

choose a video;
inspect every result in sequence;
select only the moments that matter;
download those frames without repeating the conversion.

That sounds like a small interface change, but it affects memory management, progress reporting, object URL cleanup, selection state, and download behavior.

The browser-only extraction pipeline

The conversion runs with FFmpeg compiled to WebAssembly. The selected MP4 is copied into FFmpeg's in-memory filesystem, then every decoded frame is written as a numbered PNG.

The extraction step is conceptually equivalent to:

ffmpeg -i input.mp4 -vsync 0 frame_%08d.png

Eight-digit filenames keep lexical and numeric order identical. That avoids the common frame_1, frame_10, frame_2 sorting problem when the files are displayed or passed back into an encoder.

After FFmpeg finishes, the app reads the PNG files, sorts them by frame number, creates browser object URLs, and adds them to the gallery. The source video and extracted PNGs are not sent to a conversion server.

The first run downloads roughly 32 MB of FFmpeg WebAssembly assets. That cost is shown before conversion because hiding a large first-load dependency makes a local tool feel broken on a slow connection.

A real test: 36 full-resolution frames

For a repeatable check, I used a 1.2-second, 1080×1920 MP4. The browser extracted and displayed 36 PNG frames. Together, those PNGs occupied 50.4 MB in memory even though the source MP4 was only about 140 KB.

That difference is the central constraint of client-side frame extraction: compressed video is small, while decoded lossless frames are not.

The gallery reports the frame count, dimensions, and total PNG size before the user downloads anything. In this test I selected three frames from different moments, then confirmed that the interface offered all three paths:

download one frame as a PNG;
download the selected three as one ZIP;
download all 36 as one ZIP.

Keeping hundreds of frames responsive

Every gallery thumbnail is backed by a Blob URL rather than a base64 string. Base64 expands the data and makes large DOM attributes expensive. Blob URLs let the browser keep the binary data outside the HTML while normal <img> elements render the previews.

Those URLs still need a lifecycle. When a new video is chosen, the old gallery is cleared and its object URLs are revoked. Otherwise, repeatedly converting videos in one tab would leave the previous PNG data in memory.

The selection model is deliberately simple: a Set stores the selected frame names, and the buttons derive their labels and enabled state from that set. “Select all” adds the complete ordered list; “Clear selection” empties it. Building the ZIP happens only after the user chooses a download action, so merely browsing the gallery does not create a second full copy of every PNG.

Why individual browser downloads need special handling

Triggering 300 separate downloads is hostile to both the user and the browser. It can produce hundreds of permission prompts or be blocked as abusive behavior.

Video Frame Tool therefore uses three explicit operations:

one PNG for a single useful moment;
selected ZIP for a small reference set;
all ZIP for animation and batch-processing work.

This also makes the tool useful outside illustration. A developer can pick state-transition frames for a bug report, an animator can compare spacing, and a pixel artist can export a short sequence for cleanup.

Loading a public X video without pretending it is private

The local-file path is fully client-side. The X URL path has a necessary network boundary: the app sends the public post ID to the FxTwitter API to resolve the available media URL, then downloads the selected public MP4 from X's delivery host. Frame conversion happens locally after that download.

Private, deleted, or age-restricted posts are not supported. A public URL also does not grant reuse rights, so the page tells users to process only videos they own or have permission to use.

Turning image sequences back into MP4 or GIF

The reverse path accepts individual images or a ZIP. Filenames are naturally sorted so frame_2.png stays before frame_10.png. Images with different aspect ratios are not stretched; each frame is fitted inside the first image's canvas and padded with black or white.

MP4 output uses H.264 with a broadly compatible pixel format. GIF output first builds a palette, then applies it during encoding to avoid the worst color banding. Users can choose common frame rates such as 8, 12, 15, 24, 30, or 60 fps.

Limits that still matter

This is not a replacement for a desktop video editor. Long 4K clips can exhaust browser memory, and PNG extraction is intentionally lossless and therefore large. The safest workflow is to begin with a short clip, confirm the result, and only then increase duration or resolution.

The tool also does not repair motion blur, camera shake, compression artifacts, or hidden body parts. It exposes the frames that already exist; it does not invent missing visual information.

Try it

Video Frame Tool is free, requires no account, and works in a modern desktop browser:

https://holometer.net/video-frame-tool/en/

If you try it, I am especially interested in the point where the workflow becomes uncomfortable: extraction time, gallery size, selection, or ZIP creation. Those limits are more useful than a successful five-frame demo when deciding what to optimize next.

How I Turned AI-Generated “Pixel Art” into a Real Pixel Grid in the Browser

Holomatar — Sat, 29 Aug 2026 16:56:32 +0000

AI image generators can produce artwork that looks like pixel art from a distance, while its cell sizes, outlines, and colors fall apart under zoom. This post explains how I built Pixel Maker , a browser-only converter that detects a logical grid, samples one color per cell, reduces palettes in Oklab, preserves small accents, and exports clean nearest-neighbor PNGs.

Try the tool: https://holometer.net/pixel-maker/en/

This post explains the parts that mattered most: grid detection, representative-color sampling, perceptual palette reduction, rare accent preservation, and clean export.

Why isn't nearest-neighbor resizing enough?

My first version did what many quick converters do:

shrink the source image;
enlarge it again with nearest-neighbor interpolation.

That produces visible squares, but it does not repair the source. A blurred edge becomes a larger blurred-looking block. JPEG noise becomes a collection of unrelated colors. If the generated image uses different implied pixel sizes in the hair, face, and background, resizing simply compresses those inconsistencies into a smaller canvas.

The problem was not “how do I make the pixels larger?” It was “how do I infer a useful logical grid, then choose one intentional color for every cell?”

How does the browser-only pipeline work?

Pixel Maker runs entirely in the browser with Canvas and a Web Worker. The selected image is not uploaded to a server.

The conversion pipeline is roughly:

source image
  -> optional grid estimation
  -> cell-level color sampling
  -> palette extraction and perceptual merging
  -> accent and skin-tone preservation
  -> small-cluster cleanup
  -> logical-size PNG export
  -> optional 1x–10x nearest-neighbor enlargement

Keeping these stages separate made the tool easier to tune. A single resize or quantization pass could not handle both AI-generated pseudo-pixel art and smooth illustrations well.

How do you detect a hidden pixel grid?

AI-generated pixel-art-style images often contain a weak periodic structure. Some edges line up every 6, 8, or 10 source pixels, while other regions drift away from that rhythm.

I estimate candidate cell sizes from repeated vertical and horizontal color boundaries, then compare several signals instead of trusting one peak. The detected value is only a suggestion: users can switch to a fixed logical width when the source does not contain a reliable grid.

That fallback matters. A portrait with soft gradients may not have a meaningful source grid at all, while a generated game sprite often does.

How do you choose one color per cell?

Once the logical cells are known, each cell needs a single color. A simple average tends to create muddy colors around outlines, so the default is dominant-color sampling : choose the most frequent color family inside the cell.

The tool also exposes median, mean, and center sampling because no single strategy wins for every image:

Dominant color is strongest against AI noise and JPEG artifacts.
Median is stable when a cell contains a few extreme pixels.
Mean preserves smooth photographic lighting, but can soften edges.
Center is predictable for already-clean sprites.

This choice made a larger difference than I expected. On character faces, averaging often washed out the skin and weakened the eyes; dominant sampling kept the main color planes intact.

Why reduce colors in Oklab instead of RGB?

RGB distance is a poor approximation of visual similarity. Pixel Maker converts palette candidates to Oklab , measures perceptual distance there, and merges nearby colors while weighting each cluster by how much of the image it occupies.

Large regions are protected from being collapsed too aggressively. Small colors can be merged more freely unless they qualify as important accents.

The default hand-crafted mode currently uses 16 colors, while the grid-repair mode starts at 64 colors. Users can increase the count when faces or tiny details disappear.

How do you preserve tiny accents without keeping noise?

The hard part of palette reduction is distinguishing a useful rare color from random noise. A one-pixel highlight in an eye may be important; a one-pixel compression artifact is not.

I score rare candidates using a combination of:

distance from the retained palette;
chroma;
local population;
whether nearby cells support the same color family.

This keeps small stars, eye highlights, and interface accents more reliably. A separate skin-tone safeguard can reserve a representative warm color when palette reduction would otherwise make a face too pale or gray.

What gets cleaned before PNG export?

After quantization, isolated color fragments are compared with their neighbors. A cell is replaced only when a strong local majority exists, so cleanup removes speckle without erasing every deliberate single-pixel detail.

The final PNG is rendered from the requested logical dimensions—anywhere from 16 to 512 pixels on the long side. If a larger display asset is needed, the logical image is enlarged up to 10× with nearest-neighbor interpolation.

That distinction is important: the tool resamples the source for the selected logical size instead of stretching one previously generated thumbnail.

Which conversion mode should you use?

The stricter correction mode prioritizes a consistent grid and compact palette. It works well for game assets and sprites.

The color-preserving mode keeps more of the original gradients and atmosphere. It is better when visual resemblance matters more than strict pixel-art construction.

There is no universal best conversion. The useful workflow is to start with the hand-crafted preset, inspect the eyes and outline at high zoom, then adjust logical size and palette count before editing individual pixels.

What the tool still cannot solve

This is image processing, not semantic redrawing. It cannot infer the artist’s intended eye shape or reconstruct a hand that was malformed in the generated source. Lines thinner than one logical cell may disappear. Images with no repeated structure can also produce unreliable automatic grid estimates.

For those cases, Pixel Maker includes a one-pixel editor so the last few decisions stay human.

Try it

Pixel Maker is free, requires no account, and processes images locally in the browser:

https://holometer.net/pixel-maker/en/

If you test it with an especially difficult image, I would like to know which part breaks first: grid detection, palette reduction, outlines, or small details. Those failures are the most useful input for the next version.

Disclosure: This article was edited with AI assistance from my implementation notes and verified against the live tool.