Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[darichman]

Some testing on 4x test files in 32.0.2
  - Camera file previously imported and tagged in older version of MC (camera metadata plus old MC tags)
  - Camera file newly imported (only camera embedded metadata)
  - Photo downloaded from facebook (no metadata)
  - Photo scanned into Adobe Photoshop Classic (basic metadata)

All files tagged in MC and imported into LR   [Adobe Lightroom]
All files then tagged in LR (default/XMP, IPTC, IPTC extended, EXIF)
Faces not tagged but all other mapped fields tagged
[MC Field] 'LR field'

All as expected (update in both directions)
[MC Fields]
Artist
Caption
City
Copyright
Country
Date
Event
Headline
Keywords
Name
Notes
Source (Supply Chain)
State/Province
Subcategories
Sublocation

Useful LR 'fields' not currently mapped in MC
Intellectual Genre
IPTC Subject Code
Source Type

Common [MC Fields] not currently mapped anywhere in LR
Album

Some errors in bidirectional tagging

• MC [Rating] not updating in LR. LR rating not updating in MC
• If MC [Source (Supply Chain)] tagged, updates LR 'Source'. But if LR 'Source' tagged, updates both MC [Source] and [Source Supply Chain] This is probably a holdover from the temporary mapping to MC [Source] which is custom field for most
• If MC [Image Label] tagged, updates LR 'Label'. But if LR 'Label' tagged, does not update [Image Label] as expected.
• If MC [LR Category] tagged, updates LR 'Category', but if LR 'Category' tagged, [LR Category] not updated in MC. MC [Genre] also updates LR 'Category' so I suspect this may be contributing. Suggest complete unmapping of [Genre] to 'Category' in both directions and update [LR category] from 'Category'
• MC Inconsistently Writing [Comment] to LR 'User comment' (files previously provided, offending files all scanned images, so likely Adobe embedded tags), and tagging LR 'User Comment' does not update MC [Comment].
• [Camera] not mapping nicely as previously described. Suggest consider separate MC [Camera Make] & [Camera Model] fields, and can still create a calculated field [Camera] which can combine the two: [Camera Make] [Camera Model]. Currently, if I adjust camera in MC eg 'MC Camera' then it displays in EXIF/LR as 'Make'=Google (retains the original EXIF) and 'Model'=MC. This is not desired. If it is not possible to create/use the more granular camera fields, suggest mapping [Camera] to both EXIF 'make' and 'model', so at least there is no loss of data.

Test files emailed in a zip to Yaobing

[Yaobing]

Some errors in bidirectional tagging

• MC [Rating] not updating in LR. LR rating not updating in MC
• If MC [Image Label] tagged, updates LR 'Label'. But if LR 'Label' tagged, does not update [Image Label] as expected.

So far I found a bug that prevented MC from reading these tags that were written outside of MC.

Fixed: MC did not read XMP tags "xmp:Label" and "xmp:Rating" from the XMP segment.

However, regarding Rating, I do not see Rating tagged by MC (in your group of images in folder "2a. MC Tagged First").  Check your MC settings and make sure "Rating" field's checkbox "Save in file tags (when possible)" is checked.

[Yaobing]

Some errors in bidirectional tagging

• If MC [Source (Supply Chain)] tagged, updates LR 'Source'. But if LR 'Source' tagged, updates both MC [Source] and [Source Supply Chain] This is probably a holdover from the temporary mapping to MC [Source] which is custom field for most

I don't see an issue here.  "Source" is only mapped to "Source (Supply Chain)" now.

Some errors in bidirectional tagging

• If MC [LR Category] tagged, updates LR 'Category', but if LR 'Category' tagged, [LR Category] not updated in MC. MC [Genre] also updates LR 'Category' so I suspect this may be contributing. Suggest complete unmapping of [Genre] to 'Category' in both directions and update [LR category] from 'Category'

I have just unmapped "Genre" for now. 

Some errors in bidirectional tagging

• MC Inconsistently Writing [Comment] to LR 'User comment' (files previously provided, offending files all scanned images, so likely Adobe embedded tags), and tagging LR 'User Comment' does not update MC [Comment].

I examined the four image files you sent me in December and found no issues?

The text "MC Comment" was written in all files, in UNICODE.  EXIFTool reads all of them correctly, so does XnView MP.

[Yaobing]

Some errors in bidirectional tagging

