- 1Compare RM5 and Image File Metadata
- 1.3Some Observations and Reservations re Automatic Synchronisation
- 2Copy RM Image Metadata to Image File (Picasa compatible)
- 3Copy Image Metadata from JPG to RM
- 4Further Considerations
- 4.1Inline comments
- 4.1.1Comment: There is a flaw in the above to be co...
Compare EXIF, IPTC, XMP metadata stored in image files to the Caption, Description and other metadata stored in a RootsMagic 5 database for image files linked to its Media Gallery and copy between the files and the database.
The principles and procedures outlined here, while based on the way Picasa uses metadata stored in image files, are applicable with appropriate modifications to relating other photo managers to RootsMagic 5.
Compare RM5 and Image File Metadata
I use Picasa to manage my collection of photographs and other media and often write captions in Picasa’s picture editor for photos that I upload to Picasaweb online albums. Of course, working in RootsMagic, I get to write captions and descriptions for some of the same photos and for many others that I may not have captioned in Picasa. LessTX and others have asked that RM have some capability of using metadata fields stored in the image files as a way of loading values into RootsMagic or storing them in the image (e.g., Insert Image Metadata into Database and some of the results in this search of the RootsMagic Forums). This sounded attractive on the surface and so I have looked into it further.
One result can be seen in this screenshot of a query in SQLite Expert Personal (which displays the thumbnail images, unlike most other SQLite managers):
Under the left red box is the media caption and description metadata stored in the RootsMagic 5 database in the MultiMediaTable, along with the thumbnail image, image file name and path. Under the right hand box are the values extracted by ExifTool from the Caption-Abstract and Description metadata fields stored in the image file by Picasa. With this convenient comparison of the two sources of the image metadata, I can readily see discrepancies between the two and take any needed corrective action in the corresponding application.
Some Observations and Reservations re Automatic Synchronisation
I’ll describe how I developed this query after discussing some of my observations and reservations about automatically synchronizing the captions and descriptions between the RootsMagic database and the images.
- Picasa ver 3.8.0 and RootsMagic 18.104.22.168
- Picasa stores the same value in both the Caption-Abstract and Description tags in the image (but I cannot account for one example above of several that have a Caption-Abstract value but not Description – perhaps it was written by an earlier version). Therefore, there cannot be a 1:1 relationship between the RootsMagic metadata fields and the image’s metadata fields.
- Neither RootsMagic nor Picasa have a low limit on the length of the string that can be stored in their respective places. However, the RootsMagic caption should be constrained to be quite short because so little space is provided for printing it in the one place it is used, a Scrapbook report. If the Description is also included in the Scrapbook, then both Caption and Description values must be severely limited. Picasa displays captions most generously in its slideshows, less so in the Photo Editor and to 16-60 characters under its variably zoomed thumbnails.
- Given these significant differences, I cannot see a way of automatically copying from the metadata stored in the image file to the RM fields, without following up to edit them into appropriate sizes. The reverse may be more successful: concatenate the RootsMagic fields and copy the same value to both Caption-Abstract and Description tags in the image file.
- That said, the use of the image file in a Picasa Album might dictate a quite different caption from that used in a RootsMagic Scrapbook report (just as some users were dismayed to discover that in upgrading from RM4 to RM5 they had lost the ability to have a different caption for the same image when associated with different persons, events, etc. – the usage dictates the caption).
- Therefore, caption copying must be manually controlled, except for copying to blank fields which, nonetheless, is liable to require manual follow-up.
- Although these observations are specific to RootsMagic 5-7.6 and Picasa, the RM constraints also apply in the general case and the conclusions may not be significantly altered, except for the possible maintenance of the separation between Caption and Description.
- I have not explored whether there is any appropriate image metadata tags that may correspond with RM’s media Date and Reference Number.
- Copy the windows command line shell sqlite3.exe from the sqlite-shell-win32-x86-3nnnnnn.zip file downloaded from the Precompiled Binaries for Windows section of sqlite.org to a folder of your choosing. The batch file below expects it to be in C:\Program Files (x86)\SQLite but that can be revised to suit.
- Install exiftool.exe from ExifTool in a folder along with all of the related batch files and sql scripts. It could be located elsewhere if you revise the batch file accordingly.
- Download RM5comparePicasa.bat (rev 2020-05-31) to the common folder.
- Create a shortcut to the batch file RM5comparePicasa.bat with the Target property [“C:\yourpath\RM5comparePicasa.bat” “C:\yourpath\yourRMdatabase.rmgc”], enclosing the database path in double quotes. Name the shortcut something like “RMcomparePicasa yourdatabase“. Make such a shortcut for each database you want to review.
- Download ImportPicasaDescriptions.sql to the common folder
When you click on the shortcut, it launches the batch (or Windows command) file with the path to your database file passed to it in the %1 register. The batch file deletes the old files it created in a previous run and then proceeds to build a short sql script GetImageListFromRM.sql. Then it calls sqlite3 to open your database file and run the script which outputs the results of the query to the ExifTool arguments file RMimagefiles.args, to which it then appends the -execute argument. The args file contains the list of JPG files with full pathnames recorded in the RM5 database Media Gallery. 
Next the batch file calls ExifTool to go through the list of image files, find them if it can, and extract the values from the Caption-Abstract and Description tags along with the paths and file names to a new file, ImageDescriptions.txt. There’s a pause to review any possible error reports in the command window, e.g., file not found. 
Now the batch file calls sqlite3 again to open or create the local database RM-Media.db3, creates PicasaTable with four columns matching those in the tab-delimited ImageDescription.txt and imports the latter into the table. 
That’s it for the batch file, except to generate instructions as to what to do next:
Open RM-Media.db3 with your SQLite manager (SQLite Expert Personal if you want to see the thumbnails), copy and run some SQLite statements the batch generated. 
If everything worked as intended, you should see results like this screenshot (adjust column widths to suit, of course).
ve3meo Jan 22, 2012
There is a flaw in the above to be corrected if there are multiple image files with the same file name in different paths. It has been correctly done in the RM5copyMetaDataToRM query.]
Copy RM Image Metadata to Image File (Picasa compatible)
This is basically a query in RM-Media.db3 (created and updated by the Compare utility with the RM5 database attached) to extract the list of files for which RM has a caption and the image file does not, along with the concatenation of caption and description values, and getting those into a file in the format required for ExifTool arguments with the appropriate arguments to tell ExifTool to write the value into the Caption-Abstract tag of the image files, and then run ExifTool against the args file. All this is managed by a batch file as was done for the Compare procedure. Here is an example showing how the RM5 Caption + Description end up being displayed as a Picasa caption.
This was a very tricky procedure to finally get going and resulted in considerable hair loss! The arguments for ExifTool must be one per line so carriage return/line feed controls (CR/LF) in the RM5 values must be replaced. Thus the white space above the URL in the RM Description disappears in the Picasa caption, the CR/LFs being replaced by periods.
This same difference applies in using ExifTool to copy the metadata from the image to RM: ExifTool itself substitutes a period for CR/LF embedded in the metadata values. Thus metadata values on either side containing CR/LF cannot be exactly replicated on the other, at least with ExifTool as the intermediary.
- sqlite3.exe and exiftool.exe are already installed as above
- download RM5copyMetadataToImageFileExifToolArgList.sql to the same folder as RM-Media.db3
ve3meo Jan 22, 2012
There is a flaw in the above to be corrected if there are multiple image files with the same file name in different paths. It has been correctly done in the RM5copyMetaDataToRM query.]
/* RM5copyMetadataToImageFileExifToolArgList.sql */ SELECT '-Caption-Abstract=' || REPLACE(CAST(RM.Caption AS TEXT),x'0D0A','.') || ' ' || REPLACE(CAST(RM.Description AS TEXT),x'0D0A','.') || CAST(X'0D0A' AS TEXT) || RM.MediaPath || RM.MediaFile || CAST(X'0D0A' AS TEXT) || '-execute' || Pic.ROWID || CAST(X'0D0A' AS TEXT) AS Args FROM MultiMediaTable AS RM INNER JOIN PicasaTable AS Pic ON RM.MediaFile COLLATE NOCASE = Pic.MediaFile WHERE (RM.Caption IS NOT NULL OR RM.Description IS NOT NULL) AND (Pic.Caption LIKE '-' AND Pic.Description LIKE '-') ;
- RM5copyMetadataToImageFileExifToolArgList.bat.bak Download to the same folder: (Remove .bak extension added to bypass some systems’ security)
ECHO OFF ECHO .ATTACH DATABASE '%1' > RM5copyMetaData.sql ECHO < RM5copyMetadataToImageFileExifToolArgList.sql >> RM5copyMetaData.sql
- Download RM5copyMetadataToImageFile.bat.bak to the common folder and remove the .bak extension
- Create a shortcut to the batch file RM5copyMetadataToImageFile.bat with the Target property [“C:\yourpath\RM5copyMetadataToImageFile.bat” “C:\yourpath\yourRM5database.rmgc”] and name it something like “RM5copyMetadataToImageFile – yourdatabase“. Make such a shortcut for each database you want to copy captions from.
ECHO OFF REM RM5copyMetadataToImageFile.bat REM REM Build sql file ECHO ATTACH DATABASE '%~1' AS RM ; > RM5copyMetaData.sql TYPE RM5copyMetadataToImageFileExifToolArgList.sql >> RM5copyMetaData.sql "C:\Program Files (x86)\SQLite\sqlite3.exe" RM-Media.db3 < RM5copyMetaData.sql > RM5copyMetaDataToImageFile.args ECHO . ECHO Check RM5copyMetaDataToImageFile.args before proceeding to write to the image files PAUSE exiftool -@ RM5copyMetaDataToImageFile.args > RM5copyMetaDataToImageFile.log ECHO . ECHO Finished copying captions to image files PAUSE END
First run the Compare utility against your database to ensure that the RM-Media.db3 is up-to-date with the current metadata from all of the images used by the database. Then click on the shortcut “RM5copyMetadataToImageFile – yourdatabase“. The Windows Command console will open and, almost immediately, you will asked to
Check RM5copyMetaDataToImageFile.args before proceeding to write to the image files
Open the file (in the folder common to all of the .bat and .sql files you have installed as instructed above) with a non-wrapping text editor and note that each file is addressed by a triplet of three lines and an empty line after as:
-Caption-Abstract=Obituary - Colin xxx North Bay Nugget - Aug 13, 1956 C:MyDocsFamilyTreeHolxxxScrapbookxxxxxxn, Colin - obituary - 1956.jpg -execute2 -Caption-Abstract=Registration of birth of Helen xxx 13 C:MyDocsFamilyTreeHolxxxScrapbookxxxxxxth, Helen Elizabeth - Birth Register xxx13.jpg -execute3 ...
There should be nothing else in this args file than the triplets of single lines as above. The number following -execute is the PicasaTable rowid, which may be useful in tracking down a problem if ExifTool encounters a bad image file (I think it will report that number in its error message).
Then, press any key to launch ExifTool to work on the list of files. ExifTool copies each file to a .jpg_original file and re-writes the .jpg file with the new Caption-Abstract value added.
After some time, proportional to the number of files being processed, you will see the message “Finished … Press any key to continue.” Because the batch file is really basic with no error-trapping, you will see this message regardless of errors. It’s possible that no file may have been processed. Inspect the file RM5copyMetaDataToImageFile.log for any error message.
Assuming no errors, if Picasa is set to monitor the folders where these image files are located and was running at the time they were being revised by ExifTool, you will have seen the little pop-up message from Picasa as it updates its thumbnails and its internal storage of captions for searching. The ability to search through captions is one of Picasa’s strong features, along with its facial recognition and multiple views: Albums, People, Folders.
Copy Image Metadata from JPG to RM
This procedure is trivial compared to the opposite direction. The heavy work has been done in the Compare… procedure, which should be carried out before attempting to copy metadata to the RootsMagic database as the Copy… relies on the RM-Media.db3 database created and updated by Compare… The only operation that makes sense to me that would benefit from such a procedure is to copy multiple image files’ Caption-Abstract values to empty RootsMagic captions for those files. Copying onto existing captions is necessarily a manual process and could be done with copy/paste between the applications.
This is essentially a SQL query against both the RootsMagic database and the RM-Media.db3 database. However, it’s complicated by the fact that I cannot figure out a way to make a single UPDATE statement work for multiple captions so a batch procedure is needed to generate a sql script file with multiple UPDATE statements, one per caption to be copied, and run that.
- requires sqlite3.exe command line shell as above
- Download RM5copyMetadataToRM.sql to the common folder:
-- RM5copyMetadataToRM.sql -- generates an UPDATE statement for each blank caption in RM for which there is a caption extracted from the image file -- requires RM-Media.db3 with the RM5 database ATTACHed SELECT 'UPDATE MultiMediaTable SET Caption=(SELECT Caption FROM PicasaTable WHERE ROWID=' || PicID ||') WHERE MediaID=' || MediaID ||';' AS Statement FROM ( SELECT MediaID, Pic.ROWID AS PicID FROM MultiMediaTable AS RM INNER JOIN PicasaTable AS Pic ON REPLACE(RM.MediaPath || RM.MediaFile, '', '/') LIKE Pic.MediaPath || '/' || Pic.MediaFile WHERE Pic.Caption NOT LIKE '-' AND RM.Caption IS NULL ) ;
- RM5copyMetadataToRM.bat.bak Download to the common folder: (Remove .bak extension added due some systems’ security)
ECHO OFF REM RM5copyMetadataToRM.bat REM Copies to blank RM5 captions the values from Caption-Abstract metadata stored REM in the corresponding image files REM Uses PicasaTable in RM-Media.db3 created by the related Compare routine REM and the MultiMediaTable of the target RootsMagic 5 database. REM Requires the sqlite3.exe command line shell REM REM Build and run sql script file that generates UPDATE statements for each caption to be copied ECHO ATTACH DATABASE '%~1' AS RM ; > RM5copyMetaData.sql TYPE RM5copyMetadataToRM.sql >> RM5copyMetaData.sql "C:\Program Files (x86)\SQLite\sqlite3.exe" RM-Media.db3 < RM5copyMetaData.sql > RM5UpdateCaptions.sql REM REM Build and run the sql script file that UPDATEs the target RootsMagic 5 database captions ECHO ATTACH DATABASE '%~1' AS RM ; > RM5copyMetaData.sql TYPE RM5UpdateCaptions.sql >> RM5copyMetaData.sql ECHO Check RM5copyMetaData.sql before running the caption UPDATEs PAUSE "C:\Program Files (x86)\SQLite\sqlite3.exe" RM-Media.db3 < RM5copyMetaData.sql ECHO Blank RM5 Captions Updated PAUSE END
- Create a shortcut to the batch file RM5copyMetadataToRM.bat with the Target property [“C:\yourpath\RM5copyMetadataToRM.bat” “C:\yourpath\yourRM5database.rmgc”] and name it something like “RM5copyMetadataToRM – yourdatabase“. Make such a shortcut for each database to which you want to copy captions.
First run the Compare utility against your database to ensure that the RM-Media.db3 is up-to-date with the current metadata from all of the images used by the database. Then click on the shortcut “RM5copyMetadataToRM – yourdatabase“. Follow the on-screen instructions. Use RootsMagic to check the new captions.
- The two unidirectional copy caption to blank caption procedures could be combined into one batch and made to standalone without the need for the Compare… procedure to be run in advance.
- A comparison between RM’s Caption + Description and the image file’s Caption-Abstract by substituting the CR/LF’s in the former with periods might be feasible.
- If MetaData comparisons and copying/editing were part of a future RM feature or outboard utility, it would be desirable to have a directional choice per image where there are non-blank values in both.
- What relationship should there be between RM’s Date and Reference Number fields and any EXIF, IPTC, or XMP tag?
- What changes may be needed for compatibility with media managers other than Picasa?
- LessTX wish1 LessTX wish2 vyger wish vyger wish2 Athena’s 2008 wish
14 Replies to “Media Metadata, Read, Write, Compare with Picasa #media #metadata #picasa”
So I tried this verbatim with RM7 and had some problems: I was just doing the first step, the generation of the compare of image metadata to RM caption/description data.
Specifically the issues I encountered are:
1. When I run the batch file alias, I always get an error:: Invalid TAG name: “execute ”
(But the script still runs ok.)
2. I get a bunch of “Error: File not found …” errors (for about 16 files): I am guessing it is because of the characters in the file name (Unicode characters in filename not supported??)
I can and do continue after the above errors: the script of course is programmed to tell you what to do, it says this (this is verbatim except I have changed a couple strings to anonymize the text):
Open RM-Media.db3 with your SQLite Manager, copy and run the following statements
ATTACH DATABASE ‘”C:\Users\MYUSERNAME\Documents\06.Genealogy\0.RootsMagic Genealogy DB-MYSURNAME\MYSURNAME Genealogy.rmgc”‘ ;
SELECT RM.MediaFile COLLATE NOCASE, Thumbnail, RM.Caption COLLATE NOCASE AS RMcaption,
CAST(RM.Description COLLATE NOCASE AS TEXT) AS RMdescription, Pic.Caption AS MetaCaption,
Pic.Description AS MetaDescription, Pic.MediaPath FROM MultiMediaTable AS RM
INNER JOIN PicasaTable AS Pic ON RM.MediaFile COLLATE NOCASE LIKE Pic.MediaFile ;
So I run next SQLiteExpert Personal 22.214.171.1246 64 bit and open the RM-Media.db3 file, select PicasaTable in RM-Media database on left side of SQLiteExpert and in the SQL tab on the right paste the text as instructed (“ATTACH DATABASE …LIKE Pic.MediaFile ;”):
The result is a popup error window titled “SQLiteExpertPers64” indicating this error text:
near “;”: syntax error
ATTACH DATABASE ‘”C:\Users\myusername\Documents\…path_to_my…\RootsMagicDB.rmgc” ;.
Any ideas on what the issue could be? (I am totally new to SQL: no idea what the syntax issue could be.)
(FYI, I have unifuzz64.dll downloaded, but did not load that in this case since RMNOCASE sorting does not appear to be used, so I assume it is not required.)
Wow, 8 years have gone since that was published and we have transferred thepage from WikiSpaces to WordPress. I can see that transition has corrupted code blocks on the page (but should have had no effect on the attached files), notably the loss of the backslash character in the quoted filepaths. It will take me some time to fix those errors but somehow you seem to have progressed further than where they appear.
“-execute” is an argument for ExifTool so I assume the “Invalid Tag name” error report is from it. If that is systemic, then there should be no point in proceeding beyond that error.
Are you saying the “file not found” error is only for a subset of the files processed and that the rest are ok?
The “near “;”: syntax error” looks to be the imbalanced single quotation mark around the path in the ATTACH statement; needs the closing ‘.
This script predates my discovery of unifuzz so it used the COLLATE NOCASE workaround. You could delete all those and load unifuzz – might have a bearing on the “file not found” errors.
FYI the error is not about “-execute” but “-execute ” (not the added space, if that makes a difference).
The “file not found” is only on a subset of file, which I noticed all happen to have unicode in the names…
So the 1st thing I want to try is unifuzz:
However I always get “Error: The specified module could not be found.”
I have tried all obvious syntaxes…any ideas on how to get this to load?
I have changed a line in the batch file thus:
ECHO .mode tabs > GetImageListFromRM.sql
ECHO .load “unifuzz64.dll” > GetImageListFromRM.sql
ECHO .mode tabs >> GetImageListFromRM.sql
I have tried all different kinds of syntax in the .load line with no luck (with and without quotes/path/.dll extension…!): any ideas how to get this to work?
(All files in the same c:\bin directory!)
The command line executable sqlite3.exe is a 32-bit app so you must load the 32-bit unifuzz.dll extension.
I’ve gone through the page and corrected visible errors which proved to be a learning curve trying to use the newish block editor introduced to this site when we upgraded recently from WordPress 4 to WP5. Haven’t yet tried running the procedures and may not have done so since first publishing them. Since then, SQLite and SQLite managers have gone through many changes and we now have Windows PowerShell. And ExifTool now has its own site and may also have changed. If it all works as originally written will be a testament to backwards compatibility!
OK thanks for the help: the 32/64 bit thing helped solve the unifuzz error!
The missing files error was indeed due to unicode: I solved this by adding an exiftool argument up front (after -T) : “-charset filename=utf8 “.
Still having I think minor issues, but will work on this further now to get all the way done … I think I am almost there.
Good work. I’m now working through the instructions and encountering what you describe.
There are trivial errors that you have found you can ignore, arising from the 3
ERASE commands in the batch file to remove the files from a previous run. If those files do not exist, you get the “file cannot be found” error. Next time you run it, no such error. I didn’t learn enough Windows Command syntax to figure out how to test the files exist and make the erase conditional.
The “Invalid TAG name: “execute “” I have not looked into but it seems to be only a warning.
The “near “;”: syntax error” stemming from the ATTACH statement seems to be the result of two changes in SQLite, I think. One is that it now seems that the filepath must be enclosed in either single quotes or double quotes but not both. 8 years ago, I think if the filepath had a space character in it, the ‘”filepath”‘ syntax was necessary for ATTACH. Double quotes are necessary in the shortcut to pass the whole string to %1 and the batch command.
The other error around the ATTACH statement is that it must now end with “AS schema-name”. So RM5comparePicasa.bat now reads:
ECHO ATTACH DATABASE %1 AS RM; –enclose unquoted filepath in either single or double quotes if none
OK, so I seem to be mostly OK until I try to execute SQL on the new RM-Media database: I still get an SQL error.
Please refer to this image:
(1) Batch file executes OK except for error about “execute” – that seems exiftool related but the exiftool “ImageDescriptions.txt” file is created and seems OK for content
(2) I copy the SQL that batch file displays
(3) In SQLite Personal 64 bit I do two things: load 64 bit unifuzz, then paste and exceute the SQL code: this gives an SQL error as shown in the image. 🙁
Any idea what the issue is?
I know nothing really of SQL, but according to this page:
The ATTACH command syntax is this:
ATTACH [DATABASE] ‘filename’ AS database_name;
Is that a change from when you first wrote this page? Your ATTACH command has no “AS database_name”, and uses double AND single quotes around the filename of the database.
So I changed that first line of SQL to the following:
ATTACH DATABASE ‘”C:\bin2\cdb.rmgc”‘ ;
ATTACH DATABASE ‘C:\bin2\cdb.rmgc’ as CDB;
Ta-da! That seemed to fix it.
The only issue is the output just shows “(blob)” in the thumnail column, so maybe SQLite Expert Personal no longer supports display of JPG thumbnails?
Also the text does not wrap as shown in your screen shot: every item is on a a single-height line: text is simply cut-off if the column is too narrow, it does not wrap like in your screenshot.
Ah, you posted while I was still composing. We’re on the same page, now.
I was surprised to see just (blob) using SQLite Expert Personal 5 but it is simply a setting. Tools > Options > Grids > Show images
And wordwrap is an option in the same area called “Cell auto-height”.
That -execute warning is a mystery to me. The line:
ECHO -execute >> RMimagefiles.args
appends -execute to that file. Commenting it out results in an error message for every line in ImageDescriptions.txt being imported into the PicasaTable and a null result.
This pc doesn’t have Picasa so I’m hazy on what metadata tags it used and whether I can see them with Windows File Explorer. I’m seeing nothing in the PicasaTable for its set of media files.
I’ve just uncovered another change in the way things work. I couldn’t understand why running the Compare procedure across JPG files that included some from my Picasa era it was retrieving nought from the metadata. Back then, according to what I wrote, Picasa stored its caption in either or both Caption-Abstract and Description and those are the names that once worked as arguments for exiftool.exe. I’m beginning to think my files were stripped of the Picasa metadata.
This page provides some useful clues: http://metadatadeluxe.pbworks.com/w/page/47662311/Top%2010%20List%20of%20Embedded%20Metadata%20Properties
I can add IPTC:Caption-Abstract value using the exifToolGUI app and retrieve it with the exiftool statement as written. I tried to write to EXIF:Description using exifToolGUI but it was rejected. The above reference for Description shows EXIF:ImageDescription under Description for Picasa (along with IPTC:Caption-Abstract) and I could add that tag. To retrieve it, the exiftool argument has to be changed from -Description to -ImageDescription.
Because you are starting from a different metadata management software, perhaps you have used other tags for your captions. In any case, there will be revisions needed in the arguments passed to exiftool.
Meanwhile, I may try revisiting my old computer with Picasa (not sure if that’s one or two ago) and see if there are still JPGs on it with Picasa metadata.
I need to correct some misinformation in that previous comment. The -Description argument for exiftool.exe was and still is valid. In the ExifToolGUI shell for ExifTool.exe, I thought I had to enter it in the Workspace Definition as -exif:Description and that was rejected so, based on that reference I cited which showed Picasa using exif:ImageDescription I tried it and it was accepted. I’ve now found that all I had to enter is -Description and can now retrieve values from both iptc:Caption-Abstract and a Description tag of unknown family.
What’s got me even more unsettled (because these procedures did work) is that my working set of image files associated with my RootsMagic databases is now devoid of either Caption-Abstract or Description values. Yet I have found (browsing with ExifToolGUI) copies of the files with that metadata in an old RM6 style website generated in 2016 (each image in three sizes, all with the metadata copied from the RM caption and description by my procedure). And another set that may have gone through an even more convoluted process involving FTM and Ancestry.ca before coming back to RM as renamed files in one folder but with the metadata intact. The latest image file was 2014 and the latest with the caption from RM 2013.
Somewhere along the way, not only did I change computers (twice) but I also consolidated the media under a Google Drive folder. I must have had duplicated files and overwritten or discarded those that had caption+description written from RM. Bummer. That’s one of the risks with the metadata tucked away out of site in the usual user interfaces.
Auto import of image metadata (Family Historian Forum) https://www.fhug.org.uk/forum/viewtopic.php?f=32&t=12761&sid=35da5d0834d058ad78067c5bf468cc43