(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)
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’!”
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
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?
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.
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 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 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.
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.
Gramps and its display of image metadata has been of interest to me for some time and in my recent attempts to understand and, hopefully, improve the situation, I came across your updates on Github
at: Gramps - PhotoTaggingGramplet.py - Modified to display person regions embedded in photos · GitHub
I have downloaded the 2 files you posted and have been using them as part of my test bed with reasonable success.
‘Reasonable’, because, even though I have a test image with a ‘face’ region tagged - using Window Photo Gallery - I do not see the data displayed for the face under ‘Image Metadata’.
Needeass to say, I am very much a newb in both Gramps & Python and though most of my work was done under Windows, I have managed to set up a working development setup using a Mint PC for the Gramps testing under Visual Studio code.
Still I am interested enough in both Gramps and metadata that I would want to keep going and sort out whatever is holding things up at my end.
If you have any thoughts on this, I much appreciate them.
I think the reasonable success is because the files you found are specifically for the PhotoTagging Gramplet and not the Image Metadata viewer.
I’ve submitted code for the Image Metadata viewer and hope it will be approved and included in 5.2.
In the meantime, you can update the code on your installation. Make a copy of the original files in your installation and then replace gramps\plugins\gramplet\metadataviewer.py and gramps\plugins\gramplet\metadataviewer.py with the following.
I don’t know much about Windows Photo Gallery or if it supports the necessary metadata. Exiftool is a great tool for inspecting the metadata in your files. https://exiftool.org/. If you download exiftool and run the command:
If Windows Photo Gallery has tagged the faces with the Metadata Working Group Regions Tags you should see a section of output like this.
Region Name : Henders, Alicia Augusta, Jackson, Edward Stephan
Region Type : Face, Face
Region Area X : 0.546807, 0.333652
Region Area Y : 0.233446, 0.197671
Region Area W : 0.0794214, 0.0854258
Region Area H : 0.105499, 0.10073
Region Area Unit : normalized, normalized
Region Person Display Name : Henders, Alicia Augusta, Jackson, Edward Stephan
Region Rectangle : 0.507096, 0.180696, 0.0794214, 0.105499, 0.290939, 0.147306, 0.0854258, 0.10073'Preformatted text`
If you don’t see these tags in the output from exiftool then faces won’t display in the Gramps Image Metadata viewer.
Thank you for the latest files, but something else must have changed as well as I am unable to use Gramps with those 2 new files
Comparing the new ones with those I downloaded from Github, it seems that one class was renamed from MetadataViewer to MetadataView and I don’t seem to be able to get past that.
Also, I have verified with exiftool that the file I am using for testing the face data does indeed contain such data