• [Camera] not mapping nicely as previously described. Suggest consider separate MC [Camera Make] & [Camera Model] fields, and can still create a calculated field [Camera] which can combine the two: [Camera Make] [Camera Model]. Currently, if I adjust camera in MC eg 'MC Camera' then it displays in EXIF/LR as 'Make'=Google (retains the original EXIF) and 'Model'=MC. This is not desired. If it is not possible to create/use the more granular camera fields, suggest mapping [Camera] to both EXIF 'make' and 'model', so at least there is no loss of data.

We made the following changes:

Changed: "Camera" field is made "Clear-only", so users will not be able to change camera Make and Model in EXIF image tags.  Also user-defined custom fields "Make" and "Model" will not be supported in EXIF handling.

Changed: MC will not only remove XMP, IPTC, MJMD image segments, but also remove the entire EXIF segment when executing "Remove Tags".

We made the first change because EXIF specifies that "Make" and "Model" are to be "Freeze 1" type, meaning that they should not be changed except that they can be removed in special circumstances.  These tags are set by cameras and there is no reason for a user to mess with them.

The second change is just because we forgot to delete the EXIF in the past, even as we deleted all other metadata segments.

[Yaobing]

Common [MC Fields] not currently mapped anywhere in LR
Album

As you previously suggested, XMP:event would be a good fit for [Album].  However, I am not sure if we are fully addressing marko's concern:

https://yabb.jriver.com/interact/index.php/topic,136345.msg954376.html#msg954376

Need to be careful with this one...

I have actually embraced MC's method of using the date for [Album]. Where a set of photos benefits from an actual "Album" name, I select them, and enter the desired album name manually.

I have several views based around whether or not the [Album] tag is a date, and, my super-duper "rename, move & copy files" expression, that takes care of all files and media types and is the only one I've used for more than ten years, has rules in there to deal with with whether or not the photo is part of a named album or just a date. They get filed on disk differently.

I would regret any change here that broke these things.

Finally, thank you for your testing and reporting in this thread. I am aware what you need to put into it and it's greatly appreciated. I wish I could be more help, sadly, there's so little time these days

How about:
if the mapped IPTC field is empty (almost invariably will be unless you are importing a file tagged by a photographer using the extended IPTC fields) then use date per current.

If the mapped IPTC field is populated, use that.

If Album actively tagged in MC, write to the mapped IPTC field.

This would preserve your (and my) workflow and allow portability of the field.

marko, does darichman's proposal address your concern?

[marko]

Read it three times, no alarm bells ringing. Go for it, I'll test once it's in. Thanks for asking.

marko.

[darichman]

Thanks all - sorry a few days behind. Sorting out my 4 year-olds birthday (it was a success)

I will catch up with build .06 and do some testing

[darichman]

Hi team - thanks again for the major work in this area. MC is playing very nicely with LR now.
Some screenshots of the below attached in a zipped file, and test files emailed to Yaobing

Have done similar test with Build 32.0.6 and Lightroom Classic 13.1 latest build
  - Camera file previously imported and tagged in older version of MC (camera metadata plus old MC tags)
  - Camera file newly imported (only camera embedded metadata)
  - Photo downloaded from facebook (no metadata)
  - Photo scanned into Adobe Photoshop Classic (basic scanner/software metadata)

All files tagged in MC and imported into LR [Adobe Lightroom]
All files then tagged in LR (default/XMP, IPTC, IPTC extended, EXIF)
Faces not tagged but all other mapped fields tagged
[MC Field] (LR field)

Observations below - just a few little quirks to be ironed out still, and some comments re the [Camera] changes, hopefully for broader discussion

[Artist]
If two artists tagged in MC 'MC Artist 1; MC Artist 2' these display nicely in LR IPTC (Creator) as 'MC Artist 1, MC Artist 2'.
Also, when (Creator) updated in LR to 'LR Artist 1, LR Artist 2' this updates nicely in MC as two semicolon delimited artists. This is great!
Interestingly, in LR EXIF (Artist) only displays as 'MC Artist 1'. (See emailed image 'LR Default Fields.jpeg') however LR is internally consistent with this, as if I edit 'Creator' in LR, it also only displays/updates to 'LR Artist 1' and omits LR Artist 2 altogether.
I don't think this is any issue with how MC is handling the fields so this looks good.

[Rating]
I am still not seeing any interoperability between the two programs.
In the emailed test files, I tagged [Rating] as 3 stars in MC.
In LR, all files display as unrated. I then tagged (Rating) as '4 stars' in LR, but update from tags in MC does not update (still displays 3 stars)

[Comment]
I still see inconsistent updating of 'User Comment' in LR when [Comment] written in MC.
The files where this occurred were all scanned files imported from scanner into Photoshop.  See the emailed test file "Scanned.jpeg"
When I update (User comment) to 'LR User Comment' in LR, MC fails to update [Comment] which still reads 'MC Comment'

