7 replies to this topic

[TomH]

Working with strathglass on the old procedure interchanging photo metadata between Picasa and RM5 via the image file, I've confirmed that they still apply to RM 7.6.3. But with Picasa no longer marketed and supported, the question of interchange with other content manager software for photos is appropriate. And digging into the old procedures and online resources about photo metadata has reminded me how complex a rabbits' warren it is with multiple standards (IPTC, EXIF, XMP, ...) partially and inconsistently supported across multiple products. Given that RM7 has four properties it allows the user to define for each image file, to what photo metadata tags should these be mapped? And vice-versa?

• Caption
• Description
• Date
• Reference No.  

An approach is to choose one photo metadata standard that has a distinct field for each of these - I'm not sure there is one, and, if there is, is it the only one? Another is to choose one metadata tag and map each RM field to a section of a conactenated string separated by some code (similar to TMG's Memo field which had up to 10 sub-fields, separated by "||").

 

That decision is complicated by what metadata is visible and preserved by various systems. A report several years ago showed that Microsoft's SkyDrive and Windows Live Photo Gallery corrupted or lost chunks of metadata if a piece had previously been added by a specific software (Photo Supreme) whose output was perfectly compliant with the standards. Windows 10 File Explorer shows but a tiny chunk of a few metadata tags. You would not want to read a paragraph in its Title or any field, let alone edit it. IrfanView supports longer form text in its IPTC viewer/editor but its EXIF support is read-only. Perhaps it is the software chosen for viewing/managing embedded metadata that dictates the relationship between RM's Media Gallery media properties and the embedded metadata but consideration must also be given to the paths an image file may traverse.

 

There is probably a question about which software should be the master for metadata, given that it may be confusing and risky to have metadata being transferred in both directions (think TreeShare as an analogy).

 

If this sounds confusing, it is because embedded metadata is not unified having been developed in different branches for different camera manufacturers and other products or for different purposes and end-uses.

 

Any insights much appreciated.

[keithcstone]

