I got over the problem with the white space thanks to Ricardo, but now I tried to read meta-data from old JPEG files, which uses a different format than EXIF or EXIF embedded in an other framework like JFIF.
Are there any plans to support these formats: (?)
* JFIF (APP0) - standard JFIF header.
* JFIF Extension (APP0) - as saved by older digital cameras and some other applications.
* CIFF (APP0) - Canon's digital camera info section.
* Olympus (APP12) - info wrritten by some Olympus digital cameras.
* Photoshop (APP13) - Photoshop resource data, includes inline thumbnail.
* Adobe (APP14) - written by Adobe applications (Photoshop etc).
* Comment section.
I know these are quite old metadata formats but I think some old cameras are still in use. I just wonder if there are plans to support them.
What about PIM (PRINT Image Matching) is there a way to get these informations out of the image files? Are there any plans to support these additional informations?
Thanks for your help and your informations,
kind regards.
Stefan Moser
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are no current plans to support these formats.
PMT's focus is on industry-wide standards. Since EXIF and TIFF have been widely accepted as the industry's standard image file formats, PMT supports them. For current and future persistence of image metadata, XML is also a standard format which PMT supports; and XML is how the DIG35 has specified its metadata storage. When the JPEG2000 file format comes into common usage, there are plans to implement JPEG2000 Accessors in PMT too.
PMT also allows other formats to be supported, provided you write an appropriate XML schema file and XML translation table. In other words, you can write your own schema to extend PMT's capabilities to read and write from various vendor-specific file locations.
Just a note about PIM. It contains vendor-specific information that is unavailable to the general public. This means that only those who are privy to its contents can take advantage of the metadata. PMT cannot work with PIM, as long as it's undisclosed.
If you do choose to create additional schema's and translation tables, please consider sharing your work with the rest of the OpenSource community by contacting us. Even though PMT's current resources are such that the most common file formats have been implemented, other formats could be incorporated, extending PMT's feature set.
Dan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I realize that this thread is rather old, but this it relates to the type of work I'd like to do with PMT.
The first poster above mentions photoshop metadata (APP13). As I understand it this metadata structure is a standard created by IPTC (International Press Telecommunications Council) and adopted by Photoshop. Adobe is continuing to use this standard in version 7.0 of Photoshop (The latest version).
I would be happy to work on a schema to access this format. Unfortunately, I can ony consider myself a beginning C++ programmer and intermediate at best with XML. What resources are available for me to get started creating this new XML schema?
thanks,
Dave
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your interest in PMT. I was thinking that you might want the full XMP metadata that Adobe embeds within it's images and documents rather than IPTC (I don't remember off-hand which app segment they put it in ... you can search www.adobe.com for specs, etc.) However, if you're still interested in the IPTC data only within Exif files, one could modify the Exif Accessor in PMT to query OpenExif for the relevant app segments, interpret them, and insert the data into the metadata tree. The latest version of OpenExif (at least the latest in CVS) will support this.
XMP is a little more complex as it can be in just about all file formats. The solution here I'm thinking would be to write it's own accessor, and then allow the other accessors to call it with the appropriate data.
As for aids in writing for the PMT, check out the documentation in our docs directory. If you still have questions, or have something to contribute, please send me a note here at SourceForge.
Hope this helps,
Sam.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I got over the problem with the white space thanks to Ricardo, but now I tried to read meta-data from old JPEG files, which uses a different format than EXIF or EXIF embedded in an other framework like JFIF.
Are there any plans to support these formats: (?)
* JFIF (APP0) - standard JFIF header.
* JFIF Extension (APP0) - as saved by older digital cameras and some other applications.
* CIFF (APP0) - Canon's digital camera info section.
* Olympus (APP12) - info wrritten by some Olympus digital cameras.
* Photoshop (APP13) - Photoshop resource data, includes inline thumbnail.
* Adobe (APP14) - written by Adobe applications (Photoshop etc).
* Comment section.
I know these are quite old metadata formats but I think some old cameras are still in use. I just wonder if there are plans to support them.
What about PIM (PRINT Image Matching) is there a way to get these informations out of the image files? Are there any plans to support these additional informations?
Thanks for your help and your informations,
kind regards.
Stefan Moser
Stefan,
There are no current plans to support these formats.
PMT's focus is on industry-wide standards. Since EXIF and TIFF have been widely accepted as the industry's standard image file formats, PMT supports them. For current and future persistence of image metadata, XML is also a standard format which PMT supports; and XML is how the DIG35 has specified its metadata storage. When the JPEG2000 file format comes into common usage, there are plans to implement JPEG2000 Accessors in PMT too.
PMT also allows other formats to be supported, provided you write an appropriate XML schema file and XML translation table. In other words, you can write your own schema to extend PMT's capabilities to read and write from various vendor-specific file locations.
Just a note about PIM. It contains vendor-specific information that is unavailable to the general public. This means that only those who are privy to its contents can take advantage of the metadata. PMT cannot work with PIM, as long as it's undisclosed.
If you do choose to create additional schema's and translation tables, please consider sharing your work with the rest of the OpenSource community by contacting us. Even though PMT's current resources are such that the most common file formats have been implemented, other formats could be incorporated, extending PMT's feature set.
Dan
Hello,
I realize that this thread is rather old, but this it relates to the type of work I'd like to do with PMT.
The first poster above mentions photoshop metadata (APP13). As I understand it this metadata structure is a standard created by IPTC (International Press Telecommunications Council) and adopted by Photoshop. Adobe is continuing to use this standard in version 7.0 of Photoshop (The latest version).
I would be happy to work on a schema to access this format. Unfortunately, I can ony consider myself a beginning C++ programmer and intermediate at best with XML. What resources are available for me to get started creating this new XML schema?
thanks,
Dave
Thanks for your interest in PMT. I was thinking that you might want the full XMP metadata that Adobe embeds within it's images and documents rather than IPTC (I don't remember off-hand which app segment they put it in ... you can search www.adobe.com for specs, etc.) However, if you're still interested in the IPTC data only within Exif files, one could modify the Exif Accessor in PMT to query OpenExif for the relevant app segments, interpret them, and insert the data into the metadata tree. The latest version of OpenExif (at least the latest in CVS) will support this.
XMP is a little more complex as it can be in just about all file formats. The solution here I'm thinking would be to write it's own accessor, and then allow the other accessors to call it with the appropriate data.
As for aids in writing for the PMT, check out the documentation in our docs directory. If you still have questions, or have something to contribute, please send me a note here at SourceForge.
Hope this helps,
Sam.