[Source]
LR (Source) is updating both [Source (Supply Chain)] (as expected) and custom field [Source]
If you recall, many users were concerned about mapping to [Source] as this they use this custom field in other areas of the program
Suggest unmapping (Source) from [Source]

[Label]
LR (Label) is updating both [Image Label] (as expected) but also custom field [Label]
Similarly, when we were mapping fields, there was feedback not to use [Label] as others used this for tagging music labels.
Suggest unmapping (Label) from [Label] and mapping only to [Image Label]

[Event] / [Album]
[Event] is currently writing to (Event) - tags in MC are read in LR.
But changes in LR (Event) are not picked up in MC [Event]
I note plan to remap [Album] to (Event) which I support!
Suggest unmap (Event) from [Event] and remap to [Album]

[Events]
I have a field in default field in MC called [Events] (semicolon delimited list) which I cannot delete
No fields in my library have an entry in this field. What is the intended use for this field?

[Genre] / [LR Category]
Confirmed Genre no longer mapped and [LR Category] <> (Category) now working fine. Thanks.

(Source Type)
This would be a useful IPTC field that is not supported in MC. Suggest adding [Source Type] with preselected list only.

[Camera]
I note [Camera] now no longer editable. While I understand the rationale, I would like to note some consequences (which are major for my workflow)
I have used this field for years to tag and organise home media.

• Scanners do not often add this metadata. I would previously tag Epson WF-7720 MFC in the [Camera] field for example.
• In not all cases will a phone or a camera create this field. Consider home video files created on your phone or camera. Previously I could tag these in MC too to match the photos taken on the same camera. I can no longer do this. Consider photos edits on phones. Often the [Camera] field is empty, but really should be populated with the phone, so I would usually tag this in [Camera] to match the original. Now this will remain empty and edits will no longer remain with the camera/phone files

I believe above illustrate appropriate use cases for the field.
Notwithstanding this, in my personal workflow I have multiple expressions and custom fields using [Camera] (eg combining [Camera], [Source] and [Artist] to organise in rename file expressions etc). These are now broken unfortunately. It also means there is a legacy of files previously tagged with [Camera] in MC with fragmented EXIF fields that I can no longer correct from within the program.

I appeal for the dreaded 'could it be an option' 'option... would you set [Camera] by default to have 'save in file tags' unchecked, but allow the user to change this if desired? If there is not J River support for writing to (Make) and (Model) fully [this would be my best pick], how about allowing the user to edit [Camera] but just writing this to an MC tag only (ie not back to EXIF)? So read from EXIF but not write? This way we don't lose previous functionality and EXIF data would be untouched. Thanks for considering

[marko]

If there is not J River support for writing to (Make) and (Model) fully [this would be my best pick], how about allowing the user to edit [Camera] but just writing this to an MC tag only (ie not back to EXIF)? So read from EXIF but not write? This way we don't lose previous functionality and EXIF data would be untouched.

For all of the reasons stated, I strongly support this.

[Yaobing]

[Camera] is editable again in build 7.

[darichman]

Yaobing - I have seen the change log and really happy you've taken another look at this. I'm excited about the Make / Model cleaning as well as this is a big reason I edit the field - ie all Nikon together, not various permutations of Nikon, NIKON corporation, Nikon corp etc.

My testing time is weekends so will look as soon as I get the chance. Keen to see Album mapped as well, so thanks 🙏

Aden: I posted below in the build thread, but will do so here as well to keep image tagging discussion together.

If I have [Make] & [Model] fields, and tag them in MC, will this write to EXIF? Will it modify [Camera] in MC? If [Camera] is edited in MC is there any attempt to parse into [Make] & [Model] and update these also? Eg first word goes to Make & rest goes to Model?

[Yaobing]

If I have [Make] & [Model] fields, and tag them in MC, will this write to EXIF? Will it modify [Camera] in MC? If [Camera] is edited in MC is there any attempt to parse into [Make] & [Model] and update these also? Eg first word goes to Make & rest goes to Model?

I disabled separate [Make] and [Model] user fields for fearing that might cause confusion.  If they are still desired, I can enable them.

When [Camera] is edited, MC will update Make and Model by taking the first word for "Make" and the rest for "Model".  If you encounter a specific camera manufacturer who's name needs more than one word, let us know and we will fine tune this.

[Yaobing]

