Add ability to ignore WebP animations

[SpikeViper]

My project requires the ability to save one image in a variety of formats, specifically with animated and non-animated versions of the image (so they can be switched off for epileptic users). We'd like to use WebP encoding and while one could technically do two decoding runs, one of which with max frames = 1, it is far more efficient to just add a flag to the encoder allowing for it to ignore animated frames and save a static image.

The change is implemented below:
Valour-Software@4957384

[tocsoft]

alternative that should work today without any library changes is to save out the animated version first, than delete the additional frames and then save again with just the single frame in the image.

[JimBobSquarePants]

Why re decode? I can only imagine that you are over complicating something somewhere. We have all the APIs in place to allow you to clone, export frames, save etc in a manner where you shouldn’t even need to care what the input format is.

Without a code sample we can only guess what you are doing but I’m not going to accept some format specific hack when there are viable alternatives available.

[SpikeViper]

Specifically, the workflow is the following:
Starting at full resolution, save in X formats including static and animated versions.
Then drop resolution and repeat.

for (image sizes)
for (format)
save()

mutate -> new size

This is being used at scale for image uploads so cloning and wasting RAM or removing our ability to process in parallel for each format are dealbreakers. We'll just use our tweaks internally - we were trying to contribute. It would be easier if all the assemblies were not marked as internal and we could just create an encoder extension.

Considering each format has its own encoder, with its own properties, "format specific hack" doesn't make sense to me, but I'll accept that you're not interested in adding the option.

[tocsoft]

What might not be helping in our decision making/this discussion is that with your current workflow you are highly at risk of introducing compounding errors by resizing in a loop in that way (resizing something already resized). You really should go back to the original for each resize operation for the best quality at each size.

Given that best practice recomdation you should already have a new copy for each size, thus the process of handling all the animated exports, removing unwanted frames then handling static versions as a 2nd loop would make more sense.

@JimBobSquarePants please correct me if I'm wrong on our best practice recommendation here.

[JimBobSquarePants]

Just to be clear here @SpikeViper I don't mean the term hack in a derogatory sense more as a narrow scope fix. I've made mistakes in the past adding format specific behavior that should have been normalized and I'm pushing now for more general solutions to problems. Opening a PR at this point, while honorable is premature.

Now @tocsoft has a very valid point here regarding best practice. By continuously resampling a previously resampled image you introduce a lot of error which is detrimental to the quality of the output. We would recommend normally that you should clone the image to resample if operating more than one time.

Regardless of the origin of your image though we can efficiently perform the operation you require using code like the following.

int width = ... ;
using Image<Rgba32> animated = ... ;// This could be a clone or the original.
animated.Mutate(x => x.Resize(width, 0));
animated.SaveAsWebp("animated.webp");

if (animated.Frames.Count > 1)
{
    // The memory required to clone a single frame will almost always be less than what
    // we just gave back to the pool by downscaling the image. Pooled memory is discontiguous
    // so OOM exceptions are very rare.
    using Image<Rgba32> nonAnimated = animated.Frames.CloneFrame(0);
    nonAnimated.SaveAsWebp("non-animated.webp");
}

[SpikeViper]

I appreciate the additional information. I'll try out the suggestion.