Skip to main content
Known Participant
August 23, 2011
Open for Voting

P: Add Layers to Lightroom

  • August 23, 2011
  • 97 replies
  • 11684 views

I've seen a plugin that adds layers to LR which would save a lot of to-ing and fro-ing to Photoshop. The plugin is actually stand-alon, but also integrates with LR to some extent. It allows many of the layer options found in Photoshop. Not tried it but seems like a cracking idea! 🙂

Making LR more of an editor could make Photoshop redundant for pure photographic work

97 replies

Inspiring
January 31, 2012
"Who said otherwise?"
You wrote earlier: "You can’t turn a kitchen knife into an effective tool to handle screwing in screws".
You were thus suggesting that LR (kitchen knife) cannot be turned into something that supports layers (screwing in screws). This is incorrect. One may not want layers in LR for several reasons, but it is not a case of changing a tool against its nature.

BTW, AfterShot Pro (formerly known as Bibble5) demonstrates how layers can co-exist with parametric editing.

"Myth?"
The perceived chasm between "pixel pushing" and "parametric editing" is often used to explain to people that LR cannot do things that PS can do. Even quite prominent figures who associate themselves with Adobe would have you believe that for instance retouching will never be part of LR because only a "pixel pushing" program like PS can "push pixels" whereas LR is a parametric editor and that one really needs to understand the difference between the two fundamentally different image editing paradigms.

"I took umbrage with something you wrote quite clearly:"
You take umbrage, because you are reading something into it that I didn't write. In my statement (you take issue with) "Here's how Lightroom is destructive just as Photoshop is: For instance, when you clone one area over another, the target pixels get destroyed."
a) the "target pixels" (that get destroyed) are of course not the pixels of the original. In both LR and PS, the target is a working copy.
b) you can replace "destructive" with another term if you like. The statement just says LR and PS are no different in how they need to change working copies.

All my statement, you take issue with, is saying is "If you call PS 'destructive' you can call LR 'destructive' as well since both have to 'push pixels' in working copies. I'm effectively trying to say that the issue with PS is not that it is "destructive" (it isn't if you don't saver over originals), the issue with PS is that it is "non-remembering" (in the sense of not being able to replay edits on demand). I hope that is clearer now.

>If you do not save over the original what gets destroyed?

"In the case of Photoshop, the iteration. In the case of LR, with raw data, nothing."
In the case of PS, nothing ever needs to be destroyed ever, as long as you keep inventing new names for every iteration. Again, the issue is not destruction. The issue is the ability to replay edits.

BTW, whether the original is RAW or not is irrelevant. In either case LR does not overwrite original image data. In either case PS need not overwrite original image data.

"If you edit that rendered data in Photoshop, then yes, there can and is some data loss.". Again, no rendered data ever needs to be destroyed / lost.

The only thing that gets lost when editing in PS vs LR are the editing actions. The latter are stored as editing instructions as part of the metadata in LR. They are lost in PS. That is the only fundamental difference.
Inspiring
January 31, 2012
"So this is my point: The only significant difference between the "non-destructive" vs "destructive" paradigms are that you keep editing instructions in the former case but not in the latter."

I would argue that that point is very loosely connected to reality. In one case, you only have to apply one operation at a time, and thus the performance of the application is dependent largely on the performance of EACH operation. In the other case, all the operations have to be performed each time any operation is changed, thus the performance is dependent on the performance of the SUM of all operations. Secondly, in the destructive case, you need not turn each operation into a set of instructions (a "recipe"), but can instead apply them as you go, such as while using a brush or the liquify tool. In the non-destructive case, you have to convert every motion or brush stroke into metadata that can be applied later as other settings are changed. These are quite fundamental differences that definitely limit what each method is capable of accomplishing.
TheDigitalDog
Inspiring
January 30, 2012
>>My point was to destroy the myth that is based on the assumption that "pixel pushing" and "parametric editing" are so fundamentally different that "pixel pushing" supports certain operations that "parametric editing does not".

Who said otherwise? Myth? I took umbrage with something you wrote quite clearly:

Here's how Lightroom is destructive just as Photoshop is: For instance, when you clone one area over another, the target pixels get destroyed. Ouch!

>If you do not save over the original what gets destroyed?

In the case of Photoshop, the iteration. In the case of LR, with raw data, nothing.

>The only difference: LR uses metadata to remember how to "push"/"destroy" those pixels in the working copy again.

