Print

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

[Daydream]

Not sure if Daydream, Marko & others have thoughts on applications, use case of these fields.

I'm late and you guys have been doing a bang-up job grinding at details to get them just right. My number one pick is IPTC [Headline]. In a lot of cases I've seen it provides a much more to-the-point description of what is going on in a photo than [Caption]. That succinct info is much easier to use for filtering or metadata post-processing. This last part is very dear to me. A lot of software out there can read photo metadata. But MC has the Expression Language. Once fields can be read a lot of options open up, to extract specific parts from said metadata, to rename things, etc.

[darichman]

Thanks Daydream.

Hoping to keep up the momentum and get as full a suite of field compatibility as we can (while it's fresh in your heads Matt, Yaobing and team ) Do you think Headline should map from [Name] or be its own field? Currently, [Name] is by default pulled from just the filename.

JRiver team, how are things looking for these ones, at a minimum?

Based on above, some requests/suggestions to finetune compatibility with Adobe software:

• Could [Album] be mapped to IPTC 'scene'
• You mentioned a new 'ImageTitle' EXIF field coming with EXIF 3.0 - is this version waiting MC incorporation or has it yet to be released? Failing this could we possibly get MC to write [Name] to XMP 'Title' and IPTC 'Headline', as will avoid conflict with 'User Comment' if [Comment] also written (I use [Comment] for purpose distinct from Name). The documented use of IPTC 'Headline' is "a brief synopsis or summary of the contents of the image". I am not sure if the same ASCII limitations would apply to these fields?
• Could we please add a [Sublocation] to map to IPTC 'Sublocation', completing the locations fields (used for a venue etc, for example the name of a restaurant or theme park, as a 'subplace' within the suburb)
• Could MC's rating be mapped to LR's 'Rating'?
• Can we create a field [Source] and map to IPTC 'Source'. I already have a custom field for this purpose, called [Source] (mine is a list field) - ie where the image was obtained
• Can we create a field [Label] (or Photo Label if this is too vague) and map to Adobe XML 'Label' - these are user customisable labels in Lightroom, which correspond to colours that can be toggled in views. Lightroom will recognise 4 values, with anything else coming under 'White'. Tagging documented here.
• Regarding your comments about the [Camera] field - there are some instances where would make sense this is editable - my scanner does not write this field, but I use MC to tag 'Epson WF7720' for example'. Would you consider exposing 'Make' and 'Model' as editable fields (?[Camera Make], [Camera Model]) and then having [Camera] set as an uneditable calculated field from those two fields?
• There are two IPTC Category fields (Category and Other Categories). Currently, [Genre] is mapped to 'Category'. Would we consider creating [Category] to map to 'Category', and potentially map [Genre] to 'Other Categories' as this seems a better fit

[rblnr]

Well understood on aspirational, more complicated that more pressing stuff, and perhaps out of the wheelhouse of this thread.   Just mentioned it because it’s the feature I’d find most useful at this point. 

Thanks for the reply!

[darichman]

Well understood on aspirational, more complicated that more pressing stuff, and perhaps out of the wheelhouse of this thread.   Just mentioned it because it’s the feature I’d find most useful at this point. 

Thanks for the reply!

We're with you though! One day, and baby steps

Gentle weekly bump on closing out the IPTC/EXIF/XMP support

[JimH]

Gentle weekly bump on closing out the IPTC/EXIF/XMP support

Keep it up!  We're with you.  Thanks again for your patient efforts.

[Daydream]

Do you think Headline should map from [Name] or be its own field? Currently, [Name] is by default pulled from just the filename.

In my opinion [Headline] should be it's own thing, for 2 reasons: compatibility with other software and safety/readability. It's supposed to be more succinct than [Caption], but it's still a string field. Could get something in it that's very long.

Generically I'd say [Title] <-> [Name], [Headline] <-> [Headline], [Caption] <-> [Caption] / [Description].

[darichman]

In my opinion...
Generically I'd say [Title] <-> [Name], [Headline] <-> [Headline], [Caption] <-> [Caption] / [Description].

This sounds sensible to me

[darichman]

31.0.64 (10/2/2023)

1. Changed: Internal change in EXIF reading and writing.  Testing is appreciated.

I will try later this week. Anything I should be looking out for?

[markf2748]

• Could [Album] be mapped to IPTC 'scene'

This one has me puzzled.  There is no IPTC 'scene' listed in the reference below, only a numeric 'Scene Code'.

In any case, in MC I think of [Album] as more general than 'scene' since in the usual sense a picture Album would typically contain many scenes, and a scene could include many individual pictures.   I think the existing MC tag [Places] covers the idea of 'scene'.

In MC this seems a natural and logical tag organization:

[Album]="Trip to NYC"
   [Places]="Times Square"
   [Places]="Central Park"
   [Places]="Empire State Building"

Perhaps the mappings should be
[Album] <--> IPTC 'Event Name'
[Places] <--> IPTC 'Location shown'

Reference: See "Scene Code", "Event Name", and "Location shown in the image" in  https://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata

[Yaobing]

31.0.64 (10/2/2023)

1. Changed: Internal change in EXIF reading and writing.  Testing is appreciated.

I will try later this week. Anything I should be looking out for?

Just check and see if you see anything weird happening.  There should be no functionality (such as field mapping) change.  I just made some internal data structure change in preparation for new field mapping. 

[darichman]

Just check and see if you see anything weird happening.  There should be no functionality (such as field mapping) change. I just made some internal data structure change in preparation for new field mapping.

Thanks Yaobing. I have done my routine tests of importing files from different sources, tagging them, then importing into Google photos and lightroom. Have not run into anything unexpected. I have now also tried tagging in LR and updating MC library from tags (comments below)

This one has me puzzled.  There is no IPTC 'scene' listed in the reference below, only a numeric 'Scene Code'.

In any case, in MC I think of [Album] as more general than 'scene' since in the usual sense a picture Album would typically contain many scenes, and a scene could include many individual pictures.   I think the existing MC tag [Places] covers the idea of 'scene'.

In MC this seems a natural and logical tag organization:

[Album]="Trip to NYC"
   [Places]="Times Square"
   [Places]="Central Park"
   [Places]="Empire State Building"

Perhaps the mappings should be
[Album] <--> IPTC 'Event Name'
[Places] <--> IPTC 'Location shown'

Reference: See "Scene Code", "Event Name", and "Location shown in the image" in  https://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata

Thanks Mark. To clarify, my references to IPTC fields in the earlier posts are from how they are displayed in lightroom in default views (see attached image) which I'm guessing isn't a one for one with the IPTC standards. That suggests to me that even lightroom refers to the IPTC standard fields in different ways, as some of the fields you mentioned are not displayed in default IPTC fields in lightroom and you have to go drilling down to extended views. It might be a whole other job to map that out too (I'm not sure I have the emotional fortitude for this!!) There is a view called IPTC extension which shows some of the fields you have mentioned. I would argue that the location shown should be linked to the Sublocation, City etc fields - interestingly when these are set in MC they do not display in the 'location shown' fields in the extended IPTC view (see picture). I am not sure why there are differences in the Image Location fields and Location shown fields (compare both attached pictures).

So it might mean a balance between MC mapping to fields that are not too obscure and actually used in other software and settings, and fields that make semantic sense. I guess it has to be intuitive, and interoperable re compatibility. Does anyone else use these IPTC fields in any other setting? My experience/use case (and therefore preferred solutions targeted) between Adobe and MC, so I recognise this is not the only use case. I would like album to appear somewhere in lightroom (and vice versa)

I will split my post as becoming big.

[darichman]

Updated summary of field mappings.
Test software MC 31.0.65, Adobe Lightroom Classic v12
____ below indicates not currently mapped in that program

[MC] <> [Lightroom]
[date] <> EXIF date time original + EXIF date time + IPTC date created
[name] <> title
[artist] <> EXIF artist + IPTC creator
[camera] <*> awkward compatibility as MC combines EXIF Make + Model
[comment] > EXIF user comment
[caption] <> IPTC description
[Genre] <> IPTC category, would it be possible to change this to map to a new MC field [Category]
_____ <> IPTC other categories, would it be possible to change this to map to [Genre]
_____ <> IPTC [Scene]
_____ <> IPTC [Headline]
_____ <> IPTC sublocation
[City] <> IPTC city
[State/Province] <> IPTC state
[Country] <> IPTC country
[Keywords] <> Keywords
[People], partial mapping compatibility, see comments below
_____ <> IPTC source
[Copyright] <> Copyright

Existing fields in MC not mapped anywhere:
[Rating] - ?map this to LR XMP rating?
[Album] - ?map to IPTC event

Fields in LR not currently mapped in MC (not complete list but ones I would use here):
IPTC headline - ?new field [Headline]
IPTC Sublocation - ?new [Sublocation] field
IPTC Source -?new [Source] field
IPTC other categories - see comments below re Category and Other Categories

Test of tagging in LR, then updated library from tags in MC
Following fields updated: [Date], [Name] (from LR title), [Artist], [Caption] (from description), [Keywords] (correctly as list), [Label] (this is new, thanks!), [Country], [State/Province], [City]. [Copyright]
Fields not updated in MC: [Comment] (set in LR 'user comment') and obviously all fields above that don't have an equivalent field in MC yet.

Some quirkiness in some fields

• [Label]: Thank you(!!!) for supporting this - this one will have a huge impact on my workflow. One quirk to iron out: if multiple colour labels set in LR, only one will show in MC. Could this be made a list? As possible to tag multiple colours/labels in LR. Bonus: some ability in MC to overlay a colour in thumbnail views, with toggle on/off
• [Genre]: I tagged Category as 'LR category' in lightroom. In MC this displays only as 'LR' under [Genre]
• I would suggest new field [Category] (mapped to IPTC 'Category') and [Genre] mapped to IPTC 'other categories'. Propose both as list fields as photos may belong to multiple categories and subcategories. If concern for impact of Genre for other media types, maybe just keep things separate and create new list-type fields [Category] and [Subcategory]?
• [People]: If photo is facetagged in LR, MC does a great job of pulling into [People] as a list. One small issue is that MC changes capitalisation (?title case) - I tagged a face as LR person, and MC populated [People] with 'Lr person'
• [People]: Another quirk with facetagging in LR is that LR will also add the face name as a keyword (I feel like this might be a setting - I will try to clarify). This means that when 'update library from tags' is run in MC, then the people will also be added as keywords. This isn't ideal, but I'm not sure a way around this in MC as Adobe is writing to both.
• [People]: If a photo is facetagged in LR, MC's library is updated to reflect this, and then in MC's [People] field you 1) edit a name or 2) add a name, in neither case is this reflected in LR. This gets complicated. Would it somehow be possible for MC to write any name edits to be reflected in LR fields? I can't see how adding a new person in [People] from MC would work though, as MC does not have facetagging ability so there is no 'face' in LR to match it to.
• [People]: More problematic even, is that if you do make any edit to the [People] field from MC at any time, then no subsequent changes made in LR through facetagging will be inherited when you do an 'update library from tags' in MC. Where is MC storing this [People] info? I would say if I have more uptodate facetagging in LR then there should be a way to force MC to overwrite it's own [People] tag with the facetagging data

