Skip to main content
F
FeedbackCommunityMember
Inspiring
April 7, 2011
Open for Voting

P: Prevent loss of Edit Histories when Reimporting Photos

  • April 7, 2011
  • 66 replies
  • 2513 views

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.

    66 replies

    Show previous replies
    F
    FeedbackCommunityMemberAuthor
    Inspiring
    April 10, 2011
    Dan, I also agree a 100% with your comment.
    john beardsworth
    Community Expert
    john beardsworthCommunity Expert
    Community Expert
    April 10, 2011
    It doesn't really matter whether the default is on or off - but what is important is that if it's added, it should only be an option.

    Also missing is metadata for custom fields defined through the SDK. There's a fine XMP reading and writing engine that's just waiting to be used!
    L
    Lee Jay
    Inspiring
    April 10, 2011
    I agree 100%, Dan.
    D
    dtull
    Participating Frequently
    April 10, 2011
    If we could ensure the storage design was efficient enough to not be an undue burden (bloated size) and XMP was extended to be more complete with respect to the catalog, I would say the default behavior should be to preserve all data and let people optionally choose to exclude the data they don't mind losing rather than making presumptions about what is important and what is not.
    john beardsworth
    Community Expert
    john beardsworthCommunity Expert
    Community Expert
    April 10, 2011
    I've said I don't see much value in Dan's summarised history, but I did say "I do think there should be an option... to save history to XMP, but it [the option] should include other Lightroom work that isn't currently saved out. So I'd like it to be my choice whether to save stacking info, assignment to collections, virtual copies etc.". I'd probably switch off the history option though, and think off should be the default.
    Victoria Bampton LR Queen
    Community Expert
    Victoria Bampton LR QueenCommunity Expert
    Community Expert
    April 10, 2011
    But John, you just said you didn't want that extra data in XMP....

    Putting it in the normal XMP files would certainly be my first choice.
    Victoria - The Lightroom Queen
    areohbee
    areohbee
    Legend
    April 10, 2011
    Would it really be necessary to invent a new file format, just to add a few blocks to the xmp?
    john beardsworth
    Community Expert
    john beardsworthCommunity Expert
    Community Expert
    April 10, 2011
    Not another format, another type of sidecar!

    TBH storing extra fields would not "interfere with the XMP spec" or trouble other programs. It's the X in XMP - extensible by you, me or Adobe. Adding extra fields is what it's all about, and other programs simply pass over fields which they aren't set up to read. OTOH a new format or sidecar would make it more complicated to update other programs as they'd have to have logic for a new file type and data format, rather than just being told to read a new XMP field.
    Victoria Bampton LR Queen
    Community Expert
    Victoria Bampton LR QueenCommunity Expert
    Community Expert
    April 10, 2011
    If the purpose is just for backup/transfer/security, perhaps I could throw another alternative into the net - how would it work for people if there was a LR-specific sidecar option, which could contain absolutely everything including History, flags, etc. Something like XMP sidecars, but without interfering with the XMP spec and without having to worry about it breaking other programs that use XMP.
    Victoria - The Lightroom Queen
    F
    FeedbackCommunityMemberAuthor
    Inspiring
    April 9, 2011
    Thanks a lot for your comments, Dan. It is very good to see that you have looked into compression options already at some point.

    It seems that there is little contention about compressing (older) backups. I'll do that manually for now, but it would be nice if some automation would be available in the future. The latter could include moving backups from a (quick working) drive to another (archival) drive once backups have reached a certain age.
    Show more replies
    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices