Skip to main content
Participating Frequently
April 25, 2015
Question

Face image region data written according to XMP-mwg-rs, but NOT read by LR.

  • April 25, 2015
  • 2 replies
  • 16158 views

Great to see that LR CC writes face data to XMP-mwg-rs tags (jay!), according to Metadata Working Group (i.e. Adobe, Microsoft, Sony, Nokia, and others) extension of XMP. See  Image Region Metadata, Section 5.9 in the Metadata Working Group Spec.

---- XMP-mwg-rs

RegionAppliedToDimensionsW      : 1768

RegionAppliedToDimensionsH      : 2656

RegionAppliedToDimensionsUnit   : pixel

RegionRotation                  : -1.43512

RegionName                      : Benoit Gindele

RegionType                      : Face

RegionAreaH                     : 0.04897

RegionAreaW                     : 0.03262

RegionAreaX                     : 0.59858

RegionAreaY                     : 0.72477

RegionRotation                  : -1.52229

However, LR does NOT read and process existing XMP-mwg-rs written by other software, e.g. Picasa  (Nooooooo!).

Picasa in turn reads and shows XMP-mwg-rs tags created by LR CC flawlessly.

With large collections this is obviously a severe limitation for moving to LR, as well as for general interoperability. Adobe went half the way.

Thousands and thousands of clicks to go, again...

This topic has been closed for replies.

2 replies

Participant
May 6, 2015

Here is what I found that fixed the problem for me

Below is the solution to get face tags from windows photo gallery to Lightroom for me. Be sure to backup your files.


*** Backup your files ***

Move people names to keywords for Lightroom. Do this if you're using lightroom, do not do it if you're using picassa. I haven't yet been able to check to see but I'm guessing I will have to "convert it to a person tag" in lightroom keywords since they show as descriptive tags but I have tested everything else.

With Exiftool, open the command prompt and navigate to the folder with exiftool in it:


Add the people names to the keywords

exiftool "-xmp:subject+<regionname" FolderName -overwrite_origional_in_place -m -r


This came from:

Migrating from WPG to Lightroom 6 - People Tags

johnrellis
Legend
April 26, 2015

Upload to Dropbox or similar a sample pic from Picasa that shows the problem and post the link here.  That will let us identify the specific issue and file a bug report/feature request.

GintonicAuthor
Participating Frequently
April 27, 2015

This image has a named face image region applied through Picasa:

https://dl.dropboxusercontent.com/u/13499200/IMG_0903.JPG

Exiftool output:

---- XMP-mwg-rs

RegionAppliedToDimensionsW      : 3264

RegionAppliedToDimensionsH      : 2448

RegionAppliedToDimensionsUnit   : pixel

RegionName                      : Nicoletta S.

RegionType                      : Face

RegionAreaX                     : 0.778799

RegionAreaY                     : 0.18076

RegionAreaW                     : 0.0649509

RegionAreaH                     : 0.10335

RegionAreaUnit                  : normalized

When importing the file, LR CC does not seem to read and process the XMP-mwg-rs tags.

Neither does the name show up in the People list, nor does it show the region area and the associated name in the corresponding interface.

As mentioned in opening post, going the other way works: Images with named regions added through LR CC are recognized by Picasa, added to its list of people and can be processed through its face region overlay interface, i.e. renamed, moved, deleted etc.

johnrellis
Legend
January 29, 2017

johnrellis wrote:

...

The core issue is that LR represents named faces using both MWG regions and keywords, whereas Picasa apparently just uses MWG regions. When LR imports a Picasa photo, it correctly imports the region and the name attached to the region. But because Picasa didn't also record a keyword for that person, LR didn't attach any keyword to the photo on import. I don't see anything in the MWG Guidance that prefers the behavior of one program over the other in this situation.

If Picasa didn't record a keyword for that person, then why does Lr create a keyword for that person?  As shown in the screenshot above, Lr created a Person Keyword for Nicoletta Stanescu, but didn't associate the keyword to the photo from which it got the metadata for the keyword.  To be consistent with your explanation, it seems like Lr should not create a keyword at all.  However I would prefer it create the keyword AND associate it to the photo

IMO, Lr should either not create a keyword at all, or ... create the keyword AND associate it with the photo. Seems like they went halfway which is causing this confusion.


What you and the others have requested -- for LR to be able to read Picasa's face metadata -- is an entirely reasonable feature request. You might wish to add your me-too vote and detailed opinion to this existing feature request in the official Adobe feedback forum: Lightroom feature request - Import Picasa face recognition data | Photoshop Family Customer Community

It would be straightforward to implement: LR is already creating the keyword for an imported face name, and it would be simple to also assign that keyword to the photo, regardless of whether the keyword appears in the XMP:Subject or IPTC:Keywords fields.

To be consistent with your explanation, it seems like Lr should not create a keyword at all.

LR's behavior matches my explanation.  When LR encounters a Metadata Working Group region with a face name, it creates the face rectangle in the LR catalog and a keyword for the face name, associated with that face rectangle.   When LR encounters a keyword in the XMP:Subject or IPTC:Keywords fields in an imported photo, it assigns that keyword to the photo. This behavior is entirely consistent with the MWG standard, but it clearly isn't desirable for people trying to import Picasa photos, since Picasa doesn't put the face names into XMP:Subject or IPTC:Keywords.

The core issue here is that LR and Picasa use the metadata fields in different ways to represent faces and people, and the MWG standard doesn't have anything to say about that (unfortunately).