P: Add Layers to Lightroom

[bcw99]

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

[Califdan]

Here's my 2 cents worth. I personally do not desire layers, per se' in LR. However I do desire a more robust targeted adjustment tool and the ability to retain PS layers. Let me explain:

1) I applaud the improvements to the targeted adjustment tool in LR4. Especailly the ability to target sharpening, noise and WB. What is now needed is some more options on the brush used for targeting to simulate some of things one can do with PS Layer Masks. e.g., something for "refine edge", perhaps a way to draw a line around the target area rather than painting with a brush, and something like the magic wand.

2 I posted this elsewhere but here it is again. If I edit in LR, then go to PS and add a layer for some reason the new PSD or TIFF file shows up in LR. If I just right click it and go right back to PS, my layers are still intact. However instead if I edit in LR then right click it to go back to PS my layers are all flattened. I'd like LR to not flatten out my PS layers but rather just add a new layer for the 2nd set of LR adjustments so that when I return to PS my original layers are still there.

Thanks

[areohbee]

Well said TK.

[bcw99]

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.

[FeedbackCommunityMember]

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.

[FeedbackCommunityMember]

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.

[TheDigitalDog]

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

[FeedbackCommunityMember]

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]

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

[FeedbackCommunityMember]

"[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]

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

[Lee Jay]

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

[FeedbackCommunityMember]

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

[TheDigitalDog]

You were thus suggesting that LR (kitchen knife) cannot be turned into something that supports layers (screwing in screws). This is incorrect.

No, I stated (didn’t suggest) one should use the right tool for the right job, I stated that given much time and money, “LR Pro“ could do everything all single Adobe App’s do today. I never said it was impossible. I said it was impractical and unnecessary. And a Kitchen Knife is a great tool... in the kitchen (I’m not knocking that specific tool).

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.

So you say, but it wasn’t here. What was stated is that there is limited engineering time and money to make a kitchen knife into a screw driver. Both tools exist. Just get one of each. Or maybe you subscribe to the $10,000 military toilet seat mode of software among other things.

The statement just says LR and PS are no different in how they need to change working copies.

I disagree in terms of the results of the processed data. I could care less about the original since I never alter the original data in either application (the old Save As point).

In the case of PS, nothing ever needs to be destroyed ever, as long as you keep inventing new names for every iteration.

So the adjustment layer that has to be flattened doesn’t alter the data? And if it does, you are saying there are no rounding errors which are destructive to the data?

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.

For the third time, the original data isn’t under discussion, it is what results from the original data! If you never want destructive edits of pixels, don’t edit them!

[FeedbackCommunityMember]

Lee Jay, your "very loosely connected to reality" comment is a stark exaggeration.

The only counterpoint you are making regards performance. Note that I mentioned "performance aside" or similar multiple times.

Of course there is is penalty for
a) recording user actions while they happen (negligible, though!) and
b) the need to replay all editing actions ever performed on an image.

However, there are optimisation techniques, such as caching. It is therefore not true that "all the operations have to be performed each time any operation is changed". As a very simple example, a change to an operation that occurs at same stage in the rendering pipeline does not need to retrigger any rendering stages before it as long as a cache of each stage is kept. Other optimisations (that may or may not slightly impact on previewing fidelity) are possible.

In summary, I do not accept your conclusion that the parametric approach excludes certain image operations because of performance considerations.

Furthermore note that certain workarounds users have to apply right now -- e.g., use fifty healing circles in a row to retouch a longish object -- are surely slower to process than a single healing application allowing the definition of a longish area (by brushing, by polygon, by an ellipse, ...).

P.S.: Final renderings will of course always require full re-renderings (i.e., imply the full sum of costs) unless enormous disk caches are used, but I believe most users care more about editing interactivity.

For those who cannot wait for their final renderings to finish there is
a) PS.
b) Bibble 5 which artificially limits the number of editing operations you can apply to an image. Hence, there will be a limit to rendering times as well.

[FeedbackCommunityMember]

Andrew, I don't think there is much progress, so I think it is time to not continue this discussion.

I feel that you have moved from your original "Educate yourself before you talk further nonsense" position that you confronted me with, but I do not see the value in exchanging further posts on the same subject.

Let me just quote something you wrote in your last comment: "Both tools exist. Just get one of each.".
My answer is "No, thank you."

If both tools cooperated to work on one object, I would agree with you. If I could use the screw driver to poke holes into a coconut in order to break it and then could use the kitchen knife to separate the edible parts from the shell, I'd get both tools.

However, the LR & PS situation is different. These tools do not work together on one image. They cannot be used in a collaborative fashion, achieving a non-destructive imaging (NDI) approach.

Whatever comes out of PS is different to what went into it. This means in LR we are dealing with at least two copies of an image. This does not support seamless NDI. This is not what I want. Hence I won't "get one of each".

If PS could be used as a rendering engine in the background while all management and editing control is exerted from within LR then I may "get one of each".