[Artist]
If two artists tagged in MC 'MC Artist 1; MC Artist 2' these display nicely in LR IPTC (Creator) as 'MC Artist 1, MC Artist 2'.
Also, when (Creator) updated in LR to 'LR Artist 1, LR Artist 2' this updates nicely in MC as two semicolon delimited artists. This is great!
Interestingly, in LR EXIF (Artist) only displays as 'MC Artist 1'. (See emailed image 'LR Default Fields.jpeg') however LR is internally consistent with this, as if I edit 'Creator' in LR, it also only displays/updates to 'LR Artist 1' and omits LR Artist 2 altogether.
I don't think this is any issue with how MC is handling the fields so this looks good.

It looks like LR is not treating "creator" (XMP) and "By-line" (IPTC) as arrays.  Both are arrays in their respective definitions.

I see a similar issue with XnView MP, which does not treat ObjectAttributeReference as an array and displays only the last element of the array.

[Rating]
I am still not seeing any interoperability between the two programs.
In the emailed test files, I tagged [Rating] as 3 stars in MC.
In LR, all files display as unrated. I then tagged (Rating) as '4 stars' in LR, but update from tags in MC does not update (still displays 3 stars)

I sent you an email with a sample image about this one.

[Comment]
I still see inconsistent updating of 'User Comment' in LR when [Comment] written in MC.
The files where this occurred were all scanned files imported from scanner into Photoshop.  See the emailed test file "Scanned.jpeg"
When I update (User comment) to 'LR User Comment' in LR, MC fails to update [Comment] which still reads 'MC Comment'

Fixed.  The issue appears to exist if you tagged an image first in MC, then outside and bring it back to MC.  The "Comment" field is mapped to EXIF, and MJMD, and not in XMP.  We were reading from MJMD before we tried EXIF.  Now we will read from EXIF before MJMD (for "Comment" only).

EDIT: Well, the fix was for MC to read the tag written by LS.  I am not sure if we still have issue with LS reading the tag written by MC.  If we still have an issue, I think it may be on LS side.  I noticed that in some of your sample images, tagged by LS after MC tagged them first, LS attempted to "correct" what MC had written, but then abandoned it, and wrote new "User Comment" tag in a different location.  The "correction" it tried to make is to change "Unicode" flag written by MC to "ASCII", and the text "MC Comment" is changed from Unicode text to ASCII text.  It makes me wonder if LS handles Unicode or not.

Even though the text "MC Comment" is fully ASCII, I still write it in Unicode because that simplifies coding, with no need to distinguish whether the text requires Unicode.

[Source]
LR (Source) is updating both [Source (Supply Chain)] (as expected) and custom field [Source]
If you recall, many users were concerned about mapping to [Source] as this they use this custom field in other areas of the program
Suggest unmapping (Source) from [Source]

[Label]
LR (Label) is updating both [Image Label] (as expected) but also custom field [Label]
Similarly, when we were mapping fields, there was feedback not to use [Label] as others used this for tagging music labels.
Suggest unmapping (Label) from [Label] and mapping only to [Image Label]

Fixed.

[Event] / [Album]
[Event] is currently writing to (Event) - tags in MC are read in LR.
But changes in LR (Event) are not picked up in MC [Event]
I note plan to remap [Album] to (Event) which I support!
Suggest unmap (Event) from [Event] and remap to [Album]

Not a bug.  If you have "Event" custom field, it will be saved in MJMD, even though we no longer save to XMP's "event" tag.

Try setting "Event" and "Album" to different values, then copy the image to a different location and/or different filename, and import it.  You will see that they will be imported separately, without interfering with each  other.

[Events]
I have a field in default field in MC called [Events] (semicolon delimited list) which I cannot delete
No fields in my library have an entry in this field. What is the intended use for this field?

Good question.  All I can say is that it is not mapped to any image tags.

(Source Type)
This would be a useful IPTC field that is not supported in MC. Suggest adding [Source Type] with preselected list only.

Will look into this.

[Yaobing]

(Source Type)
This would be a useful IPTC field that is not supported in MC. Suggest adding [Source Type] with preselected list only.

None of the images you recently sent to me contain this tag.  In IPTC specification they have "DigitalSourceType" (Iptc4xmpExt:DigitalSourceType [URI <External>]).  Perhaps this is what you referred to?

In their specification, they want an URI stored.  In an sample image from them, the value is "http://cv.iptc.org/newscodes/digitalsourcetype/softwareImage"

Each of these URIs lead you to a description.  The list of them is here

http://cv.iptc.org/newscodes/digitalsourcetype/

I am inclined to use the descriptive string in the image file directly, but I am not sure how bad a violation to IPTC spec it will be.  I would like to see how LR handles this.

[Yaobing]

Regarding [People] field:

