Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Image cropper completely redesigned #576

Open
wants to merge 4 commits into
base: 1.x
Choose a base branch
from

Conversation

manuelkleinert
Copy link

@manuelkleinert manuelkleinert commented Jun 20, 2024

Image cropper completely redesigned with consideration of thumbnail sizes and several bug fixes.

  • Takes into account the minimum size of thumbnails and dimensions.
  • Selection no longer goes beyond the window size
  • Support of different thumbnail types

In order for the dimensions of the thumbnail to be taken into account in the cropper, the thumbnail must also be defined in the Image Editable

Copy link

github-actions bot commented Jun 20, 2024

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

@manuelkleinert manuelkleinert changed the title image cropper completely redesigned with consideration of thumbnail s… [Bug] Image cropper completely redesigned Jun 20, 2024
@manuelkleinert
Copy link
Author

I have read the CLA Document and I hereby sign the CLA

@robertSt7
Copy link
Contributor

Hi @manuelkleinert the actual bugfix branch is 1.4. Could you please change the base branch to 1.4? Thanks

@manuelkleinert manuelkleinert changed the base branch from 1.x to 1.4 June 21, 2024 10:07
@herbertroth herbertroth changed the base branch from 1.4 to 1.5 July 2, 2024 12:13
@robertSt7 robertSt7 self-assigned this Jul 12, 2024
@robertSt7
Copy link
Contributor

@manuelkleinert Thanks a lot for re-basing. The PR looks really good, just one small thing. There is a minimum width when resizing the selection. Could you please fix this? Thanks
image

@manuelkleinert
Copy link
Author

manuelkleinert commented Jul 18, 2024

@robertSt7 We have intentionally implemented this so that the image cannot have a lower resolution. Alternatively, we could allow this and simply colour it red with a warning notice.

@robertSt7
Copy link
Contributor

@manuelkleinert That's a good idea, please implement that and could you please also re-base the PR to 1.x? Thanks a lot

@manuelkleinert
Copy link
Author

@robertSt7 The image cropper now allows smaller selections but displays a warning

@robertSt7
Copy link
Contributor

@manuelkleinert Thank you for that. Could you please remove the aspect of ratio enforcement too and display just a warning? Also please change the base branch to 1.x, since this is an improvement. Thanks a lot

@manuelkleinert
Copy link
Author

@robertSt7 The ratio of the images should be maintained, as they should be cropped in proportion and not distorted. For us, it makes no sense to remove this.

@manuelkleinert manuelkleinert changed the base branch from 1.5 to 1.x August 6, 2024 13:04
@robertSt7
Copy link
Contributor

@manuelkleinert When you use it in DataObjects you can actually crop your image with every proportion and the rest is filled up with a white background. If we merge this, this function will not be available anymore. And what happens if you have different proportions in media queries?

Fixed a bug in the cropper, if it has no height, it is defined as 100
Copy link

sonarcloud bot commented Aug 29, 2024

@manuelkleinert
Copy link
Author

I have also fixed a bug with the default height when it is not defined.

@robertSt7 With the data objects you can freely choose the area, since no thumbnails are defined there or am I misunderstanding something? If the section can be larger than the image, I would have to make the window larger than the image.

@fashxp
Copy link
Member

fashxp commented Aug 30, 2024

@manuelkleinert Sorry for being so picky about this one. We really like your ideas and your work 😍 .

We see an issue though with the hard limit of the aspect ratio.
The problem is not limited to data objects, it is also existing with documents. For example take the portalCarousel thumbnail definition of the demo. There you see, that for different media queries, the thumbnail definition has different aspect ratios and with cover and focal point Pimcore tries to include the most important parts of the provided image (area).
So there are use cases, where it makes sense that the editor chooses an image area with is not exactly the aspect ratio of the thumbnail definition.

I see two ways we could tackle:

  1. also just show a warning when choosing another aspect ration that the thumbnail (our preference)
  2. make the behavior configurable in the image editable (will be a bigger change)

@fashxp
Copy link
Member

fashxp commented Sep 16, 2024

@manuelkleinert any thoughts from your side?

@manuelkleinert
Copy link
Author

manuelkleinert commented Sep 16, 2024

@fashxp Sorry I don't have time to work on it right now, only in 2-3 weeks.
The image cropper is defined on the original image and not on the various responsive media sizes. The cropper does not have much influence there.

@fashxp
Copy link
Member

fashxp commented Sep 16, 2024

The image cropper is defined on the original image and not on the various responsive media sizes. The cropper does not have much influence there.

what do you mean by that?

@fashxp
Copy link
Member

fashxp commented Oct 18, 2024

@manuelkleinert friendly 🏓

@manuelkleinert
Copy link
Author

Could you make me some printscreens where exactly the problem might appear in the object?

@fashxp
Copy link
Member

fashxp commented Oct 18, 2024

As I tried to outline above, it is not limited to data objects. The situation I'm concerned about is also valid for documents.

let's say, I have following thumbnail definition:
image

with max-width: 320px having a completely different aspect ratio, because my mobile design looks different.
image

When now the image cropper is hardly fixed to the aspect ratio of the default thumbnail config, I could select something like:
image
This would result in having selected the car nicely for the default thumbnail, but for the max-width 320 thumbnail, I would not be able to get the whole car.

If I would select a big enough area that one can crop a square with containing the whole car (for the smaller thumbnail), it would look somehow like that:
image
This would result for the bigger thumbnail to loose its focus on the car.

What I actually would need to be able to do in that case is selecting a more square-like area like:
image
... which is of course a different aspect ratio that the default thumbnail and would not be possible with that change any more.
But now in combination with a focal point, Pimcore would be able to generate two thumbnails showing the whole car and keeping the focus on the car.

Does that make sense to you?

@manuelkleinert
Copy link
Author

manuelkleinert commented Oct 22, 2024

If I determine the max height and max width of all the different sizes, we could use these for the image cutout, right? And I could also deactivate the aspect on cover.

@fashxp
Copy link
Member

fashxp commented Oct 22, 2024

If I determine the max height and max width of all the different sizes, we could use these for the image cutout, right?

What do you mean with that?

And I could also deactivate the aspect on cover.

I'm not sure, if it is worth the complexity (from implementation perspective as well as from user perspective when aspect ratio is fixed, when not).
Would it not better to just show a warning when aspect ratio is different that the default thumbnail? Or allow activate/deactivate aspect ratio fixing in the cropper window via a checkbox or something?

@manuelkleinert
Copy link
Author

If we have several breakpoints (940, 720, 320 px), and these have different covers.
e.g.
200x300px
400x200px
800x100px

We could use the largest width and height.
This would now be 800x300px.

377807701-491a1e5e-cd93-4c0b-a0d0-119adddb870d

Copy link

sonarcloud bot commented Oct 22, 2024

@fashxp
Copy link
Member

fashxp commented Oct 22, 2024

Hmm, the original image could be much bigger, like 5000x2000px. So the restriction for 800x300px is not applicable, and even the aspect ratio 8:3 is not really of an value here, right?

Let's try not to complicate things too much 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants