imazen / imageflow

High-performance image manipulation for web servers. Includes imageflow_server, imageflow_tool, and libimageflow
https://docs.imageflow.io/
GNU Affero General Public License v3.0
4.18k stars 139 forks source link

Issue with Cropping Animated Gifs #652

Open caviyacht opened 2 months ago

caviyacht commented 2 months ago

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

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:

43612_right

lilith commented 2 months ago

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 https://github.com/imazen/imageflow/issues/652, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA2LH6ETUV36TORZKDFZNLZUY2VBAVCNFSM6AAAAABNTCDWF2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGUYDGOJSG44TCMQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

caviyacht commented 2 months ago

@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 commented 2 months ago

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 commented 1 week ago

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