Options
EXIF Date handling in Smugmug and LR Plugin
Ferguson
Registered Users Posts: 1,339 Major grins
There have been several discussions on this and I thought I would do some experimentation.
Smugmug and/or Lightroom and/or the Smugmug lightroom plugin do not behave in a consistent fashion, in my opinion, though it is a bit unclear how much of this is due to Adobe vs. Smugmug. This leads to the possibility of some serious confusion for users. I'd like to suggest that collectively this rises to the level of a bug. Here is what I've found in testing today (I hear things changed recently but cannot say, I did all this on 1/4/2016).
To test, I wrote an image generator that would explicitly set six EXIF fields in various combinations. They are:
a) DateTimeOriginal, i.e. code 0x9003, sometimes called Capture date time, and associated subsecond field 0x9291.
b) DateTimeDigitized, i.e. code 0x9004, original time or create time perhaps, with subsecond field 0x9292.
c) DateTime, sometimes called Modify date, with subsecond time 0x9290.
First, as best I could tell in any test, the SubSecond codes are ignored by Smugmug. While I guess a feature request, I'd offer than with today's high burst rates, omission of the subsecond field is a real deficiency notably for sorts by capture date/time. But I won't dwell on that further.
There are two fundamental issues.
1) This data is not replaced on updates. A web upload "replace", or a lightroom metadata update, OR a lightroom republish does not update these. It is necessary to delete and re-upload, which is not terribly practical in Lightroom unless one has a 1:1 correspondence between folders or collections and publishing collections (after all, the purpose of a publishing collection is to, well, collect and if one has to separately create a collection to preserve the publish collection to delete and re-upload... well, you get the idea). And in any case, it is natural that a user would believe that a replacement replaces the data, at least data that cannot be (and was not) editing on Smugmug itself.
2) The data is inconsistently updated between the plugin and web upload, as shown in the following table. Specifically:
- The LR plugin appears to set the Date Modified to the upload date (or something like that), as opposed to any metadata field from the image itself. The Web Upload on the other hand will ONLY set the Modified Date to the DateTime field within the image, and does not use either the upload or other dates if that is missing. (Note I did not test manual changes on the SM web interface to see if it sets modified date). Further note that replacement upload of the image does not change this date even from Lightroom, despite it using the upload date in the initial upload.
- The LR plugin uses DateTimeDigitized as Date Taken if the DateTimeOriginal is not present, the Web Upload will leave the Date Taken blank. The Web Upload will only use the image's DateTimeOriginal field for Date Taken.
Finally, I should note that the testing was done with JPG files, with explicit EXIF information inside the file. When I changed the capture date, it was changed in the image itself directly, and NOT through editing with Lightroom (doing it in Lightroom changes many, many fields in the image if the metadata is written to the file, as it restructures the EXIF and other segments).
I think that these together, especially the replacement issue is very confusing for users who try to understand why they are not getting the results they intend, and to suggest that Smugmug needs to address:
1) Make the LR plugin and the Web upload work the same way (even if Adobe limits what you can do in the plugin, make the web upload work the same).
2) Make all replace functions (plugin via metadata update, plugin via image update, image replace via web) update all metadata fields not manually updated on Smugmug, including the results of these three fields (however #1 makes that come out).
And if possible (admittedly an enhancement, but while you are in there):
3) Include support for the SubSecond fields, at least for DateTimeOriginal, so bursts will come out in the proper order.
Please.
Smugmug and/or Lightroom and/or the Smugmug lightroom plugin do not behave in a consistent fashion, in my opinion, though it is a bit unclear how much of this is due to Adobe vs. Smugmug. This leads to the possibility of some serious confusion for users. I'd like to suggest that collectively this rises to the level of a bug. Here is what I've found in testing today (I hear things changed recently but cannot say, I did all this on 1/4/2016).
To test, I wrote an image generator that would explicitly set six EXIF fields in various combinations. They are:
a) DateTimeOriginal, i.e. code 0x9003, sometimes called Capture date time, and associated subsecond field 0x9291.
b) DateTimeDigitized, i.e. code 0x9004, original time or create time perhaps, with subsecond field 0x9292.
c) DateTime, sometimes called Modify date, with subsecond time 0x9290.
First, as best I could tell in any test, the SubSecond codes are ignored by Smugmug. While I guess a feature request, I'd offer than with today's high burst rates, omission of the subsecond field is a real deficiency notably for sorts by capture date/time. But I won't dwell on that further.
There are two fundamental issues.
1) This data is not replaced on updates. A web upload "replace", or a lightroom metadata update, OR a lightroom republish does not update these. It is necessary to delete and re-upload, which is not terribly practical in Lightroom unless one has a 1:1 correspondence between folders or collections and publishing collections (after all, the purpose of a publishing collection is to, well, collect and if one has to separately create a collection to preserve the publish collection to delete and re-upload... well, you get the idea). And in any case, it is natural that a user would believe that a replacement replaces the data, at least data that cannot be (and was not) editing on Smugmug itself.
2) The data is inconsistently updated between the plugin and web upload, as shown in the following table. Specifically:
- The LR plugin appears to set the Date Modified to the upload date (or something like that), as opposed to any metadata field from the image itself. The Web Upload on the other hand will ONLY set the Modified Date to the DateTime field within the image, and does not use either the upload or other dates if that is missing. (Note I did not test manual changes on the SM web interface to see if it sets modified date). Further note that replacement upload of the image does not change this date even from Lightroom, despite it using the upload date in the initial upload.
- The LR plugin uses DateTimeDigitized as Date Taken if the DateTimeOriginal is not present, the Web Upload will leave the Date Taken blank. The Web Upload will only use the image's DateTimeOriginal field for Date Taken.
Finally, I should note that the testing was done with JPG files, with explicit EXIF information inside the file. When I changed the capture date, it was changed in the image itself directly, and NOT through editing with Lightroom (doing it in Lightroom changes many, many fields in the image if the metadata is written to the file, as it restructures the EXIF and other segments).
I think that these together, especially the replacement issue is very confusing for users who try to understand why they are not getting the results they intend, and to suggest that Smugmug needs to address:
1) Make the LR plugin and the Web upload work the same way (even if Adobe limits what you can do in the plugin, make the web upload work the same).
2) Make all replace functions (plugin via metadata update, plugin via image update, image replace via web) update all metadata fields not manually updated on Smugmug, including the results of these three fields (however #1 makes that come out).
And if possible (admittedly an enhancement, but while you are in there):
3) Include support for the SubSecond fields, at least for DateTimeOriginal, so bursts will come out in the proper order.
Please.
0
Comments
There is a lot of stuff to digest in here...will probably need to read a few times before I have a full handle on all it.
I think that any where you have used LR plugin with respect to metadata, you should replace that with LR.
In regard to your table, LR vs web upload, we don't handle things differently for LR....I know for a fact that LR always updates the Date Modified on export. I'm assuming you created the files and then imported them into LR and uploaded and then used the web upload on the original files ? Can you do another test for me ? Export the files from LR to disk and then upload those files using the web uploader...I think you will find that in that situation, the metadata is the same for the LR and web uploads.
I totally agree with a number of your points...including subsecond sorting and metadata replacement.
Cheers,
David
SmugMug API Developer
My Photos
That seemed likely but I want to go through them more carefully. Though something is different in how Smugmug is handling DateTimeDigitized, I think. Is that part of the changes rolled out, and maybe in the last few hours?
If you want to see them...
Gallery uploaded (once only) with plugin: LR Upload
Export to disk and upload to gallery with web: Web Upload
Original files uploaded with the web: Original via Web
The photos should be self explanatory (ignore the names, look at the image). Obviously the image is what the jpg started with, not what it ended up with necessarily.
The place I am confused is before, I thought, LR's plugin would upload a file with DateTimeDigitized only and show the Date Taken from the DateTimeDigitized (if no DateTimeOriginal present). Now I'm not seeing a Date Taken at all from LR (or the web upload). I'm wondering if my testing is overlapping some changes being made? Or did I just screw up?
More when I'm awake tomorrow.
Oh... for anyone reading this later, the links above may disappear soon, they are just test galleries.
- CreateDate = Date the file was created, also known in some places as Digitized Date. If this was a scan, the date it was scanned (as in 2016-01-04 20:58:00). If it was a photo, the original date, as assumed based on the cameras clock.
- DateCreated = The date the photo was taken, which can be modified by the user. If you needed to update metadata, this is what Photoshop/Bridge was updating. It left CreateDate alone. In the example in the other thread, it was the 1972 date.
We go down the metadata tree, looking for Digitized Date (date the file was really created), Date Taken (often DateTimeOriginal), and Date Modified. We'll look at XMP, EXIF, IPTC, etc. The update today checked for XMP CreateDate and now sets it as Digitized Date, as well as looking for DateCreated and sets that as Date Taken.
It is planned to have photo replaces update the metadata. The only thing that wouldn't change is if you updated the Title, Keywords, or Captions on SmugMug (since we store these separately).
We do store the SubSecond date, we're just not using it. I'll have to chat with the team
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
OK, I think I understand, though this is very confusing.
You are saying that the Digitized Date will not be taken as the Smugmug Date Taken at all, right? In fact it is not even shown on the info screen?
Previously when I uploaded a file which contained ONLY the Date Digitized, though the web, I did not get a Date Taken at all.
However, Lightroom adds confusion. If you publish a DateDigitized photo from lightroom, it has:
Exif IFD0 has a modify date now (when exported), which is fine, and appears in SM
IPTC now has a "Digital Creation Date" (matching the datetime digitized)
XMP-xmp has a Create Date (matches), and also Modify and Metadata Date (upload time)
All of these create dates are correct (i.e. match the DateTimeDigitized I used) but none of them cause Smugmug (via the web upload) to do a Date Taken, only a (current timestamp) Date Modified. But the LR plugin did upload the digitized date to Date Taken previously and does not now.
If that's the intended action it worked, now working both in LR and in web upload.
So you have metadata that you keep, but cannot be seen on the info screen? Interesting. I guess a question would be "why"? In both directions - why keep it if you don't use it, and why not show it if you have it? (Note I'm not objecting, it's not a privacy thing; if people put metadata in images and upload them, they certainly can't complain if it is scanned).
But in that vein, if subsecond is there, adding it just to the associated sort would be a very nice goodness, and probably cannot do any harm, since it's just associated with the sort logic and no displays (necessarily). And then some of the dunk shots I have posted will stop showing it going through the basket before it is dunked!
You are correct, though, that including subsecond in sorting would be the place where it should be used. I'll see what that would take.
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
Oh, I agree, there's really not a lot of point in showing it, other than perhaps debugging, which one could go back to the original if one knew that it was in use.
Now... I need to go back to that original problem I had with GIFS and see if armed with all this I can figure that out.
Would you be able to share a few images with me that are the same second but out of order? I'm trying to build some test cases for our Engineers to work with while we try to sort this out (pun intended :P)
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
Sure. Here's a gallery with two types of tests combined.
http://www.captivephotons.com/Other/Sort-By-Test/n-zJ7PFB/
Three of the files have all three EXIF dates set, but set differently, so you can tell which field it is sorting by. I think this is moot as I think SM is doing the right thing. Those are showing with three red lines of text.
The other six images have just the DateTimeOriginal and Subsecond set, the date time is the same on each, but the subsecond is different. I carefully uploaded out of order as I think upload order may influence how it sorts, so right now they are not in order.
These are faked test shots to make it easy (since the image shows you what date it contains). I did NOT use Lightroom to upload, so the image as uploaded should have only and exactly the EXIF fields shown in the image (I do not think that affects the sort issue but at least it is one less variable).
As to finding some real test cases... I'll look. I've avoided doing it lately and/or have overridden the capture times to whole second differences just to avoid the problem, but I suspect somewhere I can find one I let slide through.
But the above test cases should be easiest. You're welcome to the images, for that matter to the C# program that produces test cases if you want it.
Look in this gallery here and look at the 4 shots starting at #50.
That's Julian Debose leaping over a Lipscomb defender (well, almost over - giving him a knee to the chin in the process), except you'll see that #3 and #2 in the series are reversed.
Incidentally, he made the shot, was initially called as a defensive foul as they thought the Lipscomb player was in the restricted arc, but then found he was just outside of it and they called Julian for the charge and took back the two points. Not that any of this affects how it sorts of course. But it's a little more real world than my test red-on-black shots.
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
Just wanted to express my hope that this happens soon. The fact that Date Modified isn't correct on replacements has been a source of confusion and extra work for a long time. Thanks!
Let me know if it works for you or if there's still an issue.
-Aaron
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
Is a reload necessary to see it? I'm not seeing videos sorting right for example.
Also, I assume above "not" = "now".
We are not using subsecond right now. It would have required a much bigger rewrite. When we looked at the data, most of the instances of the same exact DateTime stamp occurred when doing bursts from a single camera, and thus falling back to a secondary sort using filename should yield the same results as if we had used subsecond. If course, this doesn't help the instance when 2 photographers take a photo at the same second, and then upload to one gallery.
If you have a gallery for me to take a look at, it's always helpful!
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
Oh, OK... Need to think about that, as I rename all photos for publish. But I think I'm appending enough stuff to the rename to get them in order. Maybe.
I'm astounded that adding ", isnull(subsecond,0)" or similar to the sort sequence was a major rewrite.
But... look here:
http://www.captivephotons.com/BettyJo/Fishing/
Image #4 (as I see it) has a title of "Denise and Jerry Fishing Trip - DSCN1657_68649.mp4" and shows a "Date Taken" of 2016-02-16 14:45:18.
If you look through the jpg's, it should put it at the end by date taken (the date taken is actually wrong, it is the date modified, but that's probably a different issue as you mentioned above about dodgy fields in videos). I assume if you are seeing "date taken" you should be using the same one internally to sort?
Setting it to something else and then back to date taken seems to have fixed the order to how we expected with the videos. To make galleries load faster the sort order is already defined and toggling it just updated the sorting to use the new logic. We didn't go through and automatically re-sort.
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
Got it. That did correct it.
I don't suppose you can think of an automatic way to reset them all? (Especially given I have some that are not date taken).
Or is this a cache that periodically gets cleared, like every 30 days or some such?
I guess not a big deal, but also not really practical for old history when I have no idea which ones had bursts or videos. But if you guys maybe could run some kind of big nightly job once to resort everyone according to the current settings, that sure would be a great way to close out this issue.
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
I have noticed recently that when I update a photo (develop changes, etc.) the EXIF values for date modified and software do not change. While not earth-shattering it does raise a question: why is the EXIF data not being updated? It seems only logical that when I update a photo I want to update the accompanying information...
Your statement above reads to me that currently replacing a photo does not replace the EXIF metadata. Is this really true? Hard to believe.
Thanks in advance for any further information.
Cheers, Sara
This is correct. Replacing a photo does not replace the metadata. You'd need to delete the photo and re-upload.
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
Yep - we'd love to change things, as I mentioned above, but I'm not able to comment on the timeframe as we're busy at work on some other projects. It's on my radar and something I'm pretty passionate about getting changed in the future, so you've got my vote on getting it fixed
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
Just be aware this changes the URL by which they are accessed. That's fine if people only view them in your gallery, but if you ever linked to the individual photo from the share button, this breaks the link.
Yeah, this is why this whole metadata replace thing is so convoluted.
Smugmug has always allowed one to fix metadata, but the cure is, for some, worse than the disease, when you delete and upload-as-new.
I think they are starting to hear how disruptive that is.
Though... maybe there's a solution embedded in there somewhere -- a "really replace" that does a delete and upload new but keeps the same URL, perhaps something the LR plugin could do inside the API? Just thinking out loud in case someone has an ah ha moment at SM.