Focal point support for images #7901
Replies: 9 comments 22 replies
-
the library smartcrop could be used for this |
Beta Was this translation helpful? Give feedback.
-
Heya! Thanks for opening this feature request! This feature request has received over 15 votes from the community. This means we'll move this feature request to the Under Review state! The Core team will schedule a meeting to review this request as soon as possible. The discussion will then be approved or denied. You may or may not be invited to join this meeting with the core team. For more information, see our Feature Request Process. |
Beta Was this translation helpful? Give feedback.
-
I'm tempted to give this a try and would see the following things on the to-do list for this feature:
Open questions:
|
Beta Was this translation helpful? Give feedback.
-
That’s a good point.Beste Grüße,Nils BaumgartnerAm 01.07.2023 um 18:29 schrieb Lukas Schätzle ***@***.***>:
Before implementing any automatic solution which the user can't control we should have a manual control. (Smart crop may not always identify the right crop the users wants.) After this is implemented, also adding an automatic solution (which can be overwritten by users) by default may be a good idea.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
This is a very clever feature. Beste Grüße,Nils BaumgartnerAm 02.07.2023 um 10:57 schrieb Martin Melcher ***@***.***>:
Some more elaborate suggestions, possibly for a later version:
I've seen clever implementations in some CMSes which do not only store the focal point but also a resizable rectangle around it. The image is never cropped beyond this rectangle. Other aspect ratios try to keep the focal point in the same relative position. If the focal point is in the top left corner of the rectangle, the cropped image first grows to the bottom right, keeping the focal point in the top left corner.
I've also seen the combination of a focal point and a vector in which the image should grow, but I found that both unintuitive for the users and less expressive (no minimal crop).
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
In the past, I've achieved what is being described using Cloudinary, which has a very extensive transformation API, and deals with this (and many other cropping requirements) through an attribute they named 'gravity'. The API reference has a few mentions of how this could be implemented:
I had also dabbled with imgix, which uses a attribute called Focal Point Crop. Cloudinary used X/Y values, which meant I needed to also know the original width/height of the image to do calculations. One thing I don't think I've seen discussed yet above is a relatively important part of the crop -- the 'zoom'. Imo, a friendly custom crop is flexible/chainable mix of the following: Having the existing Directus edit crop tool store those values against the image would be 👨🍳💋. Side note: a much loved/loathed feature I built into the last newsroom media library I worked on was using a gravity of 'face detection' instead of needing to manually specific a focal point :) When it worked, it saved heaps of time, and people loved it -- but the early days also had some interesting results with sports photos, where the auto detected face would be some blurry face in the crowd 😂 |
Beta Was this translation helpful? Give feedback.
-
I believe this has all the technical details in the comments above. I would love to shape this into the RFC template to make sure we can start going to implementation 🙂 (cc @w0kyj) |
Beta Was this translation helpful? Give feedback.
-
@tummerhore The only thing I'm not entirely sure about is focal point returned from the file meta information based on the presets optionally as percentages. How / where would that be used? Isn't that something you can calculate out on the fly when it's needed (f.e. with an SDK helper)? I'm a tad worried about the implications of a generated field that has a different output from it's input 🤔 |
Beta Was this translation helpful? Give feedback.
-
This feature request has been accepted and is queued to be implemented! You can follow along with the progress here: #20838 |
Beta Was this translation helpful? Give feedback.
-
Summary
Original idea by @benhaynes
Motivation & Basic Example
A user wants to display the following image with a different aspect ratio. However, the displayed section needs to be centered around the moon (green rectangle) and not around the center of the image (red rectangle).
Detailed Design
Sharp currently has no inbuilt support for defining a custom focal point, so we have to do the cropping manually. For a simple approach see my comment in the sharp repository: lovell/sharp#2740 (comment)
After the focal point for an image has been changed, all thumbnails need to be regenerated. We can do this by just deleting all generated thumbnails after the focal point change.
If there is no focal point configured, the thumbnail is generated around the center, just like it's the case now. (Basically the same as a centered focal point but we can just keep
null
stored in the database.)UI:
Add a new "focal point" tool to the image editor. After selecting it, the mouse cursor changes to the cross shape and allows selecting the focal point by clicking into the image. Clicking outside of the image sets the focal point to the nearest valid place. The current focal point is indicated by a crosshair (maybe slowly blinking for better visibility) and is only shown if both x and y coordinates exist and are valid. The toolbar shows the pixel values and also allows manual input of the numbers. Trash icon for removing the focal point and AI icon for setting the focal point via an AI library/service (optional).
API:
The assets endpoint returns the focal point information as part of the image meta data.
By default, the coordinates are pixel values. Optionally, we could also support requesting the coordinates as percentages (with query parameter). The preset focal point coordinates are generated on the fly when they are requested so they don't have to be saved to the database. (I'd expect the added latency to be very short.) Same for requesting the coordinates as percentages.
The SDK could provide a helper function to calculate the focal point coordinates for a dynamic transformation request:
Database:
Table
directus_files
needs 2 new columns to store the focal point pixel coordinates (e.g. something likefocal_point_x
andfocal_point_y
). I chose pixel values because we will lose precision for big images if we choose to save percentages.Requirements List
Must Have:
Should Have:
Could Have:
Won't Have:
Alternatives
Currently, you could provide focal point information via image tags, description or a custom field and use that to crop the image manually in the frontend. But then you can't use Directus' inbuilt thumbnail generation and it's more a hack like a real alternative.
Adoption Strategy
As a migration strategy, do not set a focal point for all existing images. That way, this would be no breaking change and exisiting thumbnails would not have to be regenerated if the focal point is not changed by the user.
Beta Was this translation helpful? Give feedback.
All reactions