Lightroom: Tree-based view of develop history for power-users

  • 8
  • Idea
  • Updated 8 years ago
  • (Edited)
My dream feature for Lr is to have a tree view of develop history rather than the linear view that it is now. The history for an image would start as a linear list like it is today. I could create branches off of the current step or any previous step. I could copy some or all develop steps from one branch to another. A step could be annotated either manually by me (e.g. "This is my latest but needs sharpening work") or automatically by Lightroom (e.g. "Printed on date X" or "Exported to Flickr on date X").

I understand that there are UI complexities here and probably problematic use-cases I haven't thought through but this would simplify or eliminate some problems I have:

- it would simplify the notion of virtual copies: they're just a branch. You could visualize where they were branched from though which is not currently possible.
- it would simplify (eliminate the need for?) snapshots - they're just a branch or at least a position on a branch.
- it would solve the problem for me of wondering what steps led me to a snapshot (i.e. current snapshots only retain a final state but they would be more useful to me if I could see what led to that state).
- it would clarify the current, confusing way that print and export events are embedded in the dev history.
- it would solve the problem of: I've created a virtual copy and refined that further than the original but now I need those refinements copied back to the original. Yes, cut and paste dev settings can do this now but I imagine knowing *what* settings to copy can be made easier with a visual UI here.

The analogy for this is version control in the programming world a la Subversion or Git but I think even non-techies with no experience with version control would still reap a lot of power and benefit from this.

Curious to hear thoughts on this.
Photo of David Burns

David Burns

  • 9 Posts
  • 1 Reply Like
  • excited

Posted 8 years ago

  • 8
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 135 Reply Likes
Snapshots are a branch, but VCs are more than a branch. You can add separate metadata to them.

Since Lightroom isn't dependent on the order in which actions are taken, I think the history panel isn't all that useful, and I support Dan's idea in another thread of a much-simplified view with all the adjustments to a particular tool condensed to one step. If exposure went from 0 to .54 to .46 to .33, I only need to know the .33 part since the two in the middle are completely irrelevant.
Photo of David Burns

David Burns

  • 9 Posts
  • 1 Reply Like
Lee - Good points. My thoughts:

- I'd forgotten that VC's are more than just dev history. I guess the problem I'd like solved then in this case is a way to somehow keep VC's in sync if I want to. Take the use case where I have an image with an 8x10 cropping and a 5x7 cropping. Any other dev changes I'd like to be kept in sync though without the current manual effort I do now.

