Lightroom: New Way to Handle Related Groups of Photos

  • 19
  • Idea
  • Updated 8 years ago
  • (Edited)
What I'm asking for here is an expansion of the current Master/Copy relationship between a Master image and Virtual Copies, so that all images related to a Master image are linked back to it regardless of file name or location. This would be implemented with features like:

  • A checkbox to identify Master Images. Can't be unchecked once other files are linked.

  • When derivative files are exported, a checkbox to 'Link to Master Photo in Catalog'

  • If that is checked, a text box for the copy name (such as "1024 JPG")

  • Ability to add existing duplicates/derivatives to a master by selecting related files and right-clicking 'Link to Master'

  • Enable the 'Go to Master' button next to 'Copy Name' for all linked files (as it works now for Virtual copies

  • 1. Either automatically stack all derivatives with the Master file, OR

  • 2. Add a 'Work with all related Files' button next to the filename, goes to something like an ad-hoc collection with the Master file and all derivative, duplicate, and virtual copies in the catalog

Paul Wasserman
Photo of paulwasserman


  • 24 Posts
  • 9 Reply Likes

Posted 8 years ago

  • 19
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 386 Reply Likes
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

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

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.
Photo of paulwasserman


  • 24 Posts
  • 9 Reply Likes
While I still would like to see the specific Master/Derivative features I requested in the original FR, I really like the 'relationship' concept as a replacement for stacks. To make this work I think the UI really needs to be intuitive. If we call the related images 'Groups' for now, here are some suggestions for starters:

To add to or create a Group:

  • A Group is created like a stack is now, via right-click

  • To add to an existing Group, the name is selected from a list

  • The list of existing Group names are those the image that was right-clicked belong to

  • A new Group can be created by entering a new name. The image that was right-clicked becomes the Master image for the new group

Working with Groups:

  • Any image that is part of a group will have a little icon (like the existing 'Collections' Icon

  • Any image that is the Master Image of a group will be identified.

  • Clicking the 'Groups' Icon on an image will bring up a list of Groups the Image belongs to

  • Selecting a group will bring up a grid with all members of the group displayed. It'd be nice if this was a pop-up window, but that might not be practical.

  • A Command button on the screen will appear saying 'Return to .... wherever you were before working with the group. Also doable via hotkey.

  • The Master image for the Group will be identified in some way, and can be changed to another image via right-click or button

  • Images can be removed from the Group or deleted here

  • If this Group was launched from a Collection, a little button will appear on each image. The button can be pressed to add or remove the image from the Collection

  • Right-Click options would include "Move to same folder as Master", "Move to selected folder" (with a folder dialogue), etc.

  • Possibly, the last Group worked with would remain persistant, like the Quick Collection. This would allow navigating to other folders or collections and dragging images to the Group, etc.

Additional thoughts welcome.

Paul Wasserman
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 386 Reply Likes
Paul - I was thinking the original FR/Idea would also fit into the "Group" idea, but if you'd prefer to keep them independent, I'll start a new thread for the "Group" idea. In any case, I'm onboard for keeping track of how photos relate to each other, whether a group relationship or master/slave...

Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 386 Reply Likes
Paul - your post above is probably the best so far to capture the essence of what this 'Idea' has become, from a user perspective. If I may summarize conceptually:

What we're talking about here is a stack-like feature (to replace stacks), except a photo can be in more than one "stack", and "stacks" can be nested, and named, and may have special features tied to them, depending on type. Some example built-in "stack" types:

- raw/jpg
- master/v-copy
- original/externally-edited
- *user-defined
- legacy stack (for backward compatibility with Lr3- stacks)

*In addition to the groups maintained natively by Lightroom (see above), user could create / name their own "stacks", for example:

"by the pool"
"in the red dress"
"burst of falcon in flight"
"pano of grand canyon"
"hdr of sunset"

I can imagine Adobe supporting hdrs & panos as built-ins too, but as long as user can define their own, I'm not sure how much that would matter... (would mostly depend on whether there is any special native handling tied to it).

Now that I'm thinking about it, being able to tie a user-defined group handler (e.g. plugin or app) to a group would go nicely - for example, if one defined a group type called "layers", then invoking the layer group handler on a layer group would load all layers into onOne's new perfect-layers plugin, obviating the need to expand, select, then invoke...

Photo of paulwasserman


  • 24 Posts
  • 9 Reply Likes
Thinking it through, the original FR does fit pretty well with the "Group" idea. It somewhat detailed out the single-file 'atomic' kind of grouping you'd mentioned elsewhere. To support this in the broader grouping strategy, perhaps a few additional specs:

  • Some sort of built-in or default Master/Copies group

  • Any new Virtual Copy gets added to this group if it exists, otherwise the group is created with the original image as the Master

  • Any derivative file created through 'Edit In' gets added to this group if it exists, otherwise the group is created.

  • The 'Edit In' dialogue adds a checkbox for "Make Edited File the Master" (useful when building a PSD from a RAW file, for example).

  • Exporting gives the option to add the Export to this group

I think that, or anything close, would do it.

I would much prefer something like the broader 'Group' strategy, and would only think of my original FR as a fall-back if the broader strategy isn't going to fly.

So, up to you if you want to post separately - it might give the subject better visibility. If not, wonder if I can change the title of this FR?

Paul Wasserman
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 386 Reply Likes
The more I think about this, the better it sounds. If group handling were refined I might just get a new drive and use it to store "related" files. I mean, for me, there are two impediments to shooting bursts, hdrs, panos, externally editing, focus stacking, virtual copies, etc...:

1. Related file management.
2. Storage.
3. (In case of external edits, add: loss of edit contiguity with source, a.k.a. the "forking disjointedness", and its cousin "the big tif").

This FR/Idea would solve #1, a couple big drives mostly solves #2, and #3 would remain to be solved - but that's another FR/Idea.

PS - I *think* you can't change titles once somebody has replied - maybe the forum "administrator" could do it. - One of us could make new FR/Idea with revised title and manually move relevant contents over if need be - standing by...
Photo of Ian Lyons

Ian Lyons, Champion

  • 28 Posts
  • 6 Reply Likes
What do you want as title? I can update it for you.
Photo of paulwasserman


  • 24 Posts
  • 9 Reply Likes
Thanks. I think "Lightroom: New Way to Handle Related Groups of Photos" would do it.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 386 Reply Likes
Sounds perfect - thanks Ian.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 386 Reply Likes
I think this is sortof what Photographe was driving at when he initiated his thread about stacks.

Put another way, 'stacking', as presently implemented is just "a group" - let us define more groups, and have the software keep track of the obvious/built-in ones too...

And also my previous idea of "atomic stacks" pales in comparison to the new more general grouping solution...
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 386 Reply Likes
Reminder: This 'Idea' evolved considerably since the original 'Idea' (which had a very different title), thus the original description just barely scratches the surface of what this 'Idea' became.

This is one of my highest hopes for Lightroom (2nd only to develop tool enhancements).

Please remember to click the '+1' button up top of page if you like what this idea became.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 386 Reply Likes
Paul - I don't think this idea is getting the attention it deserves due to people assuming its only about master/copy handling - because of the original description.

Please consider appealing to Adobe to replace the original description, and cite Master/Copy as a "use case" instead.

Otherwise, I'm planning to write up a new 'Idea' and reference this one, suggesting a merge with this one would be 'OK'. I think a lot of people never get past the first paragraph to realize it would benefit them for handling HDRs, panoramas, focus-stacks, externally-edited versions, projects, derivatives, raw+jpeg, bursts, scenes, etc., ..., and so forth, as well as the master/v-copy relationship.

Especially for people who take hundreds or even thousands of photos, that are related in a variety of ways, and then edit some of them externally, and/or make derivatives, and/or virtual copies, ..., I think this idea would be more beneficial than most people realize at first.

Metadata and collections / filtering for this? - too cumbersome and downright inadequate for dealing with (often nested) groups of related photos, me-thinks. If somebody disagrees - please advise of an alternate way for dealing with this stuff, for those of us who've yet to get a good handle on it...

Just use stacks ya say? - I say: "very funny", or "yeah, right"...
Photo of zigzag


  • 13 Posts
  • 2 Reply Likes
Might be useful to break better handling of related files down to multiple cases/issues:

1. One photo has multiple sources. (raw+jpeg)
Only ability to switch between sources is needed in addition to current default behavior.

2. One photo consists of multiple sources. (hdr, panorama)
These are special kind of groups that would almost require Lightroom to implement HDR and panorama functionality. But it may be enough to have ability to create this special kind of groups and have simple API to allow external applications/plugin combining of photos in these groups to hdr/panorama photos.

3. Multiple photos are somehow related (multiple photos, 1-multiple outputs)
3.1 Stacks/groups (bursts etc.)
One photo can be only in one group at a time.
Any useful improvement to general stacks/groups handling is welcome. (predefined types)
3.2 Collections (maybe)
One photo can be in multiple collections at the same time (or have multiple tags).
Collections could be be something in-between catalogs and tags. Think of it as sub-catalogs. (One way to implement this may be to add ability to promote tags. Promoted tags could then be viewed as collections inside of catalog.)

4. One photo source has multiple output photos (different corrections, edits...)
Keeping track of all outputs/derivatives and linking back to original source.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 386 Reply Likes

I can see how it might be useful to draw these distinctions - thank you for weighing in.

Regarding #1: Clearly having a jpeg sidecar that there is no way to "get to" (or get rid of) is one of those things that seems absurd to me. I mean, what's the point of having it in Lightroom if you can't see it, or do anything with it... - correct me if I'm missing something (I haven't shot raw+jpeg in some time, and when I did, I quickly changed preference to handle them independently, but I just did a quick-check...)

Regarding #2: Clearly some photos are merely constituents of a photo, and should not be thought of as photos in their own right, e.g. HDR. On the other hand, each member of a panorama could also be considered a photo in its own right. Now that I think about it, it could also be useful to think of HDR constituents as independent photos for some purposes. My point being that hopefully the design will not shut any doors (like raw+jpeg sidecar handling does now).

Regarding #3: This is where things get a little tricky for me. Perhaps it suffices to say I hope Adobe will think about this and come up with a slick solution.

Regarding #4: This is essentially the master/v-copy relationship right?


Photo of zigzag


  • 13 Posts
  • 2 Reply Likes
#1: Yep, exactly as you said it. There is currently no way to get to jpeg sidecar file. This is probably the smallest and easiest feature to implement.

#2: Simple solution to problem you mentioned here would be to select photos inside "panorama group" that you would like as independent photos and make virtual copies.

#3: Slick solution....I like how that sounds hehe

#4: Yes
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 386 Reply Likes
CustomMetadata now includes grouping features.

Its a far cry from what could be done natively, but is useful nevertheless.