Project

General

Profile

Actions

Bug #105463

open

Preview images in filelist are always in square format

Added by Felix Heller 2 days ago. Updated 2 days ago.

Status:
Accepted
Priority:
Must have
Assignee:
-
Category:
Image Generation / GIFBUILDER
Target version:
Start date:
2024-10-25
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
13
PHP Version:
8.3
Tags:
Complexity:
Is Regression:
Yes
Sprint Focus:

Description

I've uploaded an image file in the filelist of TYPO3 13.4.0. The option "Show thumbnails" is enabled. Directly after the upload, the preview image is shown with a correct aspect ratio:

<img src="/typo3/image/process?token=XXXXXXXXXX&amp;id=96667" width="64" height="19" title="typo3-header.jpg" loading="lazy" alt="">

After reloading the filelist, the preview image is shown with a square aspect ratio of 64x64:

<img src="/fileadmin/_processed_/1/9/preview_typo3-header_19635b6aa5.jpg?1729847087" width="64" height="64" title="typo3-header.jpg" loading="lazy" alt="">

In the file information dialog, the image is always shown with the correct aspect ratio.


I'm using GraphicsMagick (['GFX']['processor'] = 'GraphicsMagick') in version 1.3.42.

I've debugged the code and found out that the creation of the ImageMagick command changed between TYPO3 12.4 and 13.4.

TYPO3 12.4

'/usr/bin/gm' 'convert' -interlace 'None' -auto-orient '+profile' '*' -sample '64'x'64' 'jpg:/var/www/html/releases/current/public/fileadmin/user_upload/typo3-header.jpg[0]'

TYPO3 13.4

'/usr/bin/gm' 'convert' -interlace 'None' -auto-orient '+profile' '*' -auto-orient -sample 64x64! -sharpen 1x2 -quality 85 -colorspace 'RGB' 'jpg:/var/www/html/releases/current/public/fileadmin/user_upload/typo3-header.jpg[0]'

Using 64x64! instead of '64'x'64' for the sample argument forces GraphicsMagick to use exactly this aspect ratio, resulting in the processed square image. While the information dialog uses a configuration of '590m'x'400m' for the processed file, the filelist uses 64x64 and forces integer values. I've tried a User TSconfig like this but the values get casted to integer in the core:

options.file_list.thumbnail {
  width = 64m
  height = 64m
}


Files


Related issues 3 (0 open3 closed)

Related to TYPO3 Core - Task #102187: Consistently apply ImageMagick parameters when convertingClosedBenni Mack2023-10-17

Actions
Related to TYPO3 Core - Task #103351: Avoid duplicate image crop (crop-crop-scale to crop-scale)ClosedBenjamin Franzke2024-03-08

Actions
Related to TYPO3 Core - Bug #91855: Image with crop set is JPEG compressed twiceClosed2020-07-23

Actions
Actions #1

Updated by Felix Heller 2 days ago

  • Related to Task #102187: Consistently apply ImageMagick parameters when converting added
Actions #2

Updated by Garvin Hicking 2 days ago

  • Category changed from Backend User Interface to Image Generation / GIFBUILDER
Actions #3

Updated by Garvin Hicking 2 days ago

  • Related to Task #103351: Avoid duplicate image crop (crop-crop-scale to crop-scale) added
  • Related to Bug #91855: Image with crop set is JPEG compressed twice added
Actions #4

Updated by Garvin Hicking 2 days ago

only superficially looked into this. With imageMagick this still seems correct, so there's probably some code fork that goes another way for gm than im

Actions #5

Updated by Felix Heller 2 days ago

Thank you for looking into this. I've quickly installed ImageMagick (version 6.9.12-98) in my development container but the thumbnail problem is still there. The command for creating the image uses /usr/bin/convert instead of /usr/bin/gm convert, but the sample parameter forces the square aspect ratio with ImageMagick, too:

"'/usr/bin/convert' -interlace 'None' -auto-orient '+profile' '*' -auto-orient -sample 64x64! -sharpen 1x2 -quality 85 -colorspace 'sRGB' ...

Actions #6

Updated by Garvin Hicking 2 days ago

  • Status changed from New to Accepted
  • Priority changed from Should have to Must have
  • Is Regression set to Yes

Ah, yes - I see it now. I wrongly reproduced this and did not properly reload the listing. Thanks so much for getting back quickly.

So you're right, what happens is:

- Media is uploaded with dimensions 2746 x 7893 for example
- Placeholder generation calculates the thumbnail dimensions to be 22 x 64
- Emits the placeholder image with that actual 22x64 dimensions
- Original image is now resized but with the 64x64! command
- Those dimensions are now persisted to sys_file_processedfile
- This is probably what changed in comparison to 12.4, that the image dimensions from the created file are re-evaluated, instead of taken from the original configuration ('csm' vs. 'preview')
- The next time the filelist is loaded, the thumbnail dimension from sys_file_processedfile become available, and then that 64x64 image is displayed with 64x64 image dimensions

With only superficial investigation I wasn't able to find the place in the code that would re-read this. I noticed that T3v12 uses the "csm" (crop-scale-mask) file for the thumbnail, but in T3v13 the "preview" file is used instead (which has the lower resolution).

Actions

Also available in: Atom PDF