The original data is unrendered raw data. There is nothing to destroy. If you edit that rendered data in Photoshop, then yes, there can and is some data loss.
Author “Color Management for Photographers" & "Photoshop CC Color Management/pluralsight"
Inspiring
January 30, 2012
"[The preview] is a proxy generated from the original data. How do you explain that the preview is the raw data?"
I never stated that the preview is the raw data. I only said, the preview is rendered from the raw data, just like any other output.

"No, I think you are still contradicting yourself because the original data in this case of a raw is always left untouched."
I never said or implied that the original data is ever touched.

I always said that changes are made to a "working copy".

"To say that applying a clone stamp as a metadata instruction in LR destructive and the same in Photoshop where one app takes the raw data and the instruction and renders virgin pixels from the two, and suggesting the same is true in a pixel editor is a poor way to describe the differences in the processing and resulting data."

I did not attempt to wipe away any differences which are clearly there. My point was to destroy the myth that is based on the assumption that "pixel pushing" and "parametric editing" are so fundamentally different that "pixel pushing" supports certain operations that "parametric editing" does not. My point was that using terminology like "destructive" and "pixel pushing" are poor ways of suggesting that Photoshop does something that LR does not do. They both, by necessity, need to "push pixel" (destroy pixels). The question is just
a) do you write the result over the original, and
b) do you keep a record of how the user "pushed pixels" so that you can do it again?

Since Photoshop allows not writing over the original, it need not be "destructive" in terms of "a)". The only aspect in which PS really differs is regarding "b)" for some operations. Other operations (like adjustment layers) are as non-destructive like LR.

So this is my point: The only significant difference between the "non-destructive" vs "destructive" paradigms are that you keep editing instructions in the former case but not in the latter. Hence one paradigm cannot be fundamentally limited compared to the other (leaving performance aside).

"IF you want to say that non destructive editing is such that the original is left untouched, without taking the iterative data into the discussion, you can say we’ve had non destructive editing in every application ever made, since computers have provided a Save As command."
If you do not save over the original what gets destroyed? Let me quote from the document by Peter Krogh you pointed me to: "NDI has always been achievable by simply saving the file as a new file, once adjustments were made. By preserving the original file in its original state, the user is free to make additional derivative files without compromising the integrity of the source image.".

"When you take raw data and instructions, you render data for the first time. How then is this destructive?"
It is not destructive w.r.t. the original data. But if you do not save over the original data in PS, there is no destruction either.
It is destructive in the sense that in the working copy of the image used in the rendering pipeline, pixels need to be "pushed"/"destroyed". Just like in PS. The only difference: LR uses metadata to remember how to "push"/"destroy" those pixels in the working copy again. PS doesn't. You either save the working copy as a new file or save over the original.
TheDigitalDog
Inspiring
January 30, 2012
>As far as previewing is concerned, the data used for creating the proxy preview is the "actual data".

It is a proxy generated from the original data. How do you explain that the preview is the raw data? Clearly it isn’t. It was generated from that raw data source as a proxy preview, based on the current rendering instructions. And that preview (depending on the module) is a low rez version simply used to show you the current state of what the rendered data might look like IF you render it.

>Rest assured I understand the difference between rendering a preview and rendering a final output file.

Good. Because it is the rendered data we all end up with (whether we send it though the print module, ask for it to end up on the web, or export). There IS an option to print the data from a existing preview if you want to get precise here (Draft Mode Printing).

>>However, you should have just included the part that followed the quote you truncated: "... in the true sense of the word when you don't save over your original but always keep inventing new names for your image versions."

No, I think you are still contradicting yourself because the original data in this case of a raw is always left untouched. I’m referring to the rendered data. To say that applying a clone stamp as a metadata instruction in LR destructive and the same in Photoshop where one app takes the raw data and the instruction and renders virgin pixels from the two, and suggesting the same is true in a pixel editor is a poor way to describe the differences in the processing and resulting data.

IF you want to say that non destructive editing is such that the original is left untouched, without taking the iterative data into the discussion, you can say we’ve had non destructive editing in every application ever made, since computers have provided a Save As command.

With an Adjustment layer, the data (source) is non destructive. And the iteration is too, until you flatten the layer (or print the data). 99 times out 100, that has to happen. You started with exiting rendered data, you edited that data. There is some data loss due to rounding errors (we can agree that it is moot but the facts of the resulting data are what they are). When you take raw data and instructions, you render data for the first time. How then is this destructive?

>>In my initial comment, I was using "destructive" as many use it in this context. Later on, in a different comment, I remarked that "destructive" is a problematic term.

