Bug #93811

Image processing is inconsistent between FilesProcessor and Media/ImageViewHelper

Added by Claus Due 7 months ago. Updated 7 months ago.

Should have
Image Generation / GIFBUILDER
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


Note, the following is reported with .ai / .eps formats which I'm aware aren't natively supported as images. However, the issue still remains the same - FilesProcessor seems to use the correct API for processing files whereas Media/ImageViewHelper takes a shortcut that potentially causes errors when processing files that are image-incompatible, e.g. videos or PDF.

An alternative problem description could also be "Image processing ignores TYPO3_CONF_VARS.GFX.imagefile_ext when determining if file is an image".

Problem description:

Files of types like "ai" or "eps" do not get scaled when using FilesProcessor, but do get scaled when using MediaViewHelper. This is due to using different APIs:

  • FilesProcessor will use FileUtility which has a condition that checks File->getType equal to "image" before doing image processing; if matched it then uses ImageService to apply processing.
  • But MediaViewHelper directly uses ImageService to perform processing and will therefore scale/crop literally any file that can be cropped/scaled by the configured image processing mechanism (im, gm, gd)

This causes two side effects:

  • Media processing is inconsistent between FilesProcessor and MediaViewHelper
  • MediaViewHelper will explicitly treat every type of media as an "image", including videos/pdf/etc.

Fix for TYPO3 long-term:

Solve inconsistency between FilesProcessor and MediaViewHelper. Problem is, FilesProcessor uses FileUtility to process which supports all file formats, but contains a condition that only uses File->getType to determine if file is an image. If not an image, no scaling/cropping is performed.

  • Solution 1: Make MediaViewHelper also use FileUtility to do processing for consistency. Does not solve the issue that File->getType must be "image" or no processing happens, but does introduce full consistency between the two APIs.
  • Solution 2: Do solution 1 + add a condition in FileUtility that also considers any File that has a file extension that is recorded in TYPO3_CONF_VARS.GFX.imagefile_ext as being an "image", regardless of File->getType return value. Solves both the inconsistency and the problem of eps/ai/etc. not being detected as image regardless of configuration.
  • Solution 3: Do solution 1 + change determination of "type" for File when uploaded, to also consider any file extension recorded in TYPO3_CONF_VARS.GFX.imagefile_ext to be an "image". Solves both issues but does not retroactively fix files that are already uploaded (solution 2 probably preferable).

Updated by Claus Due 7 months ago

  • Status changed from New to Closed

Ah, sorry for the confusion - the FilesProcessor in question is actually from EXT:headless; the core's native FilesProcessor doesn't do image processing at all.

Closing it here, recreating for EXT:headless issue tracker.

Also available in: Atom PDF