We extract a list of persons in an image from a tag called Region - here it means a region of the image.  This is a complicated structure that includes a mandatory property called Area - for example a rectangle whose top-left corner is x% from the left edge of the image, and y% from the top of the image, and whose width is w% of the width of the image, and height is h% of the height of the image.  If the region contains a person, the region's Type property would be "Face", and the Name property contains the person's name.

Since [People] field in MC is only a list of names, there is no way we can save that into this same structure that has a lot more info.

IPTC does specify a different tag, called "PersonInImage".  That one is more in-line with our [People] field.  However, if we just write a list of names to this tag, without touching the Region tag, we might create inconsistencies.

So I am not sure what we should do.

I can imagine one day, we might implement a "Region tagger" tool, by displaying a preview of the image, and let users select a region, and enter the Type and Name of the selection ("Face", "Yaobing", or "Pet", "Lucky" for example).

[EnglishTiger]

Yaobing - was a mistake made when adding the New "State/Province" Field/Tag to MC as its flags are set to all "Media Types"?

[Yaobing]

Yaobing - was a mistake made when adding the New "State/Province" Field/Tag to MC as it's flags are set to all "Media Types"?

The "State/Province" field was added long before I started working image tagging.  So I don't know if the intention was to use it for all media types.  In theory all media types can benefit from it.

[darichman]

This is all really coming together - awesome work!!

[Camera]
I like the way this works and am happy not to need separate [Make] and [Model] fields.
Would you be happy to document exactly what tidying MC does? Things I have observed:
  First word is written to (Make) and rest to (Model).
  Some tidying of capitalisation.
  [Camera]= This is a Camera. MC writes 'This' to (make) and 'is a' to (model), suggesting it strips 'Camera'

[Comment]

I sent you an email with a sample image about this one.
Fixed.  The issue appears to exist if you tagged an image first in MC, then outside and bring it back to MC.  The "Comment" field is mapped to EXIF, and MJMD, and not in XMP.  We were reading from MJMD before we tried EXIF.  Now we will read from EXIF before MJMD (for "Comment" only).

EDIT: Well, the fix was for MC to read the tag written by LS.  I am not sure if we still have issue with LS reading the tag written by MC.  If we still have an issue, I think it may be on LS side.  I noticed that in some of your sample images, tagged by LS after MC tagged them first, LS attempted to "correct" what MC had written, but then abandoned it, and wrote new "User Comment" tag in a different location.  The "correction" it tried to make is to change "Unicode" flag written by MC to "ASCII", and the text "MC Comment" is changed from Unicode text to ASCII text.  It makes me wonder if LS handles Unicode or not.

Even though the text "MC Comment" is fully ASCII, I still write it in Unicode because that simplifies coding, with no need to distinguish whether the text requires Unicode.

