Print

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

[darichman]

Hi all - a breakout post from another thread (as per your request Jim!) I have a few nagging limitations in workflow for handling photos and personal videos (home videos from camera, phone etc) so would love these to be revisited.

But namely
More control over date handling, ?updating EXIF, IPTC integration (scanned photos, incorrect dates are a nightmare)
Revisiting tag mapping to improve integration with other platforms (lightroom, google photos)
   Some lightroom compatibility requests in this thread (2020)
Cleaning up date reading in camera/phone video files when imported (details in the linked threads below)
Fix/move/add geotags could be cool with some map integration

I described my image/photo worfklow here, which hasn't really changed that much. I'll copy relevant excerpts below:

• My 'photo' collection is a large and varied collection of image files of varying file types (some easily taggable and some not) and sources (eg many scanned images of older printed photos as well as digital camera/phone photos & videos)
• I would ideally like to stick with MC for as much of my workflow as possible (tagging, organising), but have to venture out to other programs where MC is unable to perform certain tasks (face tagging, geotagging, batch update of dates, EXIF editing, sharing through cloud platforms) especially Google Photos
• The capabilities of google photos (and other cloud services) are hard to ignore and integration should be the aim.
• I am not a fan of relinquishing my photo collection in its entirety to the cloud. I like to pick what I want to upload from my 'master' MC library (and can use a tag to flag this!). The automatic cataloging features of Google Photos are amazing, but if I want to change anything, I'm locked out. Have you tried tagging dates, multiple photos etc in Google Photos? You cannot manually tag faces or places either. There is no transparency as to how this metadata is stored, and if I download these photos and import in MC none of that data is there. I will only ever view this as a convenient, easily sharable 'copy' of a subset of my library.
• Sometimes editing photos or metadata in programs external to MC (eg facetagging or geotagging in Lightroom) can change tags/metadata in unexpected ways (date, fields not updating in MC even if manually requested)
• Photo editing is probably a separate beast so I'll leave that out of this thread.

My main desire is to have MC as the main truth for import, tag, organise of photos. But then to use it to share to other platforms (and to play nicely with them on the metadata front where possible). I am android/google based, so once my photos are tagged the way I want locally, I want to upload them to the cloud (google photos).

Here are my problems with my current workflow:

• Scanned photos represent a problem: while I can use MC to set the dates, these are not written to EXIF/IPTC. When I import MC-tagged scanned photos into lightroom, google photos etc, they always use the scanned date, which makes organisation a mess. There are naturally other tools out there to manage EXIF tags, but this is another step which I'd love to avoid given I have the correct dates in MC. Please write [date] to the file in a way that other software will read it!
• Upload to Google Photos: Unfortunately, from what I can tell, very little metadata finds its way onto Google Photos (date, keywords, camera details). I would somehow love [Album] to magically map, but this field doesn't seem to be read by Google or Adobe
• Re personal videos: I still get dodgy dates for videos when I import from android (or from a camera SD etc)
  See posts from 2012, and ten years later 2022
  The correct 'Date' should be that in [date created]. Each time I mass import videos from my Pixel phone, I have to remember to copy [date created] to [date] so they tag/sort correctly

For me, some attention to photos and home videos would be a big win. Thanks for any attention in MC31

[JimH]

There was a date change recently that might help:
https://yabb.jriver.com/interact/index.php/topic,135364.msg939375.html#msg939375

I think there was also an EXIF tag change.

[darichman]

Thanks Jim

Yes, the batch 'Adjust date/time' is great. I use it in any case where a batch of photos from a camera had the wrong date set (great for increments where they are all out by the same amount)

But this does not help for scanned photos, and does not negate the date stored in the file not being updated in a way that can reliably be read by other programs.

I have made a few screenshots to illustrate date issues with photo import/workflow

