DEV Community: Gemy Brooks

Building a browser GIF editor: the frame memory limit matters more than file size

Gemy Brooks — Tue, 03 Nov 2026 14:26:53 +0000

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.

Why Cropping an Animated GIF Is Harder Than Cropping a Regular Image

Gemy Brooks — Sun, 01 Nov 2026 16:06:08 +0000

Why Cropping an Animated GIF Is Harder Than Cropping a Regular Image

Cropping a PNG or JPEG is straightforward: load the image, select a rectangular area, crop it, and export the result.

Animated GIFs are a different story.

If you've ever tried to build an online GIF cropper, you may have discovered that simply cropping each frame independently doesn't always produce the animation you expect.

Frames can disappear, transparency can break, timing can change, and unexpected visual artifacts can appear.

Let's look at why this happens and what a reliable GIF cropping workflow should look like.

1. A GIF Isn't Just a Collection of Full Images

One common misconception is that an animated GIF is simply a sequence of complete images.

In reality, GIF uses a frame-based structure that can be more complicated.

An animated GIF contains:

A logical screen describing the animation canvas.
Image descriptors defining individual frame regions.
Frame image data.
Graphic Control Extensions containing timing and disposal information.
Optional looping information.

An important detail is that individual frames don't always contain the entire canvas.

Some GIFs use partial frame updates. Instead of storing a complete image for every frame, they only store the pixels that changed.

This can make GIF files smaller, but it also makes image processing more complicated.

2. The Disposal Method Can Change Everything

GIF frames have disposal methods that determine what happens to the canvas after a frame is displayed.

The commonly encountered methods include:

Do Not Dispose: Leave the previous frame in place.
Restore to Background: Restore the frame area to the background.
Restore to Previous: Restore the previous canvas state.

These behaviors matter when reconstructing an animation.

Imagine a GIF where a character moves from left to right.

Frame 1 contains the character on the left.

Frame 2 only contains the character's new position.

Frame 3 contains another small update.

If you crop the encoded frame rectangles directly, you may lose information needed to reconstruct the actual animation.

The safer approach is to reconstruct the complete displayed canvas before cropping.

3. A More Reliable GIF Cropping Workflow

A robust implementation can follow this pipeline:

Original GIF
     |
     v
Decode GIF structure
     |
     v
Reconstruct complete frames
     |
     v
Apply crop coordinates
     |
     v
Preserve frame timing
     |
     v
Re-encode GIF
     |
     v
Validate output animation

Let's break it down.

Step 1: Decode the GIF

Read the GIF structure and extract:

Canvas dimensions
Frame data
Frame offsets
Frame delays
Disposal methods
Transparency information
Loop settings

Step 2: Reconstruct Each Frame

Before cropping, reconstruct each frame as it should appear on the complete animation canvas.

This step is particularly important for GIFs using partial frame updates.

A decoder that returns raw frame rectangles requires additional compositing logic.

A decoder that already returns fully composited frames can simplify this stage.

Step 3: Apply the Same Crop Region to Every Frame

Suppose the original GIF has dimensions of 800 × 600 pixels.

The user selects this crop region:

const crop = {
  x: 100,
  y: 50,
  width: 400,
  height: 300
};

Apply the same coordinates to every reconstructed frame.

The output dimensions should be:

400 × 300 pixels

One important detail: if the GIF preview is scaled to fit the browser window, the selection coordinates must be converted back to the original GIF coordinate system.

Otherwise, the exported result may not match the visible selection.

Step 4: Preserve Animation Timing

Cropping should not unintentionally change how the animation plays.

Keep track of each frame's original delay.

For example:

const frame = {
  image: frameCanvas,
  delay: originalDelay
};

The encoder should receive the appropriate delay for each corresponding frame.

Also check whether the original animation uses looping information.

Step 5: Re-encode and Validate

After cropping, encode the reconstructed frames into a new GIF.

Don't assume that a successful encoding operation means the output is correct.

Decode the exported file again and verify:

Frame count
Frame order
Frame delays
Total animation duration
Transparency
Loop behavior
Canvas dimensions

This final validation step can catch problems that are difficult to notice in a single preview.

4. Transparency Is Another Common Source of Bugs

GIF transparency is not the same as the alpha channel in PNG.

GIF transparency is based on a transparent color index in the frame's color table.

That means GIF transparency is essentially binary: a palette entry is transparent or it isn't.

When rebuilding frames, careless palette conversion can introduce:

