[Feat]: sharp support for animated webp/gif

[polarathene]

Summary

In an upcoming 0.26 release of sharp, support for animated webp and gif will be available.

Motivation

gatsby-image doesn't presently support animated images and advises using plain <img> instead, but that was due to a limitation with support in sharp.

A related doc on gif usage also raises awareness regarding autoplay, while this article shows how the picture element can use a media condition to present a static image if the user has preferred reduced motion.

There's also some code in gatsby-transformer-sharp that may need to be updated should this feature be added.

[wardpeet]

Thank you for creating this feature request. I'm not sure we should add an animated gif/webp as it has a performance impact and could lead to a battery drain. If we want to hold up to our "performance"/accessbility value we should convert these gifs into video format.

More info https://web.dev/replace-gifs-with-videos/

Open to thoughts / ideas

[polarathene]

I'm not sure we should add an animated gif/webp as it has a performance impact and could lead to a battery drain.

That would be up to the developer and to a degree the browser. We can add support for the reduced motion preference, I assume that browser software on mobile could optimize for that when they see fit, like they do with other network activity, native image lazy loading, and support for dark/light theme matching the system OS preference.

Docs can continue to advise/caution against such, but if a user is going to ignore that and manually reach out for img directly as is the current advice in the gatsby-image docs, there is no negative consequence of this feature. If anything, the sharp optimizations that other image types benefit from when using gatsby-image and us adding the reduced motion support (just another media condition as alternative source selection in picture), we're actually helping developers utilize Gatsby to deliver a better experience.

For those that actually take more time to read the docs, if they'd want to go through additional effort to switch to video as we can advise, great.

If we want to hold up to our "performance"/accessbility value we should convert these gifs into video format.

That's a bigger effort to support, introduces additional maintenance effort and complexity where more could go wrong?

It'd be wiser to raise this as a warning in gatsby develop CLI and browser console output, probably wouldn't hurt to report it as some summary line at the end of a gatsby build either.

I am well aware of how bad .gif can be when done carelessly. I help support a reasonably large(1k+ MAU) community-driven content site. Some users had uploaded incredibly large GIF files, the developer of the feature had no check for a file size limit, I believe a few exceed over 100MB..

If we stick to animated image formats which would suit gatsby-image, it can continue to benefit from using the existing component and the picture element. If it were to support video, it'd be more of a gatsby-media component?

Here is a insightful article comparing GIF, APNG, WEBP and MP4/WEBM. A ~40MB GIF becomes a ~30MB WEBP, but with quality settings can be lowered down to ~5MB. That's still quite a bit, although it does depend on the content/frames for how well the data can be optimized. The MP4 optimized is only ~500KB and the WEBM a mere ~200KB. GIF was optimized down to ~20MB in a related article.

Not against the conversion, but probably shouldn't be implicit. It'd be easier to just go with the animated image support for now, and consider conversion and <video> element for the v3 rewrite with hooks?

---

TL;DR

• Easiest to support just animated image formats for now and advise using video MP4/WEBM formats instead via the docs.
• We'd still be providing a better UX via sharp + gatsby-image optimizations vs what a user may do presently as an alternative(just use <img>.
• Conversion to MP4/WEBM would be great if explicitly opt-in. I'd advise delaying that to v3, or implementing as a separate plugin + transformer + component.

[polarathene]

Version 0.26 of sharp has been officially released if anyone wants to tackle a PR for this.

[han-so1omon]

I'd like to hop on this one. Will do some research and report back

[polarathene]

@han-so1omon sorry if you've dived into this already, there will be a blocker with resizing animated images: lovell/sharp#2275

Apparently for now it can be done with an explicit pageHeight option.

You may also find that at least for operations on .gif files, the pre-built binaries for sharp will not support it as mentioned in the docs, which seems like they expect a local copy of ImageMagick or GraphicsMagick available, which complicates making that easily available to Gatsby users. Probably would require something like how MozJPEG support is provided.

Perhaps though, the MP4/WEBM route would be better in that case, but not being able to leverage existing sharp plugin support is probably going to make that more difficult/effort to integrate with Gatsby's build stage.

