Lightroom: Eliminate the "master/copy" relationship for virtual copies

  • 6
  • Idea
  • Updated 8 years ago
  • (Edited)
The current difference between "master" and "virtual copy" is completely arbitrary and artificial. Each version (whether it's a master or a VC) is a set of metadata attached to an original file on disk. Masters are not any more special than their associated copies.

The differences in the current UI are:

  • grid/filmstrip badges

  • masters don't have copy names by default

  • delete behavior is different

  • inheritance of develop history
.
A new difference has been proposed in this forum, that only masters can be renamed. (If there are other differences I haven't thought of, please note them in a comment.)

I propose that all versions of a file should be treated equally, and the artificial master/VC differences should be eliminated. I think the current master/VC dichotomy only adds confusion; they would be more naturally seen as just other variations of the same file.

Here's how I would resolve the bulleted items above:

The badges can be applied to all versions, just to indicate that copies exist.

I don't think the copy name thing is a problem, except for the behavior of the arrow in the metadata panel. Perhaps clicking one can bring you to a view of all copies (this is admittedly more awkward than the current behavior of jumping to the master).

Deletion currently brings up a dialog box whether you're deleting a master or a VC. In the new model, deleting any version would act like deleting a VC today, until you delete the last copy when it would act like deleting a master.

Develop history should be inherited when copies are created anyway, and that remains true in the new model. (Perhaps I'll post that as a separate idea.)

Renaming copies is already a problem, particularly when the name includes metadata that varies between the copies, or when using a sequence number when the selection includes multiple copies of the same photo. In this case I'd suggest popping up a modal dialog box indicating the problem and allowing the user to eliminate all but one of the versions from the selection.
Photo of Mark Sirota

Mark Sirota

  • 146 Posts
  • 29 Reply Likes

Posted 8 years ago

  • 6
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 136 Reply Likes
How would this idea integrate with the idea of eliminating both virtual copies and snapshots for some sort of combined "versions" approach? I don't use VCs because they aren't stored in the XMP data, but I am familiar with snapshots, and I'm not sure I really have my arms around what all these concepts floating around would mean as a whole.
Photo of Mark Sirota

Mark Sirota

  • 146 Posts
  • 29 Reply Likes
It's a good question, Lee Jay. I was trying to make the idea small enough to be implementable; once you take it to the logical extreme, all versions are branches off the same tree (see the earlier discussion on making Develop history act like a revision control system). That same concept could apply to LIbrary metadata as well, and makes good sense, but might be a rather big bit to chew.

In any case, I think this smaller proposal could work well with a combined snapshot/VC concept. The same idea applies -- there is no "master"; all versions are equal.

Currently, snapshots are invisible -- the only version you can view/export/publish/print is the current state (the top of the history), whether or not there's a snapshot for that version. If the current state could be viewed as just another variation, then I don't see why these ideas couldn't be integrated.
Photo of Dan Tull

Dan Tull, Employee

  • 172 Posts
  • 38 Reply Likes
The main reason that there is a master/VC distinction is because only the master gets to write its develop settings into the XMP. Now, that in and of itself is something that we'd like to resolve, but until that part changes, the master distinction remains.

Getting all the other VCs settings into the XMP as well means coordinating behavior with other apps that use XMP so they understand the data (or picking one to be the master and writing the others into an LR-specific array, which gets us back where we are now).

Still, I agree that the master/VC distinction is often not a useful one and the idea of ditching it has definitely been discussed (including a unification of snapshots and VCs into some single coherent mechanism).
Photo of Mark Sirota

Mark Sirota

  • 146 Posts
  • 29 Reply Likes
Thanks, Dan -- that's an important distinction that I hadn't thought of.
Photo of Dan Tull

Dan Tull, Employee

  • 172 Posts
  • 38 Reply Likes
Yeah, we'd probably have never made the distinction at all if it hadn't been for that XMP and ACR interop sticking points.
Photo of Sean Phillips

Sean Phillips

  • 159 Posts
  • 47 Reply Likes
That's a great piece of info Dan.

I definitely want the VC metadata to go into XMP, even if that means each copy gets its own XMP file. Other programs would only be able to access that XMP if the secondary copies were sent there from Lightroom. Lightroom would need the ability to look at all XMP files in a folder during ingesting to ensure that all additional copies are found.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 385 Reply Likes
I've been a big proponent of this for a long time.

I hope Adobe can work out the xmp issues somehow...
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 385 Reply Likes
I think this change could be made right now, if xmp is handled in a backward compatible fashion, for example:

Allow any "no-longer-virtual" copy to be tagged as "master" for xmp purposes, then handle xmp in DNG or sidecar same as now for that copy, but then add an xmp sidecar option for Lightroom's sake named base.copy-name.xm(p?). This way it works the same as now outside Lightroom, but Lightroom users could immediately enjoy the benefits of xm(p) for virtual copies too, and sidecar xm(p)s even for dngs and tif/jpgs.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 385 Reply Likes
Regarding snapshots.

I *really* like being able to make snapshots of a copy, without spawning a separate copy.

- Snapshots are useful for saving various states of a single copy, for comparison purposes or fall-back. If the proposed change were implemented, people who are using snapshots now instead of virtual copies would no longer need to do that. Don't get me wrong - I think it would be great to have an option to convert a snapshot to a copy, or vice versa, but snapshots are useful to have without them being copies - please do not get rid of snapshots, regardless of improved copy handling.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 385 Reply Likes
Note: copy/master relationship could easily be handled as a built-in case of the more general group handling proposal defined in a previous FR/Idea. As outlined in that proposal, any copy could be promoted as master, and copies could be expanded / contracted in thumbnail views etc like any other group.
Photo of Bradley Fernihough

Bradley Fernihough

  • 14 Posts
  • 0 Reply Likes
Write to xmp and i'll be happy enough, along with Marks other request for the masters histor steps to appear in each VC.