SM Displays Incorrect Time for Images

DBR

There appear to be 3 standard timestamps recorded in EXIF data. The first, DateTimeOriginal is the time and date that the image was taken. The second, DateTimeDigitized, is often the same. It's really there to distinguish between the time a picture was taken on film, and the time the film was scanned and digitized. The third, DateTime, is typically described as the date and time of image creation; however, it is generally used to record the latest time that an image was modified.

When I upload JPGs to SM, the JPGs retain all three fields in their metadata. However, when I click on the Info icon and SM pops up a box to offer additional information, it only displays two timestamps. It labels them Date Taken and Date Modified. I'm not sure where the Date Modified timestamp is coming from. It doesn't match any of the EXIF data.

The Date Taken is incorrectly set to DateTime, rather than DateTimeOriginal. Could this be fixed? Is there a setting I need to change on my account for this to work properly?

Thank you,

David

David Evertsen

DBR wrote: »

There appear to be 3 standard timestamps recorded in EXIF data. The first, DateTimeOriginal is the time and date that the image was taken. The second, DateTimeDigitized, is often the same. It's really there to distinguish between the time a picture was taken on film, and the time the film was scanned and digitized. The third, DateTime, is typically described as the date and time of image creation; however, it is generally used to record the latest time that an image was modified.

When I upload JPGs to SM, the JPGs retain all three fields in their metadata. However, when I click on the Info icon and SM pops up a box to offer additional information, it only displays two timestamps. It labels them Date Taken and Date Modified. I'm not sure where the Date Modified timestamp is coming from. It doesn't match any of the EXIF data.

The Date Taken is incorrectly set to DateTime, rather than DateTimeOriginal. Could this be fixed? Is there a setting I need to change on my account for this to work properly?

Thank you,

David

I have had issues for years with using date and time to automatically sort my images and even image name on SM forever.. There are always several images per gallery using the parameters that are not correct I have heard the same from others ..

Lille Ulven

DBR, I am just wondering... and might be completely off... could the Date Modified be the last date when you change that particular photo in your Smugmug gallery? That would at least make some sense to me

As for the DateTaken - I would love to see that fixed. Just for curiosity: are you uploading with the Smugmug LRPlugin? As I have noticed that the Plugin seems occasionally to change the Date back in LR (during sync?) for me - which is a pain in the ass to get that one right again afterwards.

Have a great weekend

Lille Ulven

DBR

Lille - yes, I think you are right. The displayed Date Modified does appear to correspond to the time I uploaded my images. And yes, I'm using the Smugmug LRPlugin. I haven't noticed it change the date back on my computer. I would be quite annoyed if it did; however, I think it's likely that if it has, I haven't noticed. How did you notice it? Do you have a feel for what would cause that, and how to avoid it?

