Repository navigation
Reduce an animated input to its first frame [patch] - #137
Merged
Merged
Conversation
An animated GIF, APNG or WebP loads with one frame per step. The Mutate calls applied to every frame, but the coverage pass in ProcessPixelRows touched only the root frame, so the remaining frames were written out as an animated PNG of raw greyscale cropped to the first frame's bounds. ProcessImage now drops every frame after the first before processing, matching the tool's single-frame output. Fixes #119 Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_01LbAGNxbUT888WNAYAvXC2p
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #119
What was wrong
Image.Load<Rgba32>decodes every frame of an animated GIF, APNG or WebP. TheMutatecalls (BlackWhite, crop/pad/resize) run on every frame.FindBrightestOpaqueValueandFlattenToCoverageAndMeasureBoundsgo throughProcessPixelRows, which only touches the root frame. So only frame 0 got the coverage pass. The other frames were saved as an animated PNG of raw greyscale, cropped to frame 0's bounding box, and the run still reported success.Change
ProcessImagenow removes every frame after the first before it does anything else, so the output is always a single-frame coverage mask. That is the tool's documented output, and the triage recommended this approach. Doing it insideProcessImagerather than inProcessDirectorykeeps it covered by unit tests.Tests
ProcessImageTests.ReducesAnAnimatedInputToItsFirstFrameis the two-frame fixture from the issue:The test asserts there is one output frame, its width is 20 (frame 0's bounds), and its pixels are the red target colour. It failed before the fix (
Frames.Countwas 2) and passes with it.Full suite: 79/79 pass. The gold-master tests need the LFS fixtures (
git lfs pull). Without them, the 8 gold-master cases fail onmaintoo.🤖 Generated with Claude Code
https://claude.ai/code/session_01LbAGNxbUT888WNAYAvXC2p
Generated by Claude Code