Regarding the [People] handling, proposal:

• If LR facetagging data exists, use this to populate [People] (per current), else use IPTC person shown to populate
• If no LR facetagging data exists, and user manually types into [People] in MC, write to IPTC 'person shown' (not currently happening)
• Any edits to [People] tag (or update tag from library) in MC should populate IPTC 'person shown'
• If LR facetagging data exists and user edits an entry in [People] (eg changes spelling of name), also write back to XMP face if this is somehow possible?
• If there is existing MC [People] data without LR facetag data, and facetag data is later entered in LR, then update library from tags should prioritise LR face XMP info in populating [People] (and therefore IPTC 'person shown') - may require comment from others, but I would argue if someone has taken time to facetag that should be source of truth for this field. In absence of MC one day incorporating facetagging

Will do some more testing. Am loving seeing these fields cross-populate - it's honestly wonderful!

[Yaobing]

Thanks Daydream.
IPT
Hoping to keep up the momentum and get as full a suite of field compatibility as we can (while it's fresh in your heads Matt, Yaobing and team ) Do you think Headline should map from [Name] or be its own field? Currently, [Name] is by default pulled from just the filename.

JRiver team, how are things looking for these ones, at a minimum?

IPTC Headline seems to be a good choice for [Name].  IPTC also has "Title", but seems to be more like an ID, or filename. I forgot Daydream's comment, which makes sense.

I will be tackling items on your list one-by-one.

Yesterday I made an attempt to support EXIF 3.0.  What I did was to map [Name] to its new tag ImageTitle.  The problem I am seeing is that other applications are not yet supporting EXIF 3.0, so we may end up with incompatibility with other apps.  For example, Windows Explorer still tries to get ImageDescription tag for image title, and does so only if the text is ASCII.  So I think I will pause EXIF 3.0 support (for now, just map [Name] to both ImageTitle and ImageDescription).  The most important addition to EXIF 3.0 specification is the support for UTF8 text.  I will gradually add those, and hope other apps will catch on too.

In the meantime I will turn my attention to IPTC.

[darichman]

Excellent, thanks Yaobing. What you say makes sense re EXIF 3.0. Not always sensible being right on the cutting edge (I work in healthcare )

Let us know if can do anything

Cheers, chris

[Yaobing]

MC's [Rating] is already mapped to XMP's Rating.  So I don't know what LR does with this, but after tagging a photo in MC with a rating of 5 stars, it shows up in XnView MP as a Rating of 5, under XMP tab.   [EDIT] I verified with Lightroom (I have LR 4.0 on my computer).  Editing Rating in LR, and save, the result is reflected in MC after updating the library.

Reading some of the IPTC specifications, I understand the concept of sublocation is a bit fuzzy and they therefore created "Location Shown" and "Location Created".  For example, a photographer standing somewhere (location created) takes a picture of a skyscraper a mile away (location shown).  Too many details in my opinion 

 

[darichman]

Noted! There may be some quirks dependent on in what order tagging occurred... MC first, LR first, existing tags edited in either program, were there existing tags in the file not created in either program. I think I tagged the rating in MC initially, but saw it did not show in LR so just assumed wasn't supported. I can try this again.

Once a few more of the fields are in there I will try to systematically troubleshoot in these contexts.

Re location created/shown - Yeah, I don't think that degree of granularity is needed personally. I just want to be able to tag sublocation (I already have a 'suburb') but am not picky about which field it's mapped to.

Thanks again

[Yaobing]

[Label]: Thank you(!!!) for supporting this - this one will have a huge impact on my workflow. One quirk to iron out: if multiple colour labels set in LR, only one will show in MC. Could this be made a list? As possible to tag multiple colours/labels in LR. Bonus: some ability in MC to overlay a colour in thumbnail views, with toggle on/off

Reading this, I am confused.  We did not have any mapping related to "Label", until I added some code yesterday (not built yet).  I did not create a new "Label" field in MC yesterday, but it would work if you have a custom field named "Label".  Using LR 4 that I found existing on my computer, I was able to put a "label" in an image.  How does a list label work in LR?  Can you email me an image that has multiple labels saved by LR (and perhaps with as many other tags saved as you care about)? 

[darichman]

Absolutely - I have emailed you four test files, tagged in LR per the attached images showing EXIF, IPTC and default fields.

Re Labels you are correct - I had a custom field called [Label] (this was previously used for music record label). So MC must be reading the LR entry in the tag if you just create a custom field. I was also wrong about Lightroom and labels - you can only assign one at a time in LR. If I add two 'labels' in MC it just shows as White (custom) in LR, not 'both' colours.

I read this in a thread about the matter:

Code: [Select]

Lightroom has a Default Color Label Set defined that assigns the 5 standard colors to defined label values. A sixth color (white) (Custom) is assigned to any label value not in the Active Color Label Set. A seventh color (gray) is assigned to any label field that is undefined (empty)

The Default Color Label Set assigns the red Color to the Label value “red” and so on all the way to purple.

There is another color label set that assigned these same 5 colors to the Label values that Bridge uses.
You can define you own five label values to colors and create your own label set. I have one that assigns colors to the label designating the status of my images at a glance. For example in my Color Label Set, the color Purple (the only one not assigned by a Hotkey) assigns the label “To Be Worked” to an image. I add this automatically on import and change color labels assigning different labels to my images as they are being worked (A red color indicates “Complete and in a Published Service”.

Lightroom only gives you 5 colors and white and gray. And you can only have one Color Label Set active at a time. Any labels not matching the current color label set will get the white indicator in the Filter bar.

So, for example, in lightroom I have defined the labels as:
Red           To Edit
Yellow   Date Error
Green   Complete
Blue   Faces Missing
Purple   Facetagged
White   Custom (anything else)
Grey           Unlabeled

If I haven't added a label, it defaults to grey. If any other label (not To Edit, Date Error, Complete, Faces Missing, Facetagged) added manually, then it appears white in LR. So theoretically should be able to have user enter anything they want in MC, and if it matches your colour labels in LR the colour should appear correctly in LR. Eg if I tag 'Date Error' in [Label] in MC it should appear as Yellow in LR. It sounds like this basic functionality shouldn't be too hard to implement in MC. It would be a wonderful bonus to also implement the actual colour labels but that would be more development work for you I'm sure

[Daydream]

A few thoughts in no particular order:
- I almost spilled my coffee reading about the EXIF 3.0 reference earlier in the week. Indeed that's too new.
- new fields added working very well (Headline, description, etc). Thanks!
- @darichman: you're hardcore, man, with your labels! I'll... keep my distance. 

Some more organized thoughts:
- we'll probably need a relatively controlled environment to test things, cause stuff gets named differently depending on application. I'm in favor of LR 12.x cause it's Adobe the company we all love... to hate; and Exiftool (12.6 and up with ExifTool GUI 6.2 and up) cause it's free, up to date, and available on multiple platforms. ACDSee, XnViewMP, IrfanView for people at large that may or may not be hardcore about their tags.
- I guess everybody can build their own, but maybe at some point MC will adapt its template for Image tags to something that resembles IPTC + Exif. Right now it takes a bit of scrolling up and down to catch the more exotic fields, when comparing tags with other programs.
- few suggestions / questions:

• LR Creator (IPTC/ExifTool By-line) field appears as Artist in MC. That's not quite to the point, maybe its own Creator field would work better? (scenario: the "creator" (me, the photographer), I'm taking a picture of an artist of some kind, and things get unclear in a hurry, who's the field all about)
• Latitude & Longitude when set in LR as GPS coordinates, appear a bit different in MC. Say 42°11'46.8" N 74°3'2.2" W appear as 42°11'46.7999999999999616"N and 74°3'2.2000020000000031"W. I like the total precision but is there something up with the symbols?
• MC Notes: Just curious, this gets populated from LR Credit line?

For example, a photographer standing somewhere (location created) takes a picture of a skyscraper a mile away (location shown).  Too many details in my opinion 

Weeell... if one has a 600mm or longer lens... "I was here, the bird in the photo was in the next state!"  BTW, somewhat related; I've never checked this before, but I was pleasantly surprised when 'Direction' field in MC correctly picked up "East" from LR as 90 degrees.

Re Labels you are correct - I had a custom field called [Label]

This is neither here nor there, as it's not necessarily related to Image support: maybe MC could visually highlight (different color, or some kind of accent, etc) the custom fields from stock fields? I've run into issues too where I lost track of which was what and couldn't make sense why some things were happening.

[darichman]

Thanks Daydream. I'm mindful everything I have requested is from the perspective of my library and workflow, which has extensive custom fields and views, so I hope there's no massive oversight in these tag standards that I'm naïve to. One day I can document this if anyone interested.

I use some broad organisers. [Group] for high level group (Family, Work etc). [Type 1] is my separator from other media types within MC (Film, Television, Music, Books, Personal). Personal contains all personal mementos (photos, home videos, scanned documents - certificates etc that go in our family 'Timeline' which is our family tree media dating back hundreds of years). [Type 2] is more specific for the media type: Photos, Artwork, Certificates, Letters, Home Videos, Birth/Death Records etc etc). [Label] gives info around sorting/tagging/editing requirements. Rest are default fields or self-explanatory.

In Lightroom, I like the colour tag ability as it gives you a snapshot, in any view, of files that need something done. If I've completely tagged everything I want (people, keywords, location for the most part) I then tag it 'Complete' and it shows up in green. In any view you can then filter by colour by toggling the labels at the top. Would love this in MC, as really I only use LR to do the things MC can't currently do (pull location fields from GPS, facetag for the most part).

- few suggestions / questions:

• LR Creator (IPTC/ExifTool By-line) field appears as Artist in MC. That's not quite to the point, maybe its own Creator field would work better? (scenario: the "creator" (me, the photographer), I'm taking a picture of an artist of some kind, and things get unclear in a hurry, who's the field all about)

I like Artist as I would view the photographer as the artist/creator synonymously. If it's a photo of a painting/artwork then that may form the subject, but I guess we can be semantic and never agree for every use case.

Once we have a more complete implementation in MC of fields in MC, we could create/agree upon some default field views. These could include Photos (EXIF), Photos (IPTC), Photos (All), Photos (Location) etc or any useful variations. I have custom ones in my library already - see attached image (file hasn't really been tagged so most fields empty but gives some insight into my tagging scheme. Many of these are custom fields, which I hope to reallocate to standard default fields once we have them incorporated

An aside - [Places] is a calculated field that gives me =[Country];[State];[City];[Subplace] and displays as a list field (including all levels) which I find really useful. Could also create a calculated nested field to give a hierarchical nested structure with the \ delimiter. Both of these could be great as default fields that use the standard Country, State, City, Sublocation fields.

[Yaobing]

Some quirkiness in some fields

• [Genre]: I tagged Category as 'LR category' in lightroom. In MC this displays only as 'LR' under [Genre]
• I would suggest new field [Category] (mapped to IPTC 'Category') and [Genre] mapped to IPTC 'other categories'. Propose both as list fields as photos may belong to multiple categories and subcategories. If concern for impact of Genre for other media types, maybe just keep things separate and create new list-type fields [Category] and [Subcategory]?

Category and Other Categories both seem to be deprecated as far as the IPTC standard is concerned.

Category is a three-character code.  We are definitely not handling it correctly as we just return it as is.  That is probably why you ended up getting "LR " as LR probably truncated it.  Here are some of the codes:

• ACE: arts, culture and entertainment
• CLJ: crime, law and justice
• DIS: disaster and accident
• FIN: economy, business and finance
• etc.

"Other Categories" tag is also deprecated.  It is an array of strings, each no more than 32 bytes long.  I am not sure if they have a standard set of strings, or are just free form strings. I probably should look for other things to map to Genre, although "Other Categories" (actually called "Supplemental Categories") is definitely better than "Category". 

[markf2748]

Thanks Mark. To clarify, my references to IPTC fields in the earlier posts are from how they are displayed in lightroom in default views (see attached image) which I'm guessing isn't a one for one with the IPTC standards. That suggests to me that even lightroom refers to the IPTC standard fields in different ways, as some of the fields you mentioned are not displayed in default IPTC fields in lightroom and you have to go drilling down to extended views. It might be a whole other job to map that out too (I'm not sure I have the emotional fortitude for this!!) There is a view called IPTC extension which shows some of the fields you have mentioned. I would argue that the location shown should be linked to the Sublocation, City etc fields - interestingly when these are set in MC they do not display in the 'location shown' fields in the extended IPTC view (see picture). I am not sure why there are differences in the Image Location fields and Location shown fields (compare both attached pictures).

It is not unexpected that LR includes IPTC Extensions and MC should make every effort to include those which are generally useful.  My understanding is that these IPTC Extensions are actually the basis for Adobe XMP.  Also, much of the IPTC Core Schema are considered Legacy (though still commonly used) and have recommended replacements in the IPTC Extensions.

In particular, 'Location Created' and 'Location Shown' are useful IPTC extensions and should be mapped to separate MC fields.  They should not be automatically conflated with Sublocation, City, etc. as you suggest, though as an individual user you are of course free to include in them whatever text you want, or ignore them entirely.

Examples:

Picture of the Manhattan skyline taken from the Statue of Liberty:
'Location Shown' = Manhattan skyline
'Location Taken' = Statue of Liberty

Ellis Island taken from the Statue of Liberty:
'Location Shown' = Ellis Island
'Location Taken' = Statue of Liberty

Brooklyn Bridge taken from Lower Manhattan:
'Location Shown' = Brooklyn Bridge
'Location Taken' = Lower Manhattan

Notre Dame Cathedral taken from the Eiffel Tower
'Location Shown' = Notre Dame Cathedral
'Location Taken' = Eiffel Tower

Planet earth viewed from the ISS
'Location Shown' = Earth
'Location Taken' = International Space Station

'Location Shown' = Andromeda Galaxy
'Location Taken' = Hubble Space Telescope

[markf2748]

Re new MC field [Label] using colors in LR:

I have a custom text field [Label] for the obvious purpose of tracking the traditional audio album manufacturer/distributor label.  I expect a large number of MC users have had such a custom field for many years.  To avoid confusion and to respect a common precedent, MC should introduce a different field name for purposes of LR compatibility and picture color labeling in general.  Maybe something like [Label (state)], [Label (color)], [Label (category)], … that maps to LR Label.

[darichman]

Category and Other Categories both seem to be deprecated as far as the IPTC standard is concerned...

Oh wow. It seems this aligns with Mark's comments further down about some fields being legacy... these seem very specific and I'm not sure MC's user base will utilise in this way. Other thoughts?

I guess there is a juncture here - to support the entire IPTC standard as its documented, or to pick and choose what we think will be useful in MC. I don't think even lightroom has visibility or editability of all the fields. I would support the latter case, but good to get as many thoughts as possible. A few fields already highlighted with differences in interpretation of intended use...

I would support not including support for these Category fields per the standard (although would personally make use of a standard type/category field that was shared between LR & MC. Is there another IPTC field that would be a best fit for this... 'Intellectual genre', 'Description writer' - I am not sure the exact intention for these fields. The 'Source type' is also a useful field (see pic) to include in MC - specifies the nature of capture of the image.

Re new MC field [Label] using colors in LR:

I have a custom text field [Label] for the obvious purpose of tracking the traditional audio album manufacturer/distributor label....

I do too. How about [Photo Label] as a default field?

In particular, 'Location Created' and 'Location Shown' are useful IPTC extensions and should be mapped to separate MC fields.  They should not be automatically conflated with Sublocation, City, etc. as you suggest, though as an individual user you are of course free to include in them whatever text you want, or ignore them entirely.

Of course you are correct, in an absolute and semantic sense, and I don't disagree. But this will add some complexity. How should we specify the fields within MC? Would we need to duplicate all the location fields (Country, State, City, Subplace)... or just subplace. A photographer could be standing across a country or state border and take a photo of the other side, so that would mean duplicating all of them?

If this were done, my personal preference would still be to retain the simple Country, State, City, Subplace (without specifying 'created') and have separate Country shown, State shown etc fields. This would mean those who wanted to use the extended implementation could, and those who don't could hide them/not use them and still have simplified field labels that aren't too verbose. GPS coordinates are also always going to reflect the location 'created' intention. Again other opinions might be needed/wanted!

Thanks for the dialogue on this... am also interested in understanding others' workflows as I've been doing things much the same way for about 20 years, with some changes needed as software comes and goes (I am a Picasa refugee).

[lepa]

I have a custom text field [Label] for the obvious purpose of tracking the traditional audio album manufacturer/distributor label.  I expect a large number of MC users have had such a custom field for many years.  To avoid confusion and to respect a common precedent, MC should introduce a different field name for purposes of LR compatibility and picture color labeling in general.  Maybe something like [Label (state)], [Label (color)], [Label (category)], … that maps to LR Label.

I have it too. I also have it set to album art files

[Yaobing]

So far I have only mapped custom field "Label" to XMP "Label".  I can create an MC stock field if needed.  Shall we call it [Image Label], or [Photo Label], or something else?

[darichman]

Happy with either. I guess Image Label more inclusive as not all will be 'photos'

[markf2748]

I guess Image Label more inclusive as not all will be 'photos'

Agree.  OK with [Image Label].

[darichman]

Quote from .73 build from Yaobing:

I will add [Scene], but I am not quite sure how I should do it.  The IPTC spec says "Scene" should contain a code (they call it "Controlled Vocabulary code".  If I understand it correctly, each (numeric) code corresponds to a text description.  So you can not really freely edit the text.  The image samples you provided, tagged with LR, contain free text in the tag.  The image sample downloaded from ITPC site contains Scene code in the tag.

Category will be added, to go along with "Supplemental Category", which can be renamed "Subcategory".  I hesitated about "Category" because in IPTC core spec, it is a three-char code, instead of a free text.  It appears that LR uses it as a free text, so maybe we can try that too.  But I don't think we will put a long text in the core IPTC tag, as it is specified to be three-char only.  I might stretch this in XMP and put any text that is not one of the "code" text in the XMP tag, but provide a better coordination between IPTC Core and XMP.

It certainly sounds like LR takes its own liberties with the IPTC standards, so with this precedent my position is that this is fine in MC too. For me, the focus is on compatibility with Lightroom and what you propose sounds like an elegant way to approach this - map to the purist IPTC intention if fits the standard, but otherwise permit free entry to maximise LR compatibility. Others can comment on if there might be other unanticipated use cases, but from my perspective this sounds great!

Should we rename "Source" to something else?

I think [Source] is most appropriate, intuitive terminology, and maps nicely to the IPTC field. For me specifically, was just hoping to keep nesting capability in MC If this is not doable, not a deal breaker, but would be nice.

Matt I will also try some date/time testing with this build but may not be until the weekend for me. Thanks both for your work here!

[markf2748]

Re mapping Lr ‘scene’ as free text:  I do not see any conflict between Lightroom and IPTC Core or IPTC Extension.  Introduce two new MC fields with mappings:

Lr ‘scene’ <-> MC [scene]

IPTC Core ‘scene code’ <-> MC [scene code]

In IPTC speak, the word scene apparently refers to a controlled vocabulary of 6-digit codes that classify scenes:
https://cv.iptc.org/newscodes/scene/
This is a dictionary of recognized values for 'scene code'.

[[ Edit 10/29/2023: @Yaobing points out in Reply #92 below (https://yabb.jriver.com/interact/index.php/topic,136345.msg951738.html#msg951738) that Lr 'scene' and IPTC Core 'scene code' are actually stored in one and the same property tag.  Therefore there is no need for MC to use two separate fields.  MC [scene code] can cover both of them.  It can be given the flexibility to recognize numeric codes (as intended by IPTC) as well as free text (used by Lr and recognized by at least some other apps). ]]

@Yaobing:  I appreciate your respect for IPTC standards.  They should not be violated for the sake of Lr compatibility.  In the long term, someday MC should be able to claim both IPTC and Lr compatibility, both significant value-added features.

In this quest, keep in mind (as I think you already do) the difference between "deprecated" and "legacy".  I feel there is no need to fully accommodate (in a bi-directional sense) deprecated features for a given standard compatibility since they have been removed entirely (but may still be in use for a different standard).  "Legacy" features are no longer recommended, but are still fully accommodated for backwards compatibility and perhaps for their widespread use.

[markf2748]

Under-the-Hood Background

IPTC Photo Metadata Standard 2023.1 specifies IPTC Core schema 1.4 and IPTC Extension schema 1.8.

IPTC Core includes:
City (legacy)
Country (legacy)
Province or State (legacy)
Sublocation (legacy)

IPTC Extension collects these four and more into a single metadata Location structure.  The members of Location are:
City
Country ISO-Code
Country Name
GPS-Altitude
GPS-Latitude
GPS-Longitude
Location Identifier
Location Name
Province or State
Sublocation
World Region

IPTC Extension metadata which use the Location structure are:
Location Shown in the Image (= “Location Shown”)
Location created

Mapping Proposal

1) Core Legacy tags shown above map to corresponding names in MC tags, pretty much as they are now.

2) IPTC Extenson “Location Shown” structure members map to MC fields using Core and other simple names when appropriate, as they are familiar and will be the most widely used.

3) IPTC Extenson “Location created” structure members map to new MC fields of the form:

[LocationCreated (xx)]
 where xx= one of City, Country, Province or State, Sublocation, GPS-Altitude, GPS-Latitude, GPS-Longitude, etc.

Example:  mapping Sublocation as free text

1) IPTC Core ‘Sublocation’ (legacy) <-> MC [sublocation]
2) IPTC Extension ‘Location Shown:Sublocation’ <-> MC [sublocation]
3) IPTC Extension ‘Location Created:Sublocation’ <-> MC [LocationCreated (sublocation)]

1) and 2) map to the same MC field.   When both IPTC tags are in play, the IPTC Extension value takes precedence.
3) is likely much less common than 1) and 2), but still fulfills a need and can tolerate the longer, unfamiliar MC field name. 