Unexpected background colors
Transparent pixels becoming opaque
Visible edges around objects
Flickering between frames

A good implementation should preserve transparency information during decoding and handle palette generation carefully during encoding.

If exact visual preservation is important, compare the exported animation against the original frame by frame.

5. Browser-Based Processing Is Worth Considering

For small and medium-sized GIF files, browser-based processing can be a practical architecture.

A typical setup might use:

Canvas for rendering and cropping.
A GIF decoder for reading frame data.
A GIF encoder for generating the output.
Web Workers for moving CPU-intensive work away from the main thread.

A simplified architecture looks like this:

Browser UI
    |
    v
File Upload
    |
    v
Web Worker
    |
    +-- GIF Decoder
    |
    +-- Frame Compositor
    |
    +-- Crop Processor
    |
    +-- GIF Encoder
    |
    v
Output Blob
    |
    v
Download

There are trade-offs.

Large animations can consume considerable memory because reconstructing every frame may require multiple full-resolution image buffers.

For this reason, a good tool should consider:

Maximum file size
Maximum frame count
Processing cancellation
Memory cleanup
Clear error messages

It is also important to release object URLs and temporary resources when processing finishes.

6. My GIF Cropping Test Checklist

When developing or evaluating a GIF cropper, I would test these cases before considering the implementation reliable.

Test case	What to verify
Simple animated GIF	All frames remain visible
Partial-frame GIF	No missing image regions
Transparent GIF	Transparency remains intact
Variable frame delays	Animation speed remains consistent
Looping GIF	Loop behavior is preserved
Large GIF	Processing doesn't freeze the page
Different crop ratios	Output coordinates are accurate

A tool that works with one simple GIF isn't necessarily ready for real-world use.

The difficult cases are usually the ones that reveal implementation problems.

Conclusion

Building an animated GIF cropper is not simply an image manipulation task.

It requires understanding frame composition, disposal methods, timing, transparency, and encoding.

The most important principle is:

Reconstruct the animation correctly before modifying it.

Once the animation is represented as complete displayed frames, applying the same crop region becomes much more predictable.

I'm also exploring browser-based visual media utilities through VisualFormat, where GIF processing is one of the areas I'm interested in building practical tools for.

Disclosure: This article was prepared with AI assistance and should be reviewed by the author for technical accuracy before publication.

Fixing Closed Eyes with AI: Why the Edit Boundary Matters

Gemy Brooks — Sat, 24 Oct 2026 10:37:29 +0000

A group photo can be almost perfect: good light, everyone in the frame, a moment worth keeping.

Then you notice that one person blinked.

For a developer, this looks like a small image-editing task. But the real requirement is more demanding:

Open the eyes while preserving everything the user already likes about the photo.

I'm building MomentRescue, a photo-repair project. This post looks at one engineering question behind its Open Eyes workflow: how do you constrain a generative edit when the requested change is tiny?

1. Define what is allowed to change

“Make this photo better” is an open-ended request.

“Repair the selected person's closed eyes” has a much narrower boundary.

That distinction should appear in the system design, not just in the prompt. A useful contract is:

One selected person per operation.
A repair region around the eyes.
Original image pixels outside that region.
A separate output file, with the original kept intact.

The model may generate more than you intend to use. Your application still decides which generated pixels reach the final image.

That is the difference between asking for restraint and enforcing it.

2. Separate generation from composition

A practical conceptual pipeline looks like this:

Original photo
  -> detect faces and confirm the selected person
  -> prepare a face crop and optional reference
  -> generate a candidate repair
  -> align the candidate to the original coordinates
  -> blend it through a bounded eye-area mask
  -> compare, review, and export

This is a design outline, not a complete implementation or a claim that every photo-repair tool works this way.

The important separation is between producing a candidate and accepting pixels into the final photo.

For an opaque RGB image, the basic blend is:

// Illustrative RGB compositing, not production image-processing code.
function blendPixel(original, candidate, maskAlpha) {
  const a = Math.max(0, Math.min(1, maskAlpha));
  return original.map((channel, i) =>
    Math.round(channel * (1 - a) + candidate[i] * a)
  );
}

Outside the permitted region, maskAlpha must be zero. At the boundary, a gradual transition can soften the seam.

The difficult work sits around this small formula: coordinate mapping, alignment, mask placement, and handling the edges of glasses. A soft mask cannot fix a misaligned eye.

