[Bug] Image cropper completely redesigned

[manuelkleinert]

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

[github-actions]

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

[manuelkleinert]

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

[robertSt7]

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

[robertSt7]

@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

[manuelkleinert]

@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]

@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]

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

[robertSt7]

@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]

@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.

[robertSt7]

@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?

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[manuelkleinert]

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]

@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]

@manuelkleinert any thoughts from your side?

[manuelkleinert]

@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]

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]

@manuelkleinert friendly 🏓

[manuelkleinert]

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

[fashxp]

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:

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

When now the image cropper is hardly fixed to the aspect ratio of the default thumbnail config, I could select something like:

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:

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:

... 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]

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]

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]

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.

[fashxp]

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 😄

[manuelkleinert]

@fashxp ratio is now removed from image cropper

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[robertSt7]

@manuelkleinert for me the ratio is still there. Could you please take another look? Thanks