Bug #72318

Epic #77810: Improve (responsive) image handling

Image Manipulation on Portrait images - wrong display in frontend?

Added by David Hoeckele almost 4 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Frontend
Target version:
-
Start date:
2015-12-18
Due date:
% Done:

0%

TYPO3 Version:
7
PHP Version:
5.5
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

I recognized a strange behaviour on image content elements + image manipulation with portrait images (landscape works like a charm)

Example:
I have an image content element with 3 images per row, all of them cropped with 1:1 ratio. (see Image_Manipulation_BE_1.png / Image_Manipulation_BE_2.png / Image_Manipulation_BE_3.png)

In Frontend all images are rendered in different ratio / height, see Image_Manipulation_FE.png

Testet on TYPO3 7.6.1

Any advice?

Image_Manipulation_BE_1.png View (340 KB) David Hoeckele, 2015-12-18 12:07

Image_Manipulation_BE_2.png View (431 KB) David Hoeckele, 2015-12-18 12:07

Image_Manipulation_BE_3.png View (320 KB) David Hoeckele, 2015-12-18 12:07

Image_Manipulation_FE.png View (175 KB) David Hoeckele, 2015-12-18 12:07

200x300-result.jpg View (150 KB) Jan Perdoch, 2015-12-21 22:29

Zrzut ekranu 2017-01-04 o 11.53.58.png View (248 KB) Rafal Brzeski, 2017-01-04 12:41

Zrzut ekranu 2017-01-04 o 11.41.20.png View (74.1 KB) Rafal Brzeski, 2017-01-04 12:41

Zrzut ekranu 2017-01-04 o 11.43.24.jpg View (94.7 KB) Rafal Brzeski, 2017-01-04 12:41

Zrzut ekranu 2017-01-04 o 11.53.43.png View (89.9 KB) Rafal Brzeski, 2017-01-04 12:41

Test.zip (159 KB) Rafal Brzeski, 2017-01-04 23:19

History

#1 Updated by Frans Saris almost 4 years ago

  • Status changed from New to Needs Feedback

What do you use to render the frontend? CSS_styled_content, fluid_styled_content or something custom? What are the settings for alignment, columns etc of the content element? Try setting it to 1 column aligned top center to see if fe ratio is then correct.

Gr. Frans

#2 Updated by Jan Perdoch over 3 years ago

Same issues. Version 7.6.1 and 7.6.2, CSS_styled_content. Setting is 1 column aligned top center. Changing of setting has no impact on crop result. It's correct after crop in BE, but shifted after save. Only for portrait images.

#3 Updated by Frans Saris over 3 years ago

So also in the backend the cropping is wrong after save? Also in the cropper window when you re-open it after save?

#4 Updated by Jan Perdoch over 3 years ago

Yes, in the backend the cropping is wrong after save. In crop editor still shows correctly cropped area. But - when I open image in desktop editor and use values from crop editor (x,y,w and h), it's same wrong cropped image, as after Save in backend. I CAN'T crop it as I want in editor.

But, when I'm trying different portrait image - on the same page, in the same content element, behavior it's completely different. I created matrix 200x300 with 50px squares. I'm attaching screenshot of result: crop (100x100 from point [50,50]), save and open again. Cropped image is correct, but in editor is wrong area and start point. I CAN crop it as I want, in this case.

I took the third test, and it seems to be same as in the second. Correctly cropped, but wrong in editor in the next editation.

#5 Updated by David Hoeckele over 3 years ago

Sorry for the late response.

We're using css_styled_content, images are aligned top left, 3 images per row.
Switching it to top center alignment, 1 image per row, the ratio-problem still persists (as Jan Perdoch already confirmed)

#6 Updated by David Rellstab over 3 years ago

Same Problem here (Version 7.6.6, CSS_styled_content). Thumbnail correctly displayed after cropping, but after saving the crop is shifted (sometetimes more, sometimes less, depending on the crop position you intened). If I don't move the initial crop position (center) it works as expected.

#7 Updated by Riccardo De Contardi about 3 years ago

  • Category set to Frontend
  • Status changed from Needs Feedback to New

#8 Updated by Frans Saris about 3 years ago

  • Parent task set to #77810

Hi David's,

in what browsers did you test/experience this behavior?

#9 Updated by Sascha Egerer about 3 years ago

  • Status changed from New to Needs Feedback

Can't reproduce that issue in version 8.

#10 Updated by Rafal Brzeski over 2 years ago

I have the same issue with portrait images only on TYPO 7.6.14,
after save cropped area are completely different (in BE and FE)

#11 Updated by Rafal Brzeski over 2 years ago

I found where the problem is.
Crop editor (Image manipulation) use dimension of image from Camera data, not real physical dimension!
See my explanation on screenshots.

#12 Updated by Frans Saris over 2 years ago

Do you have a special metadata extractor service/extension installed? And can you maybe attach your test image so I can try to reproduce your situation.

#13 Updated by Rafal Brzeski over 2 years ago

Good point Frans, in my case i use extractor -> https://typo3.org/extensions/repository/view/extractor
and this extension maps Exif dimension data to fields which corresponds to image manipulation.
So i guess that my case should be report to author (Xavier Perseguers) of extractor, right ?
In any case I have attached my "Test.jpg" image in zip.

#14 Updated by Xavier Perseguers over 2 years ago

Extractor takes the info from EXIF, right, but if they differ from the physical size, then it may be related to 2 different use cases:

  • Image was resized (e.g. in Photoshop) prior to upload and metadata is from the original file, not the uploaded one
  • Image was resized upon upload (e.g., EXT:image_autoresize)

If this happens, it looks like the crop editor should trust the metadata, when it exists since an extractor who populated the info (this is a read-only info thus cannot be changed by an editor) may be in a position to know "more" about the image than just by reading the EXIF data.

If the FAL metadata are not populated, then it's fine to read the EXIF of course, but only as failover.

Did not investigate more, if EXT:extractor may be enhanced in some way, do not hesitate to suggest change.

#15 Updated by Alexander Opitz over 2 years ago

What's the state of this issue?

#16 Updated by Alexander Opitz about 2 years ago

  • Status changed from Needs Feedback to Closed

No feedback within the last 90 days => closing this issue.

If you think that this is the wrong decision or experience this issue again, then please write to the mailing list typo3.teams.bugs with issue number and an explanation or open a new ticket and add a relation to this ticket number.

Also available in: Atom PDF