TYPO3 Core

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