0012219: Expand ImageMetadata gramplet to support XMP and IPTC metadata tags

(Note: This is a cross-post of Mantis Issues 12219 - My attempt in Mantis to show a table didn’t work. So I am adding it here.)

The current ImageMetadata gramplet only displays EXIF metadata tags. Third-party image editing/management softwares are inconsistent in the metadata tags they use to stored descriptions and other metadata. These softwares may write descriptions of the people/events in image in metadata tags that Gramps does currently support thus some information may be hidden from Gramps users.

Exiv2 supports XMP and IPTC tags.

This request suggests:

  • Expanding the metadata tags supported by the gramplet
  • Display the detailed metadata fieldname rather than the friendly names. Friendly names can be duplicated across fields and may result in the belief there is a bug in the gramplet
  • A new grouping of metadata tags so that like-tags are grouped together
  • Changing the gramplet presentation to a list view (to support better sorting)
  • Displaying a thumbnail image of any namesd regions embedded in the image.

(Note:. This change is independent of the PR I have made for the Phototagging Gramplet)

Proposed Metadata Grouping

Grouping Proposed Metadata Current Metdata
DESCRIPTION Exif.Image.ImageDescription
Exif.Image.XPSubject
Exif.Image.XPComment
Exif.Image.Rating
Xmp.dc.title
Xmp.dc.description
Xmp.dc.subject
Xmp.acdsee.caption
Xmp.acdsee.notes
Iptc.Application2.Caption
Exif.Photo.UserComment
Exif.Image.ImageDescription
Exif.Image.XPSubject
Exif.Image.XPComment
Exif.Image.XPKeywords
Exif.Image.Rating
Exif.Image.Artist
Exif.Image.Copyright
Exif.Photo.DateTimeOriginal
Exif.Photo.DateTimeDigitized
Exif.Image.DateTime
Exif.Image.TimeZoneOffset
DATE (new grouping) Exif.Photo.DateTimeOriginal
Exif.Photo.DateTimeDigitized
Exif.Image.DateTime
Exif.Image.TimeZoneOffset
PEOPLE
(new grouping)
Xmp.mwg-rs.Regions/mwg-rs:RegionList[x]/mwg-rs:Name (display thumbnail)
Xmp.iptcExt.PersonInImage
GPS Exif.GPSInfo.GPSLatitude
Exif.GPSInfo.GPSLatitudeRef
Exif.GPSInfo.GPSLongitude
Exif.GPSInfo.GPSLongitudeRef
Exif.GPSInfo.GPSAltitude
Exif.GPSInfo.GPSAltitudeRef
Exif.GPSInfo.GPSTimeStamp
Exif.GPSInfo.GPSSatellites
Exif.GPSInfo.GPSLatitude
Exif.GPSInfo.GPSLatitudeRef
Exif.GPSInfo.GPSLongitude
Exif.GPSInfo.GPSLongitudeRef
Exif.GPSInfo.GPSAltitude
Exif.GPSInfo.GPSAltitudeRef
Exif.GPSInfo.GPSTimeStamp
Exif.GPSInfo.GPSSatellites
TAGGING
(new grouping)
Exif.Image.XPKeywords
Xmp.mwg-kw.Hierarchy
Xmp.mwg-kw.Keywords
Xmp.digiKam.TagsList
Xmp.MicrosoftPhoto.LastKeywordXMP
Xmp.MicrosoftPhoto.LastKeywordIPTC
Xmp.lr.hierarchicalSubject
Xmp.acdsee.categories
IMAGE
(no changes)
Exif.Image.DocumentName
Exif.Photo.PixelXDimension
Exif.Photo.PixelYDimension
Exif.Image.XResolution
Exif.Image.ResolutionUnit
Exif.Image.YResolution
Exif.Image.ResolutionUnit
Exif.Image.Orientation
Exif.Photo.ColorSpace
Exif.Image.YCbCrPositioning
Exif.Photo.ComponentsConfiguration
Exif.Image.Compression
Exif.Photo.CompressedBitsPerPixel
Exif.Image.PhotometricInterpretation
Exif.Image.DocumentName
Exif.Photo.PixelXDimension
Exif.Photo.PixelYDimension
Exif.Image.XResolution
Exif.Image.ResolutionUnit
Exif.Image.YResolution
Exif.Image.ResolutionUnit
Exif.Image.Orientation
Exif.Photo.ColorSpace
Exif.Image.YCbCrPositioning
Exif.Photo.ComponentsConfiguration
Exif.Image.Compression
Exif.Photo.CompressedBitsPerPixel
Exif.Image.PhotometricInterpretation
RIGHTS
(new grouping)
Exif.Image.Copyright
Exif.Image.Artist
none
CAMERA
(no changes)
Exif.Image.Make
Exif.Image.Model
Exif.Photo.FNumber
Exif.Photo.ExposureTime
Exif.Photo.ISOSpeedRatings
Exif.Photo.FocalLength
Exif.Photo.FocalLengthIn35mmFilm
Exif.Photo.MaxApertureValue
Exif.Photo.MeteringMode
Exif.Photo.ExposureProgram
Exif.Photo.ExposureBiasValue
Exif.Photo.Flash
Exif.Image.FlashEnergy
Exif.Image.SelfTimerMode
Exif.Image.SubjectDistance
Exif.Photo.Contrast
Exif.Photo.LightSource
Exif.Photo.Saturation
Exif.Photo.Sharpness
Exif.Photo.WhiteBalance
Exif.Photo.DigitalZoomRation
Exif.Image.Make
Exif.Image.Model
Exif.Photo.FNumber
Exif.Photo.ExposureTime
Exif.Photo.ISOSpeedRatings
Exif.Photo.FocalLength
Exif.Photo.FocalLengthIn35mmFilm
Exif.Photo.MaxApertureValue
Exif.Photo.MeteringMode
Exif.Photo.ExposureProgram
Exif.Photo.ExposureBiasValue
Exif.Photo.Flash
Exif.Image.FlashEnergy
Exif.Image.SelfTimerMode
Exif.Image.SubjectDistance
Exif.Photo.Contrast
Exif.Photo.LightSource
Exif.Photo.Saturation
Exif.Photo.Sharpness
Exif.Photo.WhiteBalance
Exif.Photo.DigitalZoomRation
ADVANCED
(no changes)
Exif.Image.Software
Exif.Photo.ImageUniqueID
Exif.Image.CameraSerialNumber
Exif.Photo.ExifVersion
Exif.Photo.FlashpixVersion
Exif.Image.ExifTag
Exif.Image.GPSTag
Exif.Image.BatteryLevel
Exif.Image.Software
Exif.Photo.ImageUniqueID
Exif.Image.CameraSerialNumber
Exif.Photo.ExifVersion
Exif.Photo.FlashpixVersion
Exif.Image.ExifTag
Exif.Image.GPSTag
Exif.Image.BatteryLevel