- I hear you about the simplified view of dev settings only half-way (btw, don't we already have this view on the righthand panel?). By half-way, I'm referring to my usage pattern: I agree that once I'm "done" with an image, I may only care about the current state but there's a window of time where an image is "in progress" and I'm still interested in seeing the progression of changes I've made. These changes help me understand my thought process as I work towards a final image. I agree that in some cases, I'd like that list of steps optimized but not always. What I've just said seems like I support the current abilities where I'd create snapshots once I finalize a bunch of settings but I still see the value in having the ability to go back and see my steps. I think we definitely agree that, in either case, the current dev history panel is limited and could be improved.
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 135 Reply Likes
"Take the use case where I have an image with an 8x10 cropping and a 5x7 cropping. Any other dev changes I'd like to be kept in sync though without the current manual effort I do now."

I fully support this idea, but I had a different type of implementation in mind for it. Way better management of crops is high on my list of improvements that would shorten and speed up my workflow.
Photo of Mark Sirota

Mark Sirota

  • 146 Posts
  • 29 Reply Likes
Funny, I was just talking about this with a friend yesterday, thinking about how Develop history could work like a revision control system, for those programmers in our midst. Once you start down this road (or this tree, to be apropos) you pretty much want the whole kit & caboodle.

One of the challenges you didn't mention is that you might want to be able to do a merge of branches. I'm not a GUI source control user, so perhaps someone has solved this, but every mechanism I can think of is pretty ugly.

BTW, I think it does easily handle the snapshot concept quite elegantly, but not virtual copies. VCs can have different metadata too; unless you extend the history/tree concept to include that, then it's probably not realistic to fold the VC concept into this.

All that said, I think this is a "would be nice" kind of idea. If it were there I'd use it, but I can't imagine it getting anywhere near the top of my personal priority list. Given the complexity of the implementation and the other things I'd want before this, I'm not clicking the box.
Photo of john beardsworth

john beardsworth

  • 1118 Posts
  • 261 Reply Likes
I think the way forward here is to make history steps available via the SDK - with read only access - and then see what solutions pop up.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 385 Reply Likes
I'm tempted to give this reply a gold star for being one of the best points, except for the word *the* (implying mutual exclusivity in my mind). Unless plugins have thorough integration with Lightroom UI (e.g. context menus, non-modal, ...), I'd much prefer this be native.
Photo of David Burns

David Burns

  • 9 Posts
  • 1 Reply Like
Yeah, that was my feeling. I think this tree idea requires some deep UI tie-in. On the other hand, maybe one way to think of John's point is to define a new plug-in type called a 'develop listener' which is notified of any and all interaction with the dev history. That way the current Lr UI can stay put if the Lr team has too much else to do. But then they need to enable more powerful UIs for plug-ins.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 385 Reply Likes
I'm doubtful the SDK will get a complete overall come Lr4, but I'm all onboard for more plugin power (including support for develop listener / edit-history...). But my sense is that Adobe will need to develop native edit-history sophistication, before exposing it for additional plugin support. - All guess-work though... - Cheers, R.
Photo of john beardsworth

john beardsworth

  • 1118 Posts
  • 261 Reply Likes
I was simply thinking we could ask for a photo:historysteps() - something quick and dirty - not least because I really can't see Adobe going for a "power user" feature. Incremental progress rather than fundamental overhaul.

We're better off asking for SDK access to history steps allied to generic SDK enhancements such as the ability to add context menu items anywhere, or to launch a browser window within an LR dialog box. So here I would envisage someone would add a menu item to the history panel with whatever functionality is desired. For example, I'd like to send stuff to XML/XSL for display in a browser or even to go out to an Excel pivot table. But whatever.....

History enhancements that I think are more likely to have widespread appeal and therefore kick at an open door:
- make history searchable through smart collections (eg images with preset x was used)
- play history steps in navigation window and save output to movie
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 385 Reply Likes
I think there are tons of possible enhancements to the edit-history. And agree, Adobe is probably most likely to pick the lowest hanging fruit first. This is an ambitious FR, but at a minimum it should get Adobe thinking...

Bottom-line: yes - plugin support for edit-history would be welcome (even if relatively primitive), but that does not obviate the need for native improvements, in my opinion.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 385 Reply Likes
Good idea Dave - You got my vote.

Edit history is now one of my top favorite features in Lightroom, and this improvement, if Adobe could find a way, would indeed take a great feature into the realm of fantastic...

Even if branching was too much to ask for come Lr4, the annotations part would also be helpful, and a linkage/cross-reference to virtual copies & "snapshots" (which could be done as edit-history reference instead of saving an independent list of settings in effect at the time). PS - I use custom metadata to reference the point a virtual copy was forked from.
Photo of Photographe

Photographe

  • 243 Posts
  • 31 Reply Likes
Lee Jay, I don't support the idea of ditching the interim steps. Take masking. I might want to go back and retrace my steps. Even with simple things like exposure, I sometimes want to back to the way it was. Basically even though LR might not use the steps in order to create the final image, I sure do think of them in the order I made them. That said, I am sure that the history view could be improved. Do the develop actions taken while in the library transfer over to the History?
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 384 Reply Likes
"...Take masking. I might want to go back and retrace my steps..."

The suggestion is for those who want to, to be *able* to consolidate, once they are past the point where they anticipate going back to intermediate exposures, or crop values...

Those who would still prefer to see multiple intermediate steps, at least for the time being, would simply not consolidate - everybody wins...