[markf2748]

I think [Source] is most appropriate, intuitive terminology, and maps nicely to the IPTC field. For me specifically, was just hoping to keep nesting capability in MC If this is not doable, not a deal breaker, but would be nice.

I'm not sure what you are referring to here wrt an IPTC field.  Sounds like a special Lr thing - maybe a Lr custom IPTC field??  As far as I can tell there is no 'Source' field defined in the IPTC standard.
The closest I can find are:

IPTC Core 'Source (Supply Chain)' which is free text that describes a person or party involved in supplying the image.

IPTC Extension 'Digital Source Type' which is a controlled vocabulary described in:
https://cv.iptc.org/newscodes/digitalsourcetype/

If it is a custom Lr IPTC field you are using (probably defined by Adobe), then I suggest it be mapped to an MC field such as [source (Lr)] or [source (Adobe)].  The latter might be best since it's likely this field appears in other Adobe products.   A name change would also avoid the serious conflicts which several MC users are reporting today (31.0.74 release comments, over in Interact's MC 31 forum) with their own long-standing custom MC [source] fields.

To implement this source naming solution in practice, I expect it requires that MC be aware of the external program it is mapping to/from.  This probably requires a "compatibility switch" in MC options (or recognition of which program wrote the image file based on tags, which may not be dependable) and an internal mapping array.  So it gets complicated, but I think similar problems will arise when compatibility with other image processing programs is desired as well.

