Update Metadata on Replace
System
Registered Users Posts: 8,186 moderator
This discussion was created from comments split from: Upcoming Lightbox Changes.
0
Comments
I appreciate your honesty, but hard to grasp how customers will trust your company and presumably buy new features when the current main product remains broken year-after-year.
Are you saying SmugMug's priority is new products while abandoning current customers who bought the current product and reasonably expect it to work? Is that business strategy expected to work?
"All you have in business is your reputation - so it's very important that you keep your word." -- Richard Branson
"It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." -- Warren Buffett
"It takes many good deeds to build a good reputation, and only one bad one to lose it." -- Benjamin Franklin
https://www.brainyquote.com/topics/reputation
@Hpix: I'm moving this discussion to its own thread because its not related to the Lightbox discussion and I did want to respond without going too far off from the OP's discussion.
Sorry if I came off confusing -- No, I'm not saying that at all. We have absolutely no intention of abandoning current customers - you are definitely our focus.
SmugMug's existing customers have always been our focus and that's why so many of you have been customers for many many years. We do our best to make a thrilling experience for each and every one of you. No product will ever be perfect and there will always be bugs or things a product wants to improve, but the team size or other priorities mean that the product can't get to fix as quickly as they'd like. We're working hard at improving a lot of things: making a better shopping cart experience, helping all of you sell more photos, improving our apps, making it easier to get started with your first design template, ensuring your photos are as safe as possible, and helping to improve experiences that many of you have been asking for.
I've mentioned several times that this is planned to be fixed. This is something I personally want to get fixed. I understand the only thing you want to hear is "ok, this has been fixed" ... that will happen at some point.
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'd just like to add to this discussion that the opposite problem occurs in Lightroom. There, some metadata (but not all, if I recall) is updated when you "update" but there is no mechanism to update the image itself. in other words, if I change metadata, the plugin sends only the metadata, and there is no way to say "send the new image with the embedded metadata change" other than FIRST sending the metadata, then going back manually to mark the image to republish.
We also (and I think separately) have issues with how you update dates - capture, etc. I cannot recall the details, but I vaguely recall that to be similar to what is described in the original complaint - once uploaded, a delete and re-add is required.
Finally, the whole mess of how images are replaced to me makes no sense at all -- if I want to replace an image I want it REPLACED, meaning the old one is gone. Instead, you give the new one a new URL, keep the old around, and do a redirect to the new. Yes, I'm thankful that the new image doesn't require use of a new URL, but this leads to needless delays and extra https transactions, and I wonder if they do not harm SEO as well, all these redirects. A replaced image's URL should be the old URL, the old image should be GONE.
And while I have heard the argument "we preserve the old image in case you need it back, and want to call support" I think that is just plain silly. You probably also have backups if you need to roll someone's gallery back, but even if not -- give the OLD image the new URL not the replacement if you want to keep it available.
I personally think this whole thing is just a mess of programmers trying to optimize something internally. It would all just be fixed if when one replaced an image, it was REPLACED. Internally represented by a delete/add. Metadata added manually gets retained, metadata added from the prior image or from lightroom is removed and the new image provides the new metadata. Stop trying to figure out what is best or right or easiest or fastest -- just let a REPLACE be a REPLACE. This is definitely a case where the KISS principle should have applied, instead it is a nightmare of complexity, and I suspect your delay in fixing it is that it is such a house of cards you are worried you will break it worse.
https://merriam-webster.com/dictionary/replace
Nowhere in there does it say "except put them side by side, tear one apart and pick out pieces of it and replace pieces of the other, except if you are doing it from the other side you tear out different pieces, but regardless leave them bundled where you can only see bits and pieces of each and have no real clue which each piece came from".
Caveat: I haven't tested much of this in ages; I just jump through a series of hoops with each upload to get things updated. I have no idea if some of this was addressed already, but I do try to watch the news and have not noticed.
Sorry but I can't see "customer focus" in the notion that somehow "improving" what already works has a higher priority than FIXING WHAT DOES NOT WORK (which seems to have no priority at all). Will prettier frosting somehow overcome a poisoned cake?
It is NOT "thrilling" to be UNABLE to reliably and fully load and reload photos (Image+Metadata) onto your site, via your Uploader, and apparently via Lightroom too.
How many COMPLETE photos that customers PAID to put on your site are not actually there, with wrong image and/or wrong metadata? (Tens of thousands for me alone...)
Sell photos? With bad images and bad Captions and bad Dates? Good luck.
How many customers eventually discover your system is broken, then spend endless hours checking every uploaded SmugMug photo, Caption, Date, Keywords, to see which photos are broken? (I didn't, until I had uploaded more than 60,000 photos, it had never occurred to me that SmugMug is not reliable.) Then, once a massive set of bad photos is discovered, what can customers do about it? Delete and start over...
.
.
PS: How many current and prospective customers will be shocked to learn how long THIS SERIOUS BUG HAS BEEN HARMING CUSTOMERS -- at least 5 YEARS!
Here's part of a Forum discussion April 2016 (more than 30 months ago!)
https://dgrin.com/discussion/256632/exif-date-handling-in-smugmug-and-lr-plugin
April 1, 2016 Forum (part of ) conversation with @leftquark...
.
.
But the METADATA PROBLEM is not 2-1/2 years old, it seems to be at least 5 years old.
https://dgrin.com/discussion/233489/meta-data-not-included
In 2013 this was posted by a customer in a comment to SmugMug Support:
following
Instagram
Twitter
I see the Metadata update problem that I discovered a few months ago, but is actually at least 5 years old, was the subject of a long, deep discussion spanning early 2016 into 2017. Interesting to see so much user frustration, and more SmugMug promises.
https://dgrin.com/discussion/254443/replace-feature-replaces-image-but-not-metadata-for-some-bizarre-reason
As we approach 2019 SmugMug keeps claiming higher priorities as if that justifies never fixing the core product.
If there really is something to debata, all I want is for Upload+Replace to do that, to both the the Image and the Metadata. Seems like the action could be narrowed to just updating Title, Caption, Keywords, Date (essentially, the user-created IPTC and XMP data, not the camera-created EXIF data).
The 2016 discussion wanders into debate about how to handle potentially conflicing changes, online at SmugMug vs. offline then uploaded. But really is that common? Holding up the bug fix for this unlikely situation is not justifiable, and seems to be an excuse to do no nothing for 5 years.
Besides, there's a simple solution: Let the user decide at each Upload. Already, when doing Upload the user can optionally choose Replace (which actually but unstated is Replace Image only). Just expand that to three types of Replace to choose, somethng like this:
Upload & Replace Image & Tags
Upload & Replace Image only
Upload & Replace Tags only
Please, make this happen!
I think there are many ways this could be done. My preference is, if data came from the image when uploaded, replace it when replaced; if data came from manul entry after upload, do not replace it when replaced.
One can come up with scenarios where any decision you make could fail. My strongest push is for "simple". If we all understand what actually happens, I think people can copre. Right now if you think you understand, I almost guarantee you do not! It is not consistent from upload technique to technique, or item to item.
Keep it simple, and people will be OK, even if not every one gets exactly what they want.
The way I've spec'd it to work is that all the metadata would be updated during a replace, except if the Title, Caption, Keywords, or GeoLocation had been updated on SM. If they had, then the version updated on SmugMug would remain.
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
^^^ +1
That works for me, so long as Lightroom does the same thing.
Just pick up that spec and forward over to your programmers. Think of it as efficiency -- all your valuable time responding to complaints that would be saved, will give you time for new feature design.
I recommend a SIMPLE solution: ASK THE USER WHAT TO DO.
There are lots of ways to fix SmugMug's Replace problem, evidenced by years of discussion and debate, but still no resolution. So I'm interjecting, as a paying SmugMug customer, but also based on my many many years of building complex database systems and applications and web sites, writing two 1,000 page how-too books for database developers, writing hundreds of professional developer magazine articles, plus decades of speaking at developer conferences. Meaning, I understand how touching stable code is not trivial. But 5+ years of SmugMug being broken must end. Perfect is the enemy of Good.
Instead of having SM's Upload system trying to figure out what to do, by trying to evaluate what the user already did, then guess what the user wants next, potentially guessing wrong, do it the simple way: ASK THE USER.
Don't get tangled up in all the possible variations, such as considering whether the user also updated tags on SM rather than in the original local files. That's a trap, because (a) how many people try to intermix both methods, and (b) what if the user did some SM tagging, but then does it better locally and wants to replace the online tags with the new-and-improved local tags? Would this loop back to "delete and reload"?
Do not try to make SM "smart" about what to replace, it can never be smart enough. For each Upload batch, Just Ask The User what to do.
The photos belong to the user. Everything about and within the photos (Image and User Tags) arises from the user. SM should stay out of the way. The user either knows what they did before, and what they want to do now, or they don't know, don't recall, or don't care,. Fine. Have default behavior that does "whatever" but make this clear (unlike the current Upload+Replace that does not say what really happens).
WHAT ABOUT THE REST OF US? i'm sure most serious photographers carefully manage our precious photos, When we alter/edit our Images and User Tags it is intentional and precise. Stop messing it up! SmugMug doesn't need to try and be smarter than we are. LET THE USER DECIDE EXACTLY WHAT HAPPENS WHEN UPLOADING a batch.
This simple solution would be consistent with how SM behaves in most other areas, where users choose how to organize and show their photos and even format their pages. SM doesn't interfere with that, why should it continue to trash Uploading?
More SIMPLE: Giving users the Upload options they need is likely straightforward to implement by simple tweaking of SM's existing UX , screen, and database code. The only notable work needed is to have code to update a few fields of existing metadata, likely just the XMP block. Since that already happens when uploading a new photo, most of the code already exists.
Details:
The current Upload has a pulldown with options to Skip Duplicates or Replace. Just improve the options.
(Perhaps STOP on the Update screen until the user has actually chosen an option (or accepted the default), right now there's a tendency for Upload to start before the user can read and choose an option. Even if the outcome is correct, it is disconcerting to have things happen without user confirmation.)
UPLOAD SCREEN
The existing pulldown would offer revised options, which I am stating here more fully for clarity.
The screen should explain what it will do. Clarity it essential, because Uploading is the most fundamental action on SmugMug. For instance, explain that a Photo has two parts, Image and user Tags -- Title, Caption, Keywords, Date, (and possibly Geo if that is something users update).
Further explanation: Upload actions apply to the currently selected Photos only. For Photos that were already uploaded and currently exist on SmugMug, Uploading them again can Replace the Image and/or Tags of Duplicate/existing Photos, or skip them, as the user chooses. Duplicate/existing Photo are determined by having exactly the same file name.
Upload always will add any new Photo file, both its Image and its Tags. (A Photo is considered "new" if a file of the same name does not already exist on SmugMug.)
Upload Options:
(Default) Upload new Photos only, Skip Duplicates that already exist on SmugMug
Upload new Photos, and Replace any Duplicate/existing Photo's Image & User Tags (delete and reload in one step)
Upload new Photos, and Replace any Duplicate/existing Photo Images but retain their existing User Tags (actual current Replace action)
Upload new Photos, and Replace any Duplicate/existing Photo User Tags, but retain their existing Images (essential replace action that does not exist)
Useful enhancement: A checkbox to have Replace act based on file date-time, so the user doesn't have to keep track of which Photos have been changed locally, to avoid re-uploading when nothing has changed. This should be a checkbox since comparing date-time would apply to any Replace action. This requires that SM stores the original file date-time and does not alter it, but upon Replace DOES update to the new Photo version date-time.
One issue that gets lost in this is that different products' post processing have vastly different impacts on what date and time fields contain, even moreso as you get to media types such as gifs and video. I find these often much the same as smugmug -- overly complex trying to guess what is "right", but ... they exist, and are not within Smugmug's control (and often not within the users' awareness). You need to take care relying on date/time fields to make any decisions. And yes, I get that asking the user can always be an option, but these fields in particular confuse more users (including me) than you would expect.
More good discussion, and concrete suggestions.
But will SmugMug now actually fix this? When?
The original exif should never be touched except for last modified date.
But.
Very rarely I have to fix the original date if I forget to change time zones or daylight savings setting.
Be nice if latest captions keywords etc. could be updated in photo file info and be preserved in downloaded version.
My Website index | My Blog
SM has said, and I completely agree, that the downloads (presumably of the original) should never, ever be modified by SM, at all. THe download should be exactly what you upload.
At least my opinion -- do you disagree?
The Date I care about is the one displayed with the Photo as its "public" date, presumably also used to sort Photos by date/age. Tricky because photos often have multiple dates, from camera, scanner, operating system, server, when edited or copied, etc, etc. In SmugMug I don't know which metadata date field is displayed along with Caption, etc.
It is mandatory that the "public" date, after being set/corrected. can be uploaded to SmugMug, including Replaced when appropriate.
Reasons to change the date: Well, forgetting to properly set the camera date happens. As does needing to adjust the Date (or more usually the Time) of photos coming from different cameras shooting the same event, so they sort/group properly.
But also, many of my library of photos are scanned, so they have the date-time scanned, then need to be set to the original photo/event date.
And many more photos originate with family and friends, good photos but with the accurate dates-times mangled. (It is amazing how many people use Facebook as their publishing system to share photos with others. They often download as pretty good images but bizarre file names and worthless dates.The same happens with various other photo-publishing sites.)
So, often I must set the proper date (and time too) of individual photos. I do that locally, then must be able to Replace prior versions already on SmugMug -- just as I must Replace Title, Caption, Keywords quite often.
(Perhaps someone can say exactly which metadata DATE SmugMug uses, of such choices as Date Taken, File Created, File Modified and other dates associated with the Image and File?)
You and I agree completely -- once a change is made locally, if the image is uploaded as a "replace" it should change the metadata it initially set; this idea that some fields are "stuck" and never changed and some get replaced is just wrong, IMO.
As to the latter, maybe SM can respond fully. I remember trying to figure this out once before, and if I recall it is not a simple "we use this field" but more "we try this field, and if not present we use that one" and maybe some more. I found this out trying to use GIF's, if I recall, which when generated typically do not include all the same metadata fields as your render more directly from the camera. Videos are likewise weird.
We use the
Date Takenfield for the date the photo was taken. We also separately pull out the date the photo was created (often times the "Digitized Date"), last modified date and date uploaded.The Date Taken looks for these metadata fields and uses the first one it gets (i.e. if IPTC-> DateTimeCreated and EXIF -> DateTimeOriginal are different, we use EXIF).
Several of these fields are editable by various tools, including Lightroom's
Edit Capture Timefunctionality. I use this often to fix timezone issues, then upload to SmugMug with the photos displaying in the proper order.Once the replace changes are made, this field would get updated if you realized you had the wrong "Date Taken" and wanted to fix it by replacing the 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
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
**
THANK YOU**
Can you confirm that the Upload+Replace process can be repeated, and each time the newest revised local photo plus its newest revised metadata will be used? Sometimes (fairly often), Captions and Keywords get changed more than once.
I have no intention of touching metadata fields directly in SmugMug. But to round out understanding how it works: IF online metadata was changed, followed by the desire to Upload+Replace with the local version of that photo, is there a way to tell the Uploader to do a full overwrite? Might be important for folks who did a lot of online tagging because Replace was broken, but would rather switch back to Uploading. Or would the solution be to delete the posted photo and upload again as new?
Upload screen seems backwards. What's the secret?
Dragging photos onto the Web Upload screen with the intention of Replacing existing photos, there's no way to indicate this up-front. The Uploader immediately starts, using default Skip Duplicates. Then (and only then) does the option box appear. So it's impossible to change this to Replace Duplicates before one or two or several have already uploaded? Is this a game of skill or chance?