[TYPO3-dam] cronjob > errors

[Achim Eichhorn]

Hello Andreas,

I got the same error.
When diving into source codes I found the following definition in 
cc_metaexif\sv2\class.tx_ccmetaexif_sv2.php (this is the service for 
extraction EXIF data from images)

Lines 106-109

case 'ColorSpace':
case 'ColorSpaceInformation':
$this->out['fields']['color_space'] = ($value==1)?'sRGB':$value;
break;

This says if the exif data value is 1 than use "sRGB", if not, use the 
original value from the EXIF data.
The color_space tag can have two values (maybe there can be more, but I 
found no specification, only the following two constants):
 COLOR_SPACE_SRGB 1
COLOR_SPACE_UNCALIBRATED 65535

In my case I got the described error-message, when the value was 65535, 
which is logical,
because the color_space field is defined as VARCHAR(4) - and 65535 
interpreted as string consists of 5 characters.
In TCA for the color_space field are defined several more string-literals: 
(tca.php 689-694)

array('RGB', 'RGB'),
array('sRGB', 'sRGB'),
array('CMYK', 'CMYK'),
array('CMY', 'CMY'),
array('YUV', 'YUV'),
array('indexed', 'indx'),

One solution would be, to set adpot the service file in this way:

$this->out['fields']['color_space'] = ($value==1)?'sRGB':'';

But then only sRGB color space would be recognized and all the other 
color_spaces
would have to be entered from a user "by hand" which is not the way I expect 
an Media database to handle this...
But unfortunatley I don't know, how to find out, which is the correct color 
space for a special picture...
 But maybe someone has more experience with this?
Hope this helps and brings us a little bit further!

By the way, I received the same error for some images for the "meta" field, 
there we have an mysql
TEXT datatype which can be used with app. 65000 Bytes, But large Images 
often got more EXIF
information for ICC_Profiles and other things. In my case I did not need 
this Profiles,
so I adopted tx_dam_indexing in a way,
that it skips this data fields. An other solution would be, to alter the 
meta field, and use an other datatype.

I think this problems occure to other people, too,
so we perhaps find a common solution, which could be implemented in a 
future-version of dam,
so that such individual changes to the source-code will not be necessary...

Greetings Achim.