This documentation is not using the current rendering mechanism and is probably outdated. The extension maintainer should switch to the new system. Details on how to use the rendering mechanism can be found here.
Extension Key: eim2exifextract
Copyright 2003-2005, Achim Eichhorn, <AchimEichhorn@eim2.de>
This document is published under the Open Content License
available from http://www.opencontent.org/opl.shtml
The content of this document is related to TYPO3
- a GNU/GPL CMS/Framework available from www.typo3.com
Table of Contents¶
metaExtract: EXIF 1
This extension provides a service of the type 'metaExtract' which gets EXIF data from files.It is completely based on “cc_metaexif” developed by René Fritz, but does some changes I needed.When I used cc_metaexif I found some strange behaviour in my DAM installation. Some of my customer's images weren't indexed, other images, which seemed nearly the same in filesize, color-space and file-format where indexed. So I had to dive into DAM source codes and found a first hint, that some of those images had such a huge amount of meta information stored with them, that the MySQL Database Server was out of memory when writing meta information and the connection to the database broke down.If you have this problem, too and want to keep all of the meta-information, you have to reconfigure your database. You have to increase the max_packet_size, which you find in my.cnf (or whatever your MySql-configuraton file is).
When I did this, I got another error-message from typo3. This one said, that it was impossible to update the data for the fields ”colorspace” and “meta”.
The problem with “meta” was, that the MySql Datatype, which should take the meta information is of type “TEXT”. In my database this datatype can only hold data up to a size of 65536 Bytes, but the meta- information of some images was much larger.
If you come across this problem, you have two ways to solve it, the first one, if you want to keep all meta information, is to alter the MySql datatype of the meta field to some datatype which can take much larger datasets.
The other possibility, which I use in this service, is to filter the meta information and to discard informations not needed. Which data you want to skip can be configure in the page's TSConfig of your media sysfolder. More about this in the configuration section.
The other problem I had, was the thing with the colorspace. In EXIF there exist (as far as I know) only two types of colorspaces, sRGB which gets the value “1” and UNCALIBRATED with “65535”.
The database field which should take the colorspace information is of type VARCHAR(4), the programming logic in the original service did the following: If the meta value was “1”, it wrote “sRGB” to the database, when the meta-value was something <> 1, it used the original value (65535), which, interpreted as String consists of 5 characters and what leads to a MySql error. In this service I changed the logic in a way, that any other value than 1 leads to an empty String.
I hope for the future to get another possibility to fill in the correct colorspace. Maybe someone with more experience with EXIF specification has an useful hint?
You can configure this service in the TS-config section of your media sysfolder.
Here is an example:
0 = ExtensibleMetadataPlatform
1 = ImageResourceInformation
2 = ICC_Profile
skip_too_large = 1
db_field_max_len = 65535
the array discard takes all EXIF tags which should not get into you meta-data. Especially the ICC_Profile from my customer's images were very large, so I think it was a good idea, to skip them.
The parameter skip_too_large enables another mechanism, which could be used standalone, or in combination with the discard array. If you switch skip_too_large on, the algorithm collecting the exif-data examins, if the amount of data exceeds the value of db_field_max_len. If so, it skips this field.
If you altered your meta-field in the database you have to use another value for db_field_max_len.
eim2exifextract - 2