Since Lightroom is so good, what do you use Photoshop for?

Started 8 months ago | Discussions thread
ttbek
Senior MemberPosts: 1,493Gear list
Like?
Re: Actually . . . .
In reply to MiraShootsNikon, 7 months ago

MiraShootsNikon wrote:

ttbek wrote:

MarkJH wrote:

ttbek wrote:

MiraShootsNikon wrote:

Ron AKA wrote:

MiraShootsNikon wrote:

Ron AKA wrote:

Dave Stott wrote:

This is a strange dialogue. Lightroom doesn't alter pixels 'cos a RAW file doesn't have any pixels. ACR likewise doesn't create a pixel based file till you exit it.

A RAW file has to have pixel data. That is basically what it has captured from the pixels in your sensor. Just look at the metadata for a RAW file, and it will tell you the height and width in pixels, and total pixels. What it doesn't have is a physical dimension such as inches. So there is no resolution in pixels per inch, just dimensions in pixels.

RAW processing is the business of assembling groups of red-green-blue pixel data from your camera's sensor into single pixels of a given color.

I think we said the same thing. My only point was that the RAW file contains pixel data. All the rest is very interesting, but not relevant to the point that the camera sensor captures pixel data, and the RAW file is a digital recording of it.

No. We are not saying the same thing.

You seem to think Bayer RAW "pixel data" and interpolated raster "pixel data" are basically the same idea or concept. They aren't. You're talking about entirely different kinds of pixels employed for entirely different purposes, manipulated in entirely different ways.

It's not "irrelevant" that Bayer RAW data, if you could "see" it, would look nothing like an interpolated raster image. It's not "irrelevant" that the tools one might use to manipulate such different kinds of data work differently, produce different results, for different reasons.

You're caught up on the word "pixel," here, and choosing not to see the forest for the trees. Your argument is essentially this: "Any language that uses the roman alphabet is really just the same language. It's all just letters."

Actually... you seem to be under a misconception MiraShootsNikon. While it is true that the RAW processors interpolate the RAW data, this is done as the very first step. So essentially, step one is to take any language using the Roman alphabet and translate it, after that it's all the same language and worked with the same way. In other words, they do end up being manipulated in exactly the same way with differences being only in that first interpolation step, which I have not seen any RAW developer expose any user adjustable options for. Dave Stott is a bit off the mark, RAW editors do not create an image file until exported, but they do keep a rasterized intermediate file in RAM which is what all the manipulations occur on that is based on as you say "interpolated raster pixel data." So yes, lightroom does alter pixel data, just not of the source (and neither does any other program as long as you don't overwrite your original file). If you don't believe me you can go look at the source code of some of the open source RAW converters (and yes, I am quite sure the closed source ones are not doing things drastically differently).

But I think, ttbek, that you aren't giving Mira enough credit. For two reasons:

(a) Her original post, above, did observe that both Lightroom and ACR generate a raster preview that reflects changes made as users employ them; and

(b) your post *assumes* that proprietary converters don't perform operations any differently than the open source code you've seen--but if that were true, then proprietary conversions wouldn't look so much better than most of the open source conversions I have seen!

If you're going to say that I would like to see actual examples. Also, when I say it's not drastically different, I mean the methodology, not the fine tuning. I'm curious just which programs you are referring to and if you're dealing with the Bayer interpolation step, or what happens after.

Samples wouldn't have much to say about the fact that you're using knowledge of free code you have seen to describe the workings of proprietary code you haven't.

Open source is not the same as free, they coincidentally go together often though. The writer's of open source code are very often programmers that know how it is done in the industry standard. It is generally believed that AHD demosaicing is the standard in many proprietary cases (in camera and likely in say, ACR). While AHD is standard, it is not considered one of the best algorithms.

Also, it's pretty easy to see how distinctly different RAW converters approach their job: we have examples in every single DPReview camera overview, in which they show us the differences (at 1:1) between results from the reviewed camera's OEM converter and Adobe.

Different results does not indicate a fundamentally different approach. All anyone is really doing in this step is deciding the best way to weight colors based on proximity and in some more advanced algorithms on image characteristics like edges. It doesn't make sense to re-weight colors differently when someone decides they wants to adjust, say, white balance. It also doesn't make any sense to have that portion of the code be pervasive when it would need to all be redone for almost every camera that way. It is not readjusted to account for later changes and is almost the very first step. In doing some poking around I found a program will allow adjustment of the demosaicing, e.g. Darktable allows use of PPG or amaze and allows adjusting the edge threshold, color smoothing, and if and how to match greens.

To see just how much difference there is only among some of these algorithms (with not retroactive adjustments based on anything applied later) see this site (scroll to the bottom): http://www.linuxphoto.org/html/test_demosaicing.html

Frankly, I don't believe it that Lightroom or ACR work as you say--that they make a raster conversion and then simply push the pixels of that conversion according to your edits. And here's my evidence: if what you say were true, then Lightroom's heal / clone operations could look identical to those from Photoshop. But Adobe has gone on record many times saying that Lightroom's clone-heal operations are limited to what they can currently process from RAW interpolation. They aren't in other words, simply pushing pixels on a raster intermediate. Sure, that's what's happening with the preview you see in the program itself, but when you export, your changes are actually baked straight from a novel RAW interpolation.

