Support Animations via GIF/APNG

[whatnick]

datacube-ows version: master
ows_config.py version/link:: any

Description

There have been a couple of feature requests so far to support animations on demand via WMS getmap requests. Most recently from @valpesendorfer and @GypsyBojangles .

The options for output format are:

• animated gif : can be generated using Pillow, 8 bit paletted only
• animated PNG : more flexible than gif. Also consider
  https://github.com/eight04/pyAPNG

Support requires (but not limited to)

• New output format request parameter support
• Guard rails to limit time steps fetched for animation for reasonable render time
• Publishing new output format in getcapabilities
• Double checking animation format support in client software and documenting limitations #668
• Actual render code from the datacube Xarray to animated image formats.

What I Did

Collated various internal discussions and Slack messages into this issue one morning early in Narrandera.

[robbibt]

Animated PNGs are great, but good to keep in mind that they aren't supported by most social media (which is likely to be one of the main applications for animations):

https://www.macrumors.com/2019/12/24/twitter-bans-animated-png-image-files/

MP4 would be another really useful and file size efficient format.

[SpacemanPaul]

1. Animated PNGs are backwards compatible with regular PNGs, so a non-supporting client should simply see the first frame of the animation.
2. Most WMS queries would only return a single unanimated frame anyway.
3. We can't simply animate all multi-date requests, as we already have a style-specific configuration for multi-date requests (currently used for "delta" two-date difference styles).

I would therefore probably not bother initially with adding animated PNG as a separate image format type - I would just have the user request a PNG as normal, and let the details of the query (and the relevant config) determine whether the output is animated or not.

The complexities mostly arise from existing assumptions in the multi-date handling code that would need to be wound back. Most importantly we would need to change the internal API for the aggregator function to allow it to return a dataset with a time dimension, and for the PNG renderer (currently the only renderer for WMS/WMTS) to render an animated png when passed a dataset with a time dimension with length > 1.

[SpacemanPaul]

So by reckoning:

[x] New output format request parameter support not needed for APNG
[x] Guard rails to limit time steps fetched for animation for reasonable render time already supplied by multi_date API.
[x] Publishing new output format in getcapabilities not needed for APNG
[ ] Double checking animation format support in client software and documenting limitations. backwards compatible with png

I've spoken to Terria team. They don't currently support animated pngs but it wouldn't be that hard. If we implemented it, there's a good chance someone on the team would do it for the the sheer joy of it. No idea about any other clients. But everybody will at least see the first frame, because of the backwards compatibility with regular pngs.

[ ] Update internal API contracts between image renderer and aggregater functions.
[ ] If we want to support more than say 3 or 4 frames, we should extend the resource-limiting logic. 10 frames is 10 times as much data, so should be hitting the zoom limit 3 times earlier.

[SpacemanPaul]

I think the trickiest bit will be mask handling. The styling API always flattens mask in the time dimension.