Import from Phone/OS into MC
See attached pictures. In this example, the correct [Date] for both the photo and video is 9th April 2023  5:34pm (9/4/2023, I'm in Australia). This is the time they were both 'taken'. You can see in the file system filename, the phone for some reason uses PXL_20230409_073437401. The difference in the time element of this, I suspect may be due to timezone settings of the device... the actual time is 5:34am, not 07:34am.

• 1: Mixture of photos/videos to be imported from phone SD card (Google Pixel 6 Pro). Note fairly standard file naming convention in file system
• 2: Photo Windows properties: note displays correct date under 'Date taken'
• 2: Video Windows properties: note displays correct date under 'Media created'
• 3: This is the initial view when both files imported into MC (drag and drop). MC strips the additional filename string from the video file and just puts 'Pxl' in name. This is undesirable as there are dozens of videos and all will be named 'Pxl'. For the photo, MC retains the full filename for in [Name] (desired) and prefills [Album] with a short-form date
• 4: I changed the view to show some of the different dates, unedited (what shows when first imported into MC). For the video, MC is showing 9/4/23 7:43am for the video. This is incorrect - I suspect it's trying to pull this from the filename itself? Or from Date created? The correct date is actually in [Date Modified], so it's necessary for me to copy this to [Date] on every import of phone/camera video files. For the image, the correct date is used in [Date], but I have no idea where MC is getting the [Date created] time of 8/5/23 1:27pm and [date modified] time of 8/5/2023 1:42pm. At any rate, MC is showing different values for the photo and the video, which were taken at the same time

Next post, will show challenges with photos from other sources (eg scanned) and limitations with lightroom and Google Photos

[darichman]

Dates and Scanned Images

In this example, this is a digital image from a photo that was taken on 6th Jan 1969 (6/1/1969), scanned on 16/4/2008 and imported into MC today (8/5/2023). Really, the only important 'date' is 6/1/1969. I don't really need to know or care when I scanned it, although some might. Desire is for the main [Date] to be 6/1/1969.

• 5: See windows file properties - [Date taken] 16/04/2008 11:17pm (photo was scanned with Adobe Photoshop). In the second screenshot, can see [date created] 8/05/2023 1:54pm (not actually, I just copied the file to a new folder to do this test) and [date modified] 16/10/2011 6:25pm (not sure why, possibly an old tag edit from Adobe)
• 6: When imported into MC, reads the [Date] as 16/10/2011 6:25pm (ie the same as date modified) and [date created] 8/5/2023 1:54pm. Of course it doesn't know the actual date yet as I haven't tagged it.
• 7: I tagged the [Date] field as 6/1/1969, the date the photo was 'taken'
• 8: As a test, I tagged a few MC fields [Album] (MC Album), [Caption] (MC Caption) and Keywords (MC Keywords)
• 9: When I look at the windows property of the file again, the [date taken] is still 16/04/2008 11:17pm

Will split rest of post to permit attachments...

[darichman]

10 Imported file into lightroom (after tagging above in MC):

• Lightroom correctly pulls the correct 6/1/1969 date into the general [capture date] field and IPTC [date created] field. It pulls the 16/4/2008 date into the general [date] field
• It does not pull [Caption] or [Keywords] from the MC tag

11 Imported file into Google Photos

• Google photos reads the date as 16/4/2008. The correct 6/1/1969 date does not appear anywhere.
• MC's [caption] field is listed under an 'Other' field. There is a 'Description' field in Google Photos that would be the best mapping for this
• Google photos does not see [keywords] or [album]. Google has an Album field, but I'm fairly sure there's no way to force it to read from the tag (which would be ideal in a perfect world)

Thanks for looking at this Jim and team!!

[darichman]

Gentle, but hopeful, bump

[Matt]

I'm looking at this a little bit.

We already set the date to the EXIF and IPTC tags.  Keywords are stored in the IPTC tag.  Caption is saved in the XMP and IPTC tags.

Image tagging is a little bit of a scatter shot because there's no single absolute standard.  We're trying to support everything we know about.

If there are additional specific tags you would like to see mapped, please provide details.

Thanks.

[JimH]

https://yabb.jriver.com/interact/index.php/topic,126282.msg875430.html#msg875430

[Daydream]

Image tagging is a little bit of a scatter shot because there's no single absolute standard.

IPTC is a well defined standard. Any DAM software starts there.

To expand a bit with examples on my last post on the thread Jim linked to, fields like [Headline] do not exist in MC while a field like [Places] is an arbitrary combination that exists only in MC, instead of proper IPTC fields of [City], [State/Province] and [Country].

Maybe I'm a pro photographer; maybe I'm a data hoarder backing up Getty Images. Those fields matter. Also this situation raises a lot of questions regarding interoperability. I don't know how photo tags set in MC show up in other software, because MC does it's own non-standard thing. It may work, it may not, but nobody working with a lot of images would want to doubt the results at every turn, to wonder "what else...?" might go wrong.

[Matt]

Coming when the build gets out of beta:
NEW: Added the tags City and State/Province and mapped them to the same IPTC fields for images.

Thanks for the suggestion.

[darichman]

I'm looking at this a little bit.

We already set the date to the EXIF and IPTC tags.  Keywords are stored in the IPTC tag.  Caption is saved in the XMP and IPTC tags.

Thanks Matt for looking at this. Even this helps clarify how things are stored currently and probably explains some of the quirks in interoperability. Thanks (old friend) Daydream for the insights into the technical aspects of the standards - I'm not familiar with the tech parts, and am in the group that 'just wants things to work'. Of course this relies on the technical underpinnings though

The standard location fields are a great addition - I had custom [State] and [Country] MC fields so look forward to migrating these.

If there are additional specific tags you would like to see mapped, please provide details.

Matt - if [Date] is written to EXIF, do you have any insight into which [Date] field it is mapped to? See my comments in opening posts about how this is inconsistently read across programs - Google photos, lightroom.

Lightroom does not seem to pull [Caption] or [Keywords] from the MC tag (see my examples above)

Thank you thank you for looking at this!

[Matt]

Matt - if [Date] is written to EXIF, do you have any insight into which [Date] field it is mapped to? See my comments in opening posts about how this is inconsistently read across programs - Google photos, lightroom.

It's the primary "Date" field in Media Center.  We set the date in XMP, IPTC, and EXIF.

Lightroom does not seem to pull [Caption] or [Keywords] from the MC tag (see my examples above)

"Caption" and "Keywords" are written to XMP and IPTC.  Also to the MJMD tag, but that doesn't help outside JRiver.

[JimH]

darichman, 
Thanks for helping.  We won't quit until this is right. 

[marko]

I'm looking at this a little bit.

We already set the date to the EXIF and IPTC tags.  Keywords are stored in the IPTC tag.  Caption is saved in the XMP and IPTC tags.

I had quite a long post almost ready to send, then found something a lot more important....

Take an image that has no existing EXIF tag block, import it into MC and set the date.
MC does not write the date to EXIF "Date/Time Original"

Use a third party app to set the EXIF "Date/Time Original". Choose a different date/time than that set in MC. MC will immediately detect the new date and update accordingly, now, change the date in MC again, and now, MC correctly writes the date to EXIF "Date/Time Original"

So, if the EXIF date does not exist when the date is changed in MC (typical of most 'old photo' scanned images) MC should create it. It does not. That's a big deal as the EXIF "Date/Time Original" is what just about everything out there looks for when parsing an image for a date.

-marko

[darichman]

MC does not write the date to EXIF "Date/Time Original"

That could be it then! Might also make sense, as per my earlier post ('Dates and Scanned Images') MC seems to pull [Date] on import from the [Date modified] field (indicated by windows file properties).

For my personal use, none of the other date fields actually matter for me (date created vs date modified vs. date/time original etc) - I understand there might be use cases where they do. The simplest option (for me) would be that setting [Date] in MC sets [Date taken], [Date created], [Date/time original] in all the relevant tags. This could also be run from 'update tags from library' (and if no existing EXIF tag then one should be created?) This would maximise compatibility/consistency but is a bit of a blunt instrument for those who might want to preserve the other tags.

I would love to see a table that mapped out various date fields and mappings across the main programs. Eg Windows file properties lists [Date taken], [Date created], [Date modified]  vs EXIF / IPTC / XMP vs Lightoom vs Google photos.

darichman, 
Thanks for helping.  We won't quit until this is right. 

Jim I am super appreciative!! I know it's a complicated mess and might not be up there with more exciting priorities. So I do appreciate the time and effort

[Daydream]

I would love to see a table that mapped out various date fields and mappings across the main programs.

I would like that  too, but that can get weird in a hurry. Mainly because various programs don't call fields by the exact same name; i.e. what is "Byline title" in XNViewMP, it's "Author's Title" in IrfanView, it's "Job Title" in Lightroom and ACDSee, and "Creator's Job Title" in PhotoMechanic; and it's missing entirely from MC. One looks up and down 5 times for each program to see if the data doesn't pop up under some other name, and then do the whole exercise again some 70 times for all the other fields and... I tried. I felt like throwing things at the monitor after 30 minutes. I've seen some comparisons online but they were from 2007 or something, not actual anymore.

Anyways. There are resources out there. I don't know if this helps Matt & team, to feed the entire IPTC standard into some implementation/validation/automation but the latest specs are here in JSON and YAML formats. Main page here. I totally get it that very few people will need exotic stuff like "ISO Country code" or "Featured Org. Code" fields, although supporting the whole standard may be an extra selling point for MC; if you can use the data I linked to bulk-implement these (can you tell I'm not a coder? ) - awesome; if not, any efforts to add any more useful metadata are greatly appreciated.