I've had success using ACDSee and exif tool for updating the metadata in both jpg and tif. You could also consider using the Author field. This isn't specific to RM (But I'd really like to see RM use and set metadata). On one somewhat recent large project where I digitized about 1200 slides (out of maybe 10,000) from my wife's father and grandfather. Here's the process I used.

 

We transcribed the descriptions, dates, and photographer into a spreadsheet. Scanned the slides in spreadsheet order and entered the filename into the spreadsheet. After they were scanned we placed them into archival sheets to be stored in a three ring archival binder. We placed a sticky note on each page with the starting filename (they were numerical). I batch set the author and dates with ACDSee, then generated a script from the spreadsheet to set the caption using exiftool.

 

Once that was done I was able to generate slideshow movies that showed the caption.

[JimDavis79]

Said gently, I do not expect my genealogy software to do every single thing that one might do in the process of chasing my crazy ancestors.  Examples of things I don't do in RM include mind maps, complex timelines, capturing details about places, grabbing details of web sites I encounter during research (see the tool Zotero), managing research logs, to-do lists, publishing stories (in part) and this topic, digital asset management.  I use an older version of Adobe Lightroom so that I don't pay continuing subscription fees, and there are many other choices.  Lightroom provides access to every field in the EXIF and IPTC standards and if used with .jpg files, embeds the data inside the file, where it is unlikely to be lost.  My opinion is that you should choose a metadata master and tolerate the inability of other software to do all things for all purposes.

[TomH]

... I'd really like to see RM use and set metadata...

 

... batch set the author and dates with ACDSee, then generated a script from the spreadsheet to set the caption using exiftool.

 

Once that was done I was able to generate slideshow movies that showed the caption.

 

Interesting. What metadata tags did you use for date and caption?

 

A constraint in RM for captions is the single line edit box and truncation of anything over around 60 characters in the Scrapbook report. Would your captions be that short? The IPTC:Headline is named and described more in line with RM's Caption than any other field I've looked at. The IPTC:Caption-Abstract name sounds fitting but seems to be intended for longer form than Headline so might better relate to the RM Description.

[TomH]

... I do not expect my genealogy software to do every single thing that one might do in the process of chasing my crazy ancestors. 
...  My opinion is that you should choose a metadata master and tolerate the inability of other software to do all things for all purposes.

I agree and I would add that, for many RM users, RM is their (rudimentary) DAMS,MAMS,CMS for things having to do with their family tree. Thus it is their metadata master. So would there be no benefit to being able to transfer the RM metadata for media files to embedded fields within those files?
 
For those users who have invested in DAMS et al software and effort in organising the files and embedding in them their metadata, would there be no benefit in being able to compare the embedded metadata with the RM metadata and transfer some in either direction?
 
There is precedence for some support of embedded metadata in at least one other family tree software; this from the FH6 Help:

[zhangrau]

 

A constraint in RM for captions is the single line edit box and truncation of anything over around 60 characters in the Scrapbook report. 

 

I hadn't thought much about that constraint, so I ran a couple tests.

With Scrapbook Layout left & right margins set to 0.75" the Caption printed 68 characters in Georgia 12-pt Bold

Reducing the left and right margins to 0.3" bumped the character count to 78.

 

In both tests, the Description was limited to 3 lines, same length limit at the Caption.

[Jerry Bryan]

I have a long term project in progress to display all my RM data on the Web with a piece of software called GedSite. GedSite is not marketed by RM and it is designed to work with GEDCOM so that it can work with any genealogy software. However, GedSite has support for certain features that are specific to RM (and also support for certain features that are specific to RM competitors). From what I have seen, RM is the product whose GEDCOM is best supported by GedSite.

 

In particular, GedSite has excellent support for displaying media files. GedSite can display media files in photo albums which are separate from traditional genealogical reports. In this respect, it is similar to using RM's Publisher to produce a "book" with traditional genealogical reports and photo albums as separate chapters. GedSite can also display media files directly directly as a part of facts (e.g., a photo of a headstone as a part of a burial fact) and directly as a part of a citation (e.g., a birth certificate image as a part of a citation for a birth fact). These are things that are easy to do on Web and that are hard or impossible to do in any practical way with printed reports.

 

As a part of it's media support, GedSite will display captions. In the case of GEDCOM from RM, Gedsite can use either the RM caption or the caption contained in the IPTC data for the media file. This seems like a really good approach. And it would make sense to me for RM to be able to populate its own caption field from the IPTC data to avoid the need for double data entry.

 

Despite all that, I do not use GedSite's option for using RM's caption field nor GedSite's option for using IPTC data associated with the media file. Instead, I leave what GedSite considers to be the text for a caption null and instead I add white space to photos and add captions in the white space. This is very low tech, but as I have described in other threads it seems to me that this is the best way to document my photos for posterity. I don't add such captions to white space for media files that are self identifying documents such as birth certificates or census pages. I only had such captions to white space for photos of things like people and places.

 

Jerry

[JimDavis79]

I agree and I would add that, for many RM users, RM is their (rudimentary) DAMS,MAMS, CMS for things having to do with their family tree. Thus it is their metadata master. So would there be no benefit to being able to transfer the RM metadata for media files to embedded fields within those files?
 
For those users who have invested in DAMS et al software and effort in organising the files and embedding in them their metadata, would there be no benefit in being able to compare the embedded metadata with the RM metadata and transfer some in either direction?

 

Please forgive my delay in answering.  Yes, I do think there would be benefit in data transfer between RM and DAMS.  My further comments stem from years of software acquisition management in government and the private sector.  What I learned in trying to build an enterprise data exchange bus (three examples, but there are more) in a shipboard engineering system; for legacy applications at a worldwide IT company; and for a statewide student information system taught me:

 

-- the number of systems with unique data use grows with every inspection.  In this case, the starting list would be RM, the various DAM software, FamilySearch, Ancestry, and so on.  As soon as such a bus was announced, there would be a long list of unique connectors to develop.

 

-- it is nearly impossible to get the developers of individual systems to agree on a data exchange standard for such a bus.  Just look at the varying implementations of the GEDCOM standard, and then look at the interactions between the standards bodies for EXIF, IPTC and XMP.

 

-- the set of user requirements would be very long, and not complementary.  I've always used a Change Control Board with the votes belonging to paid users to prioritize what comes first and what gets done.  Even so, no one gets everything they want.

 

My gut says a limited implementation is possible, only if the developers make choices on what and how they will implement.  If, say, RM decided to implement the IPTC standard, creating and mapping fields from it to RM, then a utility could be fashioned.  That would take a lot of RM-funded effort and development time.  I'd rather RM focus on genealogy matters and RM functionality, leaving only a simple link to photos that I can manage much more easily in a dedicated program.

 

Again, all this is said gently, and I hope my words in no way offend those with different opinions.