Allow processors to generate multiple images

Problem/Motivation

Currently a processor is sent a single $temp_image_uri and returns success or failure. In some cases, it may be desired behavior for the processor to create a copy of the file. In example being cloning an uncompressed JPEG into WebP format, before additional compression occurs to the JPEG. You could then tie all the pieces together by having a pipeline that looks like:

- WebP (accepts other formats and generates WebP copy of image file)
- Krakin (for jpg and png)

The responsive image module can then be responsible for making WebP images available for browsers that support it.

Because this module takes over the ImageStyle class, I've been unable to really find another way to do this. Especially because we want WebP to be able to act before any other quality/compression takes place. There is work being done to make WebP be supported in core, however until it has full browser support(and OS for that matter), we'll probably be converting from other image formats for the foreseeable future.

Proposed resolution

The easiest way this could be done is just providing an event or hook within Drupal\imageapi_optimize\Entity\ImageAPIOptimizePipleline::applyToImage:

if ($image_changed) { // Copy the temporary file back over the original image. file_unmanaged_move($temp_image_uri, $image_uri, FILE_EXISTS_REPLACE); }

And then just let the submodules take care of the extra behavior. However, we could go further and actually create multiple image handling, but that might open an entirely new can of worms.

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Comment 3 months ago →
🇬🇧United Kingdom Driskell
The approach by @larowlan seems very useful to me, as it means existing modules are unaffected and new ones can receive additional information via the new interface. Over time perhaps some more helpers can be added for moving temporary files too but this would be a good start and works great for me.
Comment 27 days ago →
🇺🇸United States michaellander
I thought this was interesting: WebP fallback image → .. Their argument is that we aren't gaining the full benefits of compression with modules like ImageAPI Optimize Webp → because we aren't compressing from the source file. My original rationale was to avoid running images through image style processors multiple times(once as jpg, once as webp, for example), though that wouldn't matter so much if it's only running it through the image style as it's being requested for the first time. I think it's also more and more likely that people will favor AVIF with a WebP fallback, and almost never want to keep the original file format if JPG, PNG, etc..

Perhaps finding a way where we would no longer need to do the derivative handling at the imageapi_optimize level, and let optimize just worry about optimization.

I haven't looked at this stuff in awhile and will try and get caught back up.

Allow processors to generate multiple images

Problem/Motivation

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Comments & Activities