Also, preserving decoded pixels is different from preserving an original file byte for byte. Exporting can change compression and metadata.

3. Treat a reference as evidence, not a guarantee

Closed eyelids hide information. There is no reliable “sharpen” operation that reveals the person's actual eyes underneath.

An open-eye reference of the same person provides visual clues. But a sharp reference with a very different head angle can still be a poor match.

For a reference picker, useful guidance is concrete:

Choose the same person with both eyes visible.
Prefer a similar head angle and lighting.
Try a neighboring shot from the same session.
Avoid sunglasses, heavy blur, or a face that occupies very few pixels.

If the reference contains several people, the interface needs to confirm the matching person there too.

A reference reduces guesswork. It does not establish that the generated result is accurate.

4. Inspect an example at two scales

Here is an existing MomentRescue Open Eyes test.

These images use synthetic people. They are a product demonstration, not a customer photo, endorsement, or benchmark. Results vary.

Before: the center person has closed eyes.

After: the existing test result.

A full-photo view answers, “Does the picture still feel coherent?”

A close inspection answers different questions: Are both eyes looking in a compatible direction? Do the eyelids fit the face? Are the glasses frames continuous? Is there a visible blend boundary?

A result can pass one view and fail the other.

5. Give “finished” and “good” different meanings

An API response tells you that processing finished. It does not tell you whether someone looks like themselves.

I would evaluate a focused repair with three separate checks:

Check	Question
Edit containment	Did any decoded pixels outside the permitted region change?
Local quality	Do gaze, eyelids, lighting, and glasses look plausible?
User acceptance	Does the person still look like themselves to the user?

The first check can be automated by comparing decoded images outside the mask, before export. The other two still need visual judgment.

Useful evaluation cases include small faces, side profiles, glasses, mismatched references, and groups with more than one person blinking. A clean demonstration image cannot establish performance across those cases.

The broader engineering lesson

For a narrowly scoped AI edit, the output boundary is part of the feature.

The same question applies to removing a distraction, repairing a document region, or changing one object in a product photo:

Which parts of the input is the system actually allowed to rewrite?

A clear answer gives you something concrete to implement, inspect, and test.

How would you evaluate identity preservation in a small face edit, beyond checking whether the result looks plausible?

Disclosure: I am the developer behind MomentRescue. AI assistance was used to draft this article. The compositing snippet is illustrative; it is not the project's production implementation.

Workflow reference: MomentRescue's description of its selected-face repair pipeline.

How I Built an AI-Powered Real Estate Photo Editing Workflow

Gemy Brooks — Tue, 13 Oct 2026 15:44:51 +0000

How I Built an AI-Powered Real Estate Photo Editing Workflow

Real estate photography has an interesting problem: a photo can be technically correct and still look terrible in a property listing.

A room might be beautifully designed, but the camera captures a dark interior and an almost completely white window. The walls look slightly yellow, vertical lines appear tilted, and shadows hide important details.

Professional photographers know how to fix these problems. But editing dozens or hundreds of listing photos manually takes time.

As an independent developer, I became interested in a simple question:

Could I build a workflow that automates most of the repetitive editing while still giving users control over the final result?

That question led me to work on ListingPolish, an AI-powered real estate photo editing tool.

In this article, I'll explain the engineering decisions behind this kind of workflow, the problems it needs to solve, and why I think quality control matters as much as image enhancement.

1. Real Estate Photos Have Their Own Challenges

At first glance, real estate photo editing looks like a standard image enhancement problem.

Increase brightness, adjust contrast, correct colors, and you're done.

Unfortunately, it's not that simple.

Blown-out windows

This is one of the most common problems in interior photography.

The camera exposes for the darker room, leaving the outdoor view overexposed.

Simply reducing the brightness doesn't necessarily recover missing information.

For a good result, the editing system needs to handle the difference between interior and exterior exposure intelligently.

Uneven lighting

A room may have bright areas near windows and dark corners elsewhere.

A global brightness adjustment can make one area better while making another worse.

Color casts

Indoor lighting can introduce yellow, green, or blue color casts.

These are particularly noticeable on white walls, ceilings, and neutral furniture.

Perspective distortion

Wide-angle lenses are useful for photographing interiors, but they can make vertical lines appear tilted.

In real estate photography, correcting these lines can make a significant difference.

These issues convinced me that a generic "make this photo look better" button isn't enough.

2. Why I Chose APIs Instead of Training a Model

