Support disabling/limiting use of image renditions

It would be useful to be able to disable or reduce the usage of image renditions, at least for certain images.

Some images (mainly large animated GIFs) can cause problems with Willow/Wand and fail the rendition step. This is not a Wagtail issue per se, but there’s no way to avoid invoking those libraries even if you only need the original-sized image that you uploaded. Without #929, there’s no way to decouple revisions from Wagtail page loads (for example generating them offline using a different library).

The rendition process also invokes Willow to open and then re-save images even if you only ever want to display the 'original' rendition. This can be suboptimal if, say, users want to explicitly prevent any kind of recompression from occurring to uploaded files.

It would be nice to be able to configure Wagtail to always link to the original image when an original or resize-only operation is requested (DoNothingOperation, MinMaxOperation, or WidthHeightOperation). The {% image %} template tag could still generate the appropriate width and height parameters in the <img> tag, so that images would display at desired sizes (for example as thumbnails on the image browse page).

Here’s a workaround that uses a custom image model that overrides get_rendition to skip renditions for all GIFs (here it is as a PR to give a little more context). This required a few hacks, for example because image operations don’t easily expose their resizing logic independently from actually applying it.

If there’s interest in a feature like this, I’d be happy to submit a PR. One detail to discuss would be level of configurability, i.e. site-wide via setting vs. per-image type vs. per-image (maybe a “disable renditions” checkbox in the admin upload).

[tomdyson]

@chosak are you still interested in submitting a PR for this? We would welcome your help.

[gasman]

You’ve touched on it, but I think it’s worth pointing out that passing images through Willow, even with the ‘original’ filter, is not universally a bad thing - it can potentially apply optimisations, reduce JPEG quality settings to the global default, and strip EXIF metadata, which are all important if you’re chasing Google PageSpeed scores… having distinct ‘original’ and ‘raw’ filter types may well be the answer to that.

It strikes me that there are a couple of other strands of work potentially related to this:

• #1708 (support for SVG images): similar to this in that it’s an image type that needs to bypass the whole ‘renditions’ paradigm
• Not currently a ticket, but something that’s been discussed in chat: the ability to set size constraints on a selected image (e.g.: the photo on a PersonPage must be at least 400x300). This is a tricky thing to approach, since it risks tying page content too closely to a given page design.

For the latter, we considered introducing a concept of distinct “image types”, which would be defined either in the settings file or at a per-app level (possibly in models.py or wagtail_hooks) - ImageChooserPanel and ImageChooserBlock would then allow limiting the available images to one type. Possible business rules to be specified through image types might include, for example:

• Partner logo: must be a PNG sized at least 300x150, or SVG
• Staff photo: must be a JPG sized at least 400x400; user will be prompted to select a square crop of the image on upload; we will pre-generate 400x400 and greyscale 200x200 renditions of the image
• Hero image: Any format, must be exactly 1000x400; templates may only use this with the ‘raw’ image filter to prevent recompression
• Animation: must be in GIF format, any size; templates may only use this with the ‘raw’ image filter to prevent recompression