Skip to main content
Adobe Photoshop Family

142 Messages

 • 

3.7K Points

Thu, May 5, 2011 3:33 PM

6

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

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.

Responses

946 Messages

 • 

13.8K Points

10 years ago

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.

142 Messages

 • 

3.7K Points

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.

Employee

 • 

166 Messages

 • 

3K Points

10 years ago

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).

142 Messages

 • 

3.7K Points

Thanks, Dan -- that's an important distinction that I hadn't thought of.

Employee

 • 

166 Messages

 • 

3K Points

Yeah, we'd probably have never made the distinction at all if it hadn't been for that XMP and ACR interop sticking points.

164 Messages

 • 

5.2K Points

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.

4.5K Messages

 • 

76.3K Points

10 years ago

I've been a big proponent of this for a long time.

I hope Adobe can work out the xmp issues somehow...

4.5K Messages

 • 

76.3K Points

10 years ago

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.

4.5K Messages

 • 

76.3K Points

10 years ago

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.

4.5K Messages

 • 

76.3K Points

10 years ago

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.

14 Messages

 • 

290 Points

10 years ago

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