Another good idea as part of the new Lr relationship handling (stack replacement) features.
To review: Presently, one photo can be related to another photo in Lightroom via:
1. Shared stack (which suffers desparately from lack of collection support).
2. Virtual copy (deleting master silently takes all virtual copies with it).
3. Being in the same folder or collection...
Yet, in real life photos can be related in more ways, for example:
- Its an intermediate version of or component to the same exact photo (e.g. internallly edited raw and externally edited tif, or hdr/pano components).
- Its a final version of the same exact photo (e.g. virtual copy).
- Its a similar photo (e.g. part of a burst).
Personally, I think the database handling should be slightly, subtly changed, such that all photos are handled as virtual copies, meaning:
- A photo copy is defined by a set of adjustments, and the base photo to which they should be applied.
Thus, there is no longer a distinction between virtual copy and real copy.
And, then if the software/user can define relationships, for example:
- Intermediate(component)/Final
- Similar
Notes:
------
- the virtual/real relationship no longer exists (or perhaps I should say *always* exists).
- stacks don't define relationships per se, but you may have a context menu item to stack things based on relationships. (actually, stacks would no longer be necessary,
since this whole FR would really be a more sophisticated way of handling relationships than just "stackage")
- intermediate(components)/final: intermediates are hidden in default viewing mode, since they are not the final photo, but components or stepping stones to the final photo.
Summary:
--------
Relationship handling in Lightroom would be a welcome improvement, namely:
- Simplify by removing the distinction between real & virtual.
- Add the ability to define "user relationships", maybe with a default "starter" set, for example:
- hdr
- pano
- derivative
- duplicate
- burst
- same object (or person)
- same scene (or group of people)
- Note: for each of these relationships, one photo will be considered the "master", or "representative" - the signficance of which may depend on the kind of relationship.
Change the UI to automatically indicate related photos somehow, and ability to hide/show or expand/contract related photos, or edit related photos as quick collection...
Example use cases:
- One selects a bunch of photos and creates an HDR, then defines the HDR output as "representative" and the whole set as members of the "hdr" relationship.
By default, the components are hidden from view. Context menu includes things like "view only related photos" (e.g. put in quick collection for editing), and "view to include related photos" (expand internal "stack" for viewing within present folder or collection).
- One selects a bunch of photos and assigns a "burst" relationship to them. Any photo can be considered "representative" of the burst for the purpose of viewing in default mode.
Similar items exist on context menu for editing/viewing just the burst, or viewing all related burst photos.
- One could select a bunch of photos of the same object, and create a new relationship called "same object"...
- One could select a bunch of photos of the same scene, and assign it an already existing relationship called "same scene"...
- One could select a bunch of photos to be part of a collage or photobook, and assign it a new relationship called "project code-name see-saw"...
More notes:
- Photos can be members of more than one relationship.
- This could replace stacks altogether.
PS - One could accomplish most of this now, sortof, with a disciplined regimen of keywords and collections, or custom metadata and a plugin..., but I think native support would make it more straight forward to use.
Conclusion: All of this is a way of saying, "yes" to the original FR/Idea, with the additional ideas:
- to make it more general via user-creatable "relationships".
- have it replace stacks.
- promote virtual copies to "first-class-citizens" (and retire the distinction between real & virtual).
Final Thoughts:
--------------------
All of this could be made backward compatible:
- Assign stacked photos to the "legacy stack" relationship shipped with Lr4.
- Optional: assign existing real/virtual copies to a "legacy virtual" relationship.