Yes, there does seem to be some incompatibility with how MC is writing [Comment]... for some files, where Photoshop has written a 'User Comment' nothing I do in MC seems to trump this. (See attached 'Comment Field Discrepancy.jpeg)

[Rating] confirmed is working fine. Yaobing & I have emailed about this.

[Genre] is writing to (Intellectual Genre) and vice versa

[Album] is writing to (Event) and vice versa

(Source) when edited in LR is still updating both [Source (supply chain)] and user field [Source] in MC
  I note you said fixed above

(Label) when edited in LR is still updating both [Image Label] and user field [Label] in MC
  I note you said fixed above

(Source Type) in Lightroom has 5 preselected options (see attached Source Type.jpeg)

[People] : I will give this some more thought and testing
Was thinking of some possible solutions but not sure of the complexity

Location Data
There appears to be some issue with how MC is displaying lat & long data (see GPS Data screens)
  Eg in LR EXIF (GPS) 27°52'31.53" S 153°20'50.48" E
  in MC [latitude] 27°52'31.530000000000058"S  [longitude] 153°20'50.4799799999999266"E
Running 'locate on google maps' from Right click Menu in MC fails

[darichman]

[People]

Regarding [People] field:

We extract a list of persons in an image from a tag called Region - here it means a region of the image.  This is a complicated structure that includes a mandatory property called Area - for example a rectangle whose top-left corner is x% from the left edge of the image, and y% from the top of the image, and whose width is w% of the width of the image, and height is h% of the height of the image.  If the region contains a person, the region's Type property would be "Face", and the Name property contains the person's name.

Since [People] field in MC is only a list of names, there is no way we can save that into this same structure that has a lot more info.

IPTC does specify a different tag, called "PersonInImage".  That one is more in-line with our [People] field.  However, if we just write a list of names to this tag, without touching the Region tag, we might create inconsistencies.

So I am not sure what we should do.

I can imagine one day, we might implement a "Region tagger" tool, by displaying a preview of the image, and let users select a region, and enter the Type and Name of the selection ("Face", "Yaobing", or "Pet", "Lucky" for example).

I am not sure how familiar you are with how it all works in LR and Adobe suite. I have used a few pieces of software for facetagging over the years - Picasa initially, which stored the coordinate data + Face name in an XMP tag, Google photos which is highly automated and does not store anything in the file metadata (so completely limited to the google photos interface) and now LR. I have not used Apples offerings. IMO Lightroom has the most comprehensive options as

• has automatic face recognition with ability to set confidence threshholds etc
• ability to manually select an area that represents a face with a drag square tool, for instances where the software does not recognise a face. This is missing from Google.
• Face views, allowing user to rename a face, view all instances of a face etc

Some screens of LR facetagging attached.

How tagging works in LR

• user can run facetagging and name/approve suggestions
• user can manually add a face using a square rectangle tool
• the Face names are written to (Keywords), with coordinates stored (these are not visible to the user in any field, but when in face view the rectangles are visible with face named (see screens)
• So keywords in LR might read Chris Roberts, Sally Evans, Birthday, Beach (first two tagged Faces and second two generic keywords). You can have more sophisticated hierarchies but that's how it works by default
• When tags are read or updated in MC, the Face names are read in both [People] and [Keywords]. So essentially the Face Names are duplicated in [People] and in [Keywords]

MC does somehow know how to differentiate the 'Face Name' keywords into [People], as other (Keywords) are not also written to [People]. But it would be ideal not to duplicate People in both [People] and [Keywords] if possible

I see three options for MC to handle this, although option 3 might be a far reach

Option 1
MC can correctly distinguish between (Face Names) and generic (Keywords), mapping (Face Names) to [People] but not to [Keywords]. This may be possible, as you are already pulling the data into [People] per above.

MC has no ability to tag faces, but can read Facetags written by LR, ignoring and not making any use of the coordinate/region (face map) data. Updating the name of a [People] entry should ideally write this back to the face tag, but preserving the coordinate/region data.

In this option, all 'Face' tagging would be relegated to Lightroom.

Option 2a
Per Option 1, but MC also reads the coordinate/region data, and this can be toggled in photo views, displaying the face (see how it looks in LR in the attached screen).

In this option, MC can read but not write the coordinate data so can make use of it in views but not create or modify the Face tag coordinates.

Option 2b
As above, but MC can create manual face tags that are interoperable between MC and LR.

In this option, MC can read and write the coordinate data but the process is completely manual - ie no 'facial recognition'

Option 3
MC incorporates face recognition.
3a: Recognises a face is there but no effort to link it to existing faces
3b: Full facial recognition. Recognises this is a face and also recognises it as Chris Roberts.

I have no concept how difficult this would be, but sense is that even the big companies find this hard.

Personally, if MC could achieve 2a or even 2b I would be really happy.
Yaobing, I am happy to send some test files that are facetagged if helpful

[darichman]

Location Metadata
All of the relevant IPTC & EXIF location fields are now supported in MC.
In my post above I noted that MC displays the data a bit weirdly, with an accented A character I don't understand:
     153°25'35.8599600000000152"E
This prevents an effective Google Maps search

Thinking forward, there are a few ways MC could improve photo location tagging and functionality

GPS Data Available? Automatically fill Country, State, City, Sublocation
...from Google Maps or any alternative GPS/location database

Lightroom has a setting "Look up city, state and country of GPS coordinates to provide address suggestions"
In the location fields, you can then accept suggestions (denoted in italics) which are written to the tags (see in attached pics)

If MC were able to do something similar, could either:

• Right click > Update location fields from GPS Data
• Offer suggested values in the tag window which user can endorse (probably harder as would need to dynamically search this, difficulty if multiple files are selected)

It seems like this data could pretty easily be queried, with only greyzone how granular sublocation should be...
You can see in my MC tag window for location I have some legacy user fields I need to sort out (Suburb, Subplace)
Sublocation may be defined by some as a suburb or smaller area within a city, or by others as a venue or place (eg name of a restaurant). As there is no additional location field to use, moving forward I will use the location hierarchy:
   [Country]\[State]\[City]\[Sublocation] but conflate suburb & venue with a \ within the field (eg [Sublocation] = Southport\Macintosh Park)
   Eg Location nested views would display: Australia\Queensland\Gold Coast\Southport\Macintosh Park

MC Could set some default image views with a calculated Location field [Country]\[State]\[City]\[Sublocation] with collapsible nesting. This would work great in panes as could expand country > state etc

GPS Data Available? View Photos on Maps
Right click > 'Locate on Google Maps' isn't currently working from me (per above).

In ideal iteration, any number of image files (or whole library) could be viewed in an interactive map view from within MC.
Zooming in on the map narrows the photos displayed, or zooming out expands the number of photos displayed based on whether or not they appear in the area of map viewed.

Lightroom has a Map Module, selectable from the top menu bar, which allows you to bring up a map of any photos in your view or library. You can click on little bubbles which display a number of photos, and the actual photos are displayed in a view below. Ie the map is used to filter the photo view. You can 'drag' sets of photos around as well if you wanted to adjust the location, and GPS data is updated. Screenshot attached.

Google Photos uses a 'heat map style' map view based on number of photos, shown from Google Photos. Screenshot attached. This is purely for viewing (no changes can be made)

GPS Data Missing? Fill from Google Maps
Would be great if there was a Right Click > Fill GPS Data from Map
  Launches a map. User can search the map, or zoom/navigate the map, to the desired location, drop a pin, or drag and drop photos, and GPS coordinates (+ location fields per above as a bonus) are written to the file.

Incorporation of these would put MC in a category of its own, with unsurpassed library organisation, support for image tag standards and dynamic time-saving tagging features.

[Yaobing]

Location Metadata

The latest beta build should fix the GPS display issue.  Thanks for the great suggestions.

[Yaobing]

RE: [People]

I did consider something like Option 1 in your post.  It is inadequate.  If in the existing tags there are two people, say "Jim" and "Nancy".  You decide one or both of the names is wrong and change them to "Jack" and "Nora".  How do we determine which is meant for which?  Perhaps we can just use the ordering and  that seems to be the only logical choice.  What if you add a third person?  We can not do anything about it as we don't have the coordinates of the region.

So I think Option 2, with the ability to do manual face tagging,  is much better and that is something I should aim at.

Option 3 is a lofty ideal 
It likely involves AI work, and we likely don't have the resources, both man-power and data,  to do that.

 

[darichman]

So I think Option 2, with the ability to do manual face tagging,  is much better and that is something I should aim at.

Yes please

Option 3 is a lofty ideal 

I agree. If I want to do automatic tagging with tag compatibility, I will do in Lightroom - and hope for cross compatibility with MC as much as possible

Re Fixes:

3. Changed: When writing [Comment] field to EXIF "User Comment" tag, MC will determine the encoding method (Unicode or ASCII) according to the actual text, instead of using Unicode for all, to improve compatibility with other Apps that may not handle Unicode correcctly.

[Comment] and (User Comment) are working perfectly for me now in both directions. I understood about 5% of your fix Yaobing, but it seems to have worked!

1. Fixed: MC loaded XMP "Source" and "Label" tags into custom "Source" and "Label"fields after it already loaded them into stock "Source (Supply Chain)" and "Image Label" fields.  It should now only read these tags into the two stock fields.

Confirmed - the user fields [Label] and [Source] are no longer updated. Thank you.

1. Fixed: When reading GPS tags from image EXIF segment, Longitude and Latitude were displayed incorrectly, with the degree symbol mangled.

Looking good. Right click > Locate on Google Maps now works again also.

3. NEW: Added a new field "Digital Source Type" for image media type and mapped it to the XMP DigitalSourceType tag.  Users can select from a controlled vocabulary list.

Working and compatible in both directions

[Event]
[Event] is written to (Event) and read in LR. Tagging of (Event) in LR if previously tagged in MC does not update MC
Attached 'Event Inconsistencies.jpeg - tagged in both programs


[LR Category]
Observations re [LR Category] and (Category)
When MC writes [LR Category], LR only reads the first 3 characters, no matter what I enter in MC. 'MC Category' becomes 'MC' in LR... 'This is a category' becomes 'Thi' etc (see screenshot)
In LR I can enter a string of any length, and when updating library from tags in MC the full length string is read...
Maybe something similar to the [Comment] (User Comment) glitchiness?
[Subcategories] and (Other Categories) work fine.

I would make one last final appeal (for consistency) to rename
   [LR Category] to [Image Category] and [Subcategories] to [Image Subcategory]
   [Source (Supply Chain)] to [Image Source]   
These would sort/view nicely with [Image Label] in tagging views etc. Of course not critical. I like neatness

General Comments
I wrote in an earlier thread, my goal was to get to the point where I can do as much of my image tagging in MC as possible, and use LR or other software to fill in gaps. MC now supports pretty much all useful EXIF/IPTC/LR XMP tags both read & write. The gaps are now few:

• MC cannot use a map to tag location coordinates
• MC cannot use location coordinates to fill [Country], [City], [State], [Sublocation]
• MC cannot tag faces, per above - some suggestions given
• MC reads the colour labels, but does not use any colour labels in views

So notwithstanding any editing of the image file itself, on the tagging front a user would only need to use Lightroom or other software for location updating and facetagging. This is pretty great!!

[Yaobing]

[LR Category]
I have noticed one field acting strangely [LR Category] and (Category)
When MC writes [LR Category], LR only reads the first 3 characters, no matter what I enter in MC. 'MC Category' becomes 'MC' in LR... 'This is a category' becomes 'Thi' etc (see screenshot)
In LR I can enter a string of any length, and when updating library from tags in MC the full length string is read...
Maybe something similar to the [Comment] (User Comment) glitchiness?
[Subcategories] and (Other Categories) work fine.

As I mentioned before, IPTC core's Category tag allows only three characters, three char codes for a controlled vocabulary list.  If you type a free text not corresponding to any item in the list, your text gets chopped.  If you enter a "allowed phrase", for example, "Crime, law and justice" MC will save a 3-char code ("CLJ") in the image file.  If you enter "Crime, law and justice" in MC, will LR read it correctly?

XMP does not have this restriction.  By preferring XMP over IPTC core, MC avoids the issue.  Apparently, LR does the opposite, and reads only (?) from IPTC, not from XMP?

[Yaobing]

[Event]
[Event] is written to (Event) and read in LR. Tagging of (Event) in LR if previously tagged in MC does not update MC
Attached 'Event Inconsistencies.jpeg - tagged in both programs

Remember that MC now only maps "Event" to MC's [Album].  The teddy bear image you attached imported into MC correctly, with "LR Event" appearing in [Album] field.  If you also have an "Event" custom field, MC imports "MC Event" into it (from your sample image).  That is because the image still has the "Event" data saved in the MJMD section.  These are now two separate fields ([Album] and [Event]), and they import data independently and should not be consistent with each other.

[darichman]

If you enter "Crime, law and justice" in MC, will LR read it correctly?

Yes, it does - if I enter the above string LR reads as 'CLJ'.

XMP does not have this restriction.  By preferring XMP over IPTC core, MC avoids the issue.  Apparently, LR does the opposite, and reads only (?) from IPTC, not from XMP?

Yes it seems you are correct. Thanks for clarifying - I don't think we can maximise compatibility any further here

[darichman]

Remember that MC now only maps "Event" to MC's [Album].  The teddy bear image you attached imported into MC correctly, with "LR Event" appearing in [Album] field.  If you also have an "Event" custom field, MC imports "MC Event" into it (from your sample image).  That is because the image still has the "Event" data saved in the MJMD section.  These are now two separate fields ([Album] and [Event]), and they import data independently and should not be consistent with each other.

I have done these tests so many times that [Event] was still in my test views views, and I went into automatic mode comparing the two Brain fart, especially after rallying for the Event & Album support in the first place! Thanks Yaobing - sorry for making you test again.

For those that use MC for image management (not sure if this is a big or small group) I'm sure many will take it for granted that the fields just 'work' now, and will be portable with other software. But I do want to thank you for investing time into this. There could be more improvements, sure, and I will continue to use this thread to fight the image cause, but I feel happy to roll this out on my photo library now Again, huge thanks.

[marko]

Epic work. Thank you both. Truly sorry I was not able to get more involved.

[JimH]

It was Yaobing who won the day, with his usual patience and persistence!  Thanks, Yaobing.  And thanks, darichman for helping so thoroughly.  Your testing reports were invaluable.

[gappie]

We wanna thank Yaobing and darichman. especially my wife, who does the image tagging inside MC (no LR), likes the way this is going.
Looking forward to the updates.

Thanks a lot
       
Elly & Gab

[Paul Coddington]

For those that use MC for image management (not sure if this is a big or small group) I'm sure many will take it for granted that the fields just 'work' now, and will be portable with other software.

This is great news and a welcome update.

Does version 32 have color management yet?

[JimH]

MC cannot use location coordinates to fill [Country], [City], [State], [Sublocation][/li][/list]

Now it can!  https://yabb.jriver.com/interact/index.php/topic,138885.0.html

[darichman]

Now it can!  https://yabb.jriver.com/interact/index.php/topic,138885.0.html

I have seen! And it's glorious.
I have done some Facetagging and Geocoding testing and posted in both respective threads
Thank you guys for the image love