possibility to have heavily tuned VIPS for small JPEG file sizes directly out-of-the-box (see here)
this means file sizes are same as running JPEG optimizers; so you do not need any extra image-size-optimizers.
no image processing anymore in PHP
Benefit: no complexity with async loading
Benefit: faster initial rendering (if not using async loading)
less state to maintain, because we do not need to remember what images + image variants we already thumbnailed.
smaller docker images because they do not need the full VIPS etc stack.
In mid-term, I’d love to support this natively in Neos/Flow core. Unfortunately this needs quite some updates to the internal state handling, mainly decoupling Thumbnail from their backing Resource. So this is still a way to go. It might be also related to RFC: The Media CR .
Imagor Studio
Now, the author of imagor started another open Source Project Imagor Studio, which exposes the (many) image editing options of Imagor to a web UI:
Turns out the author really liked the idea, and started implementing embedded mode. Docs: Embedded Mode | Imagor Studio
Now it’s my turn to kickstart support for this in Neos
Question
Question: Should I try to kickstart this in the new media UI, or should this be done in a separate package? In the long term, I’d love to give this option to our users as part of the Neos core. What do you think?
@sebobo would love to also especially have your input
Thanks and all the best,
Sebastian
/cc @nezaniel because we discussed it in the Neos Sprint in Dresden
UPDATE: as far as I see, the new Media UI does not contain the image cropper, but that is part of the core. Then it sounds more like a custom package for a start, and then integrate this back into the core when we integrate f.e. RFC: The Media CR ?
PS: If anybody wants to join this effort, let me know, that is of course highly welcome
FYI: got a first version running right now At the moment, just opens the editor, and does not report the changes back to Neos. This is the next step, but some work is needed as well for that on the Imagor Studio side.
Thanks for your post and initiative. We are using Imagor in Neos Zebra projects, so not directly from Neos - we just pass a reasonably big image to the Content API and then use this image to apply additional processing in imagor (mostly smaller versions for a srcset).
I also think that processing images in PHP is somewhat outdated, especially performance-wise. And especially in Neos, having all the variants as assets in the database sometimes feels strange, especially if they are just the (otherwise unprocessed) smaller versions of an existing image. However, since Imagor itself is an external dependency and currently it’s still possible to flawlessly use Neos on a simple shared hosting, I would not make this a hard dependency.
Reagarding Imagor Studio:
I would be very much in favor of integrating Imagor Studio. Cropping images in the backend is of course nice, but even CMSes as a service (such as Wix) offer much more:
This would be a good selling point, because it means convenience for end-users.
Regarding the implementation, I think you could consider the current crop editor and Imagor Studio as an abstract concept like an “Image Processor”, so maybe the crop editor could stay, but it can be replaced with the more elaborate studio.
As a side note, there’s a concept for another extension of the image cropping functionality: Focal points. It would be nice if the two goals wouldn’t clash.
thanks for your thoughts, I appreciate them a lot!
I think it was really good back when we started (and served us well for the last many years), but I agree the imagor way has lots of benefits
Good point! at the sprint in Dresden, I shortly discussed with @Nezaniel about RFC: The Media CR - and as far as I understand there is the idea to have a media-focussed sprint sometime in spring 2026. Ideally that’s a good point where we can integrate the different approaches
thx for pushing this topic, from reading the GH discussion and your screenshots this sounds and looks great!
Currently we have distributed the media topic over 3 packages (ignoring the media-browser):
“neos/media” covers anything related to the Asset domain, collections, tags, thumbnails and so on, which can be used by Flow applications and Neos.
“neos/neos-ui” contains all the primary and secondary editors (incl. the ones for the media browser) and the crop.
“flowpack/media-ui” contains the module and alternative secondary editors for listing and viewing.
IMHO the media-ui doesn’t need to know much about the editing part and is currently only interested in assets and image variants. Though I would like to be able to offer some editing on the originals inside the module though, without loosing quality. Also the variant editing is not yet possible in the media-ui (the media browser has a very simple editor). Another aspect could be that the media-ui could offer to optimise originals, as often editors upload simple images with tens of megabytes. But the editors themselves don’t necessarily need to be part of the media-ui, but the media-ui should be able to show them. For that I thought about something like the secondary editor registry of the neos-ui. Maybe even some Flow app wants to have those image editing capabilities.
As you say, it would be great if the thumbnails would allow any kind of backend. It currently already allows an alternative via the staticResource if there is no resource. So maybe it could actually be easier to adapt than expected, as we also have a field for the configuration, etc.. This would also help performance, as the assets and their related entities are a big part of the number of our database queries during rendering.
