My thought is when a photo is "replaced" the ONLY thing changed/updated is the modified date. How
simply is that? Original EXIF is retained including date taken.
I take it from other postings this is because you are editing it on Smugmug directly. Fine, I think everyone is agreeing that photo's replaced will not affect data entered on the Smugmug web interface, my writeup included.
But let's say one does NOT edit metadata on Smugmug directly, then that statement would make no sense at all; if I edit the caption AND replace the photo why in the world would I not want the caption replaced on Smugmug.
I think what we are all after is that changes to metadata be reflected on Smugmug when a photo is replaced, by any mechanism, but with the caveat that metadata entered separately on the web interface always takes precedence.
I take it from other postings this is because you are editing it on Smugmug directly. Fine, I think everyone is agreeing that photo's replaced will not affect data entered on the Smugmug web interface, my writeup included.
But let's say one does NOT edit metadata on Smugmug directly, then that statement would make no sense at all; if I edit the caption AND replace the photo why in the world would I not want the caption replaced on Smugmug.
I think what we are all after is that changes to metadata be reflected on Smugmug when a photo is replaced, by any mechanism, but with the caveat that metadata entered separately on the web interface always takes precedence.
All of this still sounds confusing to me, and beyond the topic of my original post. (Granted, I should have explained that I am using a browser and not Lightroom in my original post.) Why can't SmugMug be like SoundCloud, for example? I can replace audio files, with the same audio but revised tags (i.e., revised titles), on SoundCloud. The audio files with the modified tags are then available for download for someone who wants to use a player like iTunes. But I have to edit the SoundCloud public web presentation separately to make changes to it, and I don't mind doing that in the least bit.
If Lightroom is storing all kinds of metadata only in its own "library" (i.e., XMP files), and not always embedding edited metadata in image files, that I am not really interested in using it. I look at embedded metadata in my image files with many different applications. I use Mac O.S., but also look at the metadata in my image files in Windows, for example. The idea is future proofing the image files as user friendly, cross platform image files (independent their use on SmugMug), not limiting them to requiring Lightroom.
Yup, lightroom will embed the metadata into the photo every time. The issue is just that the smugmug plugin takes a little shortcut and doesn't bother uploading the modified image when only metadata changed (so updates to captions and keywords take just seconds even for a lot of files). But if you're editing metadata (and not the images themselves), you just need to take one extra step (a couple clicks) to tell the plugin to upload the whole images with metadata embedded instead of just the metadata to the smugmug fields.
All of this still sounds confusing to me, and beyond the topic of my original post. (Granted, I should have explained that I am using a browser and not Lightroom in my original post.) Why can't SmugMug be like SoundCloud, for example? I can replace audio files, with the same audio but revised tags (i.e., revised titles), on SoundCloud. The audio files with the modified tags are then available for download for someone who wants to use a player like iTunes. But I have to edit the SoundCloud public web presentation separately to make changes to it, and I don't mind doing that in the least bit.
If I am following you, because many of us don't want to do work twice to change metadata. We want a mechanism that keeps our metadata in synch.
I think this originates with the idea of where one does editing. If you do captions on Smugmug, either entirely, or for Smugmug specifically different from what you want in your home library, then you want Smugmug's edits to take precedence over what's in the image. Makes sense, nice for those who do.
If you consider your home a "master" library, and want Smugmug (and anywhere else you put photos) to have the same data, then when you replace an image on Smugmug, you want that to replace the captions (etc) at the same time.
I think the saving grace between these two is there is no real middle ground needed. People in the second category aren't going to want to edit on Smugmug and try to sync backwards or something.
So the simple solution (at least seems simple to me) is for Smugmug to keep track of where it gets data. If it comes from web entry directly -- that rules, and never gets replaced when an image is replaced. If it comes from an image upload, then any subsequent image upload (including half-way upload from the plugin for metadata only) replaces it.
Yup, lightroom will embed the metadata into the photo every time. The issue is just that the smugmug plugin takes a little shortcut and doesn't bother uploading the modified image when only metadata changed (so updates to captions and keywords take just seconds even for a lot of files). But if you're editing metadata (and not the images themselves), you just need to take one extra step (a couple clicks) to tell the plugin to upload the whole images with metadata embedded instead of just the metadata to the smugmug fields.
But it's NOT a couple clicks, at least not if you are doing a lot of images and only want the ones changed uploaded. There are many problems with that idea.
Consider this scenario:
- Image uploaded first time with caption A
- Caption A changed to B in LR
Now if you want that to go up to SM and be fully in sync, image and metadata both, the shortest path I am aware of is this:
- Go to the collection involved (or more than one possibly)
- Publish (this updates metadata only)
- Go back to the collection involved (or more than one)
- Find the image in the collection (you did remember which one right?)
- Mark it to republish
- Publish collection
The first publish is necessary to get the metadata flag cleared. As of the beginning of the above, you can NOT mark it for republish, as it is already marked (but not marked in such a way the image is sent).
The second republish sends the image itself, with the updated metadata (so your original if downloaded has it, otherwise it still says "A"). But this second one depends on you hunting up and marking all the images to republish (or just mark every single image to republish, which I do, which is horrendously expensive in terms of network time if you have a slow network.
Now it is possible to do some convoluted stuff, like form yet another collection of all the unpublished photos so once published they are easier to find, then mark them in that collection and come back to the original collection(s) to actually do the republish. But that works poorly if you are (as I am) doing this in increments to get a gallery updated for quick consumption after an event.
Now this is not needed if you do not care if the image on Smugmug has the same metadata. The plugin today works great for that (except for capture date and if memory serves a few other things, maybe keyword removal, but I forget).
But if you want to keep everything in sync, there is no short path today to do so if you change anything after initial publish. It is certainly not a couple clicks. At least if it is, please, someone show me, because every event I jump through these hoops.
I honestly think this is easily fixable (well, as easy as any change to a big production system) in a way that will make all camps happy. It's just not as simple as each camp alone thinks it ought to be. It requires each of the mechanisms allows for the quirks of the other.
But it's NOT a couple clicks, at least not if you are doing a lot of images and only want the ones changed uploaded. There are many problems with that idea.
Consider this scenario:
- Image uploaded first time with caption A
- Caption A changed to B in LR
Now if you want that to go up to SM and be fully in sync, image and metadata both, the shortest path I am aware of is this:
- Go to the collection involved (or more than one possibly)
- Publish (this updates metadata only)
- Go back to the collection involved (or more than one)
- Find the image in the collection (you did remember which one right?)
- Mark it to republish
- Publish collection
The first publish is necessary to get the metadata flag cleared. As of the beginning of the above, you can NOT mark it for republish, as it is already marked (but not marked in such a way the image is sent).
After making the metadata updates, you can mark them as up-to-date, then mark them for republish. But the same issue does occur that it deselects the images you chose, so you have to find them again to mark them for republish. I guess you'd have to mark them in some other way (flag, quick collection, color, rating, etc) to find them quickly if you're working on a few scattered images in a big collection.
In my case I don't worry about my images having embedded captions and keywords but I can see why this would be annoying if you did.
After making the metadata updates, you can mark them as up-to-date, then mark them for republish. But the same issue does occur that it deselects the images you chose, so you have to find them again to mark them for republish. I guess you'd have to mark them in some other way (flag, quick collection, color, rating, etc) to find them quickly if you're working on a few scattered images in a big collection.
In my case I don't worry about my images having embedded captions and keywords but I can see why this would be annoying if you did.
Dave
Exactly. And I provide (via Smugmug) a zip file for download to the university for sporting events, and want the files to contain all the metadata and be correct. So as I edit I am continually publishing to get the web gallery up as fast as I can for both teams to have access to photos for their press release, and occasionally for the news paper to pull from. Then I clean up captions, typos, do final edits, and a final publish and then (after a while to make sure it is done) pull a zip file.
As I do it now, I publish, then mark to republish everything. That actually is only a few clicks, but it is a horrible waste of bandwidth for both me and Smugmug since probably 90% or 95% of the photos really do not need to go again.
I'd be fine if Smugmug updated the photos with the corrected metadata, but I can see their point that they don't want to touch the originals. But I want to have an original that is in sync, otherwise I get some embarrassing info wrong that was long ago corrected, but gets carried over into the school's CMS when they pull down the zip.
If I am following you, because many of us don't want to do work twice to change metadata. We want a mechanism that keeps our metadata in synch.
But you are apparently exporting twice, or more than twice. When I edit metadata, I do it on a copy of the JPEG(s) originally uploaded to SmugMug. In fact, per Apple's Finder, the Date Created stays the same, only the Date Modified changes. No exporting all over again involved. I like the security of knowing that I can't accidentally upload modified image data. If I have to go back to master image files and export again just to change metadata, there is the risk of accidentally creating and uploading JPEGs with modified image data.
I think what we are all after is that changes to metadata be reflected on Smugmug when a photo is replaced, by any mechanism, but with the caveat that metadata entered separately on the web interface always takes precedence.
It's really a difficult thing, because what you really want is whichever one was most recently updated, to take precedence. I can see some instances of wanting one Caption in SmugMug that you don't want in Lightroom (for example, I add HTML to my captions on SM that I don't want in LR) but this is a very custom use-case that, if built into the product, would confuse a lot of users.
Keep in mind we're also working on 2-way syncing within Lightroom, so if you update Title / Caption / Keyword / Geolocation on SM, it would get updated in LR. Then if you made an edit in LR, we'd know that was meant to replace what's in SM.
It's really a difficult thing, because what you really want is whichever one was most recently updated, to take precedence. I can see some instances of wanting one Caption in SmugMug that you don't want in Lightroom (for example, I add HTML to my captions on SM that I don't want in LR) but this is a very custom use-case that, if built into the product, would confuse a lot of users.
Well, I do not think so. I think that's wrong for the people who want to maintain their keywords or captions on Smugmug either (a) only, but might inadvertently change it in the image and upload again, or (b) who might want a DIFFERENT caption on Smugmug than what's in the image.
Now neither of them are me, but I know I've seen people here who don't want a replacement to ever change what they hand keyed on Smugmug.
Honestly, except for the tangent below, I think manual entry in the web interface as "always wins" would make people quite happy. Just track where each item came from - web, or image (or LR Plugin = image I think, but maybe a third value). At most a small int, probably a boolean for each item, how hard can that be?
Keep in mind we're also working on 2-way syncing within Lightroom, so if you update Title / Caption / Keyword / Geolocation on SM, it would get updated in LR. Then if you made an edit in LR, we'd know that was meant to replace what's in SM.
OMG, please, please, please put an OFF switch on that which we can turn off.
Two way sync is rarely a good thing, and always confuses people. I vastly prefer one version of the truth. I spent decades doing database replication, I really, truly understand the issues in synchronization in two directions, and know it is sometimes needed. And sometimes you need a root canal. But you never want one just because it's available.
Life is SO much simpler when replication goes in only one direction.
PLEASE have a switch to turn it off.
ESPECIALLY since Smugmug sometimes seems to take rather liberal interpretation of data, e.g. capture/taken dates and all the recent discussion. Or in "fixing" my own web site maybe I push the wrong button. PLEASE keep your hands off my master copies in Lightroom. That's my one version of the truth; let it be!
ESPECIALLY since so much data on Smugmug may be wrong based on all these years of inconsistent updates depending on path, and might come back down.
ESPECIALLY since, well, it's just a bad idea. Maybe a good marketing idea, but a bad idea in concept to be editing things on both places with the idea the software figures out which is right.
Keep in mind we're also working on 2-way syncing within Lightroom, so if you update Title / Caption / Keyword / Geolocation on SM, it would get updated in LR. Then if you made an edit in LR, we'd know that was meant to replace what's in SM.
OMG, please, please, please put an OFF switch on that which we can turn off.
The third party Smug Sync-back for Lightroom listed on this SmugMug Help Page gets it right, I think, at least for captions and titles. Syncing-back from SM to Lightroom is on-demand, on a gallery-by-gallery basis, but you can select multiple galleries. When it finds a mismatch, it asks for confirmation on what to do: Lightroom --> SM, SM --> Lightroom, or nothing. You can make choices one-by-one on each image. I use it, but gingerly. I too view the LR copy as the master.
On the larger issues in this thread, I too think being able to update more metadata than just caption, title, and keywords from LR to SM would be very helpful. I wanted to update copyright info at one time and discovered I had to delete the pictures and reload to do it. Same thing when I wanted to make a capture time fix on some pictures where I had the time zone way off (nine hours between Pacific and Central European Time). As noted elsewhere in this thread, it's not a lot of button-pushing, but it is a lot of bandwidth and time.
On the larger issues in this thread, I too think being able to update more metadata than just caption, title, and keywords from LR to SM would be very helpful. . . .
Very interesting. This shows how far off topic this thread has gone from my original post. Without re-reading all of it now, I don't recall anyone explaining you are limited to editing just captions, titles, and keywords from Lightroom to Smugmug. So no one cared to seriously consider to my earlier comment about the possible need to edit the EXIF timestamp?
. . . I wanted to update copyright info at one time and discovered I had to delete the pictures and reload to do it. Same thing when I wanted to make a capture time fix on some pictures where I had the time zone way off (nine hours between Pacific and Central European Time). . . . .
Please explain how you deleted the pictures and reloaded them, without ending up with new URL's (breaking the original links.)
Next time I start a new topic, I will say, "No discussion of Lightroom is welcome."
Very interesting. This shows how far off topic this thread has gone from my original post.
I think all of this had remained mostly on topic. It's impossible to discuss replacing images without discussing Lightroom, because it's another way that a replace is performed.
Today, We don't ever update metadata on a replace. Lightroom can do a replace and also update certain image details (keyword, titles, and captions) all in "one step" (it's actually multiple but wrapped into one "mark for republish"). In the future, replacing an image will update all of the metadata... Except those image details (keywords, captions, titles, geolocation) that are stored on Smugmug as specific editable fields. The discussion had been based around what to do with those fields on a replace, especially since the most common way to set them is by setting them in Lightroom.
. . .
Today, We don't ever update metadata on a replace. . . .
Confusing comment, because of course when I use Replace, the Original Size image file is replaced, both image data and metadata. I don't think that you keep the very original image file, nor should you.
. . . Lightroom can do a replace and also update certain image details (keyword, titles, and captions) all in "one step" (it's actually multiple but wrapped into one "mark for republish"). . . .
Are you saying those particular image details will also be updated in the assorted display sizes that SmugMug creates (thumbnails to X3L)? I don't believe anyone has really stated this clearly. You said that Republishing works the same as Replace, which suggests that it does not.
. . . In the future, replacing an image will update all of the metadata... Except those image details (keywords, captions, titles, geolocation) that are stored on Smugmug as specific editable fields.
In other words, you are going to maintain inconsistent metadata between the Original Size and the assorted sizes (thumbnails to X3L) that are available for downloading when Replace is used? As I said, when I use Replace, the Original Size image file is replaced, both image data and metadata (as, of course, it should be because you are replacing the file.) So now you're saying, some of the metadata is going to get updated in the assorted sizes (thumbnails to X3L), and some of it not?
P.S. I am aware that only data in certain fields, not every field, is copied to the SmugMug generated assorted sizes. I have a workaround to this problem that I am satisfied with. Problem is, the workaround doesn't get reflected in the assorted sizes when using Replace.
The third party Smug Sync-back for Lightroom listed on this SmugMug Help Page gets it right, I think, at least for captions and titles. Syncing-back from SM to Lightroom is on-demand, on a gallery-by-gallery basis, but you can select multiple galleries. When it finds a mismatch, it asks for confirmation on what to do: Lightroom --> SM, SM --> Lightroom, or nothing. You can make choices one-by-one on each image. I use it, but gingerly. I too view the LR copy as the master.
Maybe I read too much into the comment, but I do not think that is the same thing as was indicated.
The sync you are speaking of forms a link from your LR catalog to the image on Smugmug if it is broken, i.e. if the same image is in both, it finds it and creates a link.
It does not (at least I have never seen any indication it can) bring back metadata information from Smugmug and store it in your LR catalog.
Here's the real issue.
- Image in LR says caption "The Truth"
- Image uploaded to SM says caption "Web Truth", by manual edit or whatever
- Synch in some fashion
I think today they remain the same - LR says "The Truth" and web says "Web truth".
If they do a metadata two way sync, I fear that my Lightroom catalog will suddenly say "Web Truth". To me that's bad. To others that may be exactly what they want. But that's a very different feature than anything we have now.
Today LR will synch back information such as gallery descriptions and options, and photo contents (the link to the photos in other words). And the gallery description and options is a live, immediate sync, i.e. you can't make changes in LR and later publish and so create inconsistent data -- it's a live, online update if you change it in LR. You can update on SM's web and pull down to LR later, but that's gallery, not photo data; in effect data about the gallery is about Smugmug -- so making Smugmug be master is not a bad thing, as (if I published to Flickr as well) it wouldn't affect Flickr. Now if you sync photo metadata it might. Data about photos (to me) as NOT about Smugmug, Smugmug is just a consumer of that data, perhaps one of many.
To me LR is a content management system. It is the one version of the truth, and SM and any other published sites are the tails wagged by that dog.
But there are users out there where Smugmug is their content management system, the updates there are the master values for metadata like keywords. In their case they may want the dog Smugmug to wag their PC's tail.
Somehow you have to satisfy both parties, I think. Or convince one party they are just wrong headed. Which of course means convincing the other guys, not me!
... It does not (at least I have never seen any indication it can) bring back metadata information from Smugmug and store it in your LR catalog.
Here's the real issue.
- Image in LR says caption "The Truth"
- Image uploaded to SM says caption "Web Truth", by manual edit or whatever
- Synch in some fashion
I think today they remain the same - LR says "The Truth" and web says "Web truth".
At the risk of more thread drift (with apologies to NY2LA since after post #20 or so this thread clearly has moved beyond his original display copy metadata issue to a broader discussion of metadata management and integrity) ...
That's exactly what the add-in I mentioned does for both captions and titles. It puts "Web Truth" into the LR database. At that point, the original file is unchanged. Lightroom then provides the option (via the Metadata Status field or under Metadata in the menu) to save the Lightroom version of the caption, title, and other metadata to the original file. Note too that if you entered "The Truth" via Lightroom and didn't push it back to the original file, then that file does not and never did contain "The Truth".
At the risk of more thread drift (with apologies to NY2LA since after post #20 or so this thread clearly has moved beyond his original display copy metadata issue to a broader discussion of metadata management and integrity) ...
That's exactly what the add-in I mentioned does for both captions and titles. It puts "Web Truth" into the LR database. At that point, the original file is unchanged. Lightroom then provides the option (via the Metadata Status field or under Metadata in the menu) to save the Lightroom version of the caption, title, and other metadata to the original file.
My apologies, I somehow conflated that with the current Plugin functionality for syncing photos.
Note too that if you entered "The Truth" via Lightroom and didn't push it back to the original file, then that file does not and never did contain "The Truth".
I'm not quite sure what you mean here, are you referring to the idea that the XMP sidecar, if never read, is never updated into the catalog? That's true, but leaving it sitting there and incorrect is like a time bomb for one day if you did a large scale sync.
Or if you mean the fact that the raw file (if you are shooting raw) never gets updated by Lightroom at all, I understand that. But that's more implementation detail than conceptual.
So there is a tool which will sync from Smugmug's captions back to Lightroom. Good. And it sounds maybe possibly like Smugmug is planning to implement that into their own plugin. Fine, just provide an "off" switch.
All this really begs the question of "who wins" when there are updates from both ends in the future when (if) Smugmug changes so a replace reads metadata. That to me goes to the core of this whole argument.
In my mine "last entered wins" is a bad idea, because last entered may be incorrect due to Smugmug's various attempts over the years to interpret metadata and sometimes getting it wrong. To me the simplest course of action is that the user decides which end of the chain they want to be authoritative, Smugmug's web-entered data, or the photos/lightroom's data.
I think that's effectively the same as deciding "if the user enters metadata manually on Smugmug that wins". If the metadata comes from either the plugin or image data, then replacement image data wins.
Simple. Everyone will be happy. ... OK, I'll stick with "Simple".
I'm not quite sure what you mean here, are you referring to the idea that the XMP sidecar, if never read, is never updated into the catalog? That's true, but leaving it sitting there and incorrect is like a time bomb for one day if you did a large scale sync.
Or if you mean the fact that the raw file (if you are shooting raw) never gets updated by Lightroom at all, I understand that. But that's more implementation detail than conceptual.
You may have a better handle on the details than I do, but my understanding is that if one is using a non-Adobe RAW format, pushing metadata back to the "original" goes in a sidecar, and if one is using a DNG, JPG, TIFF or the like, LR will write directly to the original file.
I mostly use my camera's non-Adobe RAW format, do not write sidecars, and treat the combination of the LR catalog file and the unmodified original RAW as the masters (with cloud backups for both, totally separate from SmugMug.)
You may have a better handle on the details than I do, but my understanding is that if one is using a non-Adobe RAW format, pushing metadata back to the "original" goes in a sidecar, and if one is using a DNG, JPG, TIFF or the like, LR will write directly to the original file.
I mostly use my camera's non-Adobe RAW format, do not write sidecars, and treat the combination of the LR catalog file and the unmodified original RAW as the masters (with cloud backups for both, totally separate from SmugMug.)
You are correct, though there is some control over whether you write it back or not. But for the majority of users, output from Lightroom always comes through Publish or Export, and those take the catalog metadata and add it to the output file. That's what I meant by implementation details -- whether it's actually in the side car or the catalog shouldn't matter, unless you are doing something more unusual like taking files directly from the lightroom folders instead of using export or publish.
So for example using the LR plugin to publish (unless you select to suppress metadata period) always takes the latest LR knows about (regardless of where stored) and puts it in the actual image data, if image data is sent.
Let me just note I've found this thread very enlightening. I sort of realized that a) the files on disk (image files and sidecars), b) the Lightroom catalog if you use that connection, and c) what was up on SmugMug represented three different metadata databases that might or might not be in sync. But I didn't know all the convolutions, especially within SmugMug. I definitely sympathize with NY2LA who had a use case where metadata management was as important as image display and found himself in the middle of all this.
Replacing a photo should replace all sizes of that photo with the new one. The behavior in #3 sounds strange. It does take a few minutes for the processing / generation of image sizes to complete. If you look at the image again, does it have the proper display sizes with the new version of the photo? I ran a test and uploaded a completely separate image (same filename, so it did a replace) and all my display sizes updated to the new image.
Replacing a photo does not update its metadata. There are a few reasons but one of the main reasons this is because titles, keywords, and captions can be updated within SmugMug and can conflict with the replaced metadata. We can definitely be smarter about this and after bringing it up with the team it looks like we're going to file this as a bug and do a better job (or start, rather) replacing some or all of the metadata as well.
If you'd like to replace the metadata, the best way is to delete and replace the photo. Additionally, if you happen to use Lightroom, you can use the Publish Plugin to update the title, caption and keyword.
Will one or more of you who use the Lightroom plug in please do the following test with the following steps, and report the results:
1.) Pick one of your galleries where you used Lightroom plug in to republish photos with a revised title, caption and/or keyword.
2.) If you use right click protection, temporarily turn it off on the gallery with the republished photos.
3.) Sign out of SmugMug. (This step may be unnecessary, but please humor me.)
4.) Go to the gallery that you republished with a web browser. Pretend that you are a member of the general public, looking at your photos. Drag a few SmugMug generated display size JPEGs to your desktop.
5.) Look at the metadata in those display size JPEGs. In addition to possibly using Lightroom, try using a different program to look at the metadata. (I've learned a lot about metadata by using more than one program to look at it, because different programs read and display it differently.) If you use a Mac, try using the Inspector in Apple's Preview, or even Get Info, which will show you the title, caption, and more. Do you see the revised metadata?
Will one or more of you who use the Lightroom plug in please do the following test with the following steps, and report the results:
1.) Pick one of your galleries where you used Lightroom plug in to republish photos with a revised title, caption and/or keyword.
2.) If you use right click protection, temporarily turn it off on the gallery with the republished photos.
3.) Sign out of SmugMug. (This step may be unnecessary, but please humor me.)
4.) Go to the gallery that you republished with a web browser. Pretend that you are a member of the general public, looking at your photos. Drag a few SmugMug generated display size JPEGs to your desktop.
5.) Look at the metadata in those display size JPEGs. In addition to possibly using Lightroom, try using a different program to look at the metadata. (I've learned a lot about metadata by using more than one program to look at it, because different programs read and display it differently.) If you use a Mac, try using the Inspector in Apple's Preview, or even Get Info, which will show you the title, caption, and more. Do you see the revised metadata?
Can't try it now but I can tell you the metadata won't get updated. When you publish again after just a metadata update, the publish happens almost instantly because only a tiny bit of data gets transmitted to smugmug. If you take an extra step before or after publishing, you can tell the plugin to upload the entire files with metadata embedded. It's obvious because the publish takes a lot longer while it uploads new images.
Will one or more of you who use the Lightroom plug in please do the following test with the following steps, and report the results:
1.) Pick one of your galleries where you used Lightroom plug in to republish photos with a revised title, caption and/or keyword.
OK, I'll play. But first you have to realize there are at least two variations at this point, an image republished with only metadata changes, and an image republished with image and metadata changes.
So I'm putting up two images. These are links to the original size image (which won't change in what follows):
(Yes, I screwed up and called it "Caption" but am too lazy to go back and change, it was in the title field so going to use it)
So I went into the first and made it "Changed to title instead" and into the second and made it "Changed to title instead B" (so they are both the same right now).
Then I went into the second one "B" and edited it and converted to black and white. This will cause the entire image not just metadata to send for "B".
And I published. And waited a while (insert the "Jeopardy" tune here for waiting)
4.) Go to the gallery that you republished with a web browser. Pretend that you are a member of the general public, looking at your photos. Drag a few SmugMug generated display size JPEGs to your desktop.
5.) Look at the metadata in those display size JPEGs. In addition to possibly using Lightroom, try using a different program to look at the metadata. (I've learned a lot about metadata by using more than one program to look at it, because different programs read and display it differently.) If you use a Mac, try using the Inspector in Apple's Preview, or even Get Info, which will show you the title, caption, and more. Do you see the revised metadata?
Here's where what you are asking also splits up -- which size? In my case it generates various sizes. I also don't quite know what you mean by "drag" them over; when I drag it generates a link icon not an image. But ...
So I'm going to do a "Copy Picture" from the web page first. I did that from Collage Landscape. This will vary a lot depending on what kind of them and browser size you use.
The first image shows a caption of "Original Caption?", i.e. it does not show updated. This is not a surprise to me, as I didn't expect Smugmug to change the underlying image data.
The second "B" image shows "Original Caption B", also unchanged, yet the image is black and white. This is a huge surprise to me, and I think incorrect.
These were the smaller sizes from collage landscape. So I went into Smugmug's web and changed my display size to "Original":
First image: "Original Caption"
Second image: "Changed to title instead B"
Now this is what I expected, since only for the second image was new image data sent, and when I pull the original I am pulling the image I sent up.
HOWEVER, and I did not know this, it would appear when Smugmug regenerated the smaller image sizes, it regenerated them with the old metadata even though on the web display and the original image it had been replaced. This makes no sense at all to me. I tried a few different (but not original) and all had the "Original Caption B". This is just plain wrong and a bug, has to be.
Of interest also is that the information is not as complete in the smaller images. Smugmug is deciding what to include, and is not copying all segments from the original into the generated sizes. I'm not suggesting that is wrong, just worthy of note.
So half of this is what I expected -- sending up metadata only from the plugin updates only the web displayed data, not the image data. As designed, not what I would choose, but Smugmug says they won't change the image unless we retransmit the image.
But when the image is sent again, the Plugin (not Smugmug itself I think as a part of the replace) is refreshing the metadata for web display, and the original image is being sent which is changing the metadata in the "original" because, well, it's the original and not changed.
But what's broken (IMO) is that when the image is sent again, the generated smaller images are not drawing metadata from either the then-current web metadata or the then-current image just sent. Somehow it's preserving the old value but only for the smaller images.
I think I said somewhere far back this is a mess of special cases and workarounds.
But did this give you what you were interested in? By the way, I pulled down the latest plugin (3.0.3.0) and latest Lightroom (2015.4) was running, on windows 10 x 64 patched current.
Postscript: I did this in an unlisted gallery, and assume Smugmug staff can find it from the image links above. I should have done it in a public gallery so I could provide the link, but don't want to give off the unlisted test link. If someone really wants to see the whole gallery I'll redo it in a test but public gallery.
Will one or more of you who use the Lightroom plug in please do the following test with the following steps, and report the results: ... Do you see the revised metadata?
No. And I can pretty much replicate the other things you have reported or have been discussed on this thread. Interesting experiments.
I tried updating captions two ways, via editing in SmugMug and via Lightroom with a republish (just uploading the new caption since I didn't change the image data). In both cases, I grabbed display copies by dragging them from the browser to the desktop. I looked at the downloaded files' captions both in the Windows Explorer (Properties/Details) and by importing into Lightroom. The results were consistent. All had the original (not updated) caption.
When I download that same picture at the original size (not a smaller display copy) using the download button in the SmugMug lightbox, I still get the old caption too. This is even after having the new caption up there for a hour or so. So I can go to a picture, read the new caption, click download, and get a file with a different embedded caption. I think that's consistent with what Aaron wrote back in his big post #20.
If anyone would like to examine my test case for this, look here. My original upload had a caption "Walking back: inside the bridge." I edited it to read, "Walking back: inside the covered bridge." The latter shows on website. The former shows in any download or image-grab.
Then I tried a second experiment.
In Lightroom, when I change the caption AND edit the picture so it republishes a new Jpeg, I get the mixed results you reported. The original, retrieved via the download button, has the new caption. The display copies, retrieved by dragging to the desktop have the old one.
Same applies if I change one of the metadata fields not among SmugMug's four. I changed Creator and Copyright and marked the file to republish (Lightroom won't do so automatically). After republishing, downloading the original gives the new Creator and Copyright. Grabbing display copies does not. Can't say I'm thrilled that I could have two different copyright statements out there for what would seem to be the same image.
The test case for these two is here. The original caption used the verb "was". The update has "were". The latter shows on the website and download-button downloads. The former shows on display copy image-grabs. The original creator name used my middle initial; the update spelled it out.
I'll let you and Aaron work out whether these behaviors constitute bugs or features.
P.S. All of these pictures are available for downloading and examination. Please respect the CC-BY-NC copyright.
tl;dr of the longer post below:
- Yes, there's a "feature" in which the display sizes of a replaced image will have the stripped down version of metadata from the original image. We'll fix that when we start replacing the metadata upon replace.
- We'll be adding metadata syncing between LR and SM. We'll automatically detect which should be displayed on SM, and if there's any questions on which should be shown, we'll have a "Conflict Resolution" GUI.
The details....
Confusing comment, because of course when I use Replace, the Original Size image file is replaced, both image data and metadata. I don't think that you keep the very original image file, nor should you.
We always keep the "very original" image so that when you click the "Download Photo" button you get the exact bytes, bit for bit, that you sent us. There's also an altered original, which covers any rotations that had to be done to display the photo properly, but still contains the original resolution pixels. If you uploaded "version1", edited metadata, and replaced it with "version2", then download the original size, you'll see the metadata from "version2".
When you do the replace, we re-generate new display sizes (S, M, L, X1, X2, etc), but they contain a stripped down version of the metadata from version1. This is what Fergusen called a "bug". I'll go so far as to say it's not necessarily a "bug", however, it's definitely something we want to change. The display sizes for "version2" should have the stripped down set of metadata from "version2". This is something that will change when we start updating metadata on replace.
Are you saying those particular image details will also be updated in the assorted display sizes that SmugMug creates (thumbnails to X3L)? I don't believe anyone has really stated this clearly. You said that Republishing works the same as Replace, which suggests that it does not.
As I alluded to above, currently it does not. In the future we will.
In other words, you are going to maintain inconsistent metadata between the Original Size and the assorted sizes (thumbnails to X3L) that are available for downloading when Replace is used?
Yes, this is how it works now. In the future we're going to fix this!
All this really begs the question of "who wins" when there are updates from both ends in the future when (if) Smugmug changes so a replace reads metadata. That to me goes to the core of this whole argument.
In my mine "last entered wins" is a bad idea, because last entered may be incorrect due to Smugmug's various attempts over the years to interpret metadata and sometimes getting it wrong. To me the simplest course of action is that the user decides which end of the chain they want to be authoritative, Smugmug's web-entered data, or the photos/lightroom's data.
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.
In the web it's a bit more complicated since we don't have the conflict resolution screen and we wouldn't build one for this project. In this case, if you update the Image Details (Title, Caption, Keyword, or Geolocation) on SmugMug, we'll always keep what's in SmugMug. If you then replace an image using the "Replace" tool we won't update the Image Details, since we've detected you made a change on SM. If you do actually want the Image Details updated, you'll have to do it through SmugMug. This should be fairly simple since you can just copy the item from the metadata (or LR or your image editor of choice) and paste it into SM to update. This prevents any accidentally overwriting of what you entered into SM.
HOWEVER, and I did not know this, it would appear when Smugmug regenerated the smaller image sizes, it regenerated them with the old metadata even though on the web display and the original image it had been replaced. This makes no sense at all to me. I tried a few different (but not original) and all had the "Original Caption B". This is just plain wrong and a bug, has to be.
Yep - see above. Not necessarily a "bug" but something that will be fixed in the future.
Of interest also is that the information is not as complete in the smaller images. Smugmug is deciding what to include, and is not copying all segments from the original into the generated sizes. I'm not suggesting that is wrong, just worthy of note.
Yep - we're doing this to keep file sizes smaller, since some metadata can contain 100kb+ of metadata and we want the display sizes to load as fast as possible, especially on mobile where data speeds and data limits my apply.
OK, I'll play. But first you have to realize there are at least two variations at this point, an image republished with only metadata changes, and an image republished with image and metadata changes.
Yes, the problem exists regardless of whether you've also changed the image data, as noted in my original post.
Here's where what you are asking also splits up -- which size? In my case it generates various sizes. I also don't quite know what you mean by "drag" them over; when I drag it generates a link icon not an image. But ...
Any size other than your original size. Dragging is pretty common. Recently, I was on the phone with a friend, and I told him about my photos of him on my SmugMug website. While we were speaking on the phone, he dragged smaller sized versions of the photos to his desktop, and promptly posted them on Facebook. This was not what I had in mind. I would have preferred that he shared a link to the photos on SmugMug. This friend is not in the least bit computer savy.
These were the smaller sizes from collage landscape.
I use collage landscape as well, but I imagine it doesn't matter. Instead of using the display of all of your photos in a gallery, have you tried loading an individual photo, and accessing the icon for the assorted display sizes in the lower right? Then loading any size other than your original size, and dragging then? At any rate, I think "Copy picture" will probably work for this test once you've gone this far.
P.S. Sorry I am breaking up my reply into small replies right now. I am dealing with an unreliable internet connection at the moment, and keep losing the connection.
Of interest also is that the information is not as complete in the smaller images. Smugmug is deciding what to include, and is not copying all segments from the original into the generated sizes. I'm not suggesting that is wrong, just worthy of note.
The smaller sizes do not include information that I put into the IPTC Rights Usage Terms field, for example. So as a workaround, I started putting my rights usage terms in the Copyright Notice field, as suggested by Richard on that thread. (Actually, I now put it in both places.) I can live with that workaround. But then I discovered the problem that I brought up in my original post on this thread. Currently, every single SmugMug generated display size JPEG on my entire SmugMug website remains without my rights usage terms, because I cannot update the metadata in them.
No. And I can pretty much replicate the other things you have reported or have been discussed on this thread. Interesting experiments.
Thank you, Jtring. Part of your first test, using Lightroom with a republish, and all of your second experiment, are very pertinent to my original post. As for editing in SmugMug, personally, I would never expect, and don't think it should, trigger changes to the original or display size JPEGs.
In the web it's a bit more complicated since we don't have the conflict resolution screen and we wouldn't build one for this project. In this case, if you update the Image Details (Title, Caption, Keyword, or Geolocation) on SmugMug, we'll always keep what's in SmugMug. If you then replace an image using the "Replace" tool we won't update the Image Details, since we've detected you made a change on SM. If you do actually want the Image Details updated, you'll have to do it through SmugMug. This should be fairly simple since you can just copy the item from the metadata (or LR or your image editor of choice) and paste it into SM to update. This prevents any accidentally overwriting of what you entered into SM.
This is similar to what I already do, and I have no problem with it. Sometimes I update captions on SmugMug first because it's easier (and presumably more urgent for Google's crawling), and then use Replace with an updated caption in JPEGs when I get a chance. But in either case, it involves simply copying and pasting text, which is no problem with me.
Comments
I take it from other postings this is because you are editing it on Smugmug directly. Fine, I think everyone is agreeing that photo's replaced will not affect data entered on the Smugmug web interface, my writeup included.
But let's say one does NOT edit metadata on Smugmug directly, then that statement would make no sense at all; if I edit the caption AND replace the photo why in the world would I not want the caption replaced on Smugmug.
I think what we are all after is that changes to metadata be reflected on Smugmug when a photo is replaced, by any mechanism, but with the caveat that metadata entered separately on the web interface always takes precedence.
All of this still sounds confusing to me, and beyond the topic of my original post. (Granted, I should have explained that I am using a browser and not Lightroom in my original post.) Why can't SmugMug be like SoundCloud, for example? I can replace audio files, with the same audio but revised tags (i.e., revised titles), on SoundCloud. The audio files with the modified tags are then available for download for someone who wants to use a player like iTunes. But I have to edit the SoundCloud public web presentation separately to make changes to it, and I don't mind doing that in the least bit.
Yup, lightroom will embed the metadata into the photo every time. The issue is just that the smugmug plugin takes a little shortcut and doesn't bother uploading the modified image when only metadata changed (so updates to captions and keywords take just seconds even for a lot of files). But if you're editing metadata (and not the images themselves), you just need to take one extra step (a couple clicks) to tell the plugin to upload the whole images with metadata embedded instead of just the metadata to the smugmug fields.
Dave
If I am following you, because many of us don't want to do work twice to change metadata. We want a mechanism that keeps our metadata in synch.
I think this originates with the idea of where one does editing. If you do captions on Smugmug, either entirely, or for Smugmug specifically different from what you want in your home library, then you want Smugmug's edits to take precedence over what's in the image. Makes sense, nice for those who do.
If you consider your home a "master" library, and want Smugmug (and anywhere else you put photos) to have the same data, then when you replace an image on Smugmug, you want that to replace the captions (etc) at the same time.
I think the saving grace between these two is there is no real middle ground needed. People in the second category aren't going to want to edit on Smugmug and try to sync backwards or something.
So the simple solution (at least seems simple to me) is for Smugmug to keep track of where it gets data. If it comes from web entry directly -- that rules, and never gets replaced when an image is replaced. If it comes from an image upload, then any subsequent image upload (including half-way upload from the plugin for metadata only) replaces it.
But it's NOT a couple clicks, at least not if you are doing a lot of images and only want the ones changed uploaded. There are many problems with that idea.
Consider this scenario:
- Image uploaded first time with caption A
- Caption A changed to B in LR
Now if you want that to go up to SM and be fully in sync, image and metadata both, the shortest path I am aware of is this:
- Go to the collection involved (or more than one possibly)
- Publish (this updates metadata only)
- Go back to the collection involved (or more than one)
- Find the image in the collection (you did remember which one right?)
- Mark it to republish
- Publish collection
The first publish is necessary to get the metadata flag cleared. As of the beginning of the above, you can NOT mark it for republish, as it is already marked (but not marked in such a way the image is sent).
The second republish sends the image itself, with the updated metadata (so your original if downloaded has it, otherwise it still says "A"). But this second one depends on you hunting up and marking all the images to republish (or just mark every single image to republish, which I do, which is horrendously expensive in terms of network time if you have a slow network.
Now it is possible to do some convoluted stuff, like form yet another collection of all the unpublished photos so once published they are easier to find, then mark them in that collection and come back to the original collection(s) to actually do the republish. But that works poorly if you are (as I am) doing this in increments to get a gallery updated for quick consumption after an event.
Now this is not needed if you do not care if the image on Smugmug has the same metadata. The plugin today works great for that (except for capture date and if memory serves a few other things, maybe keyword removal, but I forget).
But if you want to keep everything in sync, there is no short path today to do so if you change anything after initial publish. It is certainly not a couple clicks. At least if it is, please, someone show me, because every event I jump through these hoops.
I honestly think this is easily fixable (well, as easy as any change to a big production system) in a way that will make all camps happy. It's just not as simple as each camp alone thinks it ought to be. It requires each of the mechanisms allows for the quirks of the other.
After making the metadata updates, you can mark them as up-to-date, then mark them for republish. But the same issue does occur that it deselects the images you chose, so you have to find them again to mark them for republish. I guess you'd have to mark them in some other way (flag, quick collection, color, rating, etc) to find them quickly if you're working on a few scattered images in a big collection.
In my case I don't worry about my images having embedded captions and keywords but I can see why this would be annoying if you did.
Dave
Exactly. And I provide (via Smugmug) a zip file for download to the university for sporting events, and want the files to contain all the metadata and be correct. So as I edit I am continually publishing to get the web gallery up as fast as I can for both teams to have access to photos for their press release, and occasionally for the news paper to pull from. Then I clean up captions, typos, do final edits, and a final publish and then (after a while to make sure it is done) pull a zip file.
As I do it now, I publish, then mark to republish everything. That actually is only a few clicks, but it is a horrible waste of bandwidth for both me and Smugmug since probably 90% or 95% of the photos really do not need to go again.
I'd be fine if Smugmug updated the photos with the corrected metadata, but I can see their point that they don't want to touch the originals. But I want to have an original that is in sync, otherwise I get some embarrassing info wrong that was long ago corrected, but gets carried over into the school's CMS when they pull down the zip.
But you are apparently exporting twice, or more than twice. When I edit metadata, I do it on a copy of the JPEG(s) originally uploaded to SmugMug. In fact, per Apple's Finder, the Date Created stays the same, only the Date Modified changes. No exporting all over again involved. I like the security of knowing that I can't accidentally upload modified image data. If I have to go back to master image files and export again just to change metadata, there is the risk of accidentally creating and uploading JPEGs with modified image data.
It's really a difficult thing, because what you really want is whichever one was most recently updated, to take precedence. I can see some instances of wanting one Caption in SmugMug that you don't want in Lightroom (for example, I add HTML to my captions on SM that I don't want in LR) but this is a very custom use-case that, if built into the product, would confuse a lot of users.
Keep in mind we're also working on 2-way syncing within Lightroom, so if you update Title / Caption / Keyword / Geolocation on SM, it would get updated in LR. Then if you made an edit in LR, we'd know that was meant to replace what's in SM.
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
Well, I do not think so. I think that's wrong for the people who want to maintain their keywords or captions on Smugmug either (a) only, but might inadvertently change it in the image and upload again, or (b) who might want a DIFFERENT caption on Smugmug than what's in the image.
Now neither of them are me, but I know I've seen people here who don't want a replacement to ever change what they hand keyed on Smugmug.
Honestly, except for the tangent below, I think manual entry in the web interface as "always wins" would make people quite happy. Just track where each item came from - web, or image (or LR Plugin = image I think, but maybe a third value). At most a small int, probably a boolean for each item, how hard can that be?
OMG, please, please, please put an OFF switch on that which we can turn off.
Two way sync is rarely a good thing, and always confuses people. I vastly prefer one version of the truth. I spent decades doing database replication, I really, truly understand the issues in synchronization in two directions, and know it is sometimes needed. And sometimes you need a root canal. But you never want one just because it's available.
Life is SO much simpler when replication goes in only one direction.
PLEASE have a switch to turn it off.
ESPECIALLY since Smugmug sometimes seems to take rather liberal interpretation of data, e.g. capture/taken dates and all the recent discussion. Or in "fixing" my own web site maybe I push the wrong button. PLEASE keep your hands off my master copies in Lightroom. That's my one version of the truth; let it be!
ESPECIALLY since so much data on Smugmug may be wrong based on all these years of inconsistent updates depending on path, and might come back down.
ESPECIALLY since, well, it's just a bad idea. Maybe a good marketing idea, but a bad idea in concept to be editing things on both places with the idea the software figures out which is right.
Nancy Regan it --> Just say No.
The third party Smug Sync-back for Lightroom listed on this SmugMug Help Page gets it right, I think, at least for captions and titles. Syncing-back from SM to Lightroom is on-demand, on a gallery-by-gallery basis, but you can select multiple galleries. When it finds a mismatch, it asks for confirmation on what to do: Lightroom --> SM, SM --> Lightroom, or nothing. You can make choices one-by-one on each image. I use it, but gingerly. I too view the LR copy as the master.
On the larger issues in this thread, I too think being able to update more metadata than just caption, title, and keywords from LR to SM would be very helpful. I wanted to update copyright info at one time and discovered I had to delete the pictures and reload to do it. Same thing when I wanted to make a capture time fix on some pictures where I had the time zone way off (nine hours between Pacific and Central European Time). As noted elsewhere in this thread, it's not a lot of button-pushing, but it is a lot of bandwidth and time.
Very interesting. This shows how far off topic this thread has gone from my original post. Without re-reading all of it now, I don't recall anyone explaining you are limited to editing just captions, titles, and keywords from Lightroom to Smugmug. So no one cared to seriously consider to my earlier comment about the possible need to edit the EXIF timestamp?
Please explain how you deleted the pictures and reloaded them, without ending up with new URL's (breaking the original links.)
Next time I start a new topic, I will say, "No discussion of Lightroom is welcome."
Today, We don't ever update metadata on a replace. Lightroom can do a replace and also update certain image details (keyword, titles, and captions) all in "one step" (it's actually multiple but wrapped into one "mark for republish"). In the future, replacing an image will update all of the metadata... Except those image details (keywords, captions, titles, geolocation) that are stored on Smugmug as specific editable fields. The discussion had been based around what to do with those fields on a replace, especially since the most common way to set them is by setting them in Lightroom.
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
Confusing comment, because of course when I use Replace, the Original Size image file is replaced, both image data and metadata. I don't think that you keep the very original image file, nor should you.
Are you saying those particular image details will also be updated in the assorted display sizes that SmugMug creates (thumbnails to X3L)? I don't believe anyone has really stated this clearly. You said that Republishing works the same as Replace, which suggests that it does not.
In other words, you are going to maintain inconsistent metadata between the Original Size and the assorted sizes (thumbnails to X3L) that are available for downloading when Replace is used? As I said, when I use Replace, the Original Size image file is replaced, both image data and metadata (as, of course, it should be because you are replacing the file.) So now you're saying, some of the metadata is going to get updated in the assorted sizes (thumbnails to X3L), and some of it not?
P.S. I am aware that only data in certain fields, not every field, is copied to the SmugMug generated assorted sizes. I have a workaround to this problem that I am satisfied with. Problem is, the workaround doesn't get reflected in the assorted sizes when using Replace.
Maybe I read too much into the comment, but I do not think that is the same thing as was indicated.
The sync you are speaking of forms a link from your LR catalog to the image on Smugmug if it is broken, i.e. if the same image is in both, it finds it and creates a link.
It does not (at least I have never seen any indication it can) bring back metadata information from Smugmug and store it in your LR catalog.
Here's the real issue.
- Image in LR says caption "The Truth"
- Image uploaded to SM says caption "Web Truth", by manual edit or whatever
- Synch in some fashion
I think today they remain the same - LR says "The Truth" and web says "Web truth".
If they do a metadata two way sync, I fear that my Lightroom catalog will suddenly say "Web Truth". To me that's bad. To others that may be exactly what they want. But that's a very different feature than anything we have now.
Today LR will synch back information such as gallery descriptions and options, and photo contents (the link to the photos in other words). And the gallery description and options is a live, immediate sync, i.e. you can't make changes in LR and later publish and so create inconsistent data -- it's a live, online update if you change it in LR. You can update on SM's web and pull down to LR later, but that's gallery, not photo data; in effect data about the gallery is about Smugmug -- so making Smugmug be master is not a bad thing, as (if I published to Flickr as well) it wouldn't affect Flickr. Now if you sync photo metadata it might. Data about photos (to me) as NOT about Smugmug, Smugmug is just a consumer of that data, perhaps one of many.
To me LR is a content management system. It is the one version of the truth, and SM and any other published sites are the tails wagged by that dog.
But there are users out there where Smugmug is their content management system, the updates there are the master values for metadata like keywords. In their case they may want the dog Smugmug to wag their PC's tail.
Somehow you have to satisfy both parties, I think. Or convince one party they are just wrong headed. Which of course means convincing the other guys, not me!
At the risk of more thread drift (with apologies to NY2LA since after post #20 or so this thread clearly has moved beyond his original display copy metadata issue to a broader discussion of metadata management and integrity) ...
That's exactly what the add-in I mentioned does for both captions and titles. It puts "Web Truth" into the LR database. At that point, the original file is unchanged. Lightroom then provides the option (via the Metadata Status field or under Metadata in the menu) to save the Lightroom version of the caption, title, and other metadata to the original file. Note too that if you entered "The Truth" via Lightroom and didn't push it back to the original file, then that file does not and never did contain "The Truth".
My apologies, I somehow conflated that with the current Plugin functionality for syncing photos.
I'm not quite sure what you mean here, are you referring to the idea that the XMP sidecar, if never read, is never updated into the catalog? That's true, but leaving it sitting there and incorrect is like a time bomb for one day if you did a large scale sync.
Or if you mean the fact that the raw file (if you are shooting raw) never gets updated by Lightroom at all, I understand that. But that's more implementation detail than conceptual.
So there is a tool which will sync from Smugmug's captions back to Lightroom. Good. And it sounds maybe possibly like Smugmug is planning to implement that into their own plugin. Fine, just provide an "off" switch.
All this really begs the question of "who wins" when there are updates from both ends in the future when (if) Smugmug changes so a replace reads metadata. That to me goes to the core of this whole argument.
In my mine "last entered wins" is a bad idea, because last entered may be incorrect due to Smugmug's various attempts over the years to interpret metadata and sometimes getting it wrong. To me the simplest course of action is that the user decides which end of the chain they want to be authoritative, Smugmug's web-entered data, or the photos/lightroom's data.
I think that's effectively the same as deciding "if the user enters metadata manually on Smugmug that wins". If the metadata comes from either the plugin or image data, then replacement image data wins.
Simple. Everyone will be happy. ... OK, I'll stick with "Simple".
You may have a better handle on the details than I do, but my understanding is that if one is using a non-Adobe RAW format, pushing metadata back to the "original" goes in a sidecar, and if one is using a DNG, JPG, TIFF or the like, LR will write directly to the original file.
I mostly use my camera's non-Adobe RAW format, do not write sidecars, and treat the combination of the LR catalog file and the unmodified original RAW as the masters (with cloud backups for both, totally separate from SmugMug.)
You are correct, though there is some control over whether you write it back or not. But for the majority of users, output from Lightroom always comes through Publish or Export, and those take the catalog metadata and add it to the output file. That's what I meant by implementation details -- whether it's actually in the side car or the catalog shouldn't matter, unless you are doing something more unusual like taking files directly from the lightroom folders instead of using export or publish.
So for example using the LR plugin to publish (unless you select to suppress metadata period) always takes the latest LR knows about (regardless of where stored) and puts it in the actual image data, if image data is sent.
Will one or more of you who use the Lightroom plug in please do the following test with the following steps, and report the results:
1.) Pick one of your galleries where you used Lightroom plug in to republish photos with a revised title, caption and/or keyword.
2.) If you use right click protection, temporarily turn it off on the gallery with the republished photos.
3.) Sign out of SmugMug. (This step may be unnecessary, but please humor me.)
4.) Go to the gallery that you republished with a web browser. Pretend that you are a member of the general public, looking at your photos. Drag a few SmugMug generated display size JPEGs to your desktop.
5.) Look at the metadata in those display size JPEGs. In addition to possibly using Lightroom, try using a different program to look at the metadata. (I've learned a lot about metadata by using more than one program to look at it, because different programs read and display it differently.) If you use a Mac, try using the Inspector in Apple's Preview, or even Get Info, which will show you the title, caption, and more. Do you see the revised metadata?
Can't try it now but I can tell you the metadata won't get updated. When you publish again after just a metadata update, the publish happens almost instantly because only a tiny bit of data gets transmitted to smugmug. If you take an extra step before or after publishing, you can tell the plugin to upload the entire files with metadata embedded. It's obvious because the publish takes a lot longer while it uploads new images.
Dave
OK, I'll play. But first you have to realize there are at least two variations at this point, an image republished with only metadata changes, and an image republished with image and metadata changes.
So I'm putting up two images. These are links to the original size image (which won't change in what follows):
http://www.captivephotons.com/photos/i-D94LW7C/0/O/i-D94LW7C.jpg
Title as originally uploaded = Original Caption
http://www.captivephotons.com/photos/i-S9Xp4g5/0/O/i-S9Xp4g5.jpg
Title as originally uploaded = Original Caption B
(Yes, I screwed up and called it "Caption" but am too lazy to go back and change, it was in the title field so going to use it)
So I went into the first and made it "Changed to title instead" and into the second and made it "Changed to title instead B" (so they are both the same right now).
Then I went into the second one "B" and edited it and converted to black and white. This will cause the entire image not just metadata to send for "B".
And I published. And waited a while (insert the "Jeopardy" tune here for waiting)
I don't. OK. I'll do one better and switch browsers where I'm not logged in.
Here's where what you are asking also splits up -- which size? In my case it generates various sizes. I also don't quite know what you mean by "drag" them over; when I drag it generates a link icon not an image. But ...
So I'm going to do a "Copy Picture" from the web page first. I did that from Collage Landscape. This will vary a lot depending on what kind of them and browser size you use.
The first image shows a caption of "Original Caption?", i.e. it does not show updated. This is not a surprise to me, as I didn't expect Smugmug to change the underlying image data.
The second "B" image shows "Original Caption B", also unchanged, yet the image is black and white. This is a huge surprise to me, and I think incorrect.
These were the smaller sizes from collage landscape. So I went into Smugmug's web and changed my display size to "Original":
First image: "Original Caption"
Second image: "Changed to title instead B"
Now this is what I expected, since only for the second image was new image data sent, and when I pull the original I am pulling the image I sent up.
HOWEVER, and I did not know this, it would appear when Smugmug regenerated the smaller image sizes, it regenerated them with the old metadata even though on the web display and the original image it had been replaced. This makes no sense at all to me. I tried a few different (but not original) and all had the "Original Caption B". This is just plain wrong and a bug, has to be.
Of interest also is that the information is not as complete in the smaller images. Smugmug is deciding what to include, and is not copying all segments from the original into the generated sizes. I'm not suggesting that is wrong, just worthy of note.
So half of this is what I expected -- sending up metadata only from the plugin updates only the web displayed data, not the image data. As designed, not what I would choose, but Smugmug says they won't change the image unless we retransmit the image.
But when the image is sent again, the Plugin (not Smugmug itself I think as a part of the replace) is refreshing the metadata for web display, and the original image is being sent which is changing the metadata in the "original" because, well, it's the original and not changed.
But what's broken (IMO) is that when the image is sent again, the generated smaller images are not drawing metadata from either the then-current web metadata or the then-current image just sent. Somehow it's preserving the old value but only for the smaller images.
I think I said somewhere far back this is a mess of special cases and workarounds.
But did this give you what you were interested in? By the way, I pulled down the latest plugin (3.0.3.0) and latest Lightroom (2015.4) was running, on windows 10 x 64 patched current.
Postscript: I did this in an unlisted gallery, and assume Smugmug staff can find it from the image links above. I should have done it in a public gallery so I could provide the link, but don't want to give off the unlisted test link. If someone really wants to see the whole gallery I'll redo it in a test but public gallery.
No. And I can pretty much replicate the other things you have reported or have been discussed on this thread. Interesting experiments.
I tried updating captions two ways, via editing in SmugMug and via Lightroom with a republish (just uploading the new caption since I didn't change the image data). In both cases, I grabbed display copies by dragging them from the browser to the desktop. I looked at the downloaded files' captions both in the Windows Explorer (Properties/Details) and by importing into Lightroom. The results were consistent. All had the original (not updated) caption.
When I download that same picture at the original size (not a smaller display copy) using the download button in the SmugMug lightbox, I still get the old caption too. This is even after having the new caption up there for a hour or so. So I can go to a picture, read the new caption, click download, and get a file with a different embedded caption. I think that's consistent with what Aaron wrote back in his big post #20.
If anyone would like to examine my test case for this, look here. My original upload had a caption "Walking back: inside the bridge." I edited it to read, "Walking back: inside the covered bridge." The latter shows on website. The former shows in any download or image-grab.
Then I tried a second experiment.
In Lightroom, when I change the caption AND edit the picture so it republishes a new Jpeg, I get the mixed results you reported. The original, retrieved via the download button, has the new caption. The display copies, retrieved by dragging to the desktop have the old one.
Same applies if I change one of the metadata fields not among SmugMug's four. I changed Creator and Copyright and marked the file to republish (Lightroom won't do so automatically). After republishing, downloading the original gives the new Creator and Copyright. Grabbing display copies does not. Can't say I'm thrilled that I could have two different copyright statements out there for what would seem to be the same image.
The test case for these two is here. The original caption used the verb "was". The update has "were". The latter shows on the website and download-button downloads. The former shows on display copy image-grabs. The original creator name used my middle initial; the update spelled it out.
I'll let you and Aaron work out whether these behaviors constitute bugs or features.
P.S. All of these pictures are available for downloading and examination. Please respect the CC-BY-NC copyright.
- Yes, there's a "feature" in which the display sizes of a replaced image will have the stripped down version of metadata from the original image. We'll fix that when we start replacing the metadata upon replace.
- We'll be adding metadata syncing between LR and SM. We'll automatically detect which should be displayed on SM, and if there's any questions on which should be shown, we'll have a "Conflict Resolution" GUI.
The details.... We always keep the "very original" image so that when you click the "Download Photo" button you get the exact bytes, bit for bit, that you sent us. There's also an altered original, which covers any rotations that had to be done to display the photo properly, but still contains the original resolution pixels. If you uploaded "version1", edited metadata, and replaced it with "version2", then download the original size, you'll see the metadata from "version2".
When you do the replace, we re-generate new display sizes (S, M, L, X1, X2, etc), but they contain a stripped down version of the metadata from version1. This is what Fergusen called a "bug". I'll go so far as to say it's not necessarily a "bug", however, it's definitely something we want to change. The display sizes for "version2" should have the stripped down set of metadata from "version2". This is something that will change when we start updating metadata on replace.
As I alluded to above, currently it does not. In the future we will.
Yes, this is how it works now. In the future we're going to fix this!
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.
In the web it's a bit more complicated since we don't have the conflict resolution screen and we wouldn't build one for this project. In this case, if you update the Image Details (Title, Caption, Keyword, or Geolocation) on SmugMug, we'll always keep what's in SmugMug. If you then replace an image using the "Replace" tool we won't update the Image Details, since we've detected you made a change on SM. If you do actually want the Image Details updated, you'll have to do it through SmugMug. This should be fairly simple since you can just copy the item from the metadata (or LR or your image editor of choice) and paste it into SM to update. This prevents any accidentally overwriting of what you entered into SM.
Yep - see above. Not necessarily a "bug" but something that will be fixed in the future.
Yep - we're doing this to keep file sizes smaller, since some metadata can contain 100kb+ of metadata and we want the display sizes to load as fast as possible, especially on mobile where data speeds and data limits my apply.
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
Yes, the problem exists regardless of whether you've also changed the image data, as noted in my original post.
Any size other than your original size. Dragging is pretty common. Recently, I was on the phone with a friend, and I told him about my photos of him on my SmugMug website. While we were speaking on the phone, he dragged smaller sized versions of the photos to his desktop, and promptly posted them on Facebook. This was not what I had in mind. I would have preferred that he shared a link to the photos on SmugMug. This friend is not in the least bit computer savy.
I use collage landscape as well, but I imagine it doesn't matter. Instead of using the display of all of your photos in a gallery, have you tried loading an individual photo, and accessing the icon for the assorted display sizes in the lower right? Then loading any size other than your original size, and dragging then? At any rate, I think "Copy picture" will probably work for this test once you've gone this far.
P.S. Sorry I am breaking up my reply into small replies right now. I am dealing with an unreliable internet connection at the moment, and keep losing the connection.
I brought up this issue is a different post: http://www.dgrin.com/showthread.php?p=2003745
The smaller sizes do not include information that I put into the IPTC Rights Usage Terms field, for example. So as a workaround, I started putting my rights usage terms in the Copyright Notice field, as suggested by Richard on that thread. (Actually, I now put it in both places.) I can live with that workaround. But then I discovered the problem that I brought up in my original post on this thread. Currently, every single SmugMug generated display size JPEG on my entire SmugMug website remains without my rights usage terms, because I cannot update the metadata in them.
Thank you, Jtring. Part of your first test, using Lightroom with a republish, and all of your second experiment, are very pertinent to my original post. As for editing in SmugMug, personally, I would never expect, and don't think it should, trigger changes to the original or display size JPEGs.
This is similar to what I already do, and I have no problem with it. Sometimes I update captions on SmugMug first because it's easier (and presumably more urgent for Google's crawling), and then use Replace with an updated caption in JPEGs when I get a chance. But in either case, it involves simply copying and pasting text, which is no problem with me.