Of much fun is THIS image they provide, that actually has all the IPTC fields populated (Core and Extensions) and can help see how thorough the IPTC metadata implementation is in your fav viewer/DAM/etc. Lightroom and PhotoMechanic dwarf everybody regarding fields recognized.

[JimH]

We will continue to work on this.  It might help if you can suggest a few IPTC tags we should read.

It's amusing to be advised to support "standards".  We invented our image tagging because we could find no standards when we began supporting images.  That was 2007 or a little earlier, around the same time that Lightroom appeared.

Correction.  Our image support dates back at least to 2004 with MC11.

[markf2748]

I would like that  too, but that can get weird in a hurry. Mainly because various programs don't call fields by the exact same name; i.e. what is "Byline title" in XNViewMP, it's "Author's Title" in IrfanView, it's "Job Title" in Lightroom and ACDSee, and "Creator's Job Title" in PhotoMechanic; and it's missing entirely from MC. One looks up and down 5 times for each program to see if the data doesn't pop up under some other name, and then do the whole exercise again some 70 times for all the other fields and... I tried. I felt like throwing things at the monitor after 30 minutes. I've seen some comparisons online but they were from 2007 or something, not actual anymore.

Perhaps JRiver could start off with a more modest goal:  produce and maintain a table of all its built-in image tags, showing the standard metadata mappings (from XMP, IPTC, Exif, ...) performed by MC (the relationship to tags in popular image processing programs would be an added bonus, but I would not expect it from JRiver).  A good start would be a clear, updated tabular version of the information in the Wiki page Photo Tagging (https://wiki.jriver.com/index.php/Photo_Tagging).  For dates, a table could indicate how MC internally maps imported OS dates upon a file read, and indicate any MC or OS dates which change after an image file save.

For an analogous example, here is how the program Mp3tag documents its mapping of multiple Audio metadata formats:
https://docs.mp3tag.de/mapping/
https://docs.mp3tag.de/mapping-table/

6/11/2023 Updated for clarity.

[Matt]

We're writing a new EXIF framework now.  The current one is not able to write tags if they're not there.  It will be a few weeks but expect full read and write support.  Thanks again for the help.

[JimH]

We're writing a new EXIF framework now.  The current one is not able to write tags if they're not there.  It will be a few weeks but expect full read and write support.  Thanks again for the help.

This should start to be available in a few days.

[darichman]

Thanks both for your commitment to an area that may not get the volume and interest of audio and video

[JimH]

It's in 31.0.26.

[Cinelder]

Thanks both for your commitment to an area that may not get the volume and interest of audio and video

+1 Greatly appreciated.  I also JRiver to manage photos, as well as audio, video.  This is a very welcome feature enhancement.