When building an AI image product, one of the first decisions is whether to develop a custom model or use an existing service.

For an independent developer, the trade-offs are important.

Training a specialized model requires datasets, computing resources, evaluation pipelines, and ongoing maintenance.

Using an established image processing API offers a much faster path to building a usable product.

It also lets me focus on the parts that directly affect the user experience:

Uploading and managing multiple photos
Coordinating processing requests
Evaluating output quality
Handling failed processing attempts
Presenting before-and-after comparisons
Managing downloads and processing costs

The goal isn't to build another image generation model.

It's to build a reliable product around image processing capabilities that already exist.

3. Designing the Processing Workflow

The workflow I designed for ListingPolish follows this structure:

User uploads photos
        |
        v
Validate input files
        |
        v
Submit enhancement job
        |
        v
Receive processed preview
        |
        v
Run quality checks
        |
        +---- Acceptable ----> Show result
        |
        +---- Needs review --> Generate feedback
                                  |
                                  v
                            Retry if supported
                                  |
                                  v
                            Review new result
        |
        v
User reviews comparison
        |
        v
Download final image

This is the workflow architecture I'm working toward, rather than a claim that every quality check or retry path is already fully automated in production.

The important idea is that image processing shouldn't be treated as a single API call.

A successful API response only tells us that processing completed.

It doesn't necessarily tell us whether the output is good.

4. Why Quality Assurance Is the Interesting Part

Imagine an AI service successfully processes an interior photograph.

The result is brighter, but the walls now have an unnatural color cast.

Technically, the processing job succeeded.

From the user's perspective, it may have failed.

This distinction matters.

I think an automated editing workflow should eventually evaluate several dimensions of output quality.

Exposure: Are important areas still too dark or overexposed?

Color consistency: Do neutral surfaces look natural?

Geometry: Are vertical lines reasonably straight?

Image artifacts: Did processing introduce visible distortion or unnatural details?

Overall consistency: Does the edited image still look like the original property?

Some checks may be possible using image analysis algorithms. Others may benefit from vision models.

The difficult part is deciding when the system should accept a result, request another attempt, or ask the user to review it.

A useful QA system should also avoid unnecessary retries. Reprocessing an image repeatedly can increase cost without improving quality.

5. The Importance of Before-and-After Previews

One lesson from thinking through this product is that users need to see what changed.

A simple result image isn't always enough.

A before-and-after comparison helps photographers identify:

Whether window details improved
Whether colors look natural
Whether shadows contain enough detail
Whether the overall image feels realistic

It also makes the tool easier to trust.

For AI image editing, trust is especially important because a visually attractive result isn't always an accurate result.

Real estate images should represent the property faithfully.

Enhancement should improve presentation without inventing features or materially changing the property.

6. Building Around a Pay-for-Download Model

Another interesting design decision is when to charge the user.

Some image processing providers support previewing results before charging for the final downloadable image.

That creates an opportunity for a more user-friendly workflow.

Instead of requiring payment before users know whether the enhancement worked, the product can allow them to inspect the preview first.

The challenge is balancing preview quality, processing costs, and abuse prevention.

Even when the final download is the billable action, uploads, processing requests, storage, and retries may still create infrastructure or provider costs.

A sustainable product needs to account for those costs.

7. What I'd Improve Next

There are several areas I'd like to continue exploring:

Better automated quality checks

A processing pipeline becomes much more useful when it can identify obvious problems before users notice them.

More useful retry feedback

Instead of retrying with the same settings, the system should ideally understand what went wrong.

For example:

Issue: Interior is still too dark
Suggestion: Improve shadow detail

Issue: Walls have a warm color cast
Suggestion: Adjust white balance

Issue: Vertical lines appear tilted
Suggestion: Apply perspective correction

These examples illustrate the kind of structured feedback a future review system could produce.

More consistent batch processing

Photographers often need an entire property listing to have a consistent visual style.

Editing each photo independently can produce inconsistent results.

Solving that problem could make automated editing substantially more valuable.

Final Thoughts

Building an AI photo editing tool isn't just about finding the best image processing model.

The surrounding workflow matters just as much.

Uploading, previewing, quality checking, retrying, comparing, and downloading are all part of the experience.

I'm exploring these ideas through ListingPolish, an AI real estate photo editing workflow.

For developers building AI-powered image tools, I'm curious:

How do you evaluate the quality of AI-generated or AI-edited images before showing them to users?

Do you rely on automated checks, human review, or a combination of both?