If you start browsing through those and looking at what smugmug says the Date Taken is, they all show up as 2015-11-22 19:03:41. That's because I had all or almost all of the shots with that incorrect date in the XMP/IPTC field when the shots were initially uploaded.
The EXIF DateTimeOriginal (and I think all other dates) were correct at the time uploaded; the mistake was very specific to that one XMP/IPTC field (and it came from copying IPTC metadata to copy titles, etc., and not realizing the date was among them).
Since I cannot look back in time I cannot say for absolute certain, but I am about 98% sure that when these galleries (and this one in particular) was uploaded, with the wrong IPTC date but the right EXIF DateTimeOriginal, that it sorted correctly (i.e. by EXIF's DateTimeOriginal). I think I would have noticed. If you look at the shots, way down at the tail end you'll see some wide shots where the players are being introduced -- those obviously were at the beginning of the game, not the end. So I think your change caused a retroactive look at the IPTC data to populate the Date Taken, and in turn something triggered a new sort calculation with what you see now.
The actual underlying data in this gallery should be right. I have not checked each individually, but I checked a few.
Perhaps you have data to the prior versions of the images, if that is helpful to you.
This has fresh photos taken a minute or so apart (the clock shown makes the order obvious but I did not try to sync the clock on the camera precisely).
Before uploading, to make issues apparent, I changed the filename to be A, B and C out of capture time order (C was earliest, etc.).
Then to recreate my XMP/IPTC issue, I copied one of their dates to the other two in the IPTC/XMP field (15:04:39 specifically).
The real date/time in the exif:dateTimeOriginal is:
C = 3:04:39 (IPTC Time Created = 3:04:39, i.e. same)
B = 3:05:35 (IPTC Time Created = 3:04:39)
A = 3:06:55 (IPTC Time Created = 3:04:39
So when Smugmug sorts, they come out A, B C, I believe because all show the same Date Taken (3:04:39) and reverts to the file name sort. EXIF's DateTimeOriginal appears to be playing no role in the sorting, I think because it played no role in the determination Smugmug uses for Date Taken.
Just to be explicit in the example in the last post -- I do not necessarily consider anything that Smugmug or Lightroom did there incorrect. I have inappropriately set all the IPTC Time Created to the same value.
Where I think this is bad is (a) if indeed it was done, that this new interpretation was applied retroactively to prior images, and ironically (b) Smugmug does not give the users any way to retroactively fix it (i.e. replace an image and have the dates be re-interpreted).
I created the above not to show something wrong, but rather the situation I started with years ago in terms of images.
Before I dive in, I'll try to clarify a few things that we did:
1. Initially, the Organizer and Gallery just used EXIF information only.
2. We updated the Photo Info overlay and in doing so, starting pulling in all the metadata. It uses the priority list above, where Composite info is given first priority.
3. At this time, we realized that the Photo Info overlay didn't match the way the galleries were sorting.
4. We updated the sort order to use the full set of metadata, using the priority list above, where Composite info is given first priority. Old Galleries must be manually re-sorted but we started to look into doing this for you. I don't think we ever did it though.
That's the point we are currently at.
It looks like, despite its documentation, the Composite data from EXIF tool is placing IPTC above all. It's not necessarily jiving with everything that I'm reading. IPTC has been the gold standard for years, but looking at other sites (500px, Flickr, etc), it looks like they're ignoring the IPTC field and just using XMP or EXIF if it exists. Continuing to dig....
Before I dive in, I'll try to clarify a few things that we did:
1. Initially, the Organizer and Gallery just used EXIF information only.
2. We updated the Photo Info overlay and in doing so, starting pulling in all the metadata. It uses the priority list above, where Composite info is given first priority.
3. At this time, we realized that the Photo Info overlay didn't match the way the galleries were sorting.
4. We updated the sort order to use the full set of metadata, using the priority list above, where Composite info is given first priority. Old Galleries must be manually re-sorted but we started to look into doing this for you. I don't think we ever did it though.
That's the point we are currently at.
But it we stop there, this is where I get confused.
After you did this, what should have happened to galleries from say a year older? Did their dates get re-evaluated?
I am just almost certain that these galleries had to have previously sorted correctly (i.e. by EXIF DateTimeOriginal). There is no way either viewers or myself would not have noticed.
I really think as you did this, some how, some way, it cause dold images in old galleries to be re-evaluated and re-sorted.
It looks like, despite its documentation, the Composite data from EXIF tool is placing IPTC above all. It's not necessarily jiving with everything that I'm reading. IPTC has been the gold standard for years, but looking at other sites (500px, Flickr, etc), it looks like they're ignoring the IPTC field and just using XMP or EXIF if it exists. Continuing to dig....
And yes, it is clear you are not giving EXIF DateTimeOriginal priority. The most recent gallery example shows that you are pulling from XMP/IPTC instead as priority.
So... maybe the real question is what is your design goal? Should it pull there first, or EXIF?
Personally I think EXIF makes more sense, but I really do not much care so long as it is defined, and so long as I can fix it when it is wrong. Which is full circle to my issue -- I have bad metadata on Smugmug and no way to fix it.
But to the OP's original issue -- I think that what they implemented, and what you think they implemented, is not the same. I think it was retroactive, and uses IPTC first.
We wanted to make sure we had everything all set with Date Taken before going through and re-sorting everyones galleries. Your old ones should have stayed in the same order they had previously been in, but I'm checking with the team to make sure there's no other reason that would have triggered a re-sort (other than toggling the Organizer or Gallery Settings Sort Direction). Can you send me a link to a gallery or two so I can take a peak at when it last re-sorted?
I've made the decision with the team to place EXIF DateTimeOriginal as the first item in the decision tree, followed by Composite (IPTC) DateTimeCreated and then XMP DateCreated. It may take us a little time to be thorough and make sure we're returning the correct "Date Taken" field in every place that it's used on SmugMug.
We wanted to make sure we had everything all set with Date Taken before going through and re-sorting everyones galleries. Your old ones should have stayed in the same order they had previously been in, but I'm checking with the team to make sure there's no other reason that would have triggered a re-sort (other than toggling the Organizer or Gallery Settings Sort Direction). Can you send me a link to a gallery or two so I can take a peak at when it last re-sorted?
I just browsed through them at random and picked ones that were clearly out of order.
But... just to be fair... I've "fixed" these indirectly by sending up new image data as replacements. It of course does not fix it, but sending it may have had some impact.
As far as I can remember, other than uploading the underlying images, I have not changed anything else on those galleries since approximately the date they were created (or a day or two after).
All were visibly out of order, presumably as a result of the IPTC date when originally set up.
I have no way to confirm, but I BELIEVE all were in a different order at around the time created, the real date created order. Especially when things like introductions are in the middle, it is very obvious when wrong.
Can you tell historically what happened, because it does not quite sound like we have the whole story yet, as (I think) your impression is these should not have been affected, and should still at this point be sorted by EXIF DateTimeOriginal (at least the older ones) right?
There's a number of other items that can trigger a re-sort, one of which is replacing an image (as is uploading a new one or deleting one), which looks like is what triggered the re-sort.
There's a number of other items that can trigger a re-sort, one of which is replacing an image (as is uploading a new one or deleting one), which looks like is what triggered the re-sort.
Then I have no historical examples that are not distorted by recent uploads.
My guess is what happened is I had the data incorrect for years, SM made the change in which date fields are used, over time I "touched" lots of galleries (all sorts of ways that can happen, and the LR Plugin is very helpful and just tags them for re-upload), and when touched they re-sorted with the new definition even though the date fields were not actually changing (could not be changing since you don't replace).
I'll wait to hear if you actually change the calculation as it will make what I am doing simpler. Even though I fixed the fields, SM thinks they are still wrong, so if you fix them, then all I need to do is trigger a re-sort.
If you don't fix them, I think the only fix that is viable is to go from date to position sort, and let LR sort by date, then use the plugin to push that position up as the right place, ignoring SM's definition of date taken.
The OP's probably will likely be fixed if you change the calculation as well to give EXIF precedence.
We did push the change live to favor EXIF. We're still looking into this though ... there's a few cases with timezone information where we want to make sure we have it right.
We did push the change live to favor EXIF. We're still looking into this though ... there's a few cases with timezone information where we want to make sure we have it right.
But is it retroactive as it was before?
I.e. if I had a gallery sorting incorrectly because my IPTC date was wrong (but EXIF DateTimeOriginal right), and...
I do nothing, will it resort?
If I trigger a resort by flipping to something else and back to Date Taken, will it resort even though I did not delete and re-upload the images?
(Note I had replaced the images in all cases and the original image on Smugmug is right, but it was wrong on initial upload).
Flipping the sort to something else and then back to Date Taken should re-trigger the sort. We haven't retroactively re-sorted all the galleries yet. We want to make sure we've got everything all set before doing that.
As replaced images, I believe it's using the original metadata (so the EXIF from the original file). :: insert the standard cry for 'please replace the metadata when i replace the image! ::
OK, I took the first of my sample galleries from a few postings back, resorted by flipping to caption and back to date taken, and it now comes up in the right order.
Thank you. I think I can just push a replacement photo back into each gallery and it should force a resort, so I am (tedious but) good.
Comments
http://www.captivephotons.com/Events/FGCUMBB/UND112215/
If you start browsing through those and looking at what smugmug says the Date Taken is, they all show up as 2015-11-22 19:03:41. That's because I had all or almost all of the shots with that incorrect date in the XMP/IPTC field when the shots were initially uploaded.
The EXIF DateTimeOriginal (and I think all other dates) were correct at the time uploaded; the mistake was very specific to that one XMP/IPTC field (and it came from copying IPTC metadata to copy titles, etc., and not realizing the date was among them).
Since I cannot look back in time I cannot say for absolute certain, but I am about 98% sure that when these galleries (and this one in particular) was uploaded, with the wrong IPTC date but the right EXIF DateTimeOriginal, that it sorted correctly (i.e. by EXIF's DateTimeOriginal). I think I would have noticed. If you look at the shots, way down at the tail end you'll see some wide shots where the players are being introduced -- those obviously were at the beginning of the game, not the end. So I think your change caused a retroactive look at the IPTC data to populate the Date Taken, and in turn something triggered a new sort calculation with what you see now.
The actual underlying data in this gallery should be right. I have not checked each individually, but I checked a few.
Perhaps you have data to the prior versions of the images, if that is helpful to you.
http://www.captivephotons.com/Other/TestDates/n-T9SPBX/
This has fresh photos taken a minute or so apart (the clock shown makes the order obvious but I did not try to sync the clock on the camera precisely).
Before uploading, to make issues apparent, I changed the filename to be A, B and C out of capture time order (C was earliest, etc.).
Then to recreate my XMP/IPTC issue, I copied one of their dates to the other two in the IPTC/XMP field (15:04:39 specifically).
The real date/time in the exif:dateTimeOriginal is:
C = 3:04:39 (IPTC Time Created = 3:04:39, i.e. same)
B = 3:05:35 (IPTC Time Created = 3:04:39)
A = 3:06:55 (IPTC Time Created = 3:04:39
So when Smugmug sorts, they come out A, B C, I believe because all show the same Date Taken (3:04:39) and reverts to the file name sort. EXIF's DateTimeOriginal appears to be playing no role in the sorting, I think because it played no role in the determination Smugmug uses for Date Taken.
Is this what you anticipated?
Where I think this is bad is (a) if indeed it was done, that this new interpretation was applied retroactively to prior images, and ironically (b) Smugmug does not give the users any way to retroactively fix it (i.e. replace an image and have the dates be re-interpreted).
I created the above not to show something wrong, but rather the situation I started with years ago in terms of images.
1. Initially, the Organizer and Gallery just used EXIF information only.
2. We updated the Photo Info overlay and in doing so, starting pulling in all the metadata. It uses the priority list above, where Composite info is given first priority.
3. At this time, we realized that the Photo Info overlay didn't match the way the galleries were sorting.
4. We updated the sort order to use the full set of metadata, using the priority list above, where Composite info is given first priority. Old Galleries must be manually re-sorted but we started to look into doing this for you. I don't think we ever did it though.
That's the point we are currently at.
It looks like, despite its documentation, the Composite data from EXIF tool is placing IPTC above all. It's not necessarily jiving with everything that I'm reading. IPTC has been the gold standard for years, but looking at other sites (500px, Flickr, etc), it looks like they're ignoring the IPTC field and just using XMP or EXIF if it exists. Continuing to dig....
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
My Website index | My Blog
But it we stop there, this is where I get confused.
After you did this, what should have happened to galleries from say a year older? Did their dates get re-evaluated?
I am just almost certain that these galleries had to have previously sorted correctly (i.e. by EXIF DateTimeOriginal). There is no way either viewers or myself would not have noticed.
I really think as you did this, some how, some way, it cause dold images in old galleries to be re-evaluated and re-sorted.
And yes, it is clear you are not giving EXIF DateTimeOriginal priority. The most recent gallery example shows that you are pulling from XMP/IPTC instead as priority.
So... maybe the real question is what is your design goal? Should it pull there first, or EXIF?
Personally I think EXIF makes more sense, but I really do not much care so long as it is defined, and so long as I can fix it when it is wrong. Which is full circle to my issue -- I have bad metadata on Smugmug and no way to fix it.
But to the OP's original issue -- I think that what they implemented, and what you think they implemented, is not the same. I think it was retroactive, and uses IPTC first.
I've made the decision with the team to place EXIF DateTimeOriginal as the first item in the decision tree, followed by Composite (IPTC) DateTimeCreated and then XMP DateCreated. It may take us a little time to be thorough and make sure we're returning the correct "Date Taken" field in every place that it's used on SmugMug.
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 just browsed through them at random and picked ones that were clearly out of order.
But... just to be fair... I've "fixed" these indirectly by sending up new image data as replacements. It of course does not fix it, but sending it may have had some impact.
http://www.captivephotons.com/Events/FGCUWBB/UNF020616/
http://www.captivephotons.com/Events/FGCUWBB/Stetson010916/
http://www.captivephotons.com/Events/FGCUWBB/STU121515/
http://www.captivephotons.com/Events/FGCUMBB/Youngstown112115/
As far as I can remember, other than uploading the underlying images, I have not changed anything else on those galleries since approximately the date they were created (or a day or two after).
All were visibly out of order, presumably as a result of the IPTC date when originally set up.
I have no way to confirm, but I BELIEVE all were in a different order at around the time created, the real date created order. Especially when things like introductions are in the middle, it is very obvious when wrong.
Can you tell historically what happened, because it does not quite sound like we have the whole story yet, as (I think) your impression is these should not have been affected, and should still at this point be sorted by EXIF DateTimeOriginal (at least the older ones) right?
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
Then I have no historical examples that are not distorted by recent uploads.
My guess is what happened is I had the data incorrect for years, SM made the change in which date fields are used, over time I "touched" lots of galleries (all sorts of ways that can happen, and the LR Plugin is very helpful and just tags them for re-upload), and when touched they re-sorted with the new definition even though the date fields were not actually changing (could not be changing since you don't replace).
I'll wait to hear if you actually change the calculation as it will make what I am doing simpler. Even though I fixed the fields, SM thinks they are still wrong, so if you fix them, then all I need to do is trigger a re-sort.
If you don't fix them, I think the only fix that is viable is to go from date to position sort, and let LR sort by date, then use the plugin to push that position up as the right place, ignoring SM's definition of date taken.
The OP's probably will likely be fixed if you change the calculation as well to give EXIF precedence.
Thank you!
That's... odd. My mis-sorted galleries are still mis-sorted. I have not heard that they changed anything yet.
But... glad it's working, I guess. Though I always prefer "we fixed it" to go along with "it's working".
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
But is it retroactive as it was before?
I.e. if I had a gallery sorting incorrectly because my IPTC date was wrong (but EXIF DateTimeOriginal right), and...
I do nothing, will it resort?
If I trigger a resort by flipping to something else and back to Date Taken, will it resort even though I did not delete and re-upload the images?
(Note I had replaced the images in all cases and the original image on Smugmug is right, but it was wrong on initial upload).
As replaced images, I believe it's using the original metadata (so the EXIF from the original file). :: insert the standard cry for 'please replace the metadata when i replace the image! ::
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
Thank you. I think I can just push a replacement photo back into each gallery and it should force a resort, so I am (tedious but) good.