Yes, it is. Especially when one doesn’t separate the original data from the derivative.
Author “Color Management for Photographers" & "Photoshop CC Color Management/pluralsight"
Inspiring
January 30, 2012
Andrew, what is the "actual data" you are talking about? As far as previewing is concerned, the data used for creating the proxy preview is the "actual data". How do you think that proxy preview is created without "destroying" some pixels? Of course, the "destruction" only affects pixels in a working copy, so no harm done.

Rest assured I understand the difference between rendering a preview and rendering a final output file. What you do not seem to understand is that both preview and final output need to be rendered (using the original data + metadata).

I have looked at the Adobe White Paper (URL above) by Peter Krogh. Where does what I have written contradict anything Peter Krogh writes? There is no contradiction. Again, I challenge you to get someone from Adobe to support your position that I have written something that is incorrect.

You quote me with "The term "destructive" is somewhat inappropriate in discussions like these because even pixel editors like Photoshop are not "destructive" ..." assuming that I'm contradicting myself. However, you should have just included the part that followed the quote you truncated: "... in the true sense of the word when you don't save over your original but always keep inventing new names for your image versions." In my initial comment, I was using "destructive" as many use it in this context. Later on, in a different comment, I remarked that "destructive" is a problematic term. Again, I do not see the problem you are seeing.
TheDigitalDog
Inspiring
January 30, 2012
>>The preview, i.e., the image you see in the Develop module, is the result of a sequential application of changes to a working copy.

It is a proxy preview and has no direct bearing on the actual data which as yet has not been edited (let alone, as you incorrectly point out, have an destructive edit applied). You’d do yourself some good, save the rest of us some time if you would read the Adobe White Paper (URL above) by Peter Krogh. You don’t need an engineer here, the paper was produced by Adobe and written by an authority on the subject.

>The term "destructive" is somewhat inappropriate in discussions like these because even pixel editors like Photoshop are not "destructive"

And yet today you wrote:
Here's how Lightroom is destructive just as Photoshop is : For instance, when you clone one area over another, the target pixels get destroyed. Ouch!
Author “Color Management for Photographers" & "Photoshop CC Color Management/pluralsight"
Inspiring
January 30, 2012
Andrew, you write "There are no pixels affected until you render the data". That is incorrect, since obviously the preview is an image made of pixels as well.

The preview, i.e., the image you see in the Develop module, is the result of a sequential application of changes to a working copy. The initial working copy is a copy of the original (e.g., demosaiced RAW image), or a smaller version of it.

Of course, when you export an image in LR then the rendering starts afresh with a certain target size, etc. But obviously the preview is just another form of rendering (in LR3 the preview sometimes omits noise reduction but that doesn't change the overall principle).

The term "destructive" is somewhat inappropriate in discussions like these because even pixel editors like Photoshop are not "destructive" in the true sense of the word when you don't save over your original but always keep inventing new names for your image versions. Assuming you do that, the only remaining difference to parametric editing then is that a parametric editor can replay edit actions, should you decide to change parameters, remove some earlier edit actions, etc. That's where you non-parametric editor gets stuck. You can revert to an older version of your image, but you cannot replay the edits that followed with different settings or replay a subset of them only. Since a parametric editor can replay all edits, it does not need to keep intermediate copies; it just keeps starting from the original, replaying all edits.

Andrew, there is no "huge misunderstanding of the processing" on my behalf. I challenge you to get an ACR programmer to state that what I have written is wrong. I'm a software engineer and I know how this stuff can be programmed.

Please be more cautious with your judgment.
Inspiring
January 30, 2012
Andrew, I posted a reply to your inappropriate criticism below.

P.S.: I looked at the "non destructive imaging" document you linked to. Where does it contradict anything I wrote? It even explains that Photoshop's adjustment layers are an example of non-destructive editing, just as I used the term "adjustment layer" when I talked about conceptual layers in the LR rendering pipeline.
bcw99Author
Known Participant
January 30, 2012
I've been caught out by that too Dan. When you return to LR from PS, the file retains its layers as it is now a photoshop bitmap file. But if you make adjustments to it in LR, it has to create a further flattened copy for its adjustments to work on.

If you then elect to edit it further in PS you will be exporting a LR file not the PSD version with layers. You can always elect to "edit a copy" which will retain the layers but will loose those last LR adjustments.

For other reasons too, I think the workflow should be such that bitmap editing is the final stage.