Did you look a at the QGIS open source project. (I have not yet.)

But I just skimmed a tutorial that talks about leveraging QGIS to link photos to a map layer… including Frame Of View cones as map markers.

It may have practical applications for some metadata you did not include above. (Including the pitch & rotation axis to supplement the compass direction & GPS coordinates.)

I have not looked at (or heard of) the QGIS project. Most images I am working with pre-date smart phones.

Please, if there are tags that should be exposed in this view let me know. I focused only on tags where it looked like names or other pieces of info would be hiding.

The lists of metadata that Exiv2 supports are found here: https://www.exiv2.org/metadata.html

The alternative approach to this gramplet is to simply return any and all metadata that are in an image. I do wonder if this would give too much information that is not practical to most Gramps users.

Another interesting document: Guide to Photo Metadata Fields from META Resources


Found the above document after reading (yet another) posting elsewhere asking for tips on labeling photos.

The disparity of replies, & lack of an efficient one, prompted me to think: “Surely there must be a buried feature in GIMP to automatically create a Caption Layer that includes markup of a metadata standard caption with bitmapping fallback. So that, for publishing software that supports Text, the bitmapped caption portion image would be cropped (without actually changing the image) and the resolution-independent caption text inserted. And where simple image display (slideshow) programs would show the bitmapped caption. It would mean GIMP could restore the Editable text for the next editting session.”

My cynical self immediately replied: “Of course that doesn’t exist. Something that simple would be in every reply to similar questions. You know that no-one would ever support such a feature. They’d insist on complicating the discussion until it became impractical… And don’t call me ‘Shirley’!”

Yes. Metadata & layers are distinct & different.

This is a concept for VIRTUALLY unflattening a flattened image & reconstructing text layer from metadata. If the software recognizes the metadata, it uses that data to create a proper caption & hide the bitmapped one… without the need for OCR.

