142 Messages
•
3.7K Points
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:
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.
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
lee_jay_fingersh
946 Messages
•
13.8K Points
10 years ago
1
0
dantull
Employee
•
166 Messages
•
3K Points
10 years ago
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).
3
rob_cole_2221866
4.5K Messages
•
76.3K Points
10 years ago
I hope Adobe can work out the xmp issues somehow...
0
0
rob_cole_2221866
4.5K Messages
•
76.3K Points
10 years ago
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.
0
0
rob_cole_2221866
4.5K Messages
•
76.3K Points
10 years ago
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.
0
0
rob_cole_2221866
4.5K Messages
•
76.3K Points
10 years ago
0
0
bradley_fernihough
14 Messages
•
290 Points
10 years ago
0
0