search

torchbox / wagtailmedia

A Wagtail module for managing video and audio files within the admin
https://pypi.org/project/wagtailmedia/
BSD 3-Clause "New" or "Revised" License
233 stars 70 forks source link

Animated gif type image sequences #127

Open thenewguy opened 3 years ago

thenewguy commented 3 years ago

Do we want to offer support for animated images? I.e. having a dedicated type like audio and video.

It is the same concept as silent video except templating would ideally be using an animated image format and the picture element to avoid autoplay issues associated with the video element

zerolab commented 3 years ago

I wonder how is this different from the Wagtail Image support for animated images?

thenewguy commented 3 years ago

This app is a better fit than wagtailimages for animations when the animation is the defining feature of the visual content. Conceptually these are more video than image and fit in with the tooling and concepts of wagtailmedia. We are really mainly just talking about a “type” here to distinguish the playback and display charactaristics of the animations from more typical video and audio media content.

The idea of adding the “picture” type is for categorization but also supported playback features. The problem is that browsers disregard video autoplay in certain scenarios. This means <video/> isn’t reliable for an animation that should always play on page load. However, the browser autoplays animated images by default without requiring user interaction. As such, it is desirable to present these animations as an “image” in an animated image format like gif/png/webp.

Wagtail’s image app is based around filters that manipulate the image in different ways. Unlike typical static images, these types of animations are meant to be included on the page as-is and only scaled proportionally with css client side if required – just like a video. You can’t just pick an animated image from the chooser panel and drop it in a page unaltered because image filters are applied to any image passed to the template. Filters like “fill-*” can remove important parts of the animation.

There is also the issue of speed – when applied to animated images, the filters can be unexpectedly slow. Since filters in wagtailimages typically happen at time of render, this can be problematic.

I have had a better workflow experience using these types of graphics with wagtailmedia than wagtailimages. However, since there isn’t a “picture” type to distinguish animated graphics I have used video formats. Being able to check for an animated graphic type in templates for a different element than audio/video would make this more widely usable.

zerolab commented 3 years ago

@thenewguy https://github.com/wagtail/rfcs/pull/71 would probably fill that need. Could you have a look and provide any comments?

thenewguy commented 3 years ago

I just read the document on my phone. I didn't see anything specific to animated images. It was my understanding that it intends to simplify multiple renditions of the same image using the picture element or srcset. Since it is still using the image handling api in wagtail that is optimized for single frame images, I don't think it will fix the difficulties with animated images