[github-actions[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here.
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[polarathene]

not stale

[github-actions[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here.
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[felpsio]

I'm needing this feature.

Currently using "gatsby-transformer-sharp": "^2.5.18", and my animated webp doesn't keep the animation after the transformation. Is there any additional config necessary to keep the animation?

[nkuehn]

Hi, I'm here because we would appreciate animated lossless image formats a lot.

Concerning "should all be video format": I agree that 95% of the animated gifs of the world would be better stored as WebM / MP4. But just like authors have to deliberately choose between PNG and JPEG (lossless / lossy) for good reasons that choice is important for content like screenshot sequences too. Screenshots of Software and web UIs are effectively line graphics, often with hair lines and they are simply not a good fit for video formats. I do not think the site generator should prescribe the usage of lossless vs. lossy media format choices. Whether something is a good practice, accessible etc. can only partially evaluated in technology. Defaults and accessibility / performance warnings are important here (e.g. no looping, maybe no animation support without a config flag at all), but the tech stack is still a tool and not the author.

Concerning gif vs. apng vs. animated webp: It could be considered to only (or at least first) bother about WebP here.

• The limited color palette of Gifs will always make the output awkward and the generator could be blamed for bad results. Plus, needs a customized libvips which will make the existing DX issues with libvips worse.
• Animated PNGs are only half-specified afaik (multiple frames OK, but the actual frame transition and sequence is not really a spec) and the file size is not convincing.
• WebP offers a proper spec, now-good browser support and good file sizes plus sharp/libvips support (and is not further complicated by having to be retained through pngquant and sharp but just sharp).

Initializing sharp with animated: true or frames : -1 and passing the metadata height as pageHeight if the metadata frames is > 1 sounds feasible to me independently of sharp intending a nicer more explicit API for the use case, so I don't consider the linked sharp issue an actual blocker. This seems to be rather blocked by "Do we want this?", "Do we want gif, too?" and "Do we want this automatically or behind a config flag?".

[polarathene]

The limited color palette of Gifs will always make the output awkward

It depends, it's not always that bad and can be a valid option when you need it without better alternatives available to use.

Plus, needs a customized libvips which will make the existing DX issues with libvips worse.

That hasn't discouraged supporting other features depending on binaries in the past, mozjpeg comes to mind IIRC depending on platform (libvips was a bit of an issue back then too though).

WebP offers a proper spec, now-good browser support

Support in Safari is very recent(also requires latest macOS from this year to use, iOS also only the latest).

IE (including Edge before the switch to Chromium base) might also be somewhat important, as small of a demographic it can be to many, depending on industry/region it's sometimes a requirement to support still and Gatsby tries not to "break" when it's possible to support fallbacks.

It might surprise you, but we've had things like TLS 1.2 since 2008, which was more broadly available to deploy around 2012-2014. It's only in 2020 that previous protocol versions have been deprecated by browsers, with mail servers due to different environments they lag a bit more behind still. Apple had TLS 1.2 support with iOS 5 I think, but only for HTTPS, other protocols like SMTP and IMAP with explicit and implicit TLS didn't receive that until iOS 9 (2015), yet there are users still stuck on that (including some on Android 4.x where TLS 1.2 even for HTTPS lacks).

---

It could be considered to only (or at least first) bother about WebP here.

Sure 👍

Something is better than nothing. If it turns out to be easier to implement just for WebP, but someone has to put in the time. Since it'll be tailored to Gatsby, we may have to wait until it's prioritized by a paid developer being assigned.

[nkuehn]

Thanks for the response @polarathene ! You caught me a bit on my learnt objection to gifs, until July 2004 you were sued for it so that seems to still be in my mind.

Also, I did forget to give enough context to the "don't convert to gif": I don't think that original files in animated WebP or PNG should be converted into animated gifs for browser compatibility reasons (the color range is restricted, even with optimizations). But if the author provides an animated gif it would be good to keep it in gif format if the necessary library is provided. Like today, WebP original files stay being delivered as WebP files in the built site even without explicitly setting the webP option to true.

we may have to wait until it's prioritized by a paid developer being assigned.

Anybody can provide a PR but I agree it would be good to have positive feedback on the conceptual approach from a gatsby staff member before putting work into it.

[petercampanelli]

Need something like this. There is some crossover between this discussion and #29410 which discusses gifs. One thing I would also need is a format supporting alpha channel which mp4 does not. I have a project where the designer has given me .mov files with transparency and the current solution is to just convert them to gifs which will increase the file size quite a bit.