GNOME Bugzilla – Bug 409050
Metadata ideas for future development
Last modified: 2008-07-30 16:40:11 UTC
Metadata Ideas - Comments welcome! ================================== Use exiftool for metadata read/write, because: - it supports Exif and MakerNotes - it supports IPTC - it supports XMP - it provides read/write support - it seems to be actively developed - libexif has saving issues (MakerNote offsets) Exiftool is a Perl program, but I don't see any real problem running it through the "system" command or something similar. We could store all the metadata (including comments) in a GHashTable, which would be initialized by file-data.c. The actual metadata would only be loaded when it was first needed. To improve access times (especially for sort-by-ExifDateTime) we could cache the metadata in a local file (sort of like the remote_cache). I think the sort is the only speed-sensitive use of the metadata. General approach: to get metadata - - check for GHashTable, use it if not NULL - otherwise check for cache file, use if mtime is OK - otherwise run "exiftool -s -s -e -G1" and save it to the cache file - read the cache into the GHashTable save metadata - use exiftool to write metadata to the image file - save metadata to the cache file too comments - store in XMP format - phase out existing XML approach - only works for read/write images, though - if XMP comment is null, read in from - XML comments (and delete XML file) - exif comments - iptc comments - in that order? editing - edit values in GHashTable - use exiftool to write metadata to the image file - save metadata to the cache file too other issues - it could be re-written to use the exiv2 command line utility instead - but that has no XMP support currently. - this is a file-based approach - doesn't integrate too nicely with the in-data jpeg rotation code, etc. Sample hash table entry: Key="[IFD0] Model" Value="FinePixS1Pro" Sample "exiftool -s -s -e -n -G1" output: [mjc@strawberry eraseme]$ exiftool -s -s -e -n -G1 s_gps.jpg [ExifTool] ExifToolVersion: 6.69 [File] FileName: s_gps.jpg [File] FileSize: 44622 [File] FileModifyDate: 2007:01:30 10:53:46 [File] FileType: JPEG [File] MIMEType: image/jpeg [File] ImageWidth: 600 [File] ImageHeight: 400 [JFIF] JFIFVersion: 1 2 [IFD0] ImageDescription: Communications [IFD0] Make: FUJIFILM [IFD0] Model: FinePixS1Pro [IFD0] Orientation: 1 [IFD0] XResolution: 300 [IFD0] YResolution: 300 [IFD0] ResolutionUnit: 2 [IFD0] Software: Adobe Photoshop 7.0 [IFD0] ModifyDate: 2002:07:19 13:28:10 [IFD0] Artist: Ian Britton [IFD0] YCbCrPositioning: 2 [IFD0] ReferenceBlackWhite: 0 255 128 255 128 255 [IFD0] Copyright: ian Britton - FreeFoto.com [ExifIFD] FNumber: 0.6402344 [ExifIFD] ExposureProgram: 4 [ExifIFD] ISO: 0 [ExifIFD] ExifVersion: 0200 [ExifIFD] DateTimeOriginal: 2002:07:13 15:58:28 [ExifIFD] CreateDate: 2002:07:13 15:58:28 [ExifIFD] ComponentsConfiguration: ... [ExifIFD] ShutterSpeedValue: 0.00138106793200498 [ExifIFD] ApertureValue: 16 [ExifIFD] BrightnessValue: 0.2601562 [ExifIFD] ExposureCompensation: -0.65 [ExifIFD] MeteringMode: 5 [ExifIFD] Flash: 0 [ExifIFD] FocalLength: 0 [ExifIFD] FlashpixVersion: 0100 [ExifIFD] ColorSpace: 1 [ExifIFD] ExifImageWidth: 2400 [ExifIFD] ExifImageLength: 1600 [ExifIFD] FocalPlaneXResolution: 12.05078 [ExifIFD] FocalPlaneYResolution: 12.05078 [ExifIFD] FocalPlaneResolutionUnit: 25.4 [ExifIFD] SensingMethod: 2 [ExifIFD] FileSource: 0 [ExifIFD] SceneType: 0 [GPS] GPSVersionID: 2 0 0 0 [GPS] GPSLatitudeRef: N [GPS] GPSLatitude: 54.9896666666667 [GPS] GPSLongitudeRef: W [GPS] GPSLongitude: 1.91416666666667 [GPS] GPSTimeStamp: 14:58:24 [GPS] GPSMapDatum: WGS84 [IFD1] Compression: 6 [IFD1] ThumbnailOffset: 1068 [IFD1] ThumbnailLength: 3662 [IPTC] EnvelopeRecordVersion: 4 [IPTC] CodedCharacterSet: .%G [IPTC] ApplicationRecordVersion: 4 [IPTC] ObjectName: Communications [IPTC] Keywords: Communications [IPTC] By-line: Ian Britton [IPTC] By-lineTitle: Photographer [IPTC] Province-State: [IPTC] Country-PrimaryLocationName: Ubited Kingdom [IPTC] CopyrightNotice: ian Britton - FreeFoto.com [IPTC] Caption-Abstract: Communications - xyz124565467 [IPTC] Writer-Editor: Ian Britton [Photoshop] DisplayedUnitsX: 1 [Photoshop] DisplayedUnitsY: 1 [Photoshop] GlobalAngle: 30 [Photoshop] GlobalAltitude: 30 [Photoshop] CopyrightFlag: 1 [Photoshop] URL: www.freefoto.com [Photoshop] PhotoshopThumbnail: (Binary data 3662 bytes, use -b option to extract) [Photoshop] PhotoshopQuality: 5 [Photoshop] PhotoshopFormat: 0 [Photoshop] ProgressiveScans: 1 [XMP-photoshop] CaptionWriter: Ian Britton [XMP-photoshop] Headline: Communications [XMP-photoshop] AuthorsPosition: Photographer [XMP-photoshop] Credit: Ian Britton [XMP-photoshop] Source: FreeFoto.com [XMP-photoshop] City: [XMP-photoshop] State: [XMP-photoshop] Country: Ubited Kingdom [XMP-photoshop] Category: BUS [XMP-photoshop] DateCreated: 2002:06:20 [XMP-photoshop] Urgency: 5 [XMP-photoshop] SupplementalCategories: Communications [XMP-xmpBJ] JobRefName: Photographer [XMP-xmpMM] DocumentID: adobe:docid:photoshop:84d4dba8-9b11-11d6-895d-c4d063a70fb0 [XMP-xmpRights] WebStatement: www.freefoto.com [XMP-xmpRights] Marked: True [XMP-dc] Description: Communications [XMP-dc] Creator: Ian Britton [XMP-dc] Title: Communications [XMP-dc] Rights: ian Britton - FreeFoto.com [XMP-dc] Subject: Communications [ICC-header] ProfileCMMType: Lino [ICC-header] ProfileVersion: 528 [ICC-header] ProfileClass: mntr [ICC-header] ColorSpaceData: RGB [ICC-header] ProfileConnectionSpace: XYZ [ICC-header] ProfileDateTime: 1998:02:09 06:49:00 [ICC-header] ProfileFileSignature: acsp [ICC-header] PrimaryPlatform: MSFT [ICC-header] CMMFlags: 0 [ICC-header] DeviceManufacturer: IEC [ICC-header] DeviceModel: sRGB [ICC-header] DeviceAttributes: 0 [ICC-header] RenderingIntent: 0 [ICC-header] ConnectionSpaceIlluminant: 0.9642 1 0.82491 [ICC-header] ProfileCreator: HP [ICC-header] ProfileID: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 [ICC_Profile] ProfileCopyright: Copyright (c) 1998 Hewlett-Packard Company [ICC_Profile] ProfileDescription: sRGB IEC61966-2.1 [ICC_Profile] MediaWhitePoint: 0.95045 1 1.08905 [ICC_Profile] MediaBlackPoint: 0 0 0 [ICC_Profile] RedMatrixColumn: 0.43607 0.22249 0.01392 [ICC_Profile] GreenMatrixColumn: 0.38515 0.71687 0.09708 [ICC_Profile] BlueMatrixColumn: 0.14307 0.06061 0.7141 [ICC_Profile] DeviceMfgDesc: IEC http://www.iec.ch [ICC_Profile] DeviceModelDesc: IEC 61966-2.1 Default RGB colour space - sRGB [ICC_Profile] ViewingCondDesc: Reference Viewing Condition in IEC61966-2.1 [ICC_Profile] Luminance: 76.03647 80 87.12462 [ICC_Profile] Technology: CRT [ICC_Profile] RedTRC: (Binary data 2060 bytes, use -b option to extract) [ICC_Profile] GreenTRC: (Binary data 2060 bytes, use -b option to extract) [ICC_Profile] BlueTRC: (Binary data 2060 bytes, use -b option to extract) [ICC-view] ViewingCondIlluminant: 19.6445 20.3718 16.8089 [ICC-view] ViewingCondSurround: 3.92889 4.07439 3.36179 [ICC-view] ViewingCondIlluminantType: 1 [ICC-meas] MeasurementObserver: 1 [ICC-meas] MeasurementBacking: 0 0 0 [ICC-meas] MeasurementGeometry: 0 [ICC-meas] MeasurementFlare: 0.00999 [ICC-meas] MeasurementIlluminant: 2 [Adobe] DCTEncodeVersion: 100 [Adobe] APP14Flags0: 16384 [Adobe] APP14Flags1: 0 [Adobe] ColorTransform: 1
Related bugs: Bug 408185 – Maker Notes gets trashed with gthumb Bug 151130 – Support Adobe XMP metadata Bug 376971 – Cache Exif DateTime tag in comment files for faster access Bug 313579 – Should use the ImageDescription EXIF tag as comment - Mike
Use Exiv2 instead (the library) Using ExifTool is overkill as you have to bring Perl with it.
Perl is included in any modern distro. I don't see that as a real problem, especially when exiftool provides XMP, ICC, AVI/WAV and raw-photo support (exiv2 doesn't support any of these). It's pretty compelling. - Mike
*** Bug 406469 has been marked as a duplicate of this bug. ***
Also: we should add a way to embed the 4500+ supported tags in the web exporter, if desired. - Mike
While I like exiftool and I like Perl the integration of a Perl program through a system() call, or whatever, makes me get that gutfeeling again: what bridges will be burnt with this aproach? You know what I mean?! If using an external program like exiftool, why not make the interface more open than limited to exiftool? Many printer dialogs let the user configure the print command to use, ie "lpr -h -P myEpson" gthumb could have similar interface with a number of "variables" to use, for instance: %f - one filename at a time, issue command several time for a range %r - all filenames, issue the command one time %c - config file to translate tag name from gthumb internal to tool specific There are many more but can be added when integrated to specific tools. If this abstraction is not done I'd propose to have an internal abstraction API to wrap all calls to access exiftool so it can be replaced more easily. Other than that, great stuff! :-) // Joakim
*** Bug 409778 has been marked as a duplicate of this bug. ***
I have made a metadata-ideas branch in svn for testing these ideas. - Mike
Created attachment 83314 [details] Sample image with lots of metadata, including XMP, IPTC, ICC, EXIF.
Actually, the metadata display function in the metadata-ideas branch looks pretty good, to me. Feedback welcome! - Mike
The current version in metadata-ideas now uses exiftool if possible, and falls back to libexif otherwise. - Mike
Update: the metadata-ideas branch works pretty well for displaying metadata and reading/saving comments in the metadata. However, I want to re-work the comment code so that we can optionally/preferentially use the new exempi library (http://www.figuiere.net/hub/blog/?2007/03/11/505-exempi-050) to read xmp comments in. This should be much faster than using exiftool, I think. Sorting by comment with exiftool will probably be dreadfully slow right now. Also, right now the metadata comments are only read in and saved to xml when you edit a comment. The metadata comments aren't used before then. That will need to be fixed, once we have a fast way of reading in the metadata comments. - Mike
Current thinking: the full metadata hash should be stored in the filedata structure when we first need the metadata, like we do with the exif datetime tag currently. (It shouldn't be added automatically in file_data_new; that would be too slow.) This would speed up sorting and comment handling significantly, I think. - Mike
I've modified the sort-by-exif-date routines to read the date tags from non-jpg files using exiftool. (For jpg files, it uses libexif, for speed). This makes it possible to have AVI files sorted properly now, since they have embedded datetime tags! This is a killer feature, for me, that makes metadata-ideas hugely worthwhile... - Mike
Trunk now reads movie dates using mplayer, which is much faster than using exiftool. I don't think I'll pursue the metadata-ideas branch further. It was useful for testing Joakim's code, which is now in trunk (and gthumb-2-10). The movie-date thing was important to me as a home-digital-camera user. The other stuff is less important to me... - Mike
Why not using gstreamer instead of mplayer? Gstreamer is the defacto standard for video in Gnome. Let's be consistent.
Hubert, Yes, gstreamer is a better way to go, once I learn how to use it ... The mplayer approach is "quick and dirty", but makes gthumb more useful immediately (for me). - Mike
So (see comment 15), there's not going to be progress in this direction? I'd say that the ability to store the metadatas inside the actual files is the most prominent missing feature from gThumb. People have thousands of tagged files, and they are not able to use their tags with a different program, or share them with someone using Windows or KDE...
Andrea, I'm dropping the metadata-ideas branch because it is a hassle to maintain it separately from trunk, and the exiftool approach probably isn't the best way to go. (exiftool is slow, and it messes with the tag names). It was useful for experimenting. However, incremental improvements can still be made to trunk. Storing comments in the metadata shouldn't be too hard, especially since Joakim's tag-writing code is now in trunk. Maybe Hubert can be convinced to add XMP support to trunk, like he did for eog :-) Of course, it gets a little messy deciding exactly where to store comments - in exif, iptc, xmp? And which gets priority when reading? - Mike
> Maybe Hubert can be convinced to add XMP support to trunk, like he did for eog > :-) Yeah might happen, might not. I have alread too many things to do :-) including finishing Exempi and libopenraw. > Of course, it gets a little messy deciding exactly where to store comments - in > exif, iptc, xmp? And which gets priority when reading? exempi will "reconcile the metadata" that means you write them in XMP and it will update the ITPC/IIM and Exif if applicable. And vice-versa. I'd recommend using XMP only. Exif is IMHO only for camera use, and IPTC/IIM is really deprecated in favor of Iptc4Xmp which is part of XMP.
Thanks, Hubert, that's really useful to know. Can exif and xmp exist separately in an image file, or do they share the same APP markers? What happens if we add xmp comments to an exif image from a camera? Anything bad? I'm not 100% sure that the existing exif tag reading code in gthumb gracefully handles exif+xmp files; that has to be checked. (We stopped using libexif to read exif tags.) - Mike
Well, to partly answer my own question, xmp and exif should co-exist, and both have an APP1 marker in jpeg. We need to check that the minimal tag reader can handle that (and the gdk-pixbuf orientation tag reader, too). If we add xmp data to an exif file, is it always placed after the exif data so that the MakerNotes don't get corrupted by changed offsets? - Mike
(In reply to comment #22) > Well, to partly answer my own question, xmp and exif should co-exist, and both > have an APP1 marker in jpeg. 2 APP1 markers with different ID strings > If we add xmp data to an exif file, is it always placed after the exif data so > that the MakerNotes don't get corrupted by changed offsets? I think it always is. Exempi use Adobe reference code, and I guess they know about the issue ;-)
Please use libraries with C interface and not Perl, because: - it is faster - it is cleaner - it reduces the problems with external tools and bugs are easier to fix - it would be easier to make small binary packages - you stay independent from the development of perl and it's packages And you should IPTC at lease on the standard fields, to be compatible with existing applications.
Sven, The current plan is to eventually use XMP (exempi) to handle metadata. - Mike
Closing as obsolete. Trunk uses exiv2.