Alternatively, provide an accurate table of exactly which custom tags and their associated programs you support, sooner rather than later.

Otherwise support only the default standards-based tags.

[EnglishTiger]

I'm not sure what you are referring to here wrt an IPTC field.  Sounds like a special Lr thing - maybe a Lr custom IPTC field??  As far as I can tell there is no 'Source' field defined in the IPTC standard.

The IPTC Photo Metadata Standard 2023.1 point 12.1.13 indicates that there is an IPTC 'Source' Field with a Label of '(Artwork or Object detail:) Source' - https://iptc.org/std/photometadata/specification/IPTC-PhotoMetadata 

[darichman]

I'm not sure what you are referring to here wrt an IPTC field.  Sounds like a special Lr thing - maybe a Lr custom IPTC field??  As far as I can tell there is no 'Source' field defined in the IPTC standard....

I suspect you're right, and Lightroom and other programs do take some liberty with these tags. I am not a purist (and just want it to work between the programs I do use) but I respect the desire to get it right for most also, and to respect the standards. And happy to defer to others on the technical side of things.

I can see some others caught out with [Source] used for other purposes. I think this is always a danger with custom fields... standardising now can be a bit of legwork for some (transferring data from one field to another if needed) but will be better in the longterm. Thanks guys for the work here.