I was going to write a second post addressing things like this. There are portions of RAW converters that rely on extracting more of dynamic range, etc.. which isn't your standard jpeg format. For reasons like this a RAW converter needs to preserve it's order of operations (operations are actually applied in one order, not matter which order you chose to apply them in), which in turn means that there are limitations on things like cloning. So, yes, I wrote that first post hastily. Things like changing exposure will grab info from the RAW differently (but does not change how they do the Bayer interpolation). Other things, like sharpening, will be basically identical in both programs. If that last part you said were true, then what you see and what is exported would have greater differences than they do.

What's interesting, to me, is that you acknowledge that there is a difference between the working Lightroom / ACR preview and the raster export. Your explanation of how these tools work makes most sense only if there is no difference, because you are essentially arguing that the working preview is the final conversion.

It is almost the final conversion, they apply the transformations only to the working area and downsize to viewing size for speed (hence why there are options for interpolation of the preview). Other than that though there is pretty much no difference.

Now, I do understand that the "RAW intermediate held in RAM" you describe would supposedly differ from the ACR / Lightroom preview in the sense that the preview is a JPEG

The preview needn't be jpeg, in fact it's unlikely that it would be jpeg, it's also unlikely that it's compressed, since that would only serve to slow down a file we're actively working with.

with a compression / render quality you can control

as far as I know you can change the render quality, not compression

, while the "RAW Intermediate" you describe would presumably not be a compressed JPEG. But I don't want to make your argument for you--maybe you'd say that it is.

Nope, definitely not. If you were referring to an intermediate for print, it would probably be a bitmap, though different printers support different formats.

http://www.cups.org/doc-1.1/sam.html#2_5

However, your suggestion that there are limitations on how Lightroom / ACR might push this "RAW Intermediate's" pixels with cloning / healing because of the "order of operations" sounds pretty vague, to me. Like you're reaching, ya know? Because if there's a bit mapped image in RAM full of full-color pixels ready to be manipulated, then we really should have every Photoshop clone / heal / patch option and all of those tools' quality available in Lightroom. Unless Adobe is justly lying / bull$hitting us for some bizarro reason.

I really think MarkJH sunk your battleship with that one, dude.

I think MarkJH needs to be a bit more clear about exactly what he's referring to so that I can tell if Adobe is BSing him or not. Now, if he's talking about what I think he's talking about then it could be because of the order of operations, and also that LR goes about the whole thing in the form of: original + all the stuff to do to it. When storing that list it's easy to do it as a set of parameters (source, destination, size, etc..) that lacks the nuance of what's available in PS. Also, since these are all reapplied when generating the preview if you want cloning one spot to another, and then cloning the cloned area to another spot, then each clone would need to be applied in order, whereas my guess is that LR would want to do them in parallel for more speed. Going back to the order of operations, there are definitely potential conflicts that may arise because of the fixed order. Suppose that applying an increased exposure on a gradient always occurs before the cloning. You do some cloning, then you set your gradient and suddenly there is a bright area on the spot you cloned to because of where these two points are relative to the gradient. The reason in MarkJH's post, "But Adobe has gone on record many times saying that Lightroom's clone-heal operations are limited to what they can currently process from RAW interpolation," does sound like BS to me, no idea if it's Adobe's or MarkJH's BS, but it does seem like BS. That's not to say that Adobe doesn't have some decent reasons, I just don't believe that's one of them. Also, Adobe has a very obvious reason to lie or BS about this... they would still like photographers to actually want PS for some things. It is to their advantage for people to buy both products. Now, if you don't believe me that the order of operations exists in this way, it does, and for many programs like this, not just LR.

Another possibility that this hints at: http://helpx.adobe.com/lightroom/kb/performance-hints.html is that they may be doing their clones even before demosaicing in order to reduce things like rounding errors, in which case their statements would make more sense... that or they have errors from buggy code... which is actually the more likely case here.

From the Darktable FAQ:

  • "How do I change the order in which modules are applied to an image? You don't. The order of the processing pixel pipeline is fixed and supposed to "just work". If you have a (valid) use case where the order doesn't work feel free to tell us. And if you really want to know the reason why this is fixed you may want to have a look at the output SVG of tools/iop_dependencies.py"

Some discussion of it for LR on DPreview: http://www.dpreview.com/forums/thread/3234180

Some more here, which also covers clone a bit, apparently it's an oddball in LR: http://www.luminous-landscape.com/forum/index.php?topic=73201.0

Technically cloning could be put into LR the way it is in PS, but there are a number of caveats like those that I mentioned. An additional order issue was brought up in that last link with respect to cropping.

 ttbek's gear list:ttbek's gear list
Canon PowerShot SX10 IS Nikon Coolpix L3 Canon EOS 5D Samsung NX300 Canon EF 28-135mm f/3.5-5.6 IS USM +9 more
Reply   Reply with quote   Complain
Post (hide subjects)Posted by
(unknown member)
(unknown member)
Keyboard shortcuts:
FForum PPrevious NNext WNext unread UUpvote SSubscribe RReply QQuote BBookmark post MMy threads
Color scheme? Blue / Yellow