I was really hoping that a Smugmug Hero would respond to this. Ideally, I'd like to hear an acknowledgement of the problem, and that a fix is underway. It would be nice even to hear that while this is an issue, changing it would be too impactful on other Smugmug clients. It would be useful even to hear that no, they don't think it's a problem, and I'm off base in my expectation. At least then there would be a point to argue. (No, Adobe's really not a small player in this field, and this seems to be the way that they interpret the metadata.)

It appears that the metadata in the images is not being changed incorrectly - it's just being displayed incorrectly. That should be reasonably straightforward to correct.

David

DBR

Anyone from Smugmug going to comment?

Lille Ulven

DBR First of all I am sorry for not having replied earlier to your question - I just did not see it before now.

How did I notice the mess up...
I had a look at one of my New Zealand galleries on my site in the beginning of the year, and of the first photos which I was certain to have uploaded and of which I was certain that it should come rather within the first five photos of the gallery (sorted by date) did not show up. I later found it hidden behind a photo that I knew for sure was taken later.
Basically Princes Wharf from Auckland was the missing photo and first when I looked through the entire gallery I found it behind the Whanganui River Valley photos, which is pretty much as wrong as it can get as I traveled from Auckland via Whanganui and Wellington to (eventually) Christchurch.
At first I thought something with the sorting must have gone wrong, but then I needed to export some of my LR files for something and again I knew a certain photo from January 2013 had to be in that selection - all my photos are named automatically with Date_Time in the beginning of the name, yet in my export catalog there was no such file. But I found the photo with a name starting with a 2014 date - which is pretty much as wrong as it can get.
So that's when I started researching it a little more. And found that some of my files that I have presented on my website got the wrong Date Time Digitized (and wrong Date Time Original). Which was surprising to me, especially since I cannot change that date so easily in LR. Yet the "original RAW files" in the same catalogue as well as the virtual copies that did not make it onto my website from both before and afterwards had the correct dates...
So that way there was at least a chance of getting it fixed by copying the Metadata from the correct file to the one which now had the correct date.

I think in the end I even used LR filters to find all NZ photos that had dates that were newer than 30th January 2013 - the day I left NZ and the same for a couple of other travel photos and seasonal photos - there is just no chance I would be able to take a photo of some Christmas decoration in April

So basically I was saved by virtual copies and the availability of JPEGs of the very same photos too for those where I had no virtual copies.

I can guarantee for one thing: I went through my entire stock of bad-language-words when I found out about it And was short before writing a bash-script to correct those dates (which would not have worked with virtual copies after all).

First of all:
I do not believe that there is any other chance when using Date Modified by Smugmug as the date of the last upload to Smugmug for sorting. This because, as far as I can recall, since LR does not make any physical changes to your files when you do any type of post-processing with them (unless you export them or specifically write your Metadata to the files) there is no such thing as a Last Updated Date in LR which Smugmug could use for this matter.
For the why that error with the write back occurred in the first place I can only help out with speculations...
I think that in some version of the plugin the Modify Date of the files was accessed (my idea comes from the fact that the Modify Date of one of my files looks very much like the date I remember to have had suddenly as the wrong Date Time Created, but this date is from before I had a website) and that at some point this has been changed to use the Date Uploaded as the date to signal to Smugmug that a file has been changed. Possibly within this change, I suspect that the synchronize function which also is triggered by a date-value accidentally had the Modify Date taken in as a "trigger value" and accidentally wrote that back into the files as Date Time Digitized. This might have occurred because someone used variable names that for the first programmer were obvious to indicate X and for programmer number 2 who continued with this function were obvious to contain Y, but it might also just be that someone during the coding got those variables just messed up. Happens to all coders from time to time, especially when under pressure or when having to learn lots of new systems. And sometimes these are the things that you do not catch in testing either - it might be that it is not just "one" function it might be that it is the input and output of two or more functions talking with each other and if you then have not perfectly clear documentation all you see is "this function gets me the date back" unfortunately it does not tell you on first view that it is giving you the Date Modified and not the Date Time Digitized that you would have wanted...
(Yes, coding databases is what still pays my bills )

So just try to give them some time to figure out what has happened here in the background. Unfortunately what to you seems like a "major error" might not be in that position on their priority list because of something that might just cause much more damage if it is not fixed fast. (Or the right person for the job is just right now on holidays and his/her replacement on sick leave.)
I bet this will be fixed, maybe it would help though send this thread to the helpdesk to let them know directly about it - or maybe send a PM to leftquark or anyone else directly involved with smug mug, so we're sure that they have seen it and it is not just some sort of "user error"?

Hope that helped a little bit.

Lille Ulven

devbobo

G'day Dave,

I haven't read all the responses, but I can tell you (you can confirm this easily enough) that LR automatically updates the Date Modified on an exported file (not the original) when published or exported from LR.

Hope this helps.

Cheers,

David

DBR

David,

Thanks for your response. It is good to have confirmation of that. However, the primary issue is that Adobe and others use the field "DateTimeOriginal" as the timestamp for when the image was taken. Smugmug ignores this field, and displays DateTime instead.

devbobo

we show all available date info, unless the metadata doesn't exist...

DBR

There are 3 EXIF fields. In the example you showed, you display two timestamps. The one labeled Date Taken is from the wrong EXIF field. It should be DateTimeOriginal. It is not.

Here's an example of one of my images. I downloaded it, and looked at its properties (in windows, right-click, select Properties, and click on the Details tab). Note that the Date Taken displayed in the properties dialog box does not match the Date Taken in the Info box from Smugmug. The properties box is getting that timestamp from the EXIF field tagged DateTimeOriginal. Smugmug is displaying a *DIFFERENT* timestamp. Incidentally, all three fields are set, and Smugmug only displays two.

DBR

Looking at the same JPG using pyExifToolGui 0.5, a nice front end to ExifTool, I see the following timestamps:

Modify Date: 2015:04:04 23:18:53 (N.B. This does not match anything Smugmug displays.)
Date/Time Original: 2015:03:29 11:45:34 (The timestamp that should be displayed.)
Create Date: 2015:03:29 11:39:48 (The timestamp that Smugmug displays as "Date Taken".)

Please take another look at this.

devbobo

The image in question has been uploaded twice...

It was originally exported from LR and uploaded to SmugMug with the following date info...
DateTimeOriginal 2015:03:29 11:39:48
DateTimeDigitized 2015:03:29 11:39:48
DateTime 2015-03-31 00:56:03

The DateTimeOriginal was then adjusted within LR, and replaced on SmugMug...
DateTimeOriginal 2015:03:29 11:45:34
DateTimeDigitized 2015:03:29 11:39:48
DateTime 2015:04:04 23:18:53

The only problem is that SmugMug doesn't currently overwrite image metadata on a replace, so what it currently disabled is as per the originally uploaded file. You can confirm this for yourself by downloading the original image and uploading it to another gallery...


Hope this helps.

Cheers,

David

DBR

Dave,

I agree with your description of the history of that image. I originally used your publish plugin to upload it without change. I then used LR to correct the timestamp on all the pictures I took from our spring trip, and re-published them. I then downloaded one of the images to display above, and the time discrepancy was in that image.

I believe that you are saying that the metadata that Smugmug displays was extracted from the original image, and that when the image was replaced, SM dis not replace its internal copy of the metadata (EXIF, IPTC, keywords, etc.). Instead, it maintained its original view of the image. Is that correct?

If that is correct, then I (and probably many others) need to change our workflow. I'd appreciate your assistance in understanding the intended workflow. How *should* users update metadata on their images?

Also, I'd like to request a modification to the Sync Photos function on your LR/SM plugin. Rather than using the Date/Time Original field in LR, use the Date/Time Digitized if it is present. That one doesn't change when using the LR Edit Capture Time, so it is more likely to match the original image correctly. This would address the issue in my other thread, titled "Lightroom Upload Plugin Miss".

devbobo

Ideally, we would automatically update the image metadata on replaces, but this starts to get difficult...especially when you take into metadata that has been added locally on SmugMug like captions, titles, keywords, geodata.

Currently, you would need to remove the photo from the published collection within LR, publish and then re-add the photo to the published collection and republished. In advance, I admit that this is laborious and counter-intuitive to the streamlining nature of the publish service. I'll take a look and see if date info is available for updating via the API and push for it to be if it isn't already.

In regard to using DateTimeDigitized, I currently do use that but only if DateTimeOriginal isn't available, I agree that it may make sense to switch to defaulting to using DateTimeDigitized but looking at the SDK documentation it appears that Adobe only give me the option of searching the catalog based on "captureDate" or "touchTime" (ie. date modified). I'll contact them to determine if there is an undocumented way to search by "digitizedDate".

Cheers,

David

DBR

Dave,

Perhaps you could suggest a better solution. My relevant workflow matches the Collaborate on Photos in the current SmugMug blog pretty well: http://news.smugmug.com/2015/05/07/the-power-of-smugmugs-lightroom-publish-tool/. I upload images and my wife helps me edit them and select favorites. It is important to get them up quickly, and to be able to work on them while she is selecting. I develop slide shows for a high school marching unit, so I have contributed images from different people and different cameras. I need to be able to update the timestamp on images as I determine what it should be - I need that for organizing images from different sources. (It's amazing how far off the clocks are in many people's cameras!)

So, I upload images and create an event. I edit my pictures - including metadata - and update them using the publish plugin. Now, I sync the images to capture the ones that my wife selected. It works pretty well if I don't update any timestamps - but I need to update timestamps to coordinate between image sources. When I update the timestamps, the sync fails pretty miserably. I have to manually resolve conflicts, and I have some images - images that I published to SM - that do not match anything. Deleting them and republishing doesn't work, because that loses the selections that my wife has made.

The blog recommends using LR to manage your SM site. That's what I do, and I've enjoyed SM and the plugin for quite a while. However, if that loses my metadata, and doesn't work for my workflow, I need something else.

Thanks,

David

DBR

Wait - I know that I've updated metadata and republished, and it has been recognized by SM. I've seen it do that with keywords. Has that changed? Is it now the case that when I update keywords and republish, they updated keywords will no longer be synchronized to SM?

If not, what metadata is updated, and what metadata is not?

Thanks!

David

devbobo

no no, I'm talking purely from a backend perspective...if I do a replace nothing is automatically extracted from metadata.

With the LR plugin when I do a replace/republish, I extract the metadata (caption, title, keywords, geodata) and make a separate API call to update those.

DBR

Oh - I'm confused. So this is simply a bug/omission? That you only extract some of the metadata, and need to extract the additional fields that SM keeps?

devbobo

DBR wrote: »

Oh - I'm confused. So this is simply a bug/omission? That you only extract some of the metadata, and need to extract the additional fields that SM keeps?

right now, we only extract and update the fields that change frequently or are updatable via the site. I believe that allowing the Date fields to be accessible via the API, would be the easiest way to resolve this current issue.

DBR

Fair enough. It seems to me that omitting some of the fields that SM uses from the API is an odd decision. I suspect it's an oversight, and I would expect that to be a fairly straightforward amendment to the API. I hope it can be addressed soon.

Thank you for pursuing this.

DBR

Any update yet? What is the timeframe that we should expect for a change in the API to support this?

Meanwhile, could you modify the LR/SM plugin to sync based on a timestamp that doesn't change, as I requested above? That won't address the overall problem of SM displaying incorrect metadata, but it should address the problems synchronization not working after updating the timestamp metadata. (Yes, I'm going through and dealing with conflict resolution on a bunch of images again because it is still broken.) Here's the suggestion I made earlier:

Also, I'd like to request a modification to the Sync Photos function on your LR/SM plugin. Rather than using the Date/Time Original field in LR, use the Date/Time Digitized if it is present. That one doesn't change when using the LR Edit Capture Time, so it is more likely to match the original image correctly. This would address the issue in my other thread, titled "Lightroom Upload Plugin Miss".

Thanks,

David

rainforest1155

DBR wrote: »

Any update yet? What is the timeframe that we should expect for a change in the API to support this?

Hi David,
Since David hadn't a chance to reply yet., let me quickly chime in that while David will keep this in mind for future API updates, we can't provide you with any time frame on when such an option might be available.

Right now, if you need to update the date on replaced photos, you could only make use of the workaround David suggested in deleting and then publishing the photo again.

I wish I had a different answer for you.

DBR

Sebastian,

Thank you for the workaround. However, as I indicated above, that really does not address my workflow. The reason it updates SmugMug's record of the metadata is that SM sees it as a different, unrelated image. This breaks the connection with with favorites in a SM Event.

The fact that SM presents incorrect metadata is a bug, and should be treated as such. David suggested that this is because of a weakness in SM's API - that there is not a direct way for him to handle this. It appears that there is action required from SM in addition to an update from David. Do you disagree with this?

There are two distinct issues. One is that when images are republished, the metadata that SM displays is only partially updated, and apparently the API only provides hooks to update some of the metadata. The second is that the SM plugin uses metadata that is not correctly updated to match pictures in the Sync Photos action. I hope to see the latter addressed by David in an update soon. It will enable my workflow. I hope to the see the former addressed by SM. It will fix something that is clearly a bug.


David

DBR

A change in the API will no doubt take some time. An update to the plugin to use a timestamp that is relatively invariant (our rarely edited) should be much simpler, and would address the issue of image synchronization. Could that update be made?

jeffbarber

Any update on this bug, it seems to still be an outstanding issue?