exception: Data too long for column 'color_space'

[sypets]

I am not sure if this is a core issue or an extractor issue. However, the problem occurs in ExifToolMetadataExtraction::extractMetaData

The problem is that the property "color_space" is evaluated to "Normal" although "sRGB" is in the exifdata and the field sys_file_metadata.color_space in the database is only 4 chars long. On writing the properties an exception is thrown. That the metadata is not written is not so severe, but that the height and width is not set has several ugly sideeffects.

We have been seeing this since Update to TYPO3 v12, did not see it before (though I can't say that it does not exists.

Impact

Debugging

public function extractMetaData(File $file, array $previousExtractedData = [])
    {
        $metadata = [];

        $extractedMetadata = $this->getExifToolService()->extractMetadata($file);
        if (!empty($extractedMetadata)) {
            $dataMapping = $this->getDataMapping($file);
            $metadata = $this->remapServiceOutput($extractedMetadata, $dataMapping);
            $this->processCategories($file, $metadata);
        }

'ColorSpace' => 'sRGB'

color_space='Normal'

---

file

exiftool Verkauf_UN_770_-_001.JPG  | grep -i "color space"
Color Space                     : sRGB

versions

• TYPO3 12.4.20
• extractor: 2.5.0

[sypets]

workaround

mysql>ALTER TABLE sys_file_metadata MODIFY COLUMN color_space VARCHAR(10);``

[chesio]

I think this is very similar to #85.

There is a core issue for #85 already, but there does not seem to be a conclusion yet whether this is more of a core issue or something that should be taken care of on extension level or even on a per project basis: https://forge.typo3.org/issues/104872

[sypets]

Thanks @chesio - I will take a look. I took care of it for now by changing the db schema, but I assume others might be affected as well and it seems to be a more general problem, you mentioned #85 and the core issue, there is also #74, and there are other issues where the metadata has wrong datatype.

I commented in the core issue.

Also, I don't know where the string "Normal" comes from, sRGB seems to get replaced by the mapping.

[sypets]

I am using out-of-the-box extractor. I did not override any mapping (as far as I am aware).

I debugged some more. In AbstractExtractionService::remapServiceOutput, the following are used to map the color_space (in this order):

1. ColorMode
2. ColorSpaceData
3. ColorSpace->Causal\Extractor\Utility\ColorSpace::normalize

With my test file, the value of ColorMode "Normal", this is what is used to write to sys_file_metadata.color_space (with width of 4 chars in DB).

exiftool color_space.jpg | grep -E "(Color Mode|Color Space)"
Color Mode                      : Normal
Color Space                     : sRGB

[sypets]

mapping:

 {
    "FAL": "color_space",
    "DATA": [
      "ColorMode",
      "ColorSpaceData",
      "ColorSpace->Causal\\Extractor\\Utility\\ColorSpace::normalize"
    ]
  },

https://github.com/xperseguers/t3ext-extractor/blob/master/Configuration/Services/ExifTool/default.json#L10

[sypets]

My suggestions:

• check if it really makes sense to use ColorMode for color_space
• in the code: check if result value fits in db field. If not set it to empty or some fallback.
• if these really are correct values, possible increase length of DB field sys_file_metadata.color_space

[xperseguers]

• check if it really makes sense to use ColorMode for color_space

Based on https://www.pantone.com/articles/color-fundamentals/color-models-explained, Color mode is actually "color model" and the system used to describe a color (RGB, CMYK, ...) whereas the color space is the mapping of real colors to the color model's particular values, e.g., sRGB and AdobeRGB are color spaces using RGB as color model/coding system.

=> Most probably it makes little sense to use ColorMode in the mapping and it should logically get dropped.