MD Template with Use Raw Value returns the Variable itself as its value

[Tveloso]

I have identified some older Files in my IMatch Database that contain GPS coordinates, but IMatch does not consider them to have GPS.  This is not just the issue of the files lacking the "file has GPS coordinates" marker in the File Window (a condition which a Database Diagnostics will correct), but the GPS Data is actually missing from the various GPS Tags that IMatch usually uses (though it can be seen in the GPS record, in the Browser MD Panel Layout).

I found that if I simply Reload Metadata for these files, the condition is corrected (and the GPS Data is mapped into all of the appropriate other tags).  But most of these files have already gone through Face recognition (including the addition of manual Face Annotations), so I would lose all of that work if I did a Reload Metadata for all of them.

The GPS values are visible in the Browser Layout:

    You cannot view this attachment.

...but not in the Default Layout:

    You cannot view this attachment.

...so I set out to create a Metadata Template to copy the GPS into the XMP Tags that the Default MD Panel Layout uses.

After running this MD Template:

    You cannot view this attachment.

...which populated these tags:

Code Select Expand

XMP::exif\GPSLatitude
XMP::exif\GPSLongitude
XMP::exif\GPSAltitude

...from these variables respectively:

Code Select Expand

{File.MD.Composite\GPS-GPSLatitude\GPSLatitude\0|numformat:float,10,6;trim:left}
{File.MD.Composite\GPS-GPSLongitude\GPSLongitude\0|numformat:float,10,6;trim:left}
{File.MD.Composite\GPS-GPSAltitude\GPSAltitude\0|value:raw;cast:int}

...the Tags in the Default MD Panel, now contained the "Variable Strings" themselves (and not the values that those Variables return when used in the VarToy App).

    You cannot view this attachment.

When I removed the formatting from the variables, unchecked the Use raw value option for each Tag in the MD Template, and ran the Template on another file, the Tags in the MD Panel were marked as modified, but they still contained no data:

    You cannot view this attachment.

In both cases the values the variables returned in VarToy were what was expected.  The "Variable alone" returned a "default formatted" value (Degrees, Minutes, and Seconds), and the "formatted Variable" returned a "Forced Raw" value (a Decimal Number).

[hluxem]

so I would lose all of that work if I did a Reload Metadata for all of them.

Not sure if I miss something, but if you write back the metadata like face anotations they will not be lost when you reload metadata . The only thing I'm not sure off are linked faces. They may end up as manual anotations.

I use a metadata template for the attitude. After applying the template the field looks empty, it's only updated after write back. Make sure you write back after applying the template.

Heiner

[Mario]

If you set RAW values from variables, make double-sure that your format is correct, e.g. no decimal comma or groupings.

When you set RAW values, the formatted value will not change unless you write back. IMatch does not update formatted values from RAW since it does not have the logic or algorithms ExifTool has for this.

You can see RAW values in the MD panel when you add the tags with the "Use raw value" option enabled.

The Default layout shipped with modern IMatch versions displays IPTC Location tags and coordinates. The "6 IPTC Location" MD Panel layout shows that data. During write-back, IMatch syncs this data into native GPS data.

Changing EXIF tags (or XMP Exif tags) via raw values from a MD template may not do what you expect it do to.

[Tveloso]

Not sure if I miss something, but if you write back the metadata like face anotations they will not be lost when you reload metadata

Thank you so much Heiner.  You're absolutely right...writing back will of course preserve all that that pending data.  In fact, a Write-Back also causes IMatch to then bring in the "missing GPS Data" when reading the file back in, so there's no need to apply my MD Template.

I guess I've got myself stuck in a self-imposed paradigm of the Write-Back being the very last thing I must do (though there have of course been plenty of times when I've done multiple Write-Backs for a given set of files).

Thanks again.

If you set RAW values from variables, make double-sure that your format is correct, e.g. no decimal comma or groupings.

Mario, I did ensure that the variables I was using did returned a proper "raw value" in VarToy. 

My specific requirement aside, what I was thinking was a bug, is that IMatch actually set the Tags to the "variable String" itself (and not the value I see being returned by the variable in VarToy):

    You cannot view this attachment.

As an expirement, I changed the target Tags on the MD Template to the iptcExt Tags in the Created Structure (which is where I usually see the GPS Data in newly indexed files of this type):

    You cannot view this attachment.

    {File.MD.XMP::iptcExt\LocationCreatedGPSLatitude\LocationCreatedGPSLatitude\0}
    {File.MD.XMP::iptcExt\LocationCreatedGPSLongitude\LocationCreatedGPSLongitude\0}
    {File.MD.XMP::iptcExt\LocationCreatedGPSAltitude\LocationCreatedGPSAltitude\0}

...using the same source variables:

    {File.MD.Composite\GPS-GPSLatitude\GPSLatitude\0|numformat:float,10,6;trim:left}
    {File.MD.Composite\GPS-GPSLongitude\GPSLongitude\0|numformat:float,10,6;trim:left}
    {File.MD.Composite\GPS-GPSAltitude\GPSAltitude\0|value:raw;cast:int}

...and got the same results:

    You cannot view this attachment.

[Mario]

Maybe variables are just not supported for setting raw data. The need to set raw data in a MD template is rare, and maybe I did not want the additional complexity? This works this way since IMatch 5, so probably you are the only person affected. May be a "won't fix" and a note box in the help to let users know.

You can use AutoFill for the same purpose, I guess. It can do raw, and may even support variables for raw values.

[Tveloso]

Just as another test, I performed the same update using the Metadata Mechanic, and got the expected results.

I created three separate presets in MD Mechanic:
    You cannot view this attachment.

...and ran each one in turn.  And as I ran each, I saw the expected values appear in the MD Panel.

In fact, both the iptcExt tag set (seen in the 6 IPTC Location Layout), and the XMP::exif tag set (seen in the 1 Default Layout) were updated with the correct values, even though MD Mechanic updated only the iptcExt tags.

[Tveloso]

Mario, looks like we typed our replies at the same time...

I understand perfectly if you designate this as a won't fix.  This is in fact a very specific condition - created for some older files (from late 2018 / early 2019 - just a few hundred of them) somehow...(some specific set of circumstances? which no longer occur).  So probably not something that would impact many (if any) users.

Now that I have two methods of fixing the issue (simply writing the files back, as Heiner suggested - or performing the update using the Metadata Mechanic), there's no longer an issue for me.

[Mario]

I will look into it for one of the next releases. Since this issue seems to be around for several years without bug report, I'll give it a low priority.

[Mario]

Avoid using Composite tags. They may not exist of be out-of-sync with the actual coordinates IMatch manages in the database until write-back.

[Mario]

I have fixed this for the next release.

[PandDLong]

I have had the same issue as Tony in the past, but found a way around it so it was not too important.

Amazing to see this obscure, low priority issue fixed.


Michael