Using markup, you’d be able to preserve the document’s typeface consistency and apply automated translation tools.

If the tool doesn’t recognize the CAPTION metadata, it just show the whole image… including the flattened bitmapped text.

The real benefit is in future-proofing the caption content a little. If you had to fix a typo, instead of having to OCR the caption, find the right font, size & decoration, the metadata would tell GIMP to snip off the caption region as a new layer, create a background color bottommost layer & create a new text layer using the marked-up metadata.

The user doing the edit could decide to discard the bitmapped caption region & fix the typo in the text layer. And when, they re-export in a format that flattens, the metadata would updated to reflect typo fix… synchronized with the fallback bitmapped caption. (The background layer gives the option to use transparency as well as opaque backdrops for the caption.)

As with metadata, this approach is a retrofit. So it isn’t the ideal solution… like image formats that universally support text areas

This seems to be where things are going right now.

You’ve probably been watching some of the MyHeritage free trial Deep Fake ancestor photo animations lately.

Remastering imagery from lower quality is gaining momentum.

I’d like to bring this discussion thread back to the idea of changes to the gramplet.

This makes sense though I wonder if anyone would go through the customization effort. Based on your idea I looked at Digikam, which I use. I learned I could customize the metadata presentation. I promptly kept the default because I didn’t feel it was worth the effort to customize for my needs. Do you think many Gramps users would do the same?

Thanks @emyoulation for the resource, it looks mostly like an alphabetical sort of information on the exiv2 metadata page. Is there something else you are highlighting that I did not see?

I see only 2 people responding to the original idea, I am wondering if this change is even needed. Any thoughts?

1 Like

Unless there was a big effort put into Validation of the Metadata, I suspect that such a feature would need to be restricted to display only … except for adding fields that have a GUI tool built to manipulate (and enforce validation of) that particular type of data.

Although I expect that Gramps would benefit greatly from a bare-bones Unicode string-length-limited editable Caption metadata field. Having a caption (that floats with the actual file in the OS storage device) would aid in re-categorizing media that had become detached from the Tree.

This proposal for the ImageMetadata gramplet not the Metadata Editor gramplet. Personally, I think writing metadata should left to other software tools.

1 Like

I’ve just done a quick search of issues in the Gramps bug tracker. After the implementation of the ImageMetadata gramplet in 2009/2010, I only see 1 request for an additional field before I opened this suggestion. A developer did respond for clarification but the requestor never responded.

I searched for: “Image metadata”, XMP, IPTC and exif. I discounted any issues related to other image gramplets (Phototagging and Edit Exif gramplets).

I don’t have the competence in Python to implement a templating system. Is anyone here able to step forward to take it on? I’m happy to do the reseach on templates from other FOSS systems.

Allowing configuration as a design goal - yes I agree. Implementing configuration options should be balanced with effort and need. In this specific case, where I see only 1 request to add a single metadata field in the previous 10 years I am not sure the need is demonstrated to make it worth the developer resources.

Broader input from the community would be helpful to decide if this feature should go ahead and how it should be implemented.

I thought you was asking for opinions, sorry…

I see no point in supporting XMP fields in Gramps if users can’t configure what field to use and it’s not possible to write any alternations of the metadata back to the file. There are no point in having metadata only stored in the Gramps database.
And any changes in metadata needs to be (semi-)automatically updated both in the database and in the files metadata, regardless of being stored in file or sidecar file.

I did ask for opinions. I have not intended to disrespect your ideas and thoughts. Your opinions are valid and welcome. At the same time, I am also hoping other community members will offer their views of what, if any, changes are needed and how they should be done.

I apologize for any disrespect.

Some thoughts:

  1. I agree that gramps should read xmp data, if it’s there. Exiftool, I think, presents gps data, no matter whether it’s xmp or exif. The default mode doesn’t tell you which it is.

  2. Regarding writing data, it’s perhaps worth noting that Apple’s Photos.app stores puts changes in its own database, but leaves the original photo alone, so you can always revert it. Personally I’ve had to make a workaround to that so that I can write my gps changes back to the original files, but it’s certainly not crazy to take that approach. Arguably a genealogy program shouldn’t be altering photos.

Currently I keep my photos for gramps (which are mainly documentary) in a separate folder, it if I get more into it, I’ll probably use something like tropy for them, and not Photos.app. The latter is great for organizing and importing, but isn’t very interoperable.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.