But then again, I don't need the full power of PS for e.g. better retouching support and/or few other additions. So why buy and use a super-duper-gianormous swiss-army knife (Photoshop) in the background to support a regular kitchen knife (LR), if it is more straightforward (and cheaper, and less demanding on the executing hardware) to add a tiny little bit from the super-duper-gianormous swiss-army knife to the existing kitchen knife?

[TheDigitalDog]

Andrew, I don't think there is much progress, so I think it is time to not continue this discussion.

That is a smart tact considering you ignore the points made, the questions asked of you but worse, and put words in my mouth such as “ Educate yourself before you talk further nonsense" or “ You were thus suggesting that LR (kitchen knife) cannot be turned into something that supports layers (screwing in screws).“

[Lee Jay]

"Of course there is is penalty for
a) recording user actions while they happen (negligible, though!)"

Actually, if you aren't quite clever and careful about how you do it, the metadata for that can easily grow to be larger than the image itself.

"However, there are optimisation techniques, such as caching. It is therefore not true that "all the operations have to be performed each time any operation is changed"."

Yes, it is, if you want the results to be an accurate reflection of how the image will look when exported, which I think is pretty critical to the editing process.

[FeedbackCommunityMember]

Andrew, I believe that "Educate yourself before you talk further nonsense" was a fair summary of your statements "That, like much of your post is incorrect and shows a huge misunderstanding of the processing." and "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.".

I purposefully didn't put the summary statement in italics because you didn't say it verbatim. I'd be very surprised if you were now seriously claiming that my summary does not reflect the message you sent with your actual statements.

And what were you intending with your "You can’t turn a kitchen knife into an effective tool to handle screwing in screws" analogy, if you weren't talking about LR and layers?

Your "get both tools" advice does not work in the case of LR & PS, but you chose to ignore my point.

Yet you accuse me of ignoring "points made". On the contrary, I put in effort to try and explain why your "points" don't make sense. Initially, you were very concerned about that LR does not alter data whereas PS does. After I refuted that point, you suddenly could not care less about originals. Your remaining point about precision ("rounding errors") could be easily refuted as well. Could, if one had the patience. Excuse me for having ran out of patience.

Please, try to use your Adobe contacts and ask them whether anything I've written is wrong. I understand you talk to the public about Lightroom and other Adobe products, so it would be good for you to spread the correct facts, not to tell those who have a correct understanding that they have a "huge misunderstanding" and need to read some white paper.

[FeedbackCommunityMember]

I fear the current way of storing metadata in LR is not very clever (catalogs compress enormously using simple WinZip and that's not even exploiting a lot of redundancy in catalogs). With reasonable cleverness applied, metadata should not outgrow image data. But I think we agree on this point.

We also agree that the Develop module preview should be an accurate reflection of the final result. Yet, we both know that this is not the case for LR3 (noise reduction and yellow/orange highlight rendering). LR4 may have improved things, but there is certainly a precedence for a "good enough" approach.

Furthermore, either you edit at "1:1" magnification at which point you don't need to render all of the image (thus saving time), or you edit with less magnification which makes it possible to take certain shortcuts as some details won't be visible unless you look at them at "1:1" magnification (or higher).

Finally, note that "good enough" need only apply for the time it takes to generate the next best approximation of the preview. Remember, you agreed with Rob Cole's suggestion?

[Lee Jay]

That comment applied to noise and sharpening, not local adjustment which need to be accurate as you lay them down.

[FeedbackCommunityMember]

First, I don't understand your point. The local adjustment won't be accurate if the underlying noise reduction and sharpening isn't accurate. The latter are examples for shortcuts taken in order to gain performance. Whether they affect the image on a global or local level does not seem to be relevant.

Second, where is the problem of achieving performant local adjustments? It is just like using a layer in Photoshop with a layer mask. I don't see why you regard local adjustments as a challenge.

[bcw99]

Cough...

I've just had a look at AfterShot/Bibble and that seems to use layers for adjustments......

[teosax]

I just downloaded perfect layers for lightroom.
I find this little plug in amazing, for the ease of use and the power and possibilities it offers
1 thing though is lacking, and i think if lightroom would finally come out of the box and give us such an important tool would be AMAZING!!!

Having the possibilities to work with 2 different pictures like in perfect layers, but at the same time being able to change for each picture any slider of the develop tool.

this function i think would really give to lightroom an edge to any other program out there, and give to user such a huge control and great way to improve quickly images, without the tedious way to have to work the image in an external editor like photoshop

PLEASE
PLEASE

[FeedbackCommunityMember]

In addition to the resize option I mentioned earlier, I would like to see an overlay option so that I can combine two photoes.

[Guest]

I recently replaced our Express Digital Software package that we used to organize, show clients, sell, and print from with Lightroom 3. I has been wonderful. The one thing that it does not have is the ability to do quick collages with a overlay. Do you think Lightroom will be able to import files with transparencies and/or do layers. This would give a studio the ability to create cards and collages quickly. We are in the process of creating a training video directed at the professional portrait studio on how to use Lightroom in the studio.