[markf2748]

The IPTC Photo Metadata Standard 2023.1 point 12.1.13 indicates that there is an IPTC 'Source' Field with a Label of '(Artwork or Object detail:) Source' - https://iptc.org/std/photometadata/specification/IPTC-PhotoMetadata 

Thanks for pointing this out!  I remember seeing it, but missed including it in my post.

We're getting on track by examining the standard and referencing its contents by the IPTC numerical index.

[Yaobing]

Thank you all for your input.

In build 75, we renamed "Source" to "Source (Supply Chain)" to keep it in line with IPTC standard.  That is the tag that LR is using for "Source".

Yes, the other IPTC "Source" tag is "(Artwork or Object detail:) Source" which we currently do not support.  If we ever need to support it, we will think of a name (maybe "AOSource").
 

[Yaobing]

In build 76, you will be able to delete  (if you want to delete it) the "Source" field that we previously created.

[Yaobing]

Re mapping Lr ‘scene’ as free text:  I do not see any conflict between Lightroom and IPTC Core or IPTC Extension.  Introduce two new MC fields with mappings:

Lr ‘scene’ <-> MC [scene]

IPTC Core ‘scene code’ <-> MC [scene code]

In IPTC speak, the word scene apparently refers to a controlled vocabulary of 6-digit codes that classify scenes:
https://cv.iptc.org/newscodes/scene/
This is a dictionary of recognized values for 'scene code'.

