Integrate automated cropping tools

We could perhaps incorporate this functionality within image_widget_crop. With specific imageStyle Like "automatic crop", we could also think a submodule that provides this functionality within IWC. CropAPI must remain exclusively used for data storage. IWC serves them and return them used based on the imageStyles.

Yup. In general I'd like to keep modules in media ecosystem focused on one task. Make them do just one thing and do that well.

Yes i think we can create a module (image_smartcrop) that this plug on IWC and add a suitable configuration (enable automated crop) on widget element or form element. This idea is quite possible that once in place @see https://github.com/drupal-media/image_widget_crop/pull/1 functionality.

I think we can postponed this and re-open after when we have this form element available to work on this. This is an beautifull idea this module and he can simply our life :D

I agree about separation in general.

Note however that the optimum user expectation is different:
- The system should offer a feasible / intelligent default cropping
- If i'm not happy with it, i can override it

Thus, if image widget crop is used and no cropping is applied, an automated cropping determination should be able to ship a fallback.
With just two separate modules, this is not possible.

As a result, it's nor per image style / effect nor per crop type.
If it was two image effects, the manual crop would need to skip its default cropping (new option). And even if we have this option and use this stack, then we can not show the intelligent default cropping selection when editing cropping.

I agree of that @miro, I think we have a strong demand of that feature in IWC too / crop, I think this feature do be ported by IWC (or other module implement Crop API). Crop API do only provide storage entity and an simple effect to apply on images, all other feature do assumed by module interface eg IWC. With IWC that feature is simple to assume @see #2810861: Automatically apply pre-selected crop types on node/media creation

I think this issue is an duplicate to #2750041: Force default crop to be applied || #2810861: Automatically apply pre-selected crop types on node/media creation we need to clarify what module assume that feature in one and centralised location (I vote IWC).

After few discuss with @slashrsm we have decide to create an decoupled module to support all Automated cropping tools cases. That can be consumed by Crop api etc... as a service totally separed of Crop stack.

I purpose to continue discuss on support request issue.

@slashrsm : it's better to switch this issue to "close" ?

Thanks all :)

This subject can be verry Fun and usefull to continue anyone need to continue this here and/or via #2830768: Automated crop integration ??

I mark that issue as Major now because that one on most important feature to have in Crop ecosystem now ! Anyone interested by this subject can go with @slashrsm and me to continue to found better solution for Crop API ? https://www.drupal.org/project/crop/issues/2830768#comment-11800311 I really need more time/ressources to continue that but I don't leave this subject before finished it !!!

Here some thoughts: We analized how to standardize media management and ended up managing classes of images.
The bundles of image types (JPG = Photo, PNG = Screenshot) are a good start until you figure out that your PNG contain multiple classes (PNG = Screenshot OR Logo).
Also the Photo has clearly various use cases we should analyze further. For instance an image that is made for a Hero background (typically JPG) has a completely different nature from a typical object teaser or main media image of an article.

The cropping strategy highly depends the image class.
For instance we
* use focal point for JPG, works well for object article images, hopefully works well for Hero, doesn't work well if you have an object image with two people (one left and one right). So it's too much simplified to only rely on that type.
* do never crop Screenshots. Or maybe put the focal point to the top, so they are cropped in the scrolling area below. Our first rule was to always scale screenshots into the bounding box.
* do never crop logos, always scale

The most simple starting point is to focus on one class such as the single-object JPG and determine a focal point if it is clear.
I remember that some automation tool reported stats that they are able to auto-optimize 95% of the images. They do color + saturation and cropping. However IMHO the problem is not that 5% are bad.

IMHO we should not strive for 100%. Instead we should strive for the best hybrid approach. First that starts with determining automation quality - so it can report if the auto-optimization thinks it worked. And it then should interact with the user if it didn't. Such a call for action can be while uploading or maybe later through a queue where you review the processing results. I've seen such a review UI also for AI based autotagging, where you see proposals and you basically just go through the queue and accept... or maybe extend if you're not happy.

Hi 👋 @miro

Great to see you here !! I’m totally aggree with your opinion ! Focal point approach are too simple and minimalistic like the « automated crop » but that’s the first step to build an api to analyze the problem and see where’s is the best place to analyze pictures. IMHO on upload is the best place but for user processing a bulk operation or multiple upload we need to thinking if that kind of behavior need to no processed in queue.

The automated crop module in my brain is only an interface to send image to google vision api and retrieve all the result of image to purpose a crop for given image. If the result isn’t satisfied for user feel free to change that but we need configurations to adjust what kind of subject we need to crop (face,object,landscape...) ? This kind of configuration can become big and scaring :D

In first thing @miro you think automated crop API can be used as base to be interfaced with api (IA) and provide an adapapter for crop api or custom api to be more flexible (like à library) ? Or we do think to change the strategy for that ? I’m open to do everything but having a more separation of things as possible sound good to me ! Crop api does communicate with other service specialized to image analysis to parse image and then crop subjects after with crop api.