Issue with Cropping Animated Gifs

[caviyacht]

I am currently trying to evaluate ImageFlow but am running into an issue when resizing animated gifs. When resizing the following image it ends up causing it to bounce around a bit. This doesn't happen in other libraries, but seems to be happening in ImageFlow and the legacy ImageResizer.

It seems like one of the frames with the lights is causing the image to be slightly bigger than the rest of the frames. Perhaps the bug is that the image size isn't taking into account the biggest image in the sequence?

Output:

using var job = new ImageJob();

// NOTE: Removing 'trim.threshold' does fix the issue, but then it doesn't trim
await job
    .Decode(await File.ReadAllBytesAsync(source))
    .ResizerCommands("width=400&bgcolor=white&trim.threshold=50")
    .EncodeToStream(destinationFile.OpenWrite(), true, new GifEncoder())
    .Finish().InProcessAsync();

Input file:

[lilith]

TrimWhitespace doesn't work on animations unless the whitespace is consistent in every frame. Perhaps it would better to only analyze the first fram for cropping data, but that is not the current logic.

…

On Tue, Sep 3, 2024, 6:36 PM caviyacht ***@***.***> wrote: I am currently trying to evaluate ImageFlow but am running into an issue when resizing animated gifs. When resizing the following image it ends up causing it to bounce around a bit. This doesn't happen in other libraries, but seems to be happening in ImageFlow and the legacy ImageResizer. It seems like one of the frames with the lights is causing the image to be slightly bigger than the rest of the frames. Perhaps the bug is that the image size isn't taking into account the biggest image in the sequence? Output: 43612_right--output-imageflow.gif (view on web) <https://github.com/user-attachments/assets/3d336caa-bbdf-4241-ac73-d7fc66f0bbaa> using var job = new ImageJob(); // NOTE: Removing 'trim.threshold' does fix the issue, but then it doesn't trimawait job .Decode(await File.ReadAllBytesAsync(source)) .ResizerCommands("width=400&bgcolor=white&trim.threshold=50") .EncodeToStream(destinationFile.OpenWrite(), true, new GifEncoder()) .Finish().InProcessAsync(); Input file: 43612_right.gif (view on web) <https://github.com/user-attachments/assets/74ee5fbb-65fd-4953-8922-442ba670122c> — Reply to this email directly, view it on GitHub <#652>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA2LH6ETUV36TORZKDFZNLZUY2VBAVCNFSM6AAAAABNTCDWF2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGUYDGOJSG44TCMQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[caviyacht]

@lilith , is this something that seems plausible to put in? We are currently using the legacy version of this image resizer (which exhibits the same issue) and are considering moving to the newer version. I don't know what ImageSharp (would rather not) is doing, but it doesn't seem to exhibit this issue, perhaps they're looking at the first frame.

[lilith]

I'll put it on the list. If you have a support contract, we can prioritize it, but you're the first to report the issue since those features were added in 2010.

[lilith]

Can you release that image into the public domain for use in our test suites?

[lilith]

So, after a closer look, just testing the first frame is wrong. And it would crop the glow on the heel of this particular image, I think?

For speed, we currently process and encode each frame in sequence rather than buffering the entire video into memory, which would be required to do this properly. I'm unsure if that tradeoff is worth it, since animated gifs aren't widely resized (and usually would be better off using a slow/offline/async tool like gifski).

Do you have a lot of animated gifs needing auto-cropping or is this a blocker for you?