Exactly, the XMP tag name 'Scene" is used for IPTC's "Scene Code", and that is what Lightroom uses to store free text.

So there is actually a conflict.  I might just relax the rule a bit, like Lightroom does.  When reading from the file, we will check if the values are codes.  If we find codes, we translate to text using the controlled vocabulary,   Otherwise we just use the text as is.  When writing to files, we will do the opposite.   

[JimH]

I've merged two similar threads here.  Thanks to everyone who has contributed.  And major thanks to Yaobing for sorting it all out and making the changes. 

I hope we've improved our compatibility with other programs.

[Yaobing]

I have added [Scene Code] support.  As a first step, I did not add a stock field "Scene Code", but coded MC so that the respective tag data will be read into the field if the user has created one.  Writing will work too.  If there is demand, I will later make it a stock field, after making sure the field name "Scene Code" is not going to cause large scale conflicts.

With regard to field names, I am going to take markf2748's suggestion of trying to always stick to the names used by IPTC.  There are cases, however, where this approach might not work because their chosen name is too generic.  In such cases I may consider adding "IPTC" in front of the tag name (for example "ITPC Scene Code").

Back to "Scene Code".  The standard actually says that the tag should save a scene code (not free text) - a six-digit code such as "011800".  This is too restrictive to MC users who probably don't even know what these codes mean.  Lightroom clearly is not adhering to this restriction as darichman's sample images demonstrate.  So I relaxed on that too, by allowing free text in the tag and at the same time interpret the codes correctly as long as the codes are valid.  For example I tagged a sample image using this (semi-colon separated list):

011800;012000;012200;Scene 2;Scene One

Five entries are saved in IPTC/XMP - three codes and two free text.
When reading such into MC, MC displays them as

011800: Close-up
012000: Performing
012200: Symbolic
Scene 2
Scene One

[Yaobing]

I have said previously that I will need to find a proper tag to map MC [Genre].  Currently it is mapped to Category (LR Category) and is not very useful.

