Lr4 Feature Request: 100% Integration With Destructive Editors

Status
Not open for further replies.

areohbee

Former Member
Joined
Sep 18, 2008
Messages
109
Location
San Francisco CA/USA
The problems with round-tripping:

- extra storage required
- extra file to manage
- extra complications in workflow due to forking disjoint and non-recreateable (destructive) edits.

I always do the same set of things when I export for external editing:

- save a snapshot of the state going in.
- then upon return, add custom metadata that references the base snapshot, and describes what was done destructively, so I could return to the destructive app for redoing that step later, if desired.
- The destructively edited version is floated to top of stack.

It just occurred to me that there is really no reason Lightroom couldn't be 1''% integrated with destructive editors,
easing me from manual file management and destructive change tracking... I mean other than a bunch of time and effort...

Regarding the extra storage required for intermediate files:

- Nothing we can do about that, except have a checkbox for whether you want your intermediate file compression lossy (jpeg) or lossless (tif).

Regarding the extra file management:

- Have lightroom do, automagically, all of the things I've been doing manually, namely:
- hide the base / intermediate files - like it does now for sidecars.
- automatically save a snapshot going in.

and perhaps most importantly:

- Adobe would need to invent a 3rd party settings interface, so applications like pt-lens could be re-invoked with the previous settings for fine-tuning.
- user could always make textual notes as a substitute for applications that have not yet been enhanced to support lightroom's external settings interface, or to supplement for cases where complete recreation of destructive edits is just not practical.

Of course, these settings and/or notes would be stored in the catalog, and seeable in the history list, and included in xmp...

If the Adobe Lightroom Team did this, then everyone could have all the things they want in Lightroom editor-wise, assuming there is a third-party app that supports it, albeit not as smoothly as it would be if implemented natively in Lightroom, but more smoothly than a round-trip is now. Adobe could then incorporate native / parametric support for various things at their leisure, for example, lens / perspective corrections.


PS - I realize there is a hitch in this: that local adjustments may no longer "line up" after external editing. This could be solved in Lr5, and left unsolved in Lr4 with a warning, or whatever. It would still be worth it.

PPS - I also realize that all of this could also be accomplished by exposing image data in the pipeline directly to imaging plugins, and then making the plugin interface photoshop compatible. I'm guessing that would be much harder to integrate into Lr4, but we may see it in Lr6 or Lr99... - I'm proposing an interim solution.

Rob
 
Can you imagine how many other programs they'd have to make it compatible with? And how many times it'd break? They don't even attempt to do that with PS! I think you'll be waiting a while, as they have a few more priorities to deal with first, but by all means add it to their feature request database using Official Feature Request/Bug Report Form
 
[quote author=Victoria Bampton link=topic=9536.msg64294#msg64294 date=127'973548]
Can you imagine how many other programs they'd have to make it compatible with?
[/quote]
I was suggesting that Adobe define an interface, such that other vendor's destructive editors could start-up with the same settings they finished with last time. Then any vendors who wanted to put "implements Lightrooms non-destructive editor interface" on their list of good things would just implement that interface. In fact, they already do something very similar for Photoshop plugins - for example, one can record a Photoshop action that remembers Topaz Adjust settings - that's because the Topaz Adjust Photoshop Plugin implements the "actions interface" defined by Adobe for Photoshop plugins. So the responsibility for implementation and testing rests on the destructive editor vendor.

Because that interface does not yet exist, I make notes in metadata that include all the settings I used in a particular non-destructive editor, for example if I correct motion blur in focus-magic I always put the radius and angle in a custom metadata field, in case I realize further on down the road that I over corrected - then I can go back into focus-magic, and enter the same settings, then tweak, and re-save. My suggestion is to have Lightroom remember those things so I don't have to, similar to the way they do now for Photoshop plugins that implement the "actions interface".

Does that make it clearer, or more confusing?!!@#$%^&*()_

I suspect Adobe has already thought about this, but I will submit it directly to them, if it still seems to make sense after it percolates on this forum for a while.
 
Yep, that makes more sense. That said, can you imagine how much that'll add to the database, which Adobe then have to protect, upgrade, etc., considering the number of different fields you'd need for all of the different programs? Photoshop only has to store it once per action - it can't do it per image.

Some kind of sidecar file specific to the third party editor with their own settings might be a solution - that the third party editor looks for its settings sidecar when a file is opened, although, I guess they could already do that without any involvement from Adobe, couldn't they?
 
can you imagine how much that'll add to the database
- Have you ever seen how much information is already stored in the database to maintain your brush strokes? - This would be a drop in the bucket. Still, if it made more sense to store it external to the database I wouldn't complain.

they could already do that without any involvement from Adobe, couldn't they?
- Although to complete the job as I'd like to see it done, Lightroom would have to get in the loop, you've got a good point - maybe I should contact epaperpress(PTLens) and request a feature to them too.
 
Status
Not open for further replies.
Back
Top