INTERACT FORUM
More => Old Versions => JRiver Media Center 31 for Windows => Topic started by: Matt on June 20, 2023, 02:49:31 pm
-
Description
We have written a new EXIF library from the ground up. It can read and write. Previous versions of MC could write the EXIF dates in some cases, but only if the file already had the date. The new library can write to any JPEG image and write any field.
This change is not available yet, but will be in the next few builds.
We also improved IPTC support and added some fields (like City, State/Province).
Instructions
Import any images. Use "Update Library From Tags" on existing images to use the new EXIF reading. Tag files and the new EXIF library will write.
-
Our goal is to improve all the image handling inside Media Center. We're open to other suggestions you may have (once we're done with the EXIF work). So please feel free to make other suggestions. Thanks.
-
Split the wiki discussion:
https://yabb.jriver.com/interact/index.php/topic,136364.0.html
-
I've been away for regional outreach but very excited to try this out :)
Our goal is to improve all the image handling inside Media Center. We're open to other suggestions you may have (once we're done with the EXIF work). So please feel free to make other suggestions. Thanks.
I will have a few. Thank you for your work on this!
-
I'll hopefully have some time to stress the EXIF writing at the weekend. It's no small thing, I know, and it's fully appreciated here.
-
Downloaded! I'll also do some tests :) Will recreate the steps in my opening post.
Question: will an 'update tags from library' create EXIFs for all selected files. Do you foresee this to be a safe undertaking, before I pull the trigger? I will do on a sample of files first
Thanks Matt and Jim!
-
Update Tags From Library should add EXIF if it's not found. Doing some samples first is smart. Thanks for the help.
-
I understand that tags in image files are read by MC and show up in the left (Tree) panel Tag Dump section, grouped under XMP, IPTC, MJMD and a few at the top are ungrouped. I would like to try MC image management on large collection of photos (unrelated to music), but have some basic questions (quick first impressions):
1) I don't see EXIF listed as a separate section in MC Tag > Tag Dump. Is that because my image has no EXIF, or is EXIF combined with IPTC?
UPDATE: I created a new Image library which imports only images and successfully imported several image folders which show up nicely in MC. Then I determined with the program XnView MP Image > Properties that one of the *.jpg image files has a ton of populated EXIF fields. However MC shows only 10 fields at the top of the Tag Dump output (unlabeled section) which pretty much correspond to the EXIF tags listed in MC's Wiki page on Photo Editing:
https://wiki.jriver.com/index.php/Photo_Tagging (https://wiki.jriver.com/index.php/Photo_Tagging)
The vast majority of EXIF tags in the file do not show up in MC Tag > Tag Dump at all, even after Library Tools > Update Library (from tags) followed by a Refresh of the Tag Window.
2) Can I create MC tag window inputs for new EXIF / IPTC tag values like I do for MJMD, in order to have them written into the image file as those types? Or am I limited to the tags read from the file at this time?
3) If I look in Options > Library & Folders > Manage Library Fields > Show only image fields I see a long list of fields, but I can't tell from the list which group (XMP, IPTC, MJMD, ...) they fall under. Are they mainly/only MJMD (I do see the new City and State/Province, but they look like any other field)?
4) Are there automatic mappings from MJMD to the other types (some IPTC mappings are described in the wiki article)? If so, a table of those mappings would be very helpful.
Thanks.
Win 11 Pro 64-bit MC 31.0.29
-
From the first post:
Matt said, "Import any images. Use "Update Library From Tags" on existing images to use the new EXIF reading. Tag files and the new EXIF library will write."
-
I'll wait for darichman's feedback...
For me, it's either flat-out not working, or I'm doing something wrong.
First attempt...
I copied some files that already existed in my library and let MC import them. The data correctly populated, as expected.
I then used XnView MP to remove all tag data, including the MJMD tags from one file.
Back in MC, I did "Update tags from library", which MC advised was successful.
In the file... nothing, nada, zilch?
I picked a different file and this time, did nothing externally. This file has an existing EXIF block that contains only "Date/Time Original" and "Date/Time Digitised" (both have the same value.)
I changed the date in MC by moving the time ahead a couple of minutes via edit in the tag window. This change is not written to the file either, where previously, MC was correctly updating the EXIF info. I also tried with the "Adjust date/time" library tool with the same negative result.
Finally, I tried with a jpg that has no tags written at all, that MC had never seen before and still, no EXIF data is created by MC when the tags (date) is altered.
:(
-
Confirmed that it does not work and I have some ideas why. We will be working on it after the Fourth of July holiday.
The only thing that will work now is if you do not remove any existing tags, and try to change the Date field. That will get saved correctly. Changes in all other fields are ignored at this point.
Sorry for the false start.
-
I think Marko you beat me to it. But I have noticed some positive observations since before the changes (at least regarding brand new files, newly imported) which aligns with what Yaobing mentioned. I will troubleshoot for already-imported files with existing tags soon.
Just scanned an image, default file metadata below (without ever having imported into MC & no tagging in other programs):
- Windows properties: Date taken 30/06/2023 8:14pm, Date modified 30/06/2023 8:19pm (reflect the date the file was scanned)
- Google photos: 30/06/2023 8:14pm
- Lightroom: Capture date 30/06/2023 8:14pm, Date created (empty)
Imported image into MC:
[Date] = 30/06/2023 8:19pm
[Date modified] = 30/06/2023 8:19pm
[Date created] = 3/07/2023 2:03pm (appears to be the date stamp for when I copied this image into a folder in windows)
Copied the original file, Tagged in MC:
[Date] = 3/1/1960 1:23pm
[Keywords] = MC keyword
[Caption] = MC caption
[Artist] = darichman
Loaded this new file in other programs (my 'expected' tag outcomes in green):
Windows file properties:
Date taken 3/01/1960 1:23pm
[Date modified] = 3/07/2023 2:07pm (the time I 'tagged' the file in MC)
[Date created] = 3/07/2023 2:03pm
Google photos: Date = 03/01/1960 (time not read)
Keywords not read (not sure this is MC's problem)
MC caption loaded into 'Other'
Lightoom: Capture date 3/1/1960 1:23pm, Date created 3/1/1960, Date 30/06/2023 8:19pm
Keywords = MC keyword, Caption = MC caption
Artist does not seem to be mapped to any author/photographer fields
Have not played around with [People] and faces again, but will do so.
-
Matt /Yaobing - you may want to take a look at this thread - https://yabb.jriver.com/interact/index.php/topic,136487.0.html (https://yabb.jriver.com/interact/index.php/topic,136487.0.html)
It looks like an invalid image size (3456 x 976357632) in the EXIF Data is causing MC31.0.29 and higher to crash out
-
Matt /Yaobing - you may want to take a look at this thread - https://yabb.jriver.com/interact/index.php/topic,136487.0.html (https://yabb.jriver.com/interact/index.php/topic,136487.0.html)
It looks like an invalid image size (3456 x 976357632) in the EXIF Data is causing MC31.0.29 and higher to crash out
Thanks for your help.
-
I know this might be one or two steps away, but this is the most comprehensive writeup of Google Photos tag (https://github.com/StarGeekSpaceNerd/Metadata_Reference/blob/master/Photos.google.com.md) compatibility I've seen.
-
The latest build should has pretty strong EXIF support now.
-
Thank you so much for this - apologies for delay in testing - it's still on my radar!!
Work / family (just about everything) has been hectic :)
-
Could someone please spell out EXIF? I have no idea what you are talking about. What is IPTC? Thank you.
-
Could someone please spell out EXIF? I have no idea what you are talking about. What is IPTC? Thank you.
This may not be the perfect thread to explain it but on short, they are both photo metadata standards. EXIF contains the technical metadata about a photo (date taken, camera model, ISO, aperture, focal length, pixel dimensions, date and time when taken, GPS coord, etc), while IPTC contains descriptive metadata about the photos (who took it, at what event, short description of what's going on in the photo, who owns the copyright to it and so on). Usually the EXIF data is stamped on the file by the camera at the moment the photo is taken while IPTC is done by the user after the fact, manually, or using automatic templates, etc.
There is a bit of perceived overlap. For example the copyright information can be set in the camera (i.e. "© what's-my-name") and the camera will stamp it as EXIF on every file. The equivalent in IPTC is much more extensive (Author/Source/Caption describing what agency to contact/what markets are under embargo/Premium rates or not, etc)
To bring it about to what I care more - appreciate the work on EXIF as its important that the technical data is imported correctly in MC. I hope at some point the focus turns to IPTC too.
-
I hope at some point the focus turns to IPTC too.
Hi Daydream. Would you be willing to start a thread with your IPTC suggestions? Thanks.
-
Interested in this but don't quite understand what's new. Using MC27 more and more as main photo archive with a range of tags filtered by a library view that works really well. Writing the date isn't an issue as it's in most photos from the start.
One thing I'd like to make more use of is the Resize function. Near full partition with 1,000s of images with much higher resolution than necessary. But when batch resizing I need it to keep the original Taken Date, not update with current date.
Also, the ability to maintain aspect ratio while entering only one dimension. I shouldn't have to calculate the other dimension.
Finally, to be able to specify the size entered as the 'longer' or the 'shorter' dimension so you can resize both landscape and portrait in the same batch to the same overall size. eg, enter longer side=1600 to get either 1600x1200 or 1200x1600.
-
Interested in this but don't quite understand what's new. Using MC27 more and more as main photo archive with a range of tags filtered by a library view that works really well. Writing the date isn't an issue as it's in most photos from the start.
One thing I'd like to make more use of is the Resize function. Near full partition with 1,000s of images with much higher resolution than necessary. But when batch resizing I need it to keep the original Taken Date, not update with current date.
Also, the ability to maintain aspect ratio while entering only one dimension. I shouldn't have to calculate the other dimension.
Finally, to be able to specify the size entered as the 'longer' or the 'shorter' dimension so you can resize both landscape and portrait in the same batch to the same overall size. eg, enter longer side=1600 to get either 1600x1200 or 1200x1600.
Hi Pogle - thanks for your suggestions but perhaps best these could be suggested in a new thread? You may not see the value of the recent EXIF changes but they are important for some of us!! If you read my initial postings on this there are lots of situations where the date is not 'in most photos from the start' - scanned photos, downloaded photos, date set wrong on camera etc.
I have done some testing and will detail a separate post.
-
Hi Matt & team. Thank you for your work on this. I have spent some time importing and tagging images from varying sources. Sorry for delay - there was a time when I could spend all day lost in my media collection. Those days are few and far between now!
Steps taken
3 test files created:
Scanned a new image (no EXIF data)
Downloaded an image from Facebook (no EXIF data)
Copied an existing imported file from MC (existing EXIF data)
Tagged files in MC
arbitrarily tagged the [Date] as 6/1/1984 (Jan 6th 1984)
tagged as many MC native fields I can think of [Artist] = 'MC artist', [Album] = 'MC album', [Caption] = 'MC caption'... similar for [Keywords], [Comment], [People], [Country], [City], [State/Province]
right clicked each file in windows and checked 'file properties' tag displays
imported into lightroom and checked tag entries
imported into google photos and checked tag entries
two of the tagged files uploaded here for reference
Results
Windows file properties
[Date] maps to 'Date taken'
[Name] maps to 'Title' and 'Subject'
[Keywords] maps to 'Tags'
'Comments' is empty
[Artist] maps to 'Authors'
no other fields visible/displayed
Lightroom
[Date] maps to 'Capture date' & 'Date created' and 'Date' for the downloaded photo without prev existing EXIF data
[Date] maps to 'Capture date/time' but not mapping to 'Date/time' for the scanned photo and camera photo with existing EXIF data- displays correct day but not year: ie 6/1/2023 for one of them and 1/8/2023 for the other, both incorrect
[Name] not read anywhere - could map to 'Title'
[Keywords] maps correctly
[Caption] maps correctly
[Artist] maps to iptc 'Creator'
[Country] maps to iptc 'Country/region'
[State/Province' maps to iptc 'State'
[City] maps to iptc 'City'
[Person] does not map to iptc 'Person shown' or to generic 'Keyword'
Google Photos
Per usual not a lot gets imported/exposed in Google photos
[Date] not mapping correctly for any of the files! The camera photo shows 6/1/2023 (correct day, wrong year), web photo showing 1/8/2023 and scanned photo showing 23/7/2023. So inconsistent results for dates but files all tagged in same way in MC
[Caption] is displayed in 'Other' but no other MC-tagged-fields visible
Summary: things are a lot better and many fields are now cross-compatible, but still some wonkiness with Dates per above. Any ideas?
-
I just tagged the date on a test image.
1/1/2000 11:05 am
Then I uploaded to Google Photos.
The first line under "Details" is the date:
Jan 1, 2000
Sat, 11:05 AM
GMT-10:00
So that seems to be working nicely for me.
-
Weird! I will do some more testing :)
-
As far as EXIF is concerned, we are currently on EXIF 2.2. The number of text tags are very limited in EXIF. Most text tags are ASCII text only.
[Name] -> EXIF's "Image Description", but if [Name] is not ASCII, we put it in "User Comment"
[Artist] -> "Artist"
[Copyright] -> "Copyright"
[Comment] -> "UserComment". This is the only text tag that allows non-ASCII characters.
These are about the only text tags that we can do with EXIF 2.2. I will soon start adding support for EXIF 3.0, which allows a number of more tags, and all text tags can be unicode.
[Date] -> EXIF's "DateTimeOriginal", i.e. the date and time the image is taken, as recorded by a camera. This is about the only "Camera tag" that we attempt to edit/set. Not sure why it is not working with Google photos for you.
-
Maybe different apps have different interpretations of "DateTime". EXIF has three date time tags:
DateTimeOriginal, that is what we map to our [Date] field. This is the date time the picture was taken.
DateTime, we are not mapping to anything. It corresponds to date time the image file is last edited. In MC we have "Date modified", but that field is not sent to tagging, maybe it just reflects the date time the file was changed (the OS tells you when the file was changed).
DateTimeDigitized, we have no corresponding field for this.
You can create a custom field "DateTimeDigitized", and see what value you get. Similarly, you can create a custom field "DateTime". Try editing these custom fields and see if other apps pick them up.
-
Thanks Yaobing
I have just done with three separate files:
- photo from my phone with existing tags from phone camera
- photo from scanner without EXIF
- photo downloaded from facebook without EXIF
I tagged them all with [Date] 1/2/1973 (1st Feb 1973)
Added a custom field [DateTime], set to save to tag, and tagged them all 6/4/1980
In MC, [Date modified] reads 4/8/2023 1:58pm
Google photos shows different dates for all of them. See attached
I am not sure what is going on - have emailed you both test files (initial untagged and then the ones after tagging in MC)
Let me know what you think
-
Regarding Google Photos, I believe it tries to get the date from one of the following:
1. EXIF DateTimeDigitized - your camera.jpg image contains this tag, and it is used. EXIF GPS Date tag (This is so silly. They choose to use this one instead of DateTimeOriginal or DateTimeDigitized, or DateTime!) EXIF DateTimeOriginal (see my new post below (https://yabb.jriver.com/interact/index.php/topic,136345.msg947737.html#msg947737))
2. From non-EXIF data: <stEvt:when>2023-07-31T08:23:50+10:00</stEvt:when> or <xap:CreateDate>2023-07-31T08:23:50+10:00</xap:CreateDate>. Scan.jpg file contains both of these and Google must have picked from one of them.
3. From OS's Date Modified (I guess). Your Facebook file does not have either of the above two, and the date Google shows is just the file modified date.
Regarding DateTime custom field, strangely, I can not tag it but I thought I was able to (I could be mistaken). The value in the custom field was not sent to EXIF code for some reason. More strangely, your files (the "Tagged in MC" set) all contain this tag, with value "1900:01:05". This is not the value you said you tried to tag it. Did you try tagging these files using another App?
-
Regarding DateTime custom field, strangely, I can not tag it but I thought I was able to (I could be mistaken). The value in the custom field was kust not sent to EXIF code for some reason. More strangely, your files (the "Tagged in MC" set) all contain this tag, with value "1900:01:05". This is not the value you said you tried to tag it. Did you try tagging these files using another App?
Weirdness... No, the only program used for any of the files was MC. I imported them, tagged as per the screenshot, closed MC and then uploaded them to google photos. Did not import into lightroom at all.
The phone image was taken straight off the phone (copied using windows copy and paste).
The FB image downloaded off facebook.
The scanned image scanned using the proprietary Epson scanner software
I guess it's a tricky balance as every software interprets the tags differently :P From a simplistic user perspective, all I really want is the [Date] tag in MC to be set/used as the main 'Date' fields in relevant software the files may be exported to (namely Lightroom and Google Photos for me). Does IPTC have a date field?
-
Does IPTC have a date field?
Yes, it has DateCreated. As far as I can tell it's mostly decoded as yyyy-mm-dd. Its definition (https://iptc.org/std/photometadata/specification/IPTC-PhotoMetadata#date-created) is a bit nauseating.
I'm joining in here for a second, from a slightly different angle. I'm trying RAW files (Canon CR2). 2 things: the size reported ([Dimensions] field) is the (I guess) embeded preview (something like 592x395). At no point in time the real size is reported, regardless of RAW decoding settings in MC or anything else I can think of. A Lightroom processed pano in DNG format does show real dimensions.
Regarding the date, changing the date in MC ([Date] field) for a RAW file triggers no real changes. An Update Tags from Library results in outright failure.
-
We do try to save date to IPTC too. I am not sure if there is something not handled correctly and we need to investigate more about it. It appears that nothing is written when the image originally does not have IPTC in it (like the facebook sample image).
Regarding Google Photos, I edited my previous post. They choose to use a more obscure tag (GPS Date). That is so silly >:(
I also figured out why I was not able to save DateTime and DateTimeDigitized. I forgot to check the checkbox "Save in file tags (when possible)" when I created these custom fields. Once the checkbox is checked, the tags are saved correctly. Too bad that still does not help with the Google Photos situation.
-
We do try to save date to IPTC too. I am not sure if there is something not handled correctly and we need to investigate more about it. It appears that nothing is written when the image originally does not have IPTC in it (like the facebook sample image).
I think this is one of the important variables between the 3 files...
Does existing EXIF tag exist (yes/no)
Does existing IPTC tag exist (yes/no)
The best outcome is that it doesn't matter if the tag exists - MC will create it if needed and write to the relevant fields, or update relevant fields if tags pre-exist.
Would you consider building an IPTC tag if does not already exist?
Regarding Google Photos, I edited my previous post. They choose to use a more obscure tag (GPS Date). That is so silly >:(
That is indeed incredibly silly... would you foresee any ill effect in writing to this field?
Thanks again. I think we are making good progress!
I have not even ventured into RAW files yet (I do not have a lot, but these will be on the agenda at some point!)
Also heic files... I have no idea what the tagging standards for these are.
Once jpeg/jpg & EXIF sorted, can figure out some sort of plan for .bmp .gif .heioc .nef .orf .png .psd .tif and .tiff files in my library :D
-
After doing a lot of testing I ended up coming to a full circle. I now conclude that it is working fine!
I don't know what happened with your tests. The first thing I did was to take a photo that already contains all datetime EXIF tags, and use a hex editor to change each datetime tag to a distinct value. Google Photos picked up the most logical one - DateTimeOriginal, which corresponds to MC's Date field when we write tags.
Next I took all three of your untagged images, and tagged them all in MC, using distinct dates for each tag. Uploaded the resulting images to Google Photos. They all are displayed correctly. See screenshots below.
MC also does save IPTC tags (some of them anyway, including Date), in all three images (including the facebook one that originally does not contain any tags). I even used the hex editor to change the dates so that the EXIF dates and IPTC date are different. Google Photos picked up the EXIF DateTimeOriginal, since ot exists, instead of IPTC. So from the point of view of making sure Google Photos pick up the date tagged by MC, tagging the EXIF DateTimeOriginal is sufficient.
-
I don't know what happened with your test set. Please you test again when a new version of MC comes out.
-
Very strange - I did this twice. Last time I had weird date errors it was due to US vs. International (dd/mm/yyyy) format, the latter being OS default for me. Any possibility this is throwing off MC's tagging? I will try again this weekend
-
The datetime format should not be an issue. In your screenshot, the "Date" field in MC was "1/2/1973", which is "the 1st of Feb. 1973". In the tag inside the image file, it is "1973:02:01 : : ", and in MC on my computer it is displayed as "2/1/1973" (US format).
-
OMG!
I can finally reproduce! It appears that Google Photos does not like datetime without time.
So, if I tag Date as "2/1/1973", the corresponding EXIF tag is written as "1973:02:01 : : ". Google does not like it. If I tag it "2/1/1973 11:20 am", the EXIF tag is "1973:02:01 11:20:00", and Google will get it.
-
This will be the fix for an upcoming new build (build 44):
Changed: Tagging of EXIF datetime tags will use format "yyyy:MM:dd 00:00:00" for dates without time, instead of "yyyy:MM:dd : : " so that Google Photos will recognize it.
-
So good! Have just tried with 3 equivalent example files, and can confirm this works in Google Photos now...
Google photos reads the following tags written from MC
- [Date]
- [Camera]
- [Caption] (to 'other' field)
Google photos does not, to my knowledge, read any other tags so this is the best compatibility we can hope for currently unless Google expands its metadata options.
I did a similar test in lightroom. Most of the fields are showing as expected, but a bit of weirdness with how the date tags are viewed.
This time I used 4 test files: a phone photo that had already prev tagged in MC (before the exif changes) and now retagged in current version, and three photos newly imported and tagged in MC using the newest (.44) version (a facebook photo, a scanned photo and a new phone camera photo not previously imported into MC).
My test date was 6th Jan 1984 (entered in MC under [Date] as 6/1/1984). This was the only date field I adjusted
- The 6/1/1984 [Date] was displayed under [Capture Date] for all files in lightroom
- Lightroom displayed [Date] inconsistently (6/1/1984 for the facebook photo, 12/8/2023 for the scanned photo, 15/6/2023 for the phone photo just now imported & tagged in MC, and 18/6/2023 for the phone photo that had previously been tagged in MC.
- [Artist] displayed correctly under Creator and Artist for all files
- Country, State, City all show correctly
- [Caption] and [Keywords] display correctly
- [Camera] handled a bit oddly - was tagged as 'MC Camera' in MC, but displays as 'Google MC' for the phone photos (was taken on a Google pixel) and just 'MC' for the others. Not critical as rarely update this field
- Could consider mapping [Name] to 'Title' and [Comment] to 'Headline'? Not sure if there are standard uses for these fields
I think it's all coming together - great work figuring out the Google photos issue.
-
The 6/1/1984 [Date] was displayed under [Capture Date] for all files in lightroom
This corresponds to DateTimeOriginal in EXIF. It is the date the image was created/taken/captured.
Lightroom displayed [Date] inconsistently (6/1/1984 for the facebook photo, 12/8/2023 for the scanned photo, 15/6/2023 for the phone photo just now imported & tagged in MC, and 18/6/2023 for the phone photo that had previously been tagged in MC.
Do you know what date time Lightroom uses for this? For example, is it DateTime, or DateTimeDigitized?
[Camera] handled a bit oddly - was tagged as 'MC Camera' in MC, but displays as 'Google MC' for the phone photos (was taken on a Google pixel) and just 'MC' for the others. Not critical as rarely update this field
Yes, I expected this to happen. We did not anticipate this to be a taggable field, so we join two EXIF tags together, Make and Model, for Camera field. When doing it in reverse we are not really able to split a string into Make and Model and save them separately. So [Camera] just gets saved to Model tag, and the original Make tag remained (Google). These tags truly should only be set by the original device that creates the image (camera or scanner) and not by an application.
Could consider mapping [Name] to 'Title' and [Comment] to 'Headline'? Not sure if there are standard uses for these fields
[Name] will be mapped to "ImageTitle", which is a new tag in EXIF 3.0. I don't see a "Headline" tag in EXIF spec. and we do currently map [Comment] to UserComment tag in EXIF.
-
This is working pretty great - it's so nice seeing (most) of these fields come up in lightroom now.
I found the following info re tagging Date metadata in lightroom
Change the photo capture time
Sometimes you need to change the capture time for your photos. For example, you might need to change the capture times if you traveled to a different time zone and didn’t change your camera’s date/time setting before you started photographing, or if you imported a scanned photo into Lightroom Classic, the photo would contain the creation date of when it was scanned, rather than when it was taken.
In order to save an edited capture time to a raw photo, you must enable the option in the Catalog Settings dialog box. See Customize catalog settings.
Changing the capture time changes the Date Time Original EXIF metadata in the Metadata panel. [b]For most cameras, Date Time Original and Date Time Digitized are the same, so Date Time Digitized changes, too. The Date Time metadata indicates the last time the photo was updated and is not affected when you change the capture time[/b].
So I think that answers your question and explains why MC's [Date] does not simply map to lightroom's vanilla 'Date'. I have tested further and ventured further into LR's handling of EXIF and IPTC. It seems lightroom also has XMP files (I think you have done some work reading these for [People] previously).
-
I have done some playing around with metadata views in Lightroom, and tagging various fields in MC to see how they are mapped. It's looking pretty great. All below done on v *.44
A few things:
- Lightroom has a 'Default' metadata view that displays a mix of its own XMP fields, IPTC and EXIF fields (see pic). To maximise compatibility for the most common use cases, it might make sense to prioritise mapping of these fields? Eg MC not currently using 'Title', 'Rating', 'Label', 'Headline'
- You can show a more comprehensive views of IPTC and EXIF fields (also images attached with displayed values after tagging in MC)
I tagged four test files from different sources in MC, some with existing EXIF/IPTC and some with neither (yellow highlighted fields are custom fields in the 'MC Fields' pic attached, all set to save tags to files)
Lightroom fields in default view that don't appear to be mapped to IPTC or EXIF (therefore probably XMP):
Rating: Not currently mapped to any MC field. Proposal - map to MC field [Rating]
Label: Not currently mapped to any MC field. Proposal - new MC field [Label] or similar
Title: Not currently mapped to any MC field. Would be great if this was mapped from [Name]
People: Mapped to [People] (some inconsistencies if Keywords also tagged)
Keywords: Mapped to [Keywords]
EXIF fields as viewable in Lightroom
'Make' and 'Model' combined in MC into [Camera] as you have indicated
'Date Time Original' mapped from MC [Date]
'Date Time Digitized' and 'Date Time' not editable in default MC fields (but user can create these fields in MC if wanted)
'User Comment' mapped from MC [Comment]
'Artist' mapped from MC [Artist]
IPTC fields as viewable in Lightroom
'Creator' mapped from MC [Artist]
'Description' mapped from MC [Caption]
'Headline' not currently mapped from MC field
'Category' from MC's [Genre]
'Date Created' from MC [Date]
'Sublocation' not currently mapped from MC field
'City' mapped from MC [City]
'State' mapped from MC [State/Province]
'Country / Region' mapped from MC [Country]
'Credit line' mapped from MC [Note]
'Source' not currently mapped from MC field
To list things in the other direction, MC's fields and how they are mapped in lightroom:
- [Name] I am not seeing this in any of the EXIF or IPTC fields in Lightroom. You mentioned is mapped to Image Description (or to User Comment if not ASCII), but perhaps Image Description not used in Lightroom. If [Comment] is filled in MC, does this trump use of [Name] anywhere potentially?
- [Album] not visible anywhere
- [Date] mapped to 'Date Time Original' and working as expected
- [Artist] mapped to EXIF 'Artist' and IPTC 'Creator'
- [Caption] mapping to IPTC 'Description'
- [Keywords] mapping to 'Keywords' - similarly not sure if these are in EXIF or IPTC, appear in separate view and not nested in EXIF/IPTC in metadata window
- [Note] mapped to IPTC 'Credit Line'
- [Comment] mapped to EXIF 'User Comment'
- [People] I recall is mapped to XMP keywords in some creative way - MC reads these, but if written from MC does not appear in lightroom under keywords (in this case MC already writing [Keywords] to LR 'Keywords'
- [Country], [State], [City] all mapped to appropriate IPTC location fields ('Sublocation' is only missing field here)
- [Genre] mapped to IPTC 'Category'
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 (https://community.adobe.com/t5/lightroom-classic-discussions/export-lightroom-color-labels-to-jpeg-metadata/td-p/8835954).
- 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
My next step will be tagging these fields in Lightroom and seeing if changes go back the other way!
Not sure if Daydream, Marko & others have thoughts on applications, use case of these fields.
Thank you for the photo attention :)
-
darichman,
Thanks very much for your thorough testing and for the detailed analysis and suggestions. It's very valuable.
And to Yaobing, for his patient pursuit of a better solution.
Jim
-
darichman,
Thanks very much for your thorough testing and for the detailed analysis and suggestions. It's very valuable.
And to Yaobing, for his patient pursuit of a better solution.
Jim
Yes. Exactly this. I've been itching to get involved, but simply have zero free time atm (wife's had two total knee replacements in five months, second was done a week ago). I have been following closely though...
-
Regarding MC's "File Tags" panel in the tag window...
It should show all the tags currently written in the selected file.
It is not showing the EXIF tags correctly. As far as I can tell, it is only showing the camera make/model info, and sometimes, not even that.
and...
why, why, oh why, does the MC date field not display the "seconds" data? only hours and minutes are displayed. If you then edit the date in tag window, say, by moving the one minute back or forwards, when MC saves that, it discards the seconds, writing them as "00". Please can this be addressed. It's bugged me for a very long time :)
-marko
-
Jim, Marko - no need for thanks as I am a direct beneficiary of this stuff being implemented!
If we can get to the point where all or most these fields are incorporated, then I have a stage 2 list, so don't thank me yet ;)
- pull country, state, suburb from GPS coordinates (I think there are some APIs that do this). Lightroom does this, see attached image - if italicised they are suggested based on GPS data & user can click to tag them. An ideal implementation in MC would be 'Tag places from GPS coordinates' (?prompt if will overwrite existing values)
- bonus implementation: add GPS coordinates manually from map (see LR implementation (https://helpx.adobe.com/au/lightroom-classic/help/maps-module.html#:~:text=If%20matches%20are%20found%2C%20Lightroom,%3E%20Auto%2DTag%20Selected%20Photos.))
- troubleshoot facetagging / [People] handling between MC & llightroom
- look into tagging of raw files, heic files, and consider intersoftware sidecar compatibility of other image files (bmp, tif, png etc)
- kind of related to images, but sort out some date handling strangeness of video files from phone and camera. See bottom paragraph of this post (https://yabb.jriver.com/interact/index.php/topic,135871.msg941250.html#msg941250)
-
Probably not in the MC wheelhouse, but any chance of adding facial recognition?
-
Probably not in the MC wheelhouse, but any chance of adding facial recognition?
This thread is about metadata tagging. So, to the minimum, this thread is the wrong place to ask this question.
-
Probably not in the MC wheelhouse, but any chance of adding facial recognition?
That would be a wonderful addition. I am not certain how big a thing this would be to develop though... Lightroom and Google Photos still don't get it completely right and they have a lot more resourcing to back it.
If we can get the basics of metadata support and interoperability with the main other image/photo contenders then some extra functionality like map view and facetagging would be an aspirational addition. Baby steps :)
-
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.
-
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 (https://community.adobe.com/t5/lightroom-classic-discussions/export-lightroom-color-labels-to-jpeg-metadata/td-p/8835954).
- 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
-
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!
-
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
-
Gentle weekly bump on closing out the IPTC/EXIF/XMP support
Keep it up! We're with you. Thanks again for your patient efforts.
-
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].
-
In my opinion...
Generically I'd say [Title] <-> [Name], [Headline] <-> [Headline], [Caption] <-> [Caption] / [Description].
This sounds sensible to me
-
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?
-
- 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 (https://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata)
-
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.
-
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 (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.
-
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!
-
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.
-
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 :P)
Let us know if can do anything
Cheers, chris
-
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 ;D
-
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
-
[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)?
-
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:
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 ;)
-
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. ;D
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 ;D
Weeell... if one has a 600mm or longer lens... "I was here, the bird in the photo was in the next state!" ;) ;D 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.
-
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.
-
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".
-
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
-
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.
-
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).
-
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
-
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?
-
Happy with either. I guess Image Label more inclusive as not all will be 'photos'
-
I guess Image Label more inclusive as not all will be 'photos'
Agree. OK with [Image Label].
-
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!
-
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/ (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 (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.
-
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.
-
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/ (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.
-
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 (https://iptc.org/std/photometadata/specification/IPTC-PhotoMetadata)
-
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.
-
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 (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. :)
-
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").
-
In build 76, you will be able to delete (if you want to delete it) the "Source" field that we previously created.
-
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/ (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.
-
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.
-
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
-
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.
-
..."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 (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 (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.
-
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 (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").
-
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.
-
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! :)
-
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
-
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)].
-
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.
-
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
-
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
-
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)
Tip of the hat from me to you, Sir.
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)
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 :(
-marko
-
Thanks Marko. I've had it almost as many times as I've been vaccinated for it!
I also use album extensively in expressions, so understand your hesitation. Only difference is I always tag it with something (eg This holiday, or that event).
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.
If support, would still need consensus on which IPTC field to map to. I know there is no 1 for 1 match for use case, but Scene makes most sense to me.
-
Has this one been fixed yet?
Not yet, I think ;)
I have emailed you a description, screens and test files.
Thanks for all the samples!
What’s the reason with [Event]? Some compatibility problem?
Our current code does not handle it correctly. So I am making some big changes, including a much needed update of a third-party library.
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)
We will eventually sort this out.
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
Got two emails from you. Thanks.
-
Our current code does not handle it correctly. So I am making some big changes, including a much needed update of a third-party library.
Thanks Yaobing. In that case, once required coding changes have occurred, my vote is to map [Album] to Event. Not one for one, but at least makes some semantic sense. Second choice would be Scene, followed by the other unmapped fields a few posts back.
In doing this testing, I did also thing about other file formats. All my testing has been with jpg/jpeg files. Have not given a thought to Raw files, tiff, png etc. What image files does MC currently store or attempt to store metadata in? I think Raw formats and tiff at least use EXIF. PNG has a few embedded fields. I'm not sure bmp & gif can store.