Have replace always replace everything same URL
Ferguson
Registered Users Posts: 1,345 Major grins
There's been so much discussion of this I'd like to throw this out in very simple terms.
I'd like to request that if you replace an image, from the web or lightroom, that EVERYTHING be replaced EXCEPT the URL.
Everything -- all metadata, the original copy, the URL stays the same (no redirects), all Metadata is re-processed just as though it was a Delete + upload EXCEPT that the original URL is the same (and associated image ID's or other identifiers needed for access).
Everything.
No keeping the old image.
No creating a new URL and redirecting the old.
No weird quirks where different size images have different metadata.
Just KISS -- if the image is replaced, replace everything.
Now that said, someone, somewhere is going to be editing the metadata on Smugmug, so maybe both web and lightroom uploads need a switch to permit this behavior vs original behavior, though honestly I think the whole idea of updating metadata in two places is just plain... well, not wise. But I get backward compatibility.
But please, please, please... for those of us who want this to be simple and understandable, and not require 100 posts to discover the quirks --
Replace does a replace. That simple.
I'd like to request that if you replace an image, from the web or lightroom, that EVERYTHING be replaced EXCEPT the URL.
Everything -- all metadata, the original copy, the URL stays the same (no redirects), all Metadata is re-processed just as though it was a Delete + upload EXCEPT that the original URL is the same (and associated image ID's or other identifiers needed for access).
Everything.
No keeping the old image.
No creating a new URL and redirecting the old.
No weird quirks where different size images have different metadata.
Just KISS -- if the image is replaced, replace everything.
Now that said, someone, somewhere is going to be editing the metadata on Smugmug, so maybe both web and lightroom uploads need a switch to permit this behavior vs original behavior, though honestly I think the whole idea of updating metadata in two places is just plain... well, not wise. But I get backward compatibility.
But please, please, please... for those of us who want this to be simple and understandable, and not require 100 posts to discover the quirks --
Replace does a replace. That simple.
0
Comments
--- Denise
Musings & ramblings at https://denisegoldberg.blogspot.com
tailoredportraits.com
As I said, I think Smugmug needs to maintain a backward compatible setting, but...
I perhaps should not have seemed so dismissive, but I just cannot fathom trusting Smugmug (or any web site) with being the only copy of my titles, captions, etc. I may one day want to go somewhere else; they may go out of business; they may install a "newer" Smugmug that screws them all up (or just some casual update as other things have been hosed). You are a very trusting sort, though I suspect you have company. And it's not lightroom -- I can't think of a single photo editing system that doesn't give you control over your own metadata if you choose to use it.
The trusting sort?
URL redirection should also be working, with the exception of CDN caching the old URL, but even that should sort itself out after a few hours. If you're finding URL's that don't automatically redirect to the latest version, please let the Heroes know and our ops team can dig in further on your URL's.
We'll continue to keep around the original versions, for the time when you accidentally replace your wedding first kiss photo with a photo of your dog, and email the heroes with "can you please help me recover my most precious photo?!".
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
OK, but why do we need to have this impact the URL's?
And waste precious http transactions with redirects.
Save them as a backup copy somewhere.
It's too complicated.
So, forgetting manual changes on SM for the moment...
Will what you are doing replace ALL metadata (that you keep) in ALL image sizes, including capture date?
I'm not asking if all sizes HAVE all metadata -- I just want to know if any OLD metadata will be retained (again, excepting manual modifications by the end user by web).
Thank you!
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
I'm not sure that's true, or I misunderstood older discussions.
Consider the scenario of image A replaced with image B. You said in an earlier post that the smaller sizes auto-generated would contain the metadata for image A, but the image from B. Perhaps I misunderstood, as this still seems bizzare as a feature, but that is the specific issue I was asking about.
I realize you do not change originals. But online display of metadata, while largely ignored by many, is still relevant, especially for systems like forums that show an image directly from your resized ones.
That's how it works today, but not how it would work when we start replacing the metadata when you replace an image.
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
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
I think this is good news, could you elaborate briefly on a couple of aspects (and save a lot of testing to discover):
Does this apply only to the web upload, or does it apply to Lightroom?
If it does not apply to lightroom, are changes there planned as well?
Including lightroom, there are three ways (at least) you can (conceptually) replace an image: Web replace, lightroom change to metadata only which "replaces" that metadata but not the image, lightroom change to image which sends the image again -- are all three of these now consistent in their result (except that the middle and later of course produce a different "original" content)?
Do the changes now apply to date taken/created as well? That one has always been a bit mysterious as well as difficult to change, is it now treated more normally (with the caveat of course you still have to figure out what the date taken is if metadata is absent in the image by looking at different segments)?
Oh... by the way... thank you for pursuing this to a deployment!
Linwood
@leftquark Hi Aaron, does the solve the problem of the file name being changed to "unknown"? Am still anxiously awaiting a resolution...
Since I've been running a few tests with Lightroom, let me report what I've seen. You can update both date taken and copyright using Lightroom but you have to "Mark to Republish" and then resend the image along with the metadata. Lightroom does not pick up a change to one of these as a cue to update and just send the metadata. From some discussion with the Lightroom Plugin developer a few years back, I gather that's an issue with Lightroom itself, not plugin construction. Still, if there is any way to revisit that one, it would be nice.
In any case, since I've used the delete-and-reload routine in the past to update these, I appreciate this latest update.
I've never seen this before - can you send me a few examples so I can look further?
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 - any time we see a new JPG file come through, we'll process it, so it should work the same across all 3 ways, for the most part. The one more confusing situation is when it's updated on SM to be something different than what's in LR.
Lightroom goes a step further and also updates the titles/captions/keywords via the API, so most likely the LR version will win out since it's forcing those fields to update, which may result in slightly different behavior than if you uploaded the photo from the web interface. For example, if you uploaded a photo with Title "Original Title", changed the Title on SM to "New Title", changed the Title in Lightroom to "Lightroom Title". If you export the photo from LR to a JPG, then upload that via the web, the title will be "New Title" since the title on SM wins out (it was changed on SM). If you publish on LR, it'll end up as "Lightroom Title" because Lightroom is assuming what you have in Lightroom is what you want.
We've been working on doing some metadata syncing in Lightroom, to ask what you want to do when we see you edited the Title, Caption or Keywords to be something different between SM and LR. That work needs to continue, as highlighted here.
Yep! The "Date Taken" is updated immediately in the "Image Info" but I'm currently investigating a potential issue with the sort order not updating immediately. We'll get that fixed, since it was our intention to have the sort order reflect the new date taken's.
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
@Leftquark, good news, I think.
Relative to lightroom superseding web, that works nicely for me (as LR for me is the "one version of the truth"), but I'll echo my original request as I think it benefits everyone: there needs to be simple and straightforward rules. If updating in Smugmug overrides the upload in one place, I think it should override in all places. I shouldn't need a book of crib notes of different circumstances to know what will happen.
So lightroom-only questoin: is the SM Plugin metadata-only update (since you mentioned the API) actually different than what happens if you upload the image via the plugin? I.e. does the fact that the image is uploaded (or not) in the plugin change what happens with respect to the metadata updates as shown? (I realize that you have to upload changes to the image if you want the original image to download with those changes, but I am asking about what you see ON smugmug.
Glad to hear date-taken is fixed (or will be).
Relative to the syncing in Lightroom -- another echo -- I'd very much like to see an option to turn OFF the metadata-only type of update. Here's my use case: I sometimes need to change metadata on a number of images. It's too hard to keep up myself with which ones I change (and in some cases it's indirect, e.g. changes to keyword definitions that result in multiple images changing). But I want the original on smugmug to also be updated.
At present there's no good way to do that. My technique is: (1) publish (metadata only goes up, along with any images changed), then (2) mark ALL to republish, as I do not know which need it, and (3) publish.
This (3) publish step might send 100 images when really only 5 needed to go, I just do not know which 5. This results in lots of wasted bandwidth to you and me, and lots of wasted space to you as I think you keep both old and new image forever (which is another thing I think you should stop doing but a separate discussion).
If instead I could turn metadata-only off (resulting in it sending the image when triggered by a metadata only change), then step (1) above sends all the images needed, and the other steps are not needed, wasting no bandwidth. And for those with metadata only updates adequate to just change Smugmug not the original, they leave it on (the default).
@leftquark
Sorry, I was not meaning to change the subject, I just thought this new information might relate to the months-old problem that came up with the API change. See: https://dgrin.com/discussion/263631/upcoming-api-changes-please-read#latest
Not a problem -- it's always OK to ask if one fix also fixes another issue. Definitely not a complete change of subject. I'll ping the team to see where they've got that one in the backlog. I don't believe this should fix that issue.
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
This should now be fixed. After replacing a photo the gallery should refresh with the correct Date Taken sort order, using the date taken found in the replaced (new) version.
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
We've been exploring that ability using these options in the Publish Settings:
Unchecking these would just send the pixels (JPG) and avoid the metadata only update. The other thing that this does is select what triggers photos to be automatically marked for republish. When I unchecked "Title", and then changed the title of the photo, Lightroom stops recognizing the photo as being needing a republish. So that might accomplish your outcome?
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
Hmmm... I see the connection but the current use case in that looks to be different. Though frankly I am unclear what they do --- until you included the screen shot I thought those selected which fields CAUSE a republish, but the heading on it says it includes the metadata to be included (as in whether it sends a title or not, not whether a title change causes a modified status for republish). Which is it?
But regardless, I think the concept of sending pixels vs just metadata is a bit at odds with either one of those?
Personally I think a separate option "Send image even if only metadata changes" to check, with default of unchecked would be a lot more clear.
It's technically both: If unchecked, Lightroom will not trigger changes to that field as the photo needing to be republished AND we won't send that field to be updated. The caveat to that, though, is that if the new title/caption/keywords are saved into the EXIF and new pixels are published, then the new method for updating the metadata during a replace will kick in.
I like that idea. I'll talk to the team.
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
So... this is confusing...
It doesn't matter to me as I include all the metadata. But...
I just went to the option and it will not let me change the first line. So it would appear all that info must always go. Does that mean one cannot chose on publish to NOT show location data? I spent a whole three minutes looking and could not see another place to change it (for LR SM, of course you can for exports).
But back to my point -- if this option even exists, and you UN-check something (let's say geolocation), but happen to send the pixels, it will then update geo-location anyway (by the new algorithm as it processes the pixels), which someone might be surprised by if they are trying to keep it private?
(Implicit plea here for consistency so everything works the same way -- KISS principle!)(ok, maybe not so implicit)
Does that mean one cannot chose on publish to NOT show location data? I spent a whole three minutes looking and could not see another place to change it (for LR SM, of course you can for exports).
You can exclude geolocation in LR's built-in metadata chooser as you hinted:
I agree, and I do want to keep it consistent but there's multiple "features" at work here which make it harder and therefore complicated. We have a number of customers on low bandwidth connections that use LR to manage their photos and metadata. They don't want to use their bandwidth every time they change a title or caption, and they want to do their title/caption changes in LR. So having the functionality to only do a metadata only update is important.
To be honest, my brain is a little fried today so I may not be fully thinking this through, but if those checkboxes in the Publish Settings only controlled whether LR saw the photo as needing republishing (and we cleaned up the wording), I think that actually keeps everything consistent. Changing the pixels would cause a republish, which would also grab the new title (in all situations). But you could have a situation where changing the title doesn't trigger the re-publish if you had unchecked that in the Publish Settings.
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
Sigh... I can't believe I didn't scroll down.
So thinking out loud, different people might want:
1) Changes in metadata without image change do nothing.
2) Changes in metadata without image change cause metadata update only, no pixels sent.
3) Changes in metadata without image change cause image update (and metadata)
I can make an argument for each of these three -- my case is (3), a more "normal" user is (2), and low bandwidth folks who want really deliberate republishing decisions could be (1). But I do not think this is the right way to approach providing options even if these are the types of use case, as the metadata is not binary but a selection of different fields. I would argue the most understandable distinction for option selection that allows clarity for for multiple metadata fields are:
1) Check metadata fields cause a republish event (as now more or less), and
2) Does a metadata-only caused republish event cause the image to be updated, or just the metadata
So for example, someone like me who wanted the image sent if metadata changes, might also really not care about keywords. So they might want caption, geo-location, etc. to cause republish AND send the whole image, but a keyword (only) change might not do either until and unless the image pixels change and then the image is sent, updating keywords also.
So my suggestion is a separate option. And clarity that the actual update when sending an image WILL include all the fields selected in the other panel.
My 2 cents.