This is where the thread diverges a little bit between the "web replace" an the "Lightroom Publish" (or re-publish).
In Lightroom, we can be a bit smart about which metadata you want to be shown, and if there's a case where we're not sure, we'll do a "Conflict Resolution" screen, similar to what we do when we try to link photos. It should allow you to pick which metadata you want to win out.
Can we come back to this one.
There are three scenarios I worry about.
First, let's pretend that you have made these changes and I start with an empty account. Can you confirm if I make ALL my changes in Lightroom, and none from the Smugmug web interface, that I will never have any conflicts and so there's nothing to resolve?
Secondly, there's years with of "stuff" out there from various correct and incorrect metadata updates. I might even have something done from the web years ago that I've forgotten, but I am more concerned that in some prior version of your code (or maybe current versions) that some metadata field you store was mis-interpreted, and so is different from what I now have in Lightroom. Can you confirm that these will NOT come back down into Lightroom, conflict resolution GUI or not? Or at least you'll give us some easy and obvious way to prevent it?
Finally -- what are you going to do in the scenario where I have published, then change metadata (but not image) and publish. Will you provide a mechanism (option) to allow me to say "if I change metadata only still send the image" so the original image has the correct metadata? If not, will you still update metadata only? And if the latter, will you ensure that is NOT flagged as though it came from a web update (and so can not be changed by a replaced image)?
First, let's pretend that you have made these changes and I start with an empty account. Can you confirm if I make ALL my changes in Lightroom, and none from the Smugmug web interface, that I will never have any conflicts and so there's nothing to resolve?
It's not built yet, but that's how it should work. If it doesn't, then there'd be a bug.
Secondly, there's years with of "stuff" out there from various correct and incorrect metadata updates. I might even have something done from the web years ago that I've forgotten, but I am more concerned that in some prior version of your code (or maybe current versions) that some metadata field you store was mis-interpreted, and so is different from what I now have in Lightroom. Can you confirm that these will NOT come back down into Lightroom, conflict resolution GUI or not? Or at least you'll give us some easy and obvious way to prevent it?
We could provide a way to turn Image Details syncing off. Additionally, it'll only sync galleries that you actively check "Sync Photos", so if you don't re-sync those, it won't do anything.
Finally -- what are you going to do in the scenario where I have published, then change metadata (but not image) and publish. Will you provide a mechanism (option) to allow me to say "if I change metadata only still send the image" so the original image has the correct metadata? If not, will you still update metadata only? And if the latter, will you ensure that is NOT flagged as though it came from a web update (and so can not be changed by a replaced image)?
We'll figure out the best way to do this. We're not going to be flagging "if it came from a web update" ... everything uses the same mechanisms (API's) ... it's just that the Lightroom Publish plugin has the ability to do multiple or different steps (for example updating an images' SM "Title" vs doing an actual image replace ... or doing both a SM Title update and the image replace).
We'll figure out the best way to do this. We're not going to be flagging "if it came from a web update" ... everything uses the same mechanisms (API's) ... it's just that the Lightroom Publish plugin has the ability to do multiple or different steps (for example updating an images' SM "Title" vs doing an actual image replace ... or doing both a SM Title update and the image replace).
Shouldn't be telling you how to implement, but I do strongly suggest you need to distinguish these two (i.e. web updates you want to preserve across image updates vs LR plugin metadata updates you don't).
Here's a usage case to think about (though I hope it doesn't happen to me): Someone switches from the plugin to a different plugin or uploader. So they've updated metadata with the SM Plugin. Hypothetically if it looks like it came from the web, then their new uploader replaces the image, you might preserve the original metadata.
OK... I'm reaching a bit on that. But the point is you are doing a good thing by getting rid of some of the past kludges. My suggestion is to make a firm statement on precedence, that all your users can understand (and hopefully agree with, but at least understand well enough to predict what will happen in any scenario they have).
Then not let the programmers' "easy" change your mind in certain cases. I'm a programmer at heart, I know how following the path of least resistance (or performance) can make for a mess of weird and inexplicable scenarios -- you have that now. You need a new attribute on a method call to record source info, just add it; that's what API versions are for.
If the average non-programmer photographer can't read an English description of how this works, and with 3 gin and tonics on-board tell you the results of any use case... send them back to the drawing board. Don't end up in this discussion again a year after you deploy.
Always love having conversations with you, Ferguson, because your replies are always well thought out! I'll bring your thoughts back to the team and we'll figure out how we'll implement it.
Updating metadata on replace is a separate item. This update only focused on fixing date taken.
Hoping to see it. This change flushed out a real problem in my workflow (not Smugmug, sadly, all on me). I was using Lightroom's Copy Metadata to copy all the settings I made on one shot at a shoot to all the other shots as a default.
Well, it appears that on import it creates a IPTC Date as well as the usual Date Time Original. I think you are taking the IPTC field first now, not the Date Time Original, if both are present.
And now all my shots were coming out at the same date/time.
I've starting going back to fix them, but one day I need to see how far back I was doing this and try to replace them all, something difficult at the moment (well, unless I can find a way to copy Date Time Original to IPTC's date -- hmm, I think there is a plugin that might do that... not that it would help at present though).
I'm currently at the WPPI photography trade show this week but let me make sure IPTC before DateTime is intended, before you go and do a bunch of work. I was under the impression DateTime should take precedence, but I could be wrong. Lemme get back to you next week.
I'm currently at the WPPI photography trade show this week but let me make sure IPTC before DateTime is intended, before you go and do a bunch of work. I was under the impression DateTime should take precedence, but I could be wrong. Lemme get back to you next week.
No hurry as there's nothing I can really do about it until the "replace" works; I can't afford to screw up all the URl's.
This is still not fixed. I uploaded JPEGs with revised titles and captions for every image in a gallery using "Replace" the other day. Then I tested downloading the X2 size of every image in the gallery. All of them still contain the old titles and captions. I hope that you will fix this issue soon.
[SNIP]
At SmugMug, we are not going to edit your original files by dumping those 4 metadata edits back into your file. It breaks sync'ing, it breaks duplicate detection, and it would mean we could no longer give you back the exact file you gave us (something we want to be able to do). Since pretty much anything is possible, we could generate a copy of the original that had the metadata updates in it, but the interest in that to date has been very low and we haven't pursued it.
Personally, I have a very high interest in being able to download a copy of my images that has SM-maintained metadata embedded in them.
Personally, I have a very high interest in being able to download a copy of my images that has SM-maintained metadata embedded in them.
We have plans to do 2 way syncing via Lightroom, but the photos you download from SmugMug will always be the photos you gave us, metadata included.
For every one customer that wants to have these edits included in their files, there's 10 customers who worry that we did something else to their photos and aren't giving them their photos back (did we downsample it? did we change the color space (sometimes yes)? did we compress it? etc)
We were waiting on the new skynet work we were performing (our system that renders and displays all your photos) to finish up before tackling this -- and this is now back in the queue for the team to work on.
@leftquark said:
We were waiting on the new skynet work we were performing (our system that renders and displays all your photos) to finish up before tackling this -- and this is now back in the queue for the team to work on.
This new Skynet, is this the reason that most of my old galleries, Smugmug style, take up to 15 sec. to load photos even though everything but gallery photos show up in less then 3 sec.? The links in "status" flicker back and forth for all that time.
@Allen said:
This new Skynet, is this the reason that most of my old galleries, Smugmug style, take up to 15 sec. to load photos even though everything but gallery photos show up in less then 3 sec.? The links in "status" flicker back and forth for all that time.
Nope - Skynet only kicks in when you upload or edit a photo and handles the initial rendering. Once the display sizes are created Skynet is mostly not involved anymore. The issue you describe seems to point to more of a CDN/connection issue. The average response times for the month look very flat and low to me. Are you seeing something different?
@Allen said:
This new Skynet, is this the reason that most of my old galleries, Smugmug style, take up to 15 sec. to load photos even though everything but gallery photos show up in less then 3 sec.? The links in "status" flicker back and forth for all that time.
Nope - Skynet only kicks in when you upload or edit a photo and handles the initial rendering. Once the display sizes are created Skynet is mostly not involved anymore. The issue you describe seems to point to more of a CDN/connection issue. The average response times for the month look very flat and low to me. Are you seeing something different?
It does seem like a CDN issue, gallery photos are the only thing affected. Every other Smug page is good as is all other sites.
Here's network run comparison of domains, Smug is faster. Consecutive/different gallery loads.
On the slow loads I can usually count to almost 15 for photos after entire page shows.
In the browser status bar I can see CDN flashing between flashes of other links.
I'm pleased to announce that we now handle "Replace" much better with respect to metadata. Upon replacing a photo, we'll now also update the metadata with the values from the new photo. This will update EXIF, Titles, Captions, Keywords, and Geo Location. If any of these fields were updated on SmugMug, we'll ignore just that field from the new photo and use the value that was on SmugMug (in other words, if you ever update a title, caption or keyword on SmugMug, the only way to update it, is through SmugMug).
Almost two years later this is still happening.
This happens very often for gallery photo loads, even for galleries that I just uploaded the same day,
I get up to a 15-20 sec. delay in load of photos AFTER the whole page loads.
On the slow loads I can usually count to almost 15 for photos after entire page shows.
In the browser status bar I can see CDN flashing between flashes of other links.
@leftquark said:
I'm pleased to announce that we now handle "Replace" much better with respect to metadata. Upon replacing a photo, we'll now also update the metadata with the values from the new photo. This will update EXIF, Titles, Captions, Keywords, and Geo Location. If any of these fields were updated on SmugMug, we'll ignore just that field from the new photo and use the value that was on SmugMug (in other words, if you ever update a title, caption or keyword on SmugMug, the only way to update it, is through SmugMug).
Thank you, leftquark. It sounds good. I remained concerned about this issue since my original post, but was too scared to check it again, afraid that I would find out it hadn't been fixed. I’m pleased to learn you’ve apparently fixed it.
This brings to mind a question, though. What happens to the metadata in photos where “Replace” was used prior to the introduction of this change? Is it necessary to use “Replace” again, or will the metadata be fixed retroactively?
@leftquark said:
I'm pleased to announce that we now handle "Replace" much better with respect to metadata. Upon replacing a photo, we'll now also update the metadata with the values from the new photo. This will update EXIF, Titles, Captions, Keywords, and Geo Location. If any of these fields were updated on SmugMug, we'll ignore just that field from the new photo and use the value that was on SmugMug (in other words, if you ever update a title, caption or keyword on SmugMug, the only way to update it, is through SmugMug).
This problem has not been fixed. I finally got around to testing it. Using the Replace feature with an updated Caption/Description, and then testing downloading a few different sizes and looking at the metadata, only the Original has the new Caption/Description. No change from the way this problem was when I first noticed it about three and a half years ago. I am using the Chrome browser on a Mac computer with High Sierra.
The problem that we set out to fix was that we weren't pulling in the new metadata when a photo was re-uploaded (replaced) to be displayed on SmugMug. For downloading, our customers have loudly told us that they expect their original file be returned to them when requesting a download of the photo, so we return the photo, byte-for-byte, back to them. This means the original file will not have SmugMug edited titles, captions, keywords or geolocations embedded back into the photo. We've heard from a large number of customers who get very worried that their photos aren't safe if we've altered, compressed (which happens with JPG's), or somehow changed their original files -- we want to keep the trust that we've kept your photos safe.
We also don't write the metadata into the display copies since the display copies are meant for display and not for downloading -- it would result in unnecessary processing to embed metadata into files that are not intended or typically used to have their metadata inspected. Typically we also purge most of the metadata in the display copies to reduce the filesize and ensure photos load as quickly as possible.
In the future we could have an option that would allow you to download original copies with the updated title/caption/keywords but I'll be honest and say that on the list of things we want to work on and provide for you, this is a low priority based on how frequently it would be used and how few people have requested it. For those of you using Lightroom, we are investigating bidirectional syncing that would grab the title, caption and keywords from SmugMug and import them back into the photos in your Lightroom catalog.
@leftquark said:
The problem that we set out to fix was that we weren't pulling in the new metadata when a photo was re-uploaded (replaced) to be displayed on SmugMug. For downloading, our customers have loudly told us that they expect their original file be returned to them when requesting a download of the photo, so we return the photo, byte-for-byte, back to them. This means the original file will not have SmugMug edited titles, captions, keywords or geolocations embedded back into the photo. We've heard from a large number of customers who get very worried that their photos aren't safe if we've altered, compressed (which happens with JPG's), or somehow changed their original files -- we want to keep the trust that we've kept your photos safe.
>
Of course. By directional syncing is a tall order. I have no interest in it, don't think it is a good idea, and it has nothing to do with my original post.
We also don't write the metadata into the display copies since the display copies are meant for display and not for downloading -- it would result in unnecessary processing to embed metadata into files that are not intended or typically used to have their metadata inspected. Typically we also purge most of the metadata in the display copies to reduce the filesize and ensure photos load as quickly as possible.
But the “display” copies are available for download via an Icon consisting of squares that appears in the lower right of each individual photo. I've been telling people who want a copy of a photo to find that Icon, pick a size of their choice, load it, right click and use Save Image As . . . But they’ll get a copy with outdated metadata, if I’ve replaced the Original with updated metadata using the Replace feature. Sometimes without my embedded Copyright Notice, if I originally uploaded that image before I started to use that field. Sometimes with a mistake that I've corrected (i.e., wrong date, wrong name of subject in Caption/Description.) Should I tell people, don't use that feature to download images? Or only download the Original for current metadata?
@leftquark said:
The problem that we set out to fix was that we weren't pulling in the new metadata when a photo was re-uploaded (replaced) to be displayed on SmugMug. For downloading, our customers have loudly told us that they expect their original file be returned to them when requesting a download of the photo, so we return the photo, byte-for-byte, back to them. This means the original file will not have SmugMug edited titles, captions, keywords or geolocations embedded back into the photo. We've heard from a large number of customers who get very worried that their photos aren't safe if we've altered, compressed (which happens with JPG's), or somehow changed their original files -- we want to keep the trust that we've kept your photos safe.
Of course. By directional syncing is a tall order. I have no interest in it, don’t think it is a good idea, and it has nothing to do with my original post.
We also don't write the metadata into the display copies since the display copies are meant for display and not for downloading -- it would result in unnecessary processing to embed metadata into files that are not intended or typically used to have their metadata inspected. Typically we also purge most of the metadata in the display copies to reduce the filesize and ensure photos load as quickly as possible.
But the “display” copies are available for download via an icon consisting of overlapping squares that appears in the lower right of an individual photo. I’ve been telling people that if they want a copy of one of my photos, find that icon, pick a size, load it, right click, and use “Save Image As…” to download it. But they’ll get a copy with outdated metadata if I’ve replaced my Original using the Replace feature. Sometimes without my Copyright Notice, if they download an image that I originally uploaded before I started to use that field. Sometimes with incorrect metadata, if I’ve corrected a mistake (i.e., date of photo, name of person in caption.) Should I tell people, don’t use that feature? And/or only download my Original?
Thanks for the clarification. When you talked about downloading the file with the new metadata in it, I was assuming you were talking about the desire to have edits made in SmugMug downloaded back. Clarifying that you're asking others to download display copies helped me understand what you were getting at.
You are correct -- there's an additional issue where the new display copies have the old metadata embedded in them. I'm actually surprised we went through and embedded any metadata in the display copies but since we are, it should be the new metadata not the old one. I've filed a bug with the engineering team on that.
@leftquark said:
Thanks for the clarification. When you talked about downloading the file with the new metadata in it, I was assuming you were talking about the desire to have edits made in SmugMug downloaded back. Clarifying that you're asking others to download display copies helped me understand what you were getting at.
You are correct -- there's an additional issue where the new display copies have the old metadata embedded in them. I'm actually surprised we went through and embedded any metadata in the display copies but since we are, it should be the new metadata not the old one. I've filed a bug with the engineering team on that.
Thank you, leftquark. Now, I finally understand where you are coming from too. Indeed, display copies don’t need to have metadata; when they are really only being used for display, that is.
Comments
Can we come back to this one.
There are three scenarios I worry about.
First, let's pretend that you have made these changes and I start with an empty account. Can you confirm if I make ALL my changes in Lightroom, and none from the Smugmug web interface, that I will never have any conflicts and so there's nothing to resolve?
Secondly, there's years with of "stuff" out there from various correct and incorrect metadata updates. I might even have something done from the web years ago that I've forgotten, but I am more concerned that in some prior version of your code (or maybe current versions) that some metadata field you store was mis-interpreted, and so is different from what I now have in Lightroom. Can you confirm that these will NOT come back down into Lightroom, conflict resolution GUI or not? Or at least you'll give us some easy and obvious way to prevent it?
Finally -- what are you going to do in the scenario where I have published, then change metadata (but not image) and publish. Will you provide a mechanism (option) to allow me to say "if I change metadata only still send the image" so the original image has the correct metadata? If not, will you still update metadata only? And if the latter, will you ensure that is NOT flagged as though it came from a web update (and so can not be changed by a replaced image)?
We could provide a way to turn Image Details syncing off. Additionally, it'll only sync galleries that you actively check "Sync Photos", so if you don't re-sync those, it won't do anything.
We'll figure out the best way to do this. We're not going to be flagging "if it came from a web update" ... everything uses the same mechanisms (API's) ... it's just that the Lightroom Publish plugin has the ability to do multiple or different steps (for example updating an images' SM "Title" vs doing an actual image replace ... or doing both a SM Title update and the image replace).
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
Shouldn't be telling you how to implement, but I do strongly suggest you need to distinguish these two (i.e. web updates you want to preserve across image updates vs LR plugin metadata updates you don't).
Here's a usage case to think about (though I hope it doesn't happen to me): Someone switches from the plugin to a different plugin or uploader. So they've updated metadata with the SM Plugin. Hypothetically if it looks like it came from the web, then their new uploader replaces the image, you might preserve the original metadata.
OK... I'm reaching a bit on that. But the point is you are doing a good thing by getting rid of some of the past kludges. My suggestion is to make a firm statement on precedence, that all your users can understand (and hopefully agree with, but at least understand well enough to predict what will happen in any scenario they have).
Then not let the programmers' "easy" change your mind in certain cases. I'm a programmer at heart, I know how following the path of least resistance (or performance) can make for a mess of weird and inexplicable scenarios -- you have that now. You need a new attribute on a method call to record source info, just add it; that's what API versions are for.
If the average non-programmer photographer can't read an English description of how this works, and with 3 gin and tonics on-board tell you the results of any use case... send them back to the drawing board. Don't end up in this discussion again a year after you deploy.
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
Updating metadata on replace is a separate item. This update only focused on fixing date taken.
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
Hoping to see it. This change flushed out a real problem in my workflow (not Smugmug, sadly, all on me). I was using Lightroom's Copy Metadata to copy all the settings I made on one shot at a shoot to all the other shots as a default.
Well, it appears that on import it creates a IPTC Date as well as the usual Date Time Original. I think you are taking the IPTC field first now, not the Date Time Original, if both are present.
And now all my shots were coming out at the same date/time.
I've starting going back to fix them, but one day I need to see how far back I was doing this and try to replace them all, something difficult at the moment (well, unless I can find a way to copy Date Time Original to IPTC's date -- hmm, I think there is a plugin that might do that... not that it would help at present though).
So... here's hoping you get it done soon!
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
No hurry as there's nothing I can really do about it until the "replace" works; I can't afford to screw up all the URl's.
It's past time that "replace" became "replace" and not a 100 step decision tree to figure out what happened.
Personally, I have a very high interest in being able to download a copy of my images that has SM-maintained metadata embedded in them.
We have plans to do 2 way syncing via Lightroom, but the photos you download from SmugMug will always be the photos you gave us, metadata included.
For every one customer that wants to have these edits included in their files, there's 10 customers who worry that we did something else to their photos and aren't giving them their photos back (did we downsample it? did we change the color space (sometimes yes)? did we compress it? etc)
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
Has this BUG been fixed yet? It is a BUG!!!
Forget syncing. My question has NOTHING to do with syncing.
We were waiting on the new skynet work we were performing (our system that renders and displays all your photos) to finish up before tackling this -- and this is now back in the queue for the team to work on.
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
This new Skynet, is this the reason that most of my old galleries, Smugmug style, take up to 15 sec. to load photos even though everything but gallery photos show up in less then 3 sec.? The links in "status" flicker back and forth for all that time.
My Website index | My Blog
Nope - Skynet only kicks in when you upload or edit a photo and handles the initial rendering. Once the display sizes are created Skynet is mostly not involved anymore. The issue you describe seems to point to more of a CDN/connection issue. The average response times for the month look very flat and low to me. Are you seeing something different?
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
It does seem like a CDN issue, gallery photos are the only thing affected. Every other Smug page is good as is all other sites.
Here's network run comparison of domains, Smug is faster. Consecutive/different gallery loads.
On the slow loads I can usually count to almost 15 for photos after entire page shows.
In the browser status bar I can see CDN flashing between flashes of other links.
My Website index | My Blog
I'm pleased to announce that we now handle "Replace" much better with respect to metadata. Upon replacing a photo, we'll now also update the metadata with the values from the new photo. This will update EXIF, Titles, Captions, Keywords, and Geo Location. If any of these fields were updated on SmugMug, we'll ignore just that field from the new photo and use the value that was on SmugMug (in other words, if you ever update a title, caption or keyword on SmugMug, the only way to update it, is through 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
Almost two years later this is still happening.
This happens very often for gallery photo loads, even for galleries that I just uploaded the same day,
I get up to a 15-20 sec. delay in load of photos AFTER the whole page loads.
My Website index | My Blog
Thank you, leftquark. It sounds good. I remained concerned about this issue since my original post, but was too scared to check it again, afraid that I would find out it hadn't been fixed. I’m pleased to learn you’ve apparently fixed it.
This brings to mind a question, though. What happens to the metadata in photos where “Replace” was used prior to the introduction of this change? Is it necessary to use “Replace” again, or will the metadata be fixed retroactively?
This problem has not been fixed. I finally got around to testing it. Using the Replace feature with an updated Caption/Description, and then testing downloading a few different sizes and looking at the metadata, only the Original has the new Caption/Description. No change from the way this problem was when I first noticed it about three and a half years ago. I am using the Chrome browser on a Mac computer with High Sierra.
The problem that we set out to fix was that we weren't pulling in the new metadata when a photo was re-uploaded (replaced) to be displayed on SmugMug. For downloading, our customers have loudly told us that they expect their original file be returned to them when requesting a download of the photo, so we return the photo, byte-for-byte, back to them. This means the original file will not have SmugMug edited titles, captions, keywords or geolocations embedded back into the photo. We've heard from a large number of customers who get very worried that their photos aren't safe if we've altered, compressed (which happens with JPG's), or somehow changed their original files -- we want to keep the trust that we've kept your photos safe.
We also don't write the metadata into the display copies since the display copies are meant for display and not for downloading -- it would result in unnecessary processing to embed metadata into files that are not intended or typically used to have their metadata inspected. Typically we also purge most of the metadata in the display copies to reduce the filesize and ensure photos load as quickly as possible.
In the future we could have an option that would allow you to download original copies with the updated title/caption/keywords but I'll be honest and say that on the list of things we want to work on and provide for you, this is a low priority based on how frequently it would be used and how few people have requested it. For those of you using Lightroom, we are investigating bidirectional syncing that would grab the title, caption and keywords from SmugMug and import them back into the photos in your Lightroom catalog.
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
>
Of course. By directional syncing is a tall order. I have no interest in it, don't think it is a good idea, and it has nothing to do with my original post.
But the “display” copies are available for download via an Icon consisting of squares that appears in the lower right of each individual photo. I've been telling people who want a copy of a photo to find that Icon, pick a size of their choice, load it, right click and use Save Image As . . . But they’ll get a copy with outdated metadata, if I’ve replaced the Original with updated metadata using the Replace feature. Sometimes without my embedded Copyright Notice, if I originally uploaded that image before I started to use that field. Sometimes with a mistake that I've corrected (i.e., wrong date, wrong name of subject in Caption/Description.) Should I tell people, don't use that feature to download images? Or only download the Original for current metadata?
Of course. By directional syncing is a tall order. I have no interest in it, don’t think it is a good idea, and it has nothing to do with my original post.
But the “display” copies are available for download via an icon consisting of overlapping squares that appears in the lower right of an individual photo. I’ve been telling people that if they want a copy of one of my photos, find that icon, pick a size, load it, right click, and use “Save Image As…” to download it. But they’ll get a copy with outdated metadata if I’ve replaced my Original using the Replace feature. Sometimes without my Copyright Notice, if they download an image that I originally uploaded before I started to use that field. Sometimes with incorrect metadata, if I’ve corrected a mistake (i.e., date of photo, name of person in caption.) Should I tell people, don’t use that feature? And/or only download my Original?
Thanks for the clarification. When you talked about downloading the file with the new metadata in it, I was assuming you were talking about the desire to have edits made in SmugMug downloaded back. Clarifying that you're asking others to download display copies helped me understand what you were getting at.
You are correct -- there's an additional issue where the new display copies have the old metadata embedded in them. I'm actually surprised we went through and embedded any metadata in the display copies but since we are, it should be the new metadata not the old one. I've filed a bug with the engineering team on that.
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, leftquark. Now, I finally understand where you are coming from too. Indeed, display copies don’t need to have metadata; when they are really only being used for display, that is.