IPTC does define a "Genre" tag, but it is a complicated structure (https://iptc.org/std/photometadata/specification/IPTC-PhotoMetadata#genre) and difficult to use in the context of MC's Genre field.

So I think I will just use "Intellectual Genre" tag.  This tag is marked "legacy" as they try to encourage people to use Genre tag mentioned above.  "Intellectual Genre" is just a simple string tag, and therefore will fit our Genre list field easily.

[markf2748]

..."Scene Code".  The standard actually says that the tag should save a scene code (not free text) - a six-digit code such as "011800".  This is too restrictive to MC users who probably don't even know what these codes mean.  Lightroom clearly is not adhering to this restriction as darichman's sample images demonstrate.  So I relaxed on that too, by allowing free text in the tag and at the same time interpret the codes correctly as long as the codes are valid.  For example I tagged a sample image using this (semi-colon separated list):

011800;012000;012200;Scene 2;Scene One

Five entries are saved in IPTC/XMP - three codes and two free text.
When reading such into MC, MC displays them as

011800: Close-up
012000: Performing
012200: Symbolic
Scene 2
Scene One

Interesting approach.  I confirm that when MC saves your example (3 codes plus 2 free text) to a local test image, XnView MP (v1.6.1) indeed reads them as five separate Iptc4xmpCore Scene Code properties, exactly as they were entered.  Same for the very valuable IPTC test site https://getpmd.iptc.org/getiptcpmd.html.  So the basic functionality is working.

bug (?): I do not see the Names ": Close-up", etc. in MC. Are you implying MC should always display the (valid) decoded 6-digits as text as you show?  Does not seem to happen in my test where MC writes the codes in the first place.

Suggestion:  It would be most helpful to anyone interested in using these codes if the MC tag window presented an ordered drop-down list of the Codes and their Names for the 24 IPTC controlled scene codes (https://cv.iptc.org/newscodes/scene), i.e.
[ ] 010100 headshot
[ ] 010200 half-length
[ ] 010300 full-length
[ ] 010400 profile
etc.
Then user just checks the boxes to add the codes to be written.  Upon reading, the detected (valid) codes are check-marked by MC (as well as shown in the tag's text box).  You might still maintain the valid code translation in the text box display.  Alternatively, open a pop-up with the same functionality.

Comment:  There are several IPTC Core properties for describing an image using free text:  Keywords, Headline, Caption/Description.  So there is no compelling reason for adding free text to [Scene Code] as far as I can see.  However several applications apparently tolerate it, so MC may as well accommodate as you have implemented it.

[Yaobing]

bug (?): I do not see the Names ": Close-up", etc. in MC. Are you implying MC should always display the (valid) decoded 6-digits as text as you show?  Does not seem to happen in my test where MC writes the codes in the first place.

Sort of a bug.  You need to do a "Update library (from tags)" to get the text.  The way I implemented it, the text is appended when reading the tag from the images.  This is related our internal design.  We need this back-and-forth to get the text appended.  I will think about it.  Actually once I get the next issue fixed, this will no longer be an issue.

Suggestion:  It would be most helpful to anyone interested in using these codes if the MC tag window presented an ordered drop-down list of the Codes and their Names for the 24 IPTC controlled scene codes (https://cv.iptc.org/newscodes/scene), i.e.
[ ] 010100 headshot
[ ] 010200 half-length
[ ] 010300 full-length
[ ] 010400 profile
etc.
Then user just checks the boxes to add the codes to be written.  Upon reading, the detected (valid) codes are check-marked by MC (as well as shown in the tag's text box).  You might still maintain the valid code translation in the text box display.  Alternatively, open a pop-up with the same functionality.

I have this on my mind exactly but have not found an easy way to implement it (yet).

Comment:  There are several IPTC Core properties for describing an image using free text:  Keywords, Headline, Caption/Description.  So there is no compelling reason for adding free text to [Scene Code] as far as I can see.  However several applications apparently tolerate it, so MC may as well accommodate as you have implemented it.

I choose this hybrid approach because of the desire to read Lightroom tags.  Lightroom breaks the Standard by allowing free text in the tag (they call it "Scene", but the tag they use is exactly the same as "Scene Code").

[darichman]

Just to say I have not forgotten about this and plan to do some solid testing. Have had a few real life things to catch up on.

Thanks so much Yaobing, Jim, Matt for the implementation & careful consideration. markf2748 and others thanks for you insights on support of standards.

[darichman]

Alright, finally had a few hours to sit down and play! I have added all mentioned custom fields, and tried tagging in both directions to see what sticks. MC 31.0.81

Overall very impressed - THANK YOU! A few niggles, some noted previously and may reflect character limitations in the tagging standards.

Step 1: import vanilla files into LR, tag in LR, import into MC
LR field > [MC Field]
Title > [Name]
Creator > [Artist]
Source > [Source (Supply Chain)]
Label > [Image Label]
Caption > [Caption]
Headline > [Headline]
Keywords > [Keywords]
Credit Line > [Notes]
User Comment > [Comment]
Category > LR Category
Other categories > [Subcategories]
Source > [Source (Supply Chain)]
Event > [Event]
Scene > [Scene Code]
Country > [Country]
State > [State/Province]
City > [City]
Sublocation > [Sublocation]
Category > [Genre]
Copyright > [Copyright]

Step 2: All fields then retagged in MC, and 'read metadata from files' run from Lightroom
[MC Field] > LR Field
[Name] > 'Title'
[Artist] > EXIF Artist, IPTC creator
[Source (supply chain)] > Source
[Image Label] > Label (and colour correctly updates in LR if matches presets - amazing!)
[Headline] > Headline
[Caption] > Description
[LR Category] > Read into 'Category' but truncated (MC LR Category became 'MC' in Lightroom - I know there was a comment about this)
[Subcategories] > Other Categories
[Scene Code] > Scene
[Country/State/City/Sublocation] > All mapped to respective fields
[Notes] > Credit Line
[Keywords] > [Keywords]
[Comment] > Inconsistently updated - some files update 'User Comment' in LR but others do not. I can send test files if desired.
[Copyright] > Copyright
[Event] > did not update in IPTC 'Event'

Lightroom fields not mapped to MC fields

• Rating did not map for me in either direction - I'm sure someone else saw this working. Is there anything I could  be missing here?
• Source Type not mapped to anything - could this please be added? Pic attached from LR IPTC view

MC fields not mapped to LR (IPTC, EXIF or XMP)
[Album] - I would really love this to go somewhere exportable to other programs. There was disagreement mapping to [Scene] or [Event]... do any other users (or devs) have any preferences? [Album] is used pretty extensively across MC, including for Images, so it would make sense for this info to be portable. I'd rather not have to migrate all [Album] data to another field but would be great to see this info in LR and other programs.

I will need to play around with [People] and [Keywords] - I have put this off as don't want to break current facetagging in LR, which I think tags to XMP (which MC can read into [People] - last I checked, renaming or adding people in MC does not update LR XMP. I'm not sure how it could, unless MC could actually read the 'face' data. I'm sure if it was you, Yaobing who worked on this some years ago?

I will make a final comment - I don't like convention of having [LR Category] and [Subcategories]... it feels like we should either omit all prefixes (Category, Subcategories) or be consistent (LR Category, LR Subcategories)? Also don't love the verbosity of 'Source (Supply Chain)' in views or expression language... I am interested in other opinions, and do understand competing want to stick with how they are referenced in IPTC standards etc. I note Lightroom simply shows Category, Subcategories, Source etc. If these are considered too generic (or too risky for users who might have their own custom fields already) how about Image Category, Image Source etc (as we have done for Image Label already). You will never please anyone, so just detailing my preferences on this - I like a nice clean tag list!

[markf2748]

Bug:  The MC tag [State/Province] is sometimes written multiple times (several duplicate lines) in the image file within MC's <MJMD>..</MJMD> section.  Some lines contain the user-modified value, some do not.  The lines can be seen by opening the image file with a text editor (such as NotePad++).  When seen in the image file, they also appear in the MC Tags Tree > Tag Dump ... <MJMD> with the name "<State/Province>".  The program XnView displays the multiple lines in its Properties > ExifTool tab > XML section with the name "State".

Note:  The described behavior is "erratic".  It may not be seen the first time the tag is changed in MC.  But change the tag a second time, and a tag line with the new value can be added to the file, while the old tag lines stick around (i.e. not replaced).  So the number of extra tag lines can build up as you work with the file multiple times in MC.  The issue can also disappear (revert to a single line) upon revising the tag value.  No consistency AFAICT.  Could it be a bad interaction between MC's <MJMD> with its preceding proprietary tagging code and XnView, or just something buggy in MC?

Attached file results from modifications of [State/Province] done in MC for the IPTC standard test image IPTC-PhotometadataRef-Std2023.1.jpg and viewing properties in XnView.

Win 11 Pro (64-bit) 22H2   MC 31.0.81

[Yaobing]

Alright, finally had a few hours to sit down and play! I have added all mentioned custom fields, and tried tagging in both directions to see what sticks. MC 31.0.81

Thanks for the detailed report.

[LR Category] > Read into 'Category' but truncated (MC LR Category became 'MC' in Lightroom - I know there was a comment about this)

We write this tag to IPTC Core (IIM) AND XMP.  The problem with IPTC Core is that it specifies this tag as a three-letter code.  It appears that Lightroom only uses IPTC but not XMP?  I mentioned this before, we are trying to stick to IPTC's three-letter code, but relaxed it for XMP.  In your previously sent sample images, LR wrote to IPTC using only three or fewer letters too (you tagged "LR Category" in LR, but MC read "LR").

[Comment] > Inconsistently updated - some files update 'User Comment' in LR but others do not. I can send test files if desired.

I don't know what is going on here.  I will look into this.  Please send sample images.

[Event] > did not update in IPTC 'Event'

It was announced in MC History that I have suspended writing of this tag until further notice.  That is why tagging in MC is not reflected in LR (or any other app).

Lightroom fields not mapped to MC fields

• Rating did not map for me in either direction - I'm sure someone else saw this working. Is there anything I could  be missing here?
• Source Type not mapped to anything - could this please be added? Pic attached from LR IPTC view

MC fields not mapped to LR (IPTC, EXIF or XMP)
[Album] - I would really love this to go somewhere exportable to other programs. There was disagreement mapping to [Scene] or [Event]... do any other users (or devs) have any preferences? [Album] is used pretty extensively across MC, including for Images, so it would make sense for this info to be portable. I'd rather not have to migrate all [Album] data to another field but would be great to see this info in LR and other programs.

I will try adding these.  [Rating] seems to work for me.

I will need to play around with [People] and [Keywords] - I have put this off as don't want to break current facetagging in LR, which I think tags to XMP (which MC can read into [People] - last I checked, renaming or adding people in MC does not update LR XMP. I'm not sure how it could, unless MC could actually read the 'face' data. I'm sure if it was you, Yaobing who worked on this some years ago?

[Keywords] should work fine.  [People] probably is a mess.  Do you have an image that has [People] tagged?

I will make a final comment - I don't like convention of having [LR Category] and [Subcategories]... it feels like we should either omit all prefixes (Category, Subcategories) or be consistent (LR Category, LR Subcategories)? Also don't love the verbosity of 'Source (Supply Chain)' in views or expression language... I am interested in other opinions, and do understand competing want to stick with how they are referenced in IPTC standards etc. I note Lightroom simply shows Category, Subcategories, Source etc. If these are considered too generic (or too risky for users who might have their own custom fields already) how about Image Category, Image Source etc (as we have done for Image Label already). You will never please anyone, so just detailing my preferences on this - I like a nice clean tag list!

You can rename the Display Name of each field. 

I have agreed to markf2748 about naming things as the Standards name them, but left [LR Category] and [Subcategories] as exceptions.  So I can entertain more suggestions on how these should be named.  [Category] is not an option because it is too generic, and very likely someone already uses a custom field [Category] for other purposes.  We ran into a big issue with [Source].  That was why we ended up using [Source (Supply Chain)].

[Yaobing]

Bug:  The MC tag [State/Province] is sometimes written multiple times (several duplicate lines) in the image file within MC's <MJMD>..</MJMD> section.  Some lines contain the user-modified value, some do not.  The lines can be seen by opening the image file with a text editor (such as NotePad++).  When seen in the image file, they also appear in the MC Tags Tree > Tag Dump ... <MJMD> with the name "<State/Province>".  The program XnView displays the multiple lines in its Properties > ExifTool tab > XML section with the name "State".

Note:  The described behavior is "erratic".  It may not be seen the first time the tag is changed in MC.  But change the tag a second time, and a tag line with the new value can be added to the file, while the old tag lines stick around (i.e. not replaced).  So the number of extra tag lines can build up as you work with the file multiple times in MC.  The issue can also disappear (revert to a single line) upon revising the tag value.  No consistency AFAICT.  Could it be a bad interaction between MC's <MJMD> with its preceding proprietary tagging code and XnView, or just something buggy in MC?

Attached file results from modifications of [State/Province] done in MC for the IPTC standard test image IPTC-PhotometadataRef-Std2023.1.jpg and viewing properties in XnView.

Win 11 Pro (64-bit) 22H2   MC 31.0.81

Thanks for reporting this.  I will investigate.

[markf2748]

Note:  The described behavior is "erratic".

With image listed in MC's lower Content Panel, now I consistently find:
RMB on image "track" > Library Tools > Update tags (from library) adds a new duplicate <State/Province> line to Tree > tag window > Tag Dump <MJMD> section.

Win 11 Pro (64-bit) 22H2   MC 31.0.82

[darichman]

It’s been a few weeks and a few more versions! I’ve just had another bout of Covid so catching up on things (third time! – perk of working in healthcare)

Keen to perfect things on the image front

With image listed in MC's lower Content Panel, now I consistently find:
RMB on image "track" > Library Tools > Update tags (from library) adds a new duplicate <State/Province> line to Tree > tag window > Tag Dump <MJMD> section.
Win 11 Pro (64-bit) 22H2   MC 31.0.82

Has this one been fixed yet?

Quote from darichman: [Comment] > Inconsistently updated - some files update 'User Comment' in LR but others do not. I can send test files if desired.
Yaobing: I don't know what is going on here. I will look into this.  Please send sample images.

I have emailed you a description, screens and test files.

[Event] > did not update in IPTC 'Event'
Yaobing: It was announced in MC History that I have suspended writing of this tag until further notice.  That is why tagging in MC is not reflected in LR (or any other app).

What’s the reason with [Event]? Some compatibility problem?

From darichman:
Source Type not mapped to anything - could this please be added? Pic attached from LR IPTC view
[Album] - I would really love this to go somewhere exportable to other programs. There was disagreement mapping to [Scene] or [Event]... do any other users (or devs) have any preferences? [Album] is used pretty extensively across MC, including for Images, so it would make sense for this info to be portable. I'd rather not have to migrate all [Album] data to another field but would be great to see this info in LR and other programs.
I will try adding these.  [Rating] seems to work for me.

Some potential fields [Album] could be mapped to:
[Scene] (IPTC image) – probably best fit?
[Event] noting above
[Job Identifier] (IPTC status)
[Intellectual Genre] (IPTC image)

[Keywords] should work fine.  [People] probably is a mess.  Do you have an image that has [People] tagged?

I will send you an email with a few permutations of files tagged in different orders (MC only, LR only, MC + LR) etc
Edit: sent

Thanks again Yaobing and team