P: Prevent loss of Edit Histories when Reimporting Photos

[FeedbackCommunityMember]

When importing DNGs with stored edits (included XMP data) then the history of the photo just shows "Imported..." instead of the list of edits.

I have a corrupt catalogue. (I did nothing to cause the correction :()
The catalogue contains photos which are not associated to folders in the library module. When I choose "Got to folder in Library module" from the context menu for such photos, nothing happens. I imported them just like any other photos, but somehow the corresponding library folder wasn't created or lost.

I tried synchroning the parent folder but the missing subfolders are not created again.

That's why I decided the only way forward is to create a new catalogue. However, the new catalogue doesn't have any of the edit history. The rendering is OK and I can reset it to see the original version of the photos but I cannot see the edit history anymore.

Why is the edit history not recreated? The essence of it must be available because otherwise the correct final rendering could not be created.

I believe edit histories should be available for JPGs, RAW and DNG files. When I decided to use DNG files vs RAW files with sidecar (XMP) files, I didn't know that I'd lose the history with a fresh import of a DNG file. I suppose that if I had XMP files, I could copy these and still had my edit histories.

[dtull]

I'd have to look at the specific trade-offs involved in the Photoshop design. Lightroom and PS are different products that may justify different choices.

[Victoria Bampton LR Queen]

Ian, considering most people assume that all of the data IS stored in XMP and are shocked to find their history etc. missing, I would have said that the default should be ON in this situation. More knowledgeable users who know they don't want it could then turn it off.

[Ian Lyons]

Victoria,

This is a fundamental change in behaviour - folk have been using Lr since 2006 and haven't had history in their files. Adobe make it the default and everything from then on has history. User unaware of the change sends image to third party who now knows exactly what was done. If you think that won't cause a riot then you've a lot to learn.

[dtull]

Ian, "h.ll to pay" (earlier comment) "you've got a lot to learn"? You're making a valid point here, but there's no need to take that condescending tone when making it.

If you're sending XMP + raw content to a third party you're implying a substantial level of trust. Sending full history is admittedly tipping your hand a bit further, but if you really don't trust the third party not to be reverse engineering your technique, you should be sending baked in rendered formats with most metadata stripped anyway.

What's clear from the thread is that careful thought will have to go into the defaults and options, but there are multiple equally valid choices here depending on the needs.

[dtull]

Ian, "h.ll to pay" (earlier comment) "you've got a lot to learn"? You're making a valid point here, but there's no need to take that condescending tone when making it.

If you're sending XMP + raw content to a third party you're implying a substantial level of trust. Sending full history is admittedly tipping your hand a bit further, but if you really don't trust the third party not to be reverse engineering your technique, you should be sending baked in rendered formats with most metadata stripped anyway.

What's clear from the thread is that careful thought will have to go into the defaults and options, but there are multiple equally valid choices here depending on the customer.

[Mark Sirota]

FWIW, I've first logged that "collapse history" function as a feature request in the 1.x days. So count me in! I don't think it needs to be anything fancy UI-wise, a menu item would do the trick. Needs to work on all selected photos.

[Ian Lyons]

Dan,

My post was not intended to be condescending, but if that's how it reads then my apologies to Victoria and anyone else who was offended.

re the thread as a whole:

Statistical data on top right says 56 replies, 10 participants and 3 people like the idea. Folk who don't like the idea don't get to vote.

[Sean Phillips]

"Folk who don't like the idea don't get to vote."

That's not fair either. Just because I don't want a change doesn't mean that I shouldn't get to influence how that change ends up looking like if Adobe does in fact decide to make the change.

[Sean Phillips]

(Having said that, I actually am one of the 3 that Liked this idea. But it's taken on a whole new life in the conversation since the FR was posted...)

[areohbee]

Perhaps a better scheme than a no-vote/pro-vote would be a priority ranking. I'm often in a quandry - do I vote for something that I think is a good idea, but isn't one of my top priorities? - Some have said "absolutely not" - since it dilutes the priorities. Others have said "yes, of course" - a good idea is a good idea...

If one was able to vote:
0 - this would be a step backwards... - I wouldn't want this, period.
1 - If everything else were already done, then this good too...
2 - good idea but not high priority
3 - good idea but not top priority
4 - top priority.

Would it be better?

[FeedbackCommunityMember]

I fully agree with Dan's reply.

[FeedbackCommunityMember]

Rob, I think you should probably raise that question in the Getting Started & FAQ thread.

I think your list is too fine-grained;
-1 (detractor),
1 (mild support),
2 (top support)
would be sufficient, AFAIC.

Perhaps voters that choose "-1" (and perhaps "2") should be required to leave a comment to justify their choice. Staff could then include or exclude such votes from the (internal) tally depending on the merit of the comment.

I'd be against allowing "-1" without a required comment because there is a chance that people will unduly dismiss ideas just because they want to help other ideas by voting down ideas that don't seem to have any value for them.

[areohbee]

Voting comment/question copies to getting started / faq as suggested - thanks. - R

Personally, I hate being shoved into too small a box. I'd even go for:

Enter your ranking:
0-10, where 0 means "bad idea" and 10 means one of the best ideas.

[john beardsworth]

"That's not fair either. Just because I don't want a change doesn't mean that I shouldn't get to influence how that change ends up looking like if Adobe does in fact decide to make the change. "

"Don't want" ranges from a neutral "do not care" to definitely disliking an idea. In either case, less time for things that you do want. That's why I asked for a "do not like" button.

[FeedbackCommunityMember]

FWIW, I created a proposal regarding a particular form of an essential history that also supports "undo" at any place in the edit history.

[Pattie_F]

Philip

You are correct that the previews are uploaded first and then the original file. This allows you to look at the thumbnails in Revel sooner. You should not run into a situation where you get the thumbnail and not the original.

Pattie