Bug #100803
open
Image Generation with crop to webp fails for high-resolution
0%
Description
We have an issue while generating images from high resolution and quality pictures.
The original image files are jpeg format, greater than 15MB (up to 21MB).
They are used as a gallery in a 2x2 grid inside the text & media elements.
To make them end user friendly we convert them to webp and different max-widths (640, 1280, 1920, 2880 and 3840).
But randomly these conversion fails for the whole set of f:uri.images and the f:image and the jpeg only gets converted to webp, but doesn't get cropped.
Most of the time we end up with 3 good cropped and converted images and 1 only converted to webp, if we try to move the crop for the failed one and clear the frontend cache all 4 sets of images are recreated and one of the four will be broken again.
The issue seems only to appear with high resolution/big image files.
We tried to switch graphicsmagick to imagemagick, but it's the same behavior. Images get converted but not cropped.
Debian 11
TYPO3 11.5.26
PHP 8.1
GraphicsMagick 1.4+really1.3.36+hg16481=
If we test the same project with the same images inside my ddev environment the images get converted and cropped correctly.
TYPO3 CMS 11.5.26 (Application Context: Production) - PHP 8.1.16
GraphicsMagick 1.4 snapshot-20210721 Q16
Since the images are from a customer we can't provide these at the moment.
It would be good if an error occurs while generating, it would be logged anywhere.
Also a check of the result against the given attributes like crop or dimensions should be implemented.
If the error isn't directly related to the TYPO3 generation/conversion of the images and is a misconfiguration of the server, additional notes in the documentation would be really helpful.
Updated by Garvin Hicking 5 months ago
- Status changed from New to Needs Feedback
Thank you for the report, and sorry for getting back late to you.
The issue sounds a bit like maybe memory or resource usage exhaustion.
Does it still happen in recent TYPO3v12? Did it only happen with webp format, or others too?
Are you able to capture the used shell graphicsmagick commands and see if it fails on a shell-level with a specific error message? Large jpegs tend to consume a lot of memory when getting uncompressed (easily more than a few hundred MiB).
I'd love to pinpoint this to research possibly improved error handling.
Updated by S P 4 months ago
ยท Edited
I can confirm this for TYPO3 10. I have JPEG images (so not only WebP affected) from a customer that just do not crop correctly. I first suspected corrupt file formats, but it turned out that the size of the images causes the problem. If I save them to a lower size with an external tool first, the cropping instantly works again in TYPO3. I have this on the live server and on my local machine (both with basically "unlimited" RAM and unrestricted PHP settings), using GraphicsMagick.
Until now I could not figure out who exactly causes this in the end, whether it is TYPO3 PHP code, the PHP runtime itself, the doing of GM or something different.
Some more insights: it is not that croppign does not work at all on large images, they actually still get cropped "somehow": it is just that the crop area seems to be "randomly" located as soon as the images gets too big.
The cropping overlay in the Backend GUI for file references works just fine and the correct crop JSON arrives in the database field of sys_file_reference.crop. But as soon as the original images should be actually cropped for the backend preview images or the Frontend templates, using this correct crop JSON information, the result is "totally random" until I overwrite the original image file with a pre-down-scaled version.
Updated by Garvin Hicking 4 months ago
TYPO3v13 received several bugfixes for this, especially in some coordination resolving functions. I'm not sure if parts of it got backported to v12, too (probably not because many parts of imagegen are largely updated in v13).
Would you be able to try to reproduce this in a v13 setup?