Provide needed image meta data for responsive images in listings / preview images

[MrTango]

As just discussed with @pnicolli @giuliaghisini and some other people here in bucharest, we need a way to provide needed meta data like image width, height, scale url and so on to render the images in listings on the frontend side.

This should be non-breaking and opt-in.

I have two ideas how this could be archived.

1. Adding a service endpoint which will provide the meta for all images of the listing and using it with expand when ever we need preview images in a listing.
2. Integrating the meta data directly into the serializer of the listing, when ever we ask for it via request parameter like previewimages=1 or image_metadata=1.

The second option would be the cleanest for the front-end to consume and should break nothing, as is would be opt-in via request parameter.

What do you think?

@tisto @sneridagh @avoinea @datakurre @thomasmassmann

[MrTango]

also related issues are: #939 and PR: https://github.com/plone/volto/pull/2103

[datakurre]

@MrTango What are "preview images" in this context? I listened to the discussion, but seemingly missed that.

[datakurre]

Obviously, there are possible performance issues. I'd guess, listings are currently based on catalog (until "fullobjects" are requested). But images sizes are not indexed, and neither are image scales. So, resolving scales would require reading that directly from the objects.

On the other hand, we do have https://github.com/plone/plone.outputfilters/blob/master/plone/outputfilters/filters/resolveuid_and_caption.py, but result from that is probably cached on Plone Classic (I recall that was part of portal transform, using its volatile cache).

[MrTango]

@datakurre the preview image is a special image field on some objects, similar to leadimage as i understood. So instead of having the frontend trying to lookup first the preview image and if thats not set falling back to the image field, the backend could do that already.

Yes excactly, in classic ui we use the output filter, which are cached for a day or so or until restart. So the same could happend for the backend part in rest-api to not recalculate everything. But as i understood, in Volto you normaly use the special flag to at leas have the scales already precalculated at that point, so the work to be done is a bit less than in classic ui.

[cekk]

@datakurre @MrTango we discussed about that here too with @jensens and @ericof and we come up with a proposal. I'm going to open a proof of concept soon but in two words:

We add a new catalog metadata "images". In that metadata we're going to store a PersistentObject with the list of all available scales (and other needed informations) for each image field of the content.

When the consumer asks _all or that specific metadata, it gets an object with all the scales without having separate endpoint calls, waking up objects, etc.

[MrTango]

ok thx for the update, please provide the details as soon as possible. If we add a lot of metadata in core via rest-api, we need to think twice about if it too much. Or is the plan to add this to the catalog in plone.volto?

[jensens]

Plan is in short: Add a PersistentDict to metadata (so it is only loaded from db if accessed) to keep the footprint of a loaded brain low.

[cekk]

First implementation here: https://github.com/plone/Products.CMFPlone/pull/3521

[datakurre]

@cekk @jensens Very nice solution!

[mauritsvanrees]

This was implemented. Is anything left to do? There may be more places where the metadata can be used, but @davisagli probably fixed the most important ones today in https://github.com/plone/plone.restapi/pull/1498 Closing. Feel free to reopen or add a new issue.

[davisagli]

@mauritsvanrees #1498 took care of using the new approach when serializing an image field. We also need to add the image_scales catalog metadata to the summary serialization so that it is available in query results, and actually make use of it instead of the old scale URLs when rendering images in listings.