Luminous Landscape Forum
Raw & Post Processing, Printing => Adobe Lightroom Q&A => Topic started by: NikosR on April 30, 2008, 04:17:25 am
-
I'm posting this here as it seems it is the most popular raw converter forum in this site but I guess it is applicable not only for Lightroom but pretty much every other raw converter out there.
The trend in the last few years has been to enhance raw converters with lots of functions to make them pretty much universal and flexible tools for the digital potographer. I certainly believe this is a good thing in principle, although opinions will vary as to how much functionality a raw converter program must have before it becomes too bloated.
However, what bugs me is that, in adding image processing capabilities to their programs, developers have not made a comprehensive attempt at clearly separating (or indicating and documenting for that matter) functions that are applied to the raw (un-demosaiced) data from ones that are applied to de-mosaiced RGB data (or bitmaps). Furthermore, I have noticed no effort in indicating which functions are applied on linear or gamma-corrected data.
To make what I'm saying a bit clearer, I'll give a few examples applicable, I think, to most converters out there:
I believe that functions like EV compensation, WB adjustment, highlight recovery are functions that operate on raw data. In contrast, things like curves, most colour corrections, vibrancy or local contrast adjustements probably operate on de-mosaiced data and, as such, they are not different in principle than equivalent adjustements that can be performed on a TIFF file with an external editor (workflow considerations not withstanding).
Furthermore, there seem to exist some functions, notably noise reduction which could be made to operate on either raw or demosaiced data with arguably different capabilities and quality of output in each case.
I would like raw converter developers to clearly indicate, both through the workflow implicitly imposed by their program and through clear documentation where exactly in the image processing pipeline a function is applied. That would help me make more educated decisions about which, internal or external, tools to apply and when.
Am I the only one to be, slightly, frustrated with this situation? Do you think what I'm writing about is only of philosophical interest and I'm just moaning too much?
-
It's my understanding that the colorspace in ACR is a combination of Prophoto gamut in a linear space.
-
Am I the only one to be, slightly, frustrated with this situation? Do you think what I'm writing about is only of philosophical interest and I'm just moaning too much?
[a href=\"index.php?act=findpost&pid=192627\"][{POST_SNAPBACK}][/a]
Yeah, pretty much...
In the case of Camera Raw/Lightroom Thomas and the Camera Raw team simply won't say EXACTLY how the processing pipeline works, why should they? It's proprietary information and disclosing it may help a competitor.
Regardless of what is being done pre or post demosaicing, everything in CR/LR _IS_ being done in linear gamma except the final output to a color space. As a result, the processing pipeline is optimal and the functions superior in the pipeline to opening the image in Photoshop for post color encoded processing.
Do you REALLY want to know what ingredients are in the sausage you're eating? Are you sure?
:~)
-
Those who are interested in learning the basic DNG processing model are welcome to read the DNG spec (chapter 6) as well as download the free DNG SDK and look at the code.
That said, from a practical perspective I don't see how knowing this information really buys the photographer anything ... at least for the photographer who just wants to get good results. For example, I could tell you that color matrices are applied before the tone curve, but how that info would help you get better pictures is not clear to me.
-
I believe that functions like EV compensation, WB adjustment, highlight recovery are functions that operate on raw data. In contrast, things like curves, most colour corrections, vibrancy or local contrast adjustements probably operate on de-mosaiced data and, as such, they are not different in principle than equivalent adjustements that can be performed on a TIFF file with an external editor (workflow considerations not withstanding).
Furthermore, there seem to exist some functions, notably noise reduction which could be made to operate on either raw or demosaiced data with arguably different capabilities and quality of output in each case.
I would like raw converter developers to clearly indicate, both through the workflow implicitly imposed by their program and through clear documentation where exactly in the image processing pipeline a function is applied. That would help me make more educated decisions about which, internal or external, tools to apply and when.
Am I the only one to be, slightly, frustrated with this situation? Do you think what I'm writing about is only of philosophical interest and I'm just moaning too much?
[a href=\"index.php?act=findpost&pid=192627\"][{POST_SNAPBACK}][/a]
I agree with Jeff and Eric. There is no situation to be frustrated with. If my understanding is correct, ALL the editing done is ACR consists of instruction sets which tell Camera Raw how to render the file into a three channel pixel-based, gamma-encoded image [while the raw file remains intact with the (changeable) instructions in an XMP file]. The instructions are non-destructive within Camera Raw because no permanent changes are being made to any data. You can make certain changes in Camera Raw which can't be made nearly as easily in Photoshop (White Balance comes to mind as an example; I also have an unproven impression that the Parametric Curve allows Curves shapes and effects which don't exhibit exactly the same kind of luminosity trade-offs which exist in a Photoshop Curve.) Be happy for all that we can do in Camera Raw and keep wishing for more to come. It's great stuff whatever the secret sauce - hasn't burned my fingers yet!
Mark
-
However, what bugs me is that, in adding image processing capabilities to their programs, developers have not made a comprehensive attempt at clearly separating (or indicating and documenting for that matter) functions that are applied to the raw (un-demosaiced) data from ones that are applied to de-mosaiced RGB data (or bitmaps). Furthermore, I have noticed no effort in indicating which functions are applied on linear or gamma-corrected data
I fully agree with this resentment. The raw processors (at least those I know) appear to concetrate on the majority of the photographers, who don't really understand the nature of their raw data, nor the associated processing.
Once I asked for the explanation of the effect of brightness, recovery, fill, contrast on an Adobe forum, and I received lots of dumb and dumber answers, but no explanation (the reading comprehension of most regular members on those forums is at kindergarden level anyway). I had to create a template in order to observe the effects on the histogram, but ACR's histogram is close to worthless.
Btw, I think "Recovery" is not guessing the clipped pixels but pulling back the highlights, which *appear* clipped. In other words, it recovers that, what ACR messed up. Thus it is not working on the raw data.
-
There is a lot of technical jargon here, but let me see if I got this right:
The original complaint was, that RAW converters not only convert, but modulate the data, so it can be handled with the image editing functions of the same program. And this make compromises to the ideal process of converting data.
Is this right?
So, to have the best possible conversion, would it be better to use a converter-only software to convert, and then only import it into Lightroom/Photoshop?
Would Nikon Capture (never seen it) be such a program, or does it also have editing functions?
-
So, to have the best possible conversion, would it be better to use a converter-only software to convert, and then only import it into Lightroom/Photoshop?
While Lightroom is not "a converter-only software" this is its main core function, ie. to provide the best possible raw conversion process.
If it has fallen short of this then its would not be living up to the companies stated goal.
-
I fully agree with this resentment. The raw processors (at least those I know) appear to concetrate on the majority of the photographers, who don't really understand the nature of their raw data, nor the associated processing.
Once I asked for the explanation of the effect of brightness, recovery, fill, contrast on an Adobe forum, and I received lots of dumb and dumber answers, but no explanation (the reading comprehension of most regular members on those forums is at kindergarden level anyway). I had to create a template in order to observe the effects on the histogram, but ACR's histogram is close to worthless.
Btw, I think "Recovery" is not guessing the clipped pixels but pulling back the highlights, which *appear* clipped. In other words, it recovers that, what ACR messed up. Thus it is not working on the raw data.
[a href=\"index.php?act=findpost&pid=192797\"][{POST_SNAPBACK}][/a]
(1) How do you know what the majority of photographers know or don't know?
(2) What's your technical underestanding of the "nature of the raw data"?
(3) What inside mathemateical knowledge do you have about the associated processing in Adobe Camera Raw?
(4) Who do you think you are to pass judgment about the level of reading comprehension in this Forum?
(5) What kind of "template" can you create to demonstrate that ACR's histogram is "close to worthless"? What proof of (counter)-concept can you offer?
(6) What makes you think recovery is pulling back the highlights? And how do you know ACR messes highlights in clipped images?
-
There is a lot of technical jargon here, but let me see if I got this right:
The original complaint was, that RAW converters not only convert, but modulate the data, so it can be handled with the image editing functions of the same program. And this make compromises to the ideal process of converting data.
Is this right?
So, to have the best possible conversion, would it be better to use a converter-only software to convert, and then only import it into Lightroom/Photoshop?
Would Nikon Capture (never seen it) be such a program, or does it also have editing functions?
[a href=\"index.php?act=findpost&pid=192805\"][{POST_SNAPBACK}][/a]
No, you didn't get it right. Read Schewe's book.
NOTHING happens to the raw data. All the editing you do in Camera Raw results in a set of meta-data instructions which tell the program how to render the file (in an intenally optimized sequence) from a linear encoded space to a gamma-encoded space with three channels. Until you or any one else reading this thread can demonstrate (not just opine) in what ways the rendering of the raw data is impaired by this instruction set you have no basis for assuming that the program's editing capabilities create any such liabilities. You should also know that Lightroom's Develop module is almost identical to Camera Raw and the program is essentially a raw converter.
-
No, you didn't get it right. Read Schewe's book.
NOTHING happens to the raw data. All the editing you do in Camera Raw results in a set of meta-data instructions which tell the program how to render the file (in an intenally optimized sequence) from a linear encoded space to a gamma-encoded space with three channels. Until you or any one else reading this thread can demonstrate (not just opine) in what ways the rendering of the raw data is impaired by this instruction set you have no basis for assuming that the program's editing capabilities create any such liabilities. You should also know that Lightroom's Develop module is almost identical to Camera Raw and the program is essentially a raw converter.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=192862\")
I was hoping this discussion would not deteriorate, again, to a discussion about meta data vs. 'pixel' editing. These are jut different processing paradigms (with obvious workflow and useability consequences) but I fail to see how they relate to my question about which function operates on pre or post demosaiced data.
Schewe notes that LR/ACR operate on linear (non gamma corrected data) and this is important to know. This by itself though does not guarrantee 'optimal processing'.
Let me try to give an example. Noise Reduction. Most raw converters offer a noise reduction function these days. Does this operate on pre or post demosaiced data? Why is this good to know?. Because performing noise reduction before demosaicing has both the potential to offer improved demosaicing quality (especially on noisy data) if done right and the potential to really screw up the demosaicing performance (e.g. colorwise) if done in a less than optimal way.
I would like to know if NR operates on real raw (i.e. pre-demosaiced) rather than just linear RGB data in order to perform educated and clever testing of the built-in NR vs. an external NR program or filter.
BTW, At least one quite well respected and I believe knowledgable person, Iliah Borg, agrees here [a href=\"http://forums.dpreview.com/forums/readflat.asp?forum=1021&thread=27750674]http://forums.dpreview.com/forums/readflat...thread=27750674[/url] that the difference between raw and RGB data (linear or not) should be more documented and de-lineated for users of raw converters.
So, if I include Panokeeper, that makes at least three of us who are not comfortable with the way things are
-
I was hoping this discussion would not deteriorate, again, to a discussion about meta data vs. 'pixel' editing. These are jut different processing paradigms (with obvious workflow and useability consequences) but I fail to see how they relate to my question about which function operates on pre or post demosaiced data.
Schewe notes that LR/ACR operate on linear (non gamma corrected data) and this is important to know. This by itself though does not guarrantee 'optimal processing'.
Let me try to give an example. Noise Reduction. Most raw converters offer a noise reduction function these days. Does this operate on pre or post demosaiced data? Why is this good to know?. Because performing noise reduction before demosaicing has both the potential to offer improved demosaicing quality (especially on noisy data) if done right and the potential to really screw up the demosaicing performance (e.g. colorwise) if done in a less than optimal way.
I would like to know if NR operates on real raw (i.e. pre-demosaiced) rather than just linear RGB data in order to perform educated and clever testing of the built-in NR vs. an external NR program or filter.
BTW, At least one quite well respected and I believe knowledgable person, Iliah Borg, agrees here http://forums.dpreview.com/forums/readflat...thread=27750674 (http://forums.dpreview.com/forums/readflat.asp?forum=1021&thread=27750674) that the difference between raw and RGB data (linear or not) should be more documented and de-lineated for users of raw converters.
[a href=\"index.php?act=findpost&pid=192905\"][{POST_SNAPBACK}][/a]
Read page 5, second bullet on Noise Reduction, antialiasing and sharpening in Jeff's book. There is additional information on page 33. I think these indications address your question in as much detail as you're likely to obtain it. The copyright notice prevents me from reproducing it here. But if that isn't enough, you can always experiment and see which workflow you like best. That's what it boils to in the end.
-
(1) How do you know what the majority of photographers know or don't know?
I see that on several forums and I assume, that those, who are posting on these forums have *more* knowledge than others.
(2) What's your technical underestanding of the "nature of the raw data"?
This is a nonsensical question. What does it mean "what is..."? Do you expect me to write down and post everything I learned and experienced relating to raw data?
(3) What inside mathemateical knowledge do you have about the associated processing in Adobe Camera Raw?
None. Had I had some, I would not have needed to ask and to experiment to find out the effects of the controls.
(4) Who do you think you are to pass judgment about the level of reading comprehension in this Forum?
I wrote the reading comprehension of most regular members on those forums.
Anyway, *now* I have a snapshot of *your* reading comprehension.
(5) What kind of "template" can you create to demonstrate that ACR's histogram is "close to worthless"?
This has nothing to do with template, it has to do with the smallness of the histogram and with the fact, that it is based on sampling.
What proof of (counter)-concept can you offer?
English is my third language, but I would not write such a sentence.
6)What makes you think recovery is pulling back the highlights?
I am getting the impression, that the only reason you posted this message is that you were bored.
And how do you know ACR messes highlights in clipped images?
This is part of the general understanding of the nature of raw data and its processing. If you are so bored, you can experiment a bit. Load any image exposed to the right which does not have any raw clipping, like a corner of the sky. Reduce the exposure by as much as you can. If there is some spike at the end of the histogram, then there was clipping on raw level.
Reset all controls to null (except WB) and turn on the clipping indicator. Now change the contrast up and down; observe the effect on the clipping. Reset the contrast. Change the saturation and observe the effect. Change the WB and observe the effect.
Now use Recovery to regain that, what was never lost. Do you understand now what I meant with "messing up the highlights"?
-
Do you think what I'm writing about is only of philosophical interest and I'm just moaning too much?
[a href=\"index.php?act=findpost&pid=192627\"][{POST_SNAPBACK}][/a]
Since we're being philosophical... you may have setup in your mind a distinction without a difference. You have to ask yourself whether it seems more likely than not that there is some point in the routine where it says ok, now demosaic based on parameters a, b, and c and then apply parameters x, y, and z Photoshop-style. I mean I'm just talking out of my armchair here and don't know one way or the other, but that doesn't seem very likely to me.
-sean
-
Since we're being philosophical... you may have setup in your mind a distinction without a difference. You have to ask yourself whether it seems more likely than not that there is some point in the routine where it says ok, now demosaic based on parameters a, b, and c and then apply parameters x, y, and z Photoshop-style. I mean I'm just talking out of my armchair here and don't know one way or the other, but that doesn't seem very likely to me.
-sean
[a href=\"index.php?act=findpost&pid=192914\"][{POST_SNAPBACK}][/a]
Yes. I believe that your, simplified, explanation is very close to the truth (although I'm not sure what you mean by Photoshop style). I want to know which functions belong to the (a,b,c) category and which to the (x,y,z) category, to use your terminology.
The reasons should be evident to people who have messed up with the internals of raw conversion.
-
I see that on several forums and I assume, that those, who are posting on these forums have *more* knowledge than others.
This is a nonsensical question. What does it mean "what is..."? Do you expect me to write down and post everything I learned and experienced relating to raw data?
None. Had I had some, I would not have needed to ask and to experiment to find out the effects of the controls.
I wrote the reading comprehension of most regular members on those forums.
Anyway, *now* I have a snapshot of *your* reading comprehension.
This has nothing to do with template, it has to do with the smallness of the histogram and with the fact, that it is based on sampling.
English is my third language, but I would not write such a sentence.
I am getting the impression, that the only reason you posted this message is that you were bored.
This is part of the general understanding of the nature of raw data and its processing. If you are so bored, you can experiment a bit. Load any image exposed to the right which does not have any raw clipping, like a corner of the sky. Reduce the exposure by as much as you can. If there is some spike at the end of the histogram, then there was clipping on raw level.
Reset all controls to null (except WB) and turn on the clipping indicator. Now change the contrast up and down; observe the effect on the clipping. Reset the contrast. Change the saturation and observe the effect. Change the WB and observe the effect.
Now use Recovery to regain that, what was never lost. Do you understand now what I meant with "messing up the highlights"?
[a href=\"index.php?act=findpost&pid=192912\"][{POST_SNAPBACK}][/a]
Yes, I'm bored with posts containing all kinds of unsubstantiated allegations. My questions were designed to elicit whatever depth there may or may not be to what your post alleged. I could go on asking what is "the general understanding of the nature of raw data", but maybe I shouldn't push too far for precision of concepts. Only reading your experiment makes no obvious sense to me, but if and when I get bored, which hasn't happened in a very long time, I may try what you suggest and see whether the light dawns. Till then, I'm out of this dialogue.
-
Is it possible to have a polite disagreement without resorting to quarrels? Please?
-
Is it possible to have a polite disagreement without resorting to quarrels? Please?
[a href=\"index.php?act=findpost&pid=192922\"][{POST_SNAPBACK}][/a]
No...of course not!
-
I would like to know if NR operates on real raw (i.e. pre-demosaiced) rather than just linear RGB data in order to perform educated and clever testing of the built-in NR vs. an external NR program or filter.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=192905\")
In Camera Raw, a portion is done in the demosaicing (the baseline as part of the demosiacing process) and a portion is done after demosaicing on the linear luminance or color data.
Which is better? That all depends...as for satisfying your own personal curiosity, why don't you just go ahead and test CR/LR vs. the rest of the noise reduction plug-ins and see what floats your boat. I have...and for at least up to ISO 800 on MY cameras, CR/LR is fine and dandy but for heavy duty noise reduction I use Noiseware...although I do so on the post processed image and apply it locally only to those areas that need it.
BTW, At least one quite well respected and I believe knowledgable person, Iliah Borg, agrees here [a href=\"http://forums.dpreview.com/forums/readflat...thread=27750674]http://forums.dpreview.com/forums/readflat...thread=27750674[/url] that the difference between raw and RGB data (linear or not) should be more documented and de-lineated for users of raw converters.
Uh huh, well since Iliah is involved in developing raw processors, his is more than an academic curiosity...and since Panopeeper also does some software, I believe to analyze raw captures, he has more than a passing interest as well. Which goes back to my first response, in the case of CR/LR, the engineers consider it proprietary information although Eric gave you a good clue where you could go to read more and see the code for DNG. Have you done that?
Do your homework bud...and then report back.
-
I was hoping this discussion would not deteriorate, again, to a discussion about meta data vs. 'pixel' editing. These are jut different processing paradigms (with obvious workflow and useability consequences) but I fail to see how they relate to my question about which function operates on pre or post demosaiced data.
Schewe notes that LR/ACR operate on linear (non gamma corrected data) and this is important to know. This by itself though does not guarrantee 'optimal processing'.
Let me try to give an example. Noise Reduction. Most raw converters offer a noise reduction function these days. Does this operate on pre or post demosaiced data? Why is this good to know?. Because performing noise reduction before demosaicing has both the potential to offer improved demosaicing quality (especially on noisy data) if done right and the potential to really screw up the demosaicing performance (e.g. colorwise) if done in a less than optimal way.
I would like to know if NR operates on real raw (i.e. pre-demosaiced) rather than just linear RGB data in order to perform educated and clever testing of the built-in NR vs. an external NR program or filter.
BTW, At least one quite well respected and I believe knowledgable person, Iliah Borg, agrees here http://forums.dpreview.com/forums/readflat...thread=27750674 (http://forums.dpreview.com/forums/readflat.asp?forum=1021&thread=27750674) that the difference between raw and RGB data (linear or not) should be more documented and de-lineated for users of raw converters.
So, if I include Panokeeper, that makes at least three of us who are not comfortable with the way things are
[a href=\"index.php?act=findpost&pid=192905\"][{POST_SNAPBACK}][/a]
Regarding me, it's not about meta vs. pixel editing.
I'm quite busy right now, and can't read up on all these technical detail at the moment.
What interests me is purely practical: I am currently using LR as the only RAW converter.
Is this my best option when I switched to Nikon, or would I be better off to used Nikon capture for conversion and LR as RAW editor and database.
(I don't see LR as a converter only, but as a database program, and it could be that this tendency will be enhanced in 2.0)
-
Am I the only one to be, slightly, frustrated with this situation? Do you think what I'm writing about is only of philosophical interest and I'm just moaning too much?
[a href=\"index.php?act=findpost&pid=192627\"][{POST_SNAPBACK}][/a]
Personally, I couldn't care less, provided the images I get at the end of the process are of sufficient "technical quality" for the purpose for which I intend to use them, and that I don't have to jump through too many hoops to get there. By "technical quality" I mean everything after I've pressed the shutter. How the bytes are handled along the way and at what point in the mosaic/de-mosaic process things are done, I couldn't give a **** about. If my image is for printing at 32" x 14" and it's of sufficiently high quality that I'm proud of it and feel comfortable showing it to others (or offering it for sale), then that's all I need. If my image is for sending to someone as a record of something, then a poor quality JPG from a camera phone with no editing is probably good enough.
At the end of the day, all that matters from the computer side of photography is that images are "fit for purpose".
-
How the bytes are handled along the way and at what point in the mosaic/de-mosaic process things are done, I couldn't give a **** about. [a href=\"index.php?act=findpost&pid=193251\"][{POST_SNAPBACK}][/a]
I'm glad you're happy not to care, but some people aren't. I see this discussion like many of the technical discussions which go on in this forum: Geeks wanting to know how things work. So far only Jeff's response concerning commercial confidence has been the only valid reason given why us users aren't entitled to know more about what is going on in our raw converters.
As for the ACR clipping thing, I think Panopeeper and Guillermo and others have pretty well described and documented this behaviour in previous threads over the last few months. Off the top of my head, I think this was why the -S option was added to dcraw, to allow a more accurate clipping point.
-
In Camera Raw, a portion is done in the demosaicing (the baseline as part of the demosiacing process) and a portion is done after demosaicing on the linear luminance or color data.
[a href=\"index.php?act=findpost&pid=192935\"][{POST_SNAPBACK}][/a]
The details of the internal processing pipeline are of great interest to the intellectually curious photographers; indeed, in Jeff's recent Camera Raw tutorial, I found the sidebar clips with Thomas Knoll to be some of the most interesting parts of the tutorial. Curiosity aside, I am quite content to leave the details of the optimal processing to Mr. Knoll. Detailed knowledge of this processing would be of no practical use to most photographers, but would be most useful to software engineers developing competing products.
One can examine the code of dng_validate, but there is no guarantee that the algorithms are the same as used in Camera Raw.
Which is better? That all depends...as for satisfying your own personal curiosity, why don't you just go ahead and test CR/LR vs. the rest of the noise reduction plug-ins and see what floats your boat. I have...and for at least up to ISO 800 on MY cameras, CR/LR is fine and dandy but for heavy duty noise reduction I use Noiseware...although I do so on the post processed image and apply it locally only to those areas that need it.
[a href=\"index.php?act=findpost&pid=192935\"][{POST_SNAPBACK}][/a]
The post processed image is not the optimal stage of the workflow to apply the NR plugins. I have communicated with Jim Christian, the developer of Noise Ninja, and he stated that NN could do a better job if it could operate on the raw data before adjustments such as exposure that alter the noise characteristics of the image have been made. BibblePro does incorporate NoiseNinja into the raw converter for optimum processing, but that feature alone is unlikely to cause many ACR users to switch over to Bibble.
Application of NR to the post processed image on a layer using surface masks and other methods for local control does have its advantages. However for those who like parametric image editing, this interrupts the workflow and requires generating and most likely storing an intermediate TIFF image.
-
While I think commercial reasons are valid in general, I would like to stress that we are not asking to know the details of the particular algorithms used.
The request to the converter authors is quite simple: Pls. indicate somehow which functions affect the raw data and which work on demosaiced data. I think this could be done without letting too much proprietary info out, and would de-confuse many users thinking that if a function is offered built-in a converter it must by definition be a better thing (quality wise) since it is done 'in raw'.
-
While I think commercial reasons are valid in general, I would like to stress that we are not asking to know the details of the particular algorithms used.
The request to the converter authors is quite simple: Pls. indicate somehow which functions affect the raw data and which work on demosaiced data. I think this could be done without letting too much proprietary info out, and would de-confuse many users thinking that if a function is offered built-in a converter it must by definition be a better thing (quality wise) since it is done 'in raw'.
[a href=\"index.php?act=findpost&pid=193331\"][{POST_SNAPBACK}][/a]
Let us suppose they were to give you this information. Could you please explain what you will do with it and why you think it will help you to improve the quality of your output, the alternative being to simply experiment on your computer whether performing certain adjustments in ACR or in PS gives preferable results.
-
Let us suppose they were to give you this information. Could you please explain what you will do with it and why you think it will help you to improve the quality of your output[a href=\"index.php?act=findpost&pid=193343\"][{POST_SNAPBACK}][/a]
It may very well improve the quality of someones output. But that's not the only reason. Some of us just like to know how things work.
-
It may very well improve the quality of someones output. But that's not the only reason. Some of us just like to know how things work.
[a href=\"index.php?act=findpost&pid=193355\"][{POST_SNAPBACK}][/a]
Well, for better or worse as the case may be, as you know, we live in a world of intellectual property rights, copyrights and patents, so much as it would interesting to know *all*, we'll just have to content ourselves with knowing what's not protected. As for the quality issue, my humble experience suggests that in this particular case the only way to really *know* - even if we had the benefit of knowing the theory - is to try the alternatives and compare them.
-
Well, for better or worse as the case may be, as you know, we live in a world of intellectual property rights, copyrights and patents, so much as it would interesting to know *all*, we'll just have to content ourselves with knowing what's not protected. [a href=\"index.php?act=findpost&pid=193363\"][{POST_SNAPBACK}][/a]
On thinking more about this IP patent stuff, I wonder if this is really a good excuse after all. In some of the cases it is possible to work out what's going on under the hood in terms of mosaiced vs demosaiced. It just needs people like Panopeeper and Guillermo and other uber-geeks to do the hard work. Now if these guys can work it out, then I am betting that the raw developers at opposition companies can work it out too.
I guess in the end it is a bit of both: Commercial confidence, and a lack of motivation to fully explain and document a product's features.
-
Bernie, I guess I find myself agreeing with Bill Janes on this one, quote:
<Detailed knowledge of this processing would be of no practical use to most photographers, but would be most useful to software engineers developing competing products.>
As for fully explaining the product's features, interestingly, when you think about it, most of the majors (e.g. Microsoft and Adobe) don't. And look at the publishing industry which has exploded to fill this gap - I think for the better.
-
One can examine the code of dng_validate, but there is no guarantee that the algorithms are the same as used in Camera Raw.
The CR code augments what's in the DNG SDK, but the fundamentals are the same.
Consider a Canon CR2 image that has been converted to a DNG. When CR processes the DNG image it uses the processing model as described in the DNG spec, clearly. When CR processes the corresponding CR2 raw file you get the same results.
-
While I think commercial reasons are valid in general, I would like to stress that we are not asking to know the details of the particular algorithms used.
The request to the converter authors is quite simple: Pls. indicate somehow which functions affect the raw data and which work on demosaiced data. I think this could be done without letting too much proprietary info out, and would de-confuse many users thinking that if a function is offered built-in a converter it must by definition be a better thing (quality wise) since it is done 'in raw'.
[a href=\"index.php?act=findpost&pid=193331\"][{POST_SNAPBACK}][/a]
Depends on what you define as 'raw'. Raw data can undero many transforms yet still be considered "raw' in the sense that the image values are scene-referred.
FYI, the DNG processing model performs a linearization of the original raw image values followed by demosaicing, then white balance. All of the other image stages follow. So to answer your question, all of the image ops except for linearization (which isn't under user control anyways) happens after demosaicing. If you want further details I encourage you to see the DNG spec.
Although to be honest I'm still not sure how this information is going to help you improve your conversion results.
As for others who want to "know how things work" because they're scientifically or technically interested in finding out, that's an understandable sentiment (trust me, I empathize) but not at all a valid or compelling reason for a company to provide the info.
-
So to answer your question, all of the image ops except for linearization (which isn't under user control anyways) happens after demosaicing. If you want further details I encourage you to see the DNG spec.
[a href=\"index.php?act=findpost&pid=193382\"][{POST_SNAPBACK}][/a]
Really? EV comp, highlight retention and WB too?
-
Yup.
-
Yup.
[a href=\"index.php?act=findpost&pid=193486\"][{POST_SNAPBACK}][/a]
Well, that's interesting regarding DNG... I'm fairly sure this is not the case with other raw converters.
-
Well, that's interesting regarding DNG... I'm fairly sure this is not the case with other raw converters.
[a href=\"index.php?act=findpost&pid=193531\"][{POST_SNAPBACK}][/a]
Nikos, could you explain what reasons you have to be "fairly sure this is not the case with other raw converters"?
Reading what Eric is telling us, it makes sense to me, albeit I have no knowledge or expertise about any of the code. But as far as I understand it, the original "raw" data is greyscale until it is demosaiced in order to impart colour information. How can one possibly perform a white balance, for example, unless there is colour to be balanced, and it goes on from there, as colour balance affects luminosity, etc.
-
Nikos, could you explain what reasons you have to be "fairly sure this is not the case with other raw converters"?
Reading what Eric is telling us, it makes sense to me, albeit I have no knowledge or expertise about any of the code. But as far as I understand it, the original "raw" data is greyscale until it is demosaiced in order to impart colour information. How can one possibly perform a white balance, for example, unless there is colour to be balanced, and it goes on from there, as colour balance affects luminosity, etc.
[a href=\"index.php?act=findpost&pid=193544\"][{POST_SNAPBACK}][/a]
Pls. do not confuse WB with colour balancing. This is a good example of the confusion that may be imparted by users not understanding the diffrence between raw and RGB data.
To WB you multiply R,G.B pixel values by suitable multipliers (usually leaving G as is and multiplying R and B ) . Raw data is not more greyscale (regardless what some people like to say) than de-mosaiced RGB data is. Both contain colour information albeit represented (coded) differently.
-
Reading what Eric is telling us, it makes sense to me, albeit I have no knowledge or expertise about any of the code. But as far as I understand it, the original "raw" data is greyscale until it is demosaiced in order to impart colour information. How can one possibly perform a white balance, for example, unless there is colour to be balanced, and it goes on from there, as colour balance affects luminosity, etc.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=193544\")
As has been discussed before on this forum, the raw file is not grayscale. The color information is present in the mosaic pattern of the Bayer array. The basic Bayer pattern is a 2 by 2 block containing 2 green pixels, one red pixel and one blue pixel. This is shown in Panopeeper's [a href=\"http://www.cryptobola.com/photobola/Image.htm]Rawanalyze Manual.[/url]
All you would have to do to white balance the original raw data would be to multiply each pixel of the raw file by its RGB multiplier. No demosaicing would be necessary.
Bill
PS: This essentially duplicates Nikos's post, which was posted while I was writing my message.
-
Page 4 of Fraser/Schewe "Real World Camera Raw.":
<No matter what the filter arrangement, the raw file simply records the luminance values for each pixel, so the raw file is a grayscale image. It contains color information...so raw converters know whether a given pixel ...........represents red, green, or blue.....but it doesn't contain anything humans can interpret as color.>
<The raw converter interpolates the missing color information for each pixel from its neighbors, a process called demosaciing............>
-
Page 4 of Fraser/Schewe "Real World Camera Raw.":
<No matter what the filter arrangement, the raw file simply records the luminance values for each pixel, so the raw file is a grayscale image. It contains color information...so raw converters know whether a given pixel ...........represents red, green, or blue.....but it doesn't contain anything humans can interpret as color.>
<The raw converter interpolates the missing color information for each pixel from its neighbors, a process called demosaciing............>
[a href=\"index.php?act=findpost&pid=193552\"][{POST_SNAPBACK}][/a]
Yes Bruce did and Schewe still maintains this raw is grayscale metaphor which I find to be quite confusing...
But this subject has been dicussed to death in other threads.
-
Yes Bruce did and Schewe still maintains this raw is grayscale metaphor which I find to be quite confusing...
But this subject has been dicussed to death in other threads.
[a href=\"index.php?act=findpost&pid=193553\"][{POST_SNAPBACK}][/a]
Nikos, either it is or it isn't, or it's the perspective from which one looks at it, or it depends on the context, so yes there can be some lack of clarity because there may be different equally valid ways of looking at it.
But whatever, I'm still having trouble seeing specifically what practical differences it would make to my workflow knowing which way to interpret this information. Sometimes in these discussions we bear witness to angels dancing on the heads of pins with zero significance to anything that matters except to code writers.
-
Nikos, either it is or it isn't, or it's the perspective from which one looks at it, or it depends on the context, so yes there can be some lack of clarity because there may be different equally valid ways of looking at it.
But whatever, I'm still having trouble seeing specifically what practical differences it would make to my workflow knowing which way to interpret this information. Sometimes in these discussions we bear witness to angels dancing on the heads of pins with zero significance to anything that matters except to code writers.
[a href=\"index.php?act=findpost&pid=193556\"][{POST_SNAPBACK}][/a]
To use the example you helped me think of, why should I WB when I can colour balance? Or, why should use EV compensation when I can use 'brightness'?
(I pose these as rhetorical questions and food for thought)
-
Page 4 of Fraser/Schewe "Real World Camera Raw.":
<No matter what the filter arrangement, the raw file simply records the luminance values for each pixel, so the raw file is a grayscale image. It contains color information...so raw converters know whether a given pixel ...........represents red, green, or blue.....but it doesn't contain anything humans can interpret as color.>
<The raw converter interpolates the missing color information for each pixel from its neighbors, a process called demosaciing............>
[a href=\"index.php?act=findpost&pid=193552\"][{POST_SNAPBACK}][/a]
An RGB image in TIFF format is gray scale by the same reasoning. There are three gray scale files with luminance values. Nothing here would be perceived as color by humans. However, each file contains tristimulus values for red, blue, and green and these are perceived in full color when properly decoded by software. In the case of the raw files, the color information is in mosaic form and in the TIFF image the color information is present in three separate channels.
Bill
-
To use the example you helped me think of, why should I WB when I can colour balance? Or, why should use EV compensation when I can use 'brightness'?
(I pose these as rhetorical questions and food for thought)
[a href=\"index.php?act=findpost&pid=193557\"][{POST_SNAPBACK}][/a]
Nikos, rhetorical or not, you've raised a couple of interesting examples, so I'll respond to them. Re the White Balance: find one of your images which seriously needs to be "white-balanced". Do it in Camera Raw using the white balance tools in the first section of the Basic Tab, render the image and save it as an RGB psd or tiff. Then go back to the raw file, undo the white balance you just created there, and render the file "non-balanced" into Photoshop. Then use whatever techniques you wish to use in Photoshop for correcting the colour balance. Compare the results on two dimensions: (i) perceived accuracy of rendition across the colour gamut, and (2) ease of workflow. I've tried this a number of times and Camera Raw always wins.
As for "EV compensation", there is a contradiction in terms here and a technical matter. Firstly, I assume we are talking at the stage of the scene capture, where EV is Equivalent Value - it trades-off shutter speed against aperture to maintain the equivalent exposure, so there is no such thing as "EV compensation". We do Compensation at capture time to change the exposure, altering the histogram. The technical fact is that we always want to get the best possible exposure at capture and rely less on Brightness or Exposure in either Camera Raw or Photoshop after the fact. The most usual example is the argument made for Expose To The Right (ETTR), also discussed extensively in these forums, and a correct recommendation. Under-exposures boosted in post-capture processing will usually display more noise than appropriate ETTR exposures which don't require such boosting.
In both your examples, doing the right thing at the right time is important, hence I believe the major reason for the interest underlying this discussion, and in both cases we find our answers with simple experiments and observation.
-
Nikos, rhetorical or not, you've raised a couple of interesting examples, so I'll respond to them. Re the White Balance: find one of your images which seriously needs to be "white-balanced". Do it in Camera Raw using the white balance tools in the first section of the Basic Tab, render the image and save it as an RGB psd or tiff. Then go back to the raw file, undo the white balance you just created there, and render the file "non-balanced" into Photoshop. Then use whatever techniques you wish to use in Photoshop for correcting the colour balance. Compare the results on two dimensions: (i) perceived accuracy of rendition across the colour gamut, and (2) ease of workflow. I've tried this a number of times and Camera Raw always wins.
As for "EV compensation", there is a contradiction in terms here and a technical matter. Firstly, I assume we are talking at the stage of the scene capture, where EV is Equivalent Value - it trades-off shutter speed against aperture to maintain the equivalent exposure, so there is no such thing as "EV compensation". We do Compensation at capture time to change the exposure, altering the histogram. The technical fact is that we always want to get the best possible exposure at capture and rely less on Brightness or Exposure in either Camera Raw or Photoshop after the fact. The most usual example is the argument made for Expose To The Right (ETTR), also discussed extensively in these forums, and a correct recommendation. Under-exposures boosted in post-capture processing will usually display more noise than appropriate ETTR exposures which don't require such boosting.
In both your examples, doing the right thing at the right time is important, hence I believe the major reason for the interest underlying this discussion, and in both cases we find our answers with simple experiments and observation.
[a href=\"index.php?act=findpost&pid=193573\"][{POST_SNAPBACK}][/a]
I believe you have come very close to answering your own question
-
An RGB image in TIFF format is gray scale by the same reasoning. There are three gray scale files with luminance values. Nothing here would be perceived as color by humans. However, each file contains tristimulus values for red, blue, and green and these are perceived in full color when properly decoded by software. In the case of the raw files, the color information is in mosaic form and in the TIFF image the color information is present in three separate channels.
Bill
[a href=\"index.php?act=findpost&pid=193566\"][{POST_SNAPBACK}][/a]
Fine, but what have we bought ourselves? Does this mean it doesn't matter whether one adjusts luminosity and colour in ACR or PS? Isn't there more to it? Different matter, but I believe also relevant to a discussion of what is best processed where, the raw file is linear, and the rendered file a gamma-encoded three channel construct. Wouldn't this create differences in tonal response which influence what element is best adjusted at which stage in the workflow?
-
Fine, but what have we bought ourselves? Does this mean it doesn't matter whether one adjusts luminosity and colour in ACR or PS? Isn't there more to it? Different matter, but I believe also relevant to a discussion of what is best processed where, the raw file is linear, and the rendered file a gamma-encoded three channel construct. Wouldn't this create differences in tonal response which influence what element is best adjusted at which stage in the workflow?
[a href=\"index.php?act=findpost&pid=193577\"][{POST_SNAPBACK}][/a]
Maybe.
Who knows?
Now you have finally joined me in my premise.
-
Maybe.
Who knows?
Now you have finally joined me in my premise.
[a href=\"index.php?act=findpost&pid=193578\"][{POST_SNAPBACK}][/a]
Well, if we've come full-circle that's fine, but I'm not sure what your premise was. Your original post is a question about whether any readers are frustrated by the state of documentation on raw conversion. I've indicated that I'm not frustrated, because I've found that the best results come from good ETTR technique at time of capture and maximizing the feasible use of the raw converter for adjusting the image before rendering it to Photoshop. If all that works best for us, we have an optimal workflow without knowing all the ingredients of the secret sauce in the raw converter. So re-answering your original question - no, I'm not frustrated - not by that matter, anyhow . Amen.
-
All you would have to do to white balance the original raw data would be to multiply each pixel of the raw file by its RGB multiplier. No demosaicing would be necessary
This is, how Rawnalyze is doing it, because Rawnalyze does not perform any de-mosaicing (Jeff Schewe tried to call the way Rawnalyze creates the composite calor a"demosaicing", but that's nonsense).
However, the camera's color space is not orthogonal. Every (or most) pixel values carry some of the other two components. Multiplying for example the "red" raw pixel values implicitely multiplies the green and blue components of that pixel as well.
why should I WB when I can colour balance?
WB is a different quality. After WB the greys remain grey, whatever you do with the color adjustment.
why should use EV compensation when I can use 'brightness'?
The so-called EV compensation of ACR (it is a misnomer) is a linear operation, at least that is my observation. The "brightness" adjustment is non-linear.
-
Fine, but what have we bought ourselves? Does this mean it doesn't matter whether one adjusts luminosity and colour in ACR or PS? Isn't there more to it? Different matter, but I believe also relevant to a discussion of what is best processed where, the raw file is linear, and the rendered file a gamma-encoded three channel construct. Wouldn't this create differences in tonal response which influence what element is best adjusted at which stage in the workflow?
[a href=\"index.php?act=findpost&pid=193577\"][{POST_SNAPBACK}][/a]
The matter of color information in raw files is more than semantics and there are practical implications. For example, one can white balance undemosaiced data since one does not need to wait for the color to appear during the demosaicing process. Using the Schewe-Fraser concept, this would not be possible, as you stated previously in this thread.
Similarly Schewe maintains that raw files lack a color space, in part because they are gray scale and lack color, assertions by Thomas Knoll and Chris Murphy to the contrary. ACR and other raw converters convert from the camera space to the internal working space (XYZ or linear ProPhotoRGB) using a 3 by 3 matrix conversion. Such conversions are used to convert from one color space to another, and how would this be possible if the camera lacks a color space? Thomas Knoll stated that the question of demosaicing is a "red herring".
Your comment about what is done where is most appropriate. For example, white balance is much easier to accomplish in a linear space since one can simply use RGB multipliers. In a gamma 2.2 space, the process would be nonlinear. Lightroom and the newer versions of ACR can white balance JPEGs; I think they first apply a reverse gamma curve to convert the image back to linear.
Bill
-
The matter of color information in raw files is more than semantics and there are practical implications. For example, one can white balance undemosaiced data since one does not need to wait for the color to appear during the demosaicing process. Using the Schewe-Fraser concept, this would not be possible, as you stated previously in this thread.
Similarly Schewe maintains that raw files lack a color space, in part because they are gray scale and lack color, assertions by Thomas Knoll and Chris Murphy to the contrary. ACR and other raw converters convert from the camera space to the internal working space (XYZ or linear ProPhotoRGB) using a 3 by 3 matrix conversion. Such conversions are used to convert from one color space to another, and how would this be possible if the camera lacks a color space? Thomas Knoll stated that the question of demosaicing is a "red herring".
Your comment about what is done where is most appropriate. For example, white balance is much easier to accomplish in a linear space since one can simply use RGB multipliers. In a gamma 2.2 space, the process would be nonlinear. Lightroom and the newer versions of ACR can white balance JPEGs; I think they first apply a reverse gamma curve to convert the image back to linear.
Bill
[a href=\"index.php?act=findpost&pid=193583\"][{POST_SNAPBACK}][/a]
Bill, yes I agree it is more than semantics and there are practical implications. We've just been bantering about whether we find them out more practically from knowing the code (difficult for obvious reasons) or by experiment. But I don't understand how one can white balance non-demosaiced data. This eludes me.
No doubt Jeff can speak for himself in response to your second paragraph, but can you point us to where Thomas and Chris have said as you indicated here? I'd like to see the context.
Your rejoinder on the relevance of linearity to white balancing - agreed - much easier to get this right in ACR than in PS.
-
In general you want certain operations in a raw converter to be done in a linear space. These include white balance and exposure compensation (which is just a linear scaling of the data), for sure. Other things are more debatable but may be convenient to have while you're in the raw conversion interface anyways.
bjanes, you correctly describe the matrix operations used to obtain XYZ coordinates from camera RGB (or GMCY) coordinates. You can think of the camera RGB/GMCY space as a color space but it's not colorimetrically defined. The matrices provide the colorimetric interpretation.
NikosR, your recent questions seem to be more about understanding how to use CR's controls, rather than needing to know the underlying details of how CR works. For example, with regards to your question about Exposure vs. Brightness -- Panopeeper covered it: the former is linear and hence preserves linear tonal relationships, but can cause clipping. The latter is a non-linear tone curve adjustment (and hence doesn't preserve linear tonal relationships) which doesn't clip. Two different ways to adjust tonality, with pros and cons of each.
-
Bill, yes I agree it is more than semantics and there are practical implications. We've just been bantering about whether we find them out more practically from knowing the code (difficult for obvious reasons) or by experiment. But I don't understand how one can white balance non-demosaiced data. This eludes me.
No doubt Jeff can speak for himself in response to your second paragraph, but can you point us to where Thomas and Chris have said as you indicated here? I'd like to see the context.
Your rejoinder on the relevance of linearity to white balancing - agreed - much easier to get this right in ACR than in PS.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=193605\")
[a href=\"http://luminous-landscape.com/forum/index.php?showtopic=22471&st=0&p=168050&#entry168050]Knoll and Murphy Responses[/url]
-
OK Bill, thanks - I remember that thread now - probably one of the more torturous ones in this Forum - and good to see the usual suspects haven't given-up yet!
-
OK Bill, thanks - I remember that thread now - probably one of the more torturous ones in this Forum - and good to see the usual suspects haven't given-up yet!
[a href=\"index.php?act=findpost&pid=193630\"][{POST_SNAPBACK}][/a]
Considering that that particular thread resulted in my choosing to ignore bjanes as a LL forum user, I won't be responding to anything he posts either directly (since I don't see his posts) or indirectly because somebody else quotes him. I'm done talking to that individual...
-
Considering that that particular thread resulted in my choosing to ignore bjanes as a LL forum user, I won't be responding to anything he posts either directly (since I don't see his posts) or indirectly because somebody else quotes him. I'm done talking to that individual...
[a href=\"index.php?act=findpost&pid=193639\"][{POST_SNAPBACK}][/a]
I guess there are worse things than being ignored by Schewe. It is difficult to disagree with him without drawing abuse and it is also a waste of time to do so, since he seldom retracts demonstrably incorrect positions. No more abuse from the motorcycle contingent, not a bad thing.
Bill
-
The latter is a non-linear tone curve adjustment (and hence doesn't preserve linear tonal relationships) which doesn't clip
IMO this needs a bit explanation (not for madmanchan, who certainly knows this).
"Brightness" does not cause clipping the way the "exposure" adjustment does, i.e. by blowing the linear values out of the range. However, it does cause the *RGB* values growing up to 255 (depending on the the image and other settings), which triggers the clipping indication if turned on.
My point here is, that the user does not see the difference between clippings of different sources:
1. raw pixel saturation
2. induced clipping of the linear values (due to WB, saturation, contrast, exposure adjustment) and
3. reaching the top RGB value in the mapping.
-
It would be useful to have 2 highlight clipping indicators:
1. (red) What we have now (presumably) - hard-clipped pixels per raw
2. (orange) "Soft-clipped" pixels that are clipped as a result of current settings
This is not as simple as it sounds, for the raw "color" channels do not translate in RGB red, green and blue. A raw pixel does not even translate into a single RGB pixel.
I would find this a useful tool to help know whether to mess around trying to recover "blown" highlights
I may be wrong, but my understanding is, that the "true recovery", i.e. guessing the clipped pixels based on their context does not depend on the "recovery" slider, i.e. it always happens.
The "recovery" slider reduces the highlights, no matter if there was raw clipping.
-
I think this is is an interesting point. It would be useful to have 2 highlight clipping indicators:
1. (red) What we have now (presumably) - hard-clipped pixels per raw
2. (orange) "Soft-clipped" pixels that are clipped as a result of current settings.
I would find this a useful tool to help know whether to mess around trying to recover "blown" highlights.
[a href=\"index.php?act=findpost&pid=193659\"][{POST_SNAPBACK}][/a]
GB, Given their limited time and resources between program up-dates, I would not recommend this as a high priority item. The distinction you're making between "hard" and "soft" clipping seems to me rather elusive. I think it boils down to this: if all three channels are clipped, no recovery is possible because there simply isn't any information on which to build. If at least one channel has some information, Recovery can work as explained on page 38 of Fraser/Schewe. "Messing around" in this context simply means moving the slider to see what it does - or doesn't.
-
I may be wrong, but my understanding is, that the "true recovery", i.e. guessing the clipped pixels based on their context does not depend on the "recovery" slider, i.e. it always happens.
The "recovery" slider reduces the highlights, no matter if there was raw clipping.
[a href=\"index.php?act=findpost&pid=193664\"][{POST_SNAPBACK}][/a]
Now wouldn't it be nice if we could have some documentation from Adobe explaining what is going on here? Surely this isn't a commercial confidence issue?
-
............ Surely this isn't a commercial confidence issue?
[a href=\"index.php?act=findpost&pid=193697\"][{POST_SNAPBACK}][/a]
What makes you think it isn't? Pretty neat feature when you see it working, isn't it?
-
Now wouldn't it be nice if we could have some documentation from Adobe explaining what is going on here?
Well, yes, but of course you can't expect a useful documentation of a product for only a few hundred bucks, can you?
Anyway, I guess the Bruce/Schewe book does contain specific information. I learned, that the best is to test such issues. I just did test this; you don't need to touch the recovery slider in order to activate the guessing.
-
What makes you think it isn't? Pretty neat feature when you see it working, isn't it?
[a href=\"index.php?act=findpost&pid=193701\"][{POST_SNAPBACK}][/a]
I don't know, because I don't know what it is that it is supposed to be doing. I find I can achieve most things with the Exposure slider anyway and that way still retain somewhat normal contrast in the image (as opposed to the recovery slider which just seems to dull the highlights).
-
NikosR, your recent questions seem to be more about understanding how to use CR's controls, rather than needing to know the underlying details of how CR works.[a href=\"index.php?act=findpost&pid=193616\"][{POST_SNAPBACK}][/a]
[/quote]
Please pay attention to the fact that I stressed these are posed as rhetorical questions and food for thought. Having a clearer high level (no need to know about the algorithmic details - it is these I would consider highly proprietary stuff) helps a user get a grasp of the proper way of using controls or even perform educated rather than random tests.
And please remember that in my OP I was referring to virtually all raw converters out there. Not just Lightroom / ACR.
The fact that not many people, even in this forum frequented by users of higher than average level, understand, for example, how WB is accomplished in a non-demosaiced space is again food for thought.
-
For example, with regards to your question about Exposure vs. Brightness -- Panopeeper covered it: the former is linear and hence preserves linear tonal relationships, but can cause clipping. The latter is a non-linear tone curve adjustment (and hence doesn't preserve linear tonal relationships) which doesn't clip. Two different ways to adjust tonality, with pros and cons of each.
[a href=\"index.php?act=findpost&pid=193616\"][{POST_SNAPBACK}][/a]
What makes you assume that Exposure is always adjusted in a demosaiced space, if that's what you are alluding to?
-
I don't know, because I don't know what it is that it is supposed to be doing. I find I can achieve most things with the Exposure slider anyway and that way still retain somewhat normal contrast in the image (as opposed to the recovery slider which just seems to dull the highlights).
[a href=\"index.php?act=findpost&pid=193716\"][{POST_SNAPBACK}][/a]
Bernie, yes, the Exposure slider is critical, but achieving "most things" with it is another matter. It or Recovery, depending, is the first step after White Balance, but I find often that Fill, Blacks and less often Brightness also make a huge difference to the quality of the image's tonality - before getting to the Tone Curves. The purposes and roles of Exposure and Recovery are explained with rather more precision on page 38 and on pages 141/142 of Fraser/Schewe. I really suggest to one and all interested in this topic, if you haven't done so already, to read this book. Believe me I get nothing whatever for recommending it - it's just "essential reading" if the subject is essential to you, as it is to me.
-
By "most things" I meant in terms of highlight recovery. I probably should have said "most images". Fill, Blacks and brightness certainly have a roll. Infact, since recently trying LR's auto adjustment on a few images lately (and liking the result), I have been a bit of a convert to the brightness slider. I like to use a little less Fill, but add in a bit of Brightness.
-
Now wouldn't it be nice if we could have some documentation from Adobe explaining what is going on here? Surely this isn't a commercial confidence issue?
[a href=\"index.php?act=findpost&pid=193697\"][{POST_SNAPBACK}][/a]
More documentation regarding the Recovery and Exposure sliders would be welcome. The documentation does state that Exposure is in increments of f/stops and has the same effect as changing the f/stop by an equal increment. This implies that the adjustment is linear. The PS documentation says use recovery to bring the highlights down. Experience demonstrates that it affects highlights more than mid tone and dark tones and is thus nonlinear.
When dealing with overexposure, when does one use recovery and when does he use exposure? A simple test can help here. I Exposed a MacBeth color checker with my Nikon D3 according to the light meter and in one stop increments and used ACR for rendering. With the D3, ACR uses a base line exposure of +0.5 EV and one must use a negative exposure of -0.5 EV in ACR to cancel this.
According to Bruce Lindbloom, the proper values in ProPhotoRGB for the neutral squares of the color checker are 233, 189, 144, 102, 66, and 37. For the nominal exposure, I used Exposure at -0.3 (close to the -0.5 mentioned above) to get the white patch to a pixel value of 233:
[attachment=6433:attachment]
For a one stop overexposure, it would make sense to use -1 EV of exposure compensation added to the -0.3 value used for the nominal exposure development:
[attachment=6434:attachment]
Recovery can't do the job. Using 100% recovery, the white patch comes down to 246, but the other patches are too light and the color is washed out. As documented, recovery affects the highlights more than the remaining tones. The -0.3 exposure adjustment is to account for the baseline exposure that ACR uses for the D3.
[attachment=6435:attachment]
From these tests, I conclude that when correcting overexposure, the Exposure slider is the primary tool. The recovery slider would be useful in high dynamic range shots where the highlights are burnt out but the midtones are properly exposed. Further discussion is invited.
Bill
-
By "most things" I meant in terms of highlight recovery. I probably should have said "most images". Fill, Blacks and brightness certainly have a roll. Infact, since recently trying LR's auto adjustment on a few images lately (and liking the result), I have been a bit of a convert to the brightness slider. I like to use a little less Fill, but add in a bit of Brightness.
[a href=\"index.php?act=findpost&pid=193750\"][{POST_SNAPBACK}][/a]
Bernie, Exposure isn't ideal for highlight recovery because you often find yourself dulling the rest of the image to ramp-down a few partially blown highlights in very small parts of the image. But Exposure is best where correcting an overall under-exposure, for example. That's why Recovery is there - to deal in a targeted manner with highlights. As for Fill, Blacks and Brightness, I don't think it optimal to be a convert to any particular control on this panel - one uses what works best for the image at hand. For example, if you want more granularity in the separation of shadow tones but the mid tones upward are OK, you'll get much more mileage playing between Fill and Blacks. And better yet, if the luminosity problem is confined to one colour group, adjusting the Luminosity of the offending colour group in the HSL tab can work wonders - for example overly dark skies are well-handled by lightening the Blues in the L tab of the HSL panel.
-
More documentation regarding the Recovery and Exposure sliders would be welcome. The documentation does state that Exposure is in increments of f/stops and has the same effect as changing the f/stop by an equal increment. This implies that the adjustment is linear. The PS documentation says use recovery to bring the highlights down. Experience demonstrates that it affects highlights more than mid tone and dark tones and is thus nonlinear.
When dealing with overexposure, when does one use recovery and when does he use exposure? A simple test can help here. I Exposed a MacBeth color checker with my Nikon D3 according to the light meter and in one stop increments and used ACR for rendering. With the D3, ACR uses a base line exposure of +0.5 EV and one must use a negative exposure of -0.5 EV in ACR to cancel this.
From these tests, I conclude that when correcting overexposure, the Exposure slider is the primary tool. The recovery slider would be useful in high dynamic range shots where the highlights are burnt out but the midtones are properly exposed. Further discussion is invited.
Bill
[a href=\"index.php?act=findpost&pid=193751\"][{POST_SNAPBACK}][/a]
Bill, take a rather heavily under-exposed image into ACR and normalize the histogram with the Exposure slider. You will see that as it shifts the histogram to the right, the very darkest tones hardly budge, the mid-tones spread somewhat and the right tail of the distribution moves the most. Not sure whether this fits a linear behaviour pattern, but whatever, that's what happens.
Test charts is one way of exploring these things and they can provide some useful guidance, but honestly, there's only a few sliders in that tab, it has a logical workflow layout, and the optimal combination of adjustments really tends to be very image-specific, so my more pedestrian approach is simply to pull-up the real-world images on a well calibrated/profiled display and just go down and up the page to get things either just-right (to the extent feasible in ACR) or almost just-right, and in the latter case revert to Curves and HSL for the finishing touches. What's really nice about this "little" program is that the rocket-science is under the hood and the U.I. very friendly. Some basic instruction along with experience and experimentation on real-world photos takes one a very long way to getting the most it can offer.
-
What makes you assume that Exposure is always adjusted in a demosaiced space, if that's what you are alluding to?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=193736\")
Nikos, some research (open info from his website) about the individual to whom you are asking this question: [a href=\"http://people.csail.mit.edu/ericchan/]Eric Chan[/url]
-
Bernie, Exposure isn't ideal for highlight recovery because you often find yourself dulling the rest of the image to ramp-down a few partially blown highlights in very small parts of the image. But Exposure is best where correcting an overall under-exposure, for example. That's why Recovery is there - to deal in a targeted manner with highlights. As for Fill, Blacks and Brightness, I don't think it optimal to be a convert to any particular control on this panel - one uses what works best for the image at hand. For example, if you want more granularity in the separation of shadow tones but the mid tones upward are OK, you'll get much more mileage playing between Fill and Blacks. And better yet, if the luminosity problem is confined to one colour group, adjusting the Luminosity of the offending colour group in the HSL tab can work wonders - for example overly dark skies are well-handled by lightening the Blues in the L tab of the HSL panel.
[a href=\"index.php?act=findpost&pid=193754\"][{POST_SNAPBACK}][/a]
I don't know whether I am being sloppy, or you are being extra critical, but I am not being absolutist here. I am just saying that for some of my (landscape) images of late, I have found the brightness slider usefull. Previous to this, I had never touched it.
As for your (perhaps absolutist??) statement that the Exposure slider isn't ideal for highlight recovery, I'd say this: Using the Exposure slider to darken everything and then use the Fill or Brightness to bring the darker tones back up (to where they were), OR, use the Recovery slider to drop the highlights and leave the other tones where they were; you say Tomato, I say Toma®to. However, like I said, I feel using the Recovery slider method leads to flat dull highlights. I find using the Exposure slider retains good contrast in the brighter tones.
One other thing. I think (although I am happy to be corrected) Nikos's question was rhetorical.
-
Bill, take a rather heavily under-exposed image into ACR and normalize the histogram with the Exposure slider. You will see that as it shifts the histogram to the right, the very darkest tones hardly budge, the mid-tones spread somewhat and the right tail of the distribution moves the most. Not sure whether this fits a linear behaviour pattern, but whatever, that's what happens.
[a href=\"index.php?act=findpost&pid=193759\"][{POST_SNAPBACK}][/a]
Mark,
Since we are talking about highlight recovery, I'm not sure why you bring up an example with underexposure. In the example you cite, the exposure control is not equivalent to increasing exposure in the camera as advertised. There are limitations to what it can do. In the example I gave, exposure does work in a more or less linear fashion.
Test charts is one way of exploring these things and they can provide some useful guidance, but honestly, there's only a few sliders in that tab, it has a logical workflow layout, and the optimal combination of adjustments really tends to be very image-specific, so my more pedestrian approach is simply to pull-up the real-world images on a well calibrated/profiled display and just go down and up the page to get things either just-right (to the extent feasible in ACR) or almost just-right, and in the latter case revert to Curves and HSL for the finishing touches. What's really nice about this "little" program is that the rocket-science is under the hood and the U.I. very friendly. Some basic instruction along with experience and experimentation on real-world photos takes one a very long way to getting the most it can offer.
[a href=\"index.php?act=findpost&pid=193759\"][{POST_SNAPBACK}][/a]
The ACR controls in the basic panel are arranged in a logical fashion, and it is often advised to work from top to bottom. The advice of Thomas Knoll in the LL ACR tutorial (CR05, around 5:30) is instructive. When correcting images, he uses exposure to set the white value and then brightness to adjust the mid tones. With the advent of Lightroom, he noted that some photographers use exposure to adjust the mid tones and then recovery to adjust the highlights.
He does not specifically state that he uses this approach for overexposed images where highlight recovery is needed, but recovery is not the tool that he would first use. According to his suggestions, exposure would be the first tool. Brightness or recovery could be used next. Fine tuning with Curves and HSL could come later.
There are only a few sliders on the basic panel, but the number of permutations is rather large, especially when the sub panels are brought into play. A random approach to use of these sliders could consume a great deal of time.
Test charts do not duplicate real world experience, but they are instructive in that they enable one to measure exactly what each control does. Once one understands the controls, then he can use this knowledge to adjust the image.
-
I don't know whether I am being sloppy, or you are being extra critical, but I am not being absolutist here. I am just saying that for some of my (landscape) images of late, I have found the brightness slider usefull. Previous to this, I had never touched it.
As for your (perhaps absolutist??) statement that the Exposure slider isn't ideal for highlight recovery, I'd say this: Using the Exposure slider to darken everything and then use the Fill or Brightness to bring the darker tones back up (to where they were), OR, use the Recovery slider to drop the highlights and leave the other tones where they were; you say Tomato, I say Toma®to. However, like I said, I feel using the Recovery slider method leads to flat dull highlights. I find using the Exposure slider retains good contrast in the brighter tones.
One other thing. I think (although I am happy to be corrected) Nikos's question was rhetorical.
[a href=\"index.php?act=findpost&pid=193771\"][{POST_SNAPBACK}][/a]
No, I'm not being extra-critical and not absolutist. There is an unfortunate tendancy in this thread and in the previous one which Bill Janes referenced, for people to launch into attacks on the personae of the discussants rather than stick to the subject matter.
I agree with you that excessive adjustment of highlights with Recovery can overly flatten the highlights. Indeed, there is nothing absolutist about any of this - that's what I've been trying to say - maybe the message isn't communicating as it should. Like everything in Photoshop, there are umpteen ways to skin the cat, and it all depends on what works best for the image at hand; but there are some general principles one can start with, including the advice to use the program from top to bottom and left to right, but this isn't dogma either.
-
Mark,
Since we are talking about highlight recovery, I'm not sure why you bring up an example with underexposure. In the example you cite, the exposure control is not equivalent to increasing exposure in the camera as advertised. There are limitations to what it can do. In the example I gave, exposure does work in a more or less linear fashion.
The ACR controls in the basic panel are arranged in a logical fashion, and it is often advised to work from top to bottom. The advice of Thomas Knoll in the LL ACR tutorial (CR05, around 5:30) is instructive. When correcting images, he uses exposure to set the white value and then brightness to adjust the mid tones. With the advent of Lightroom, he noted that some photographers use exposure to adjust the mid tones and then recovery to adjust the highlights.
He does not specifically state that he uses this approach for overexposed images where highlight recovery is needed, but recovery is not the tool that he would first use. According to his suggestions, exposure would be the first tool. Brightness or recovery could be used next. Fine tuning with Curves and HSL could come later.
There are only a few sliders on the basic panel, but the number of permutations is rather large, especially when the sub panels are brought into play. A random approach to use of these sliders could consume a great deal of time.
Test charts do not duplicate real world experience, but they are instructive in that they enable one to measure exactly what each control does. Once one understands the controls, then he can use this knowledge to adjust the image.
[a href=\"index.php?act=findpost&pid=193775\"][{POST_SNAPBACK}][/a]
You drew a conclusion that the Exposure slider works in a linear fashion. You based that on an example of an experiment you performed with a test chart. Fine as far as it goes, but the example I gave was intended to suggest that maybe it is less linear than suggested when called upon for other purposes. Perhaps someone who really KNOWS the answer to this could clarify it.
Regardless of who advises what, let us just explore the logic here, and as I keep saying, what's optimal will vary from one image to anther, albeit there are general principles guiding the workflow. So let's say we start with an image which has blown highlights and is otherwise under-exposed. Where would you start? Would you ramp-up the Exposure slider blowing the highlights further, or would you Recover the highlights and then ramp up the Exposure, working inter-actively between them till you reach a limit or a visually satifactory result? Not being dogmatic, I would say it doesn't matter much. In this kind of situation, it's just a matter of workflow convenience because ACR will process all the moves in its own determined sequence regardless of when you or I adjust what. For an image of this kind, I like playing with Recovery first, just to see how much this targeted adjustment can do for me, and to see how much head-room it gives me for then correcting the under-exposure in the rest of the image. But I could have started with Exposure and then applied more Recovery.
Finally, I hope you don't believe I do any of this randomly. I've processed literally thousands of images through this plug-in and I have neither the time, patience or absence of standards to do this kind of thing "randomly". Cummon Bill, get real! OK, sermon over, back to processing!
-
Nikos, some research (open info from his website) about the individual to whom you are asking this question: Eric Chan (http://people.csail.mit.edu/ericchan/)
[a href=\"index.php?act=findpost&pid=193761\"][{POST_SNAPBACK}][/a]
I know who Eric is, I'm not sure what this has to do with my question. Both raw and de-mosaiced linear spaces are, well, linear so my question still stands.
-
My response was merely intended to suggest that you can take his word for it, but as you wish to peak further under the hood - fine by me of course, "over and out" to Eric.
-
Both raw and de-mosaiced linear spaces are, well, linear so my question still stands.
Because noise reduction in ACR is integrated in the demosaicing process.
-
Because noise reduction in ACR is integrated in the demosaicing process.
[a href=\"index.php?act=findpost&pid=193854\"][{POST_SNAPBACK}][/a]
The question was about EV compensation, I'm not sure where NR fits in this question
-
The question was about EV compensation, I'm not sure where NR fits in this question
That was my answer to your question. I think this is the point, where the "legitimacy" of the curiosity ends, as this issue has absolutely no relevance to the outcome of raw processing, except, well, regarding the noise reduction.
With "legitimate curiosity" I mean questions regarding the outcome of the raw processing, i.e. what a certain action is doing, not how. The what should be part of the native documentation, the how is proprietory information. For example it is absolutely "legitimate" to ask, what effect the "recovery" slider is causing.
Pls note, that I have no insider information regarding ACR's processing logic; I am referring to what I regard logical under the given circumstances, but that may be incorrect regarding ACR's actual processing.
-
You drew a conclusion that the Exposure slider works in a linear fashion. You based that on an example of an experiment you performed with a test chart. Fine as far as it goes, but the example I gave was intended to suggest that maybe it is less linear than suggested when called upon for other purposes. Perhaps someone who really KNOWS the answer to this could clarify it.
[a href=\"index.php?act=findpost&pid=193793\"][{POST_SNAPBACK}][/a]
From its description in the Adobe help, the Exposure slider should perform a linear scaling of the luminance data, just as decreasing the exposure by 1.0 EV scales all the picture elements by a factor of 0.5.
This can be shown by experiment with Imatest and a Stouffer wedge. With the ACR defaults, the black point is 5, which rolls off the shadows. The default Contrast of +25, Brightness of +50, and the default point curve are applied with the exposure adjustment and complicate the resulting curve.
Here are the tone curves with ACR defaults and Exposure set to 0 and -1:
[attachment=6463:attachment]
Here are the tone curves with ACR defaults except for Black = 0:
[attachment=6464:attachment]
And finally, here are the tone curves with ACR linear settings (black = 0, contrast = 0, brightness = 0, point curve = linear):
[attachment=6465:attachment]
This last set of curves demonstrates that the Exposure adjustment is indeed linear over the entire range, except for the deepest shadows where the data are not good.
Panopeeper knows quite a bit in this area and also believes the Exposure adjustment is linear. Anyone who states otherwise should back up his statement with data.
The so-called EV compensation of ACR (it is a misnomer) is a linear operation, at least that is my observation. The "brightness" adjustment is non-linear.
[a href=\"index.php?act=findpost&pid=193581\"][{POST_SNAPBACK}][/a]
Regardless of who advises what, let us just explore the logic here, and as I keep saying, what's optimal will vary from one image to anther, albeit there are general principles guiding the workflow. So let's say we start with an image which has blown highlights and is otherwise under-exposed. Where would you start? Would you ramp-up the Exposure slider blowing the highlights further, or would you Recover the highlights and then ramp up the Exposure, working inter-actively between them till you reach a limit or a visually satifactory result? Not being dogmatic, I would say it doesn't matter much. In this kind of situation, it's just a matter of workflow convenience because ACR will process all the moves in its own determined sequence regardless of when you or I adjust what. For an image of this kind, I like playing with Recovery first, just to see how much this targeted adjustment can do for me, and to see how much head-room it gives me for then correcting the under-exposure in the rest of the image. But I could have started with Exposure and then applied more Recovery.
[a href=\"index.php?act=findpost&pid=193793\"][{POST_SNAPBACK}][/a]
I think Thomas Knoll's suggestions are for routine images in general, but there is no one more qualified to give such advise. I agree that one must evaluate the individual image. The example you gave with a generally underexposed image with blown highlights represents a high contrast scene whose dynamic range is greater than that of the camera. One must decide which luminances to favor in the final image. As you note, the order in which you do the recovery and exposure adjustments does not matter, since all these adjustments are concatenated and performed in the preferred order by ACR. As Schewe demonstrates in the tutorial, a curve applied to the highlights can also be useful and can give more control than the sliders.
-
From its description in the Adobe help, the Exposure slider should perform a linear scaling of the luminance data, just as decreasing the exposure by 1.0 EV scales all the picture elements by a factor of 0.5.
This can be shown by experiment with Imatest and a Stouffer wedge. With the ACR defaults, the black point is 5, which rolls off the shadows. The default Contrast of +25, Brightness of +50, and the default point curve are applied with the exposure adjustment and complicate the resulting curve.
Here are the tone curves with ACR defaults and Exposure set to 0 and -1:
[attachment=6463:attachment]
Here are the tone curves with ACR defaults except for Black = 0:
[attachment=6464:attachment]
And finally, here are the tone curves with ACR linear settings (black = 0, contrast = 0, brightness = 0, point curve = linear):
[attachment=6465:attachment]
This last set of curves demonstrates that the Exposure adjustment is indeed linear over the entire range, except for the deepest shadows where the data are not good.
Panopeeper knows quite a bit in this area and also believes the Exposure adjustment is linear. Anyone who states otherwise should back up his statement with data.
I think Thomas Knoll's suggestions are for routine images in general, but there is no one more qualified to give such advise. I agree that one must evaluate the individual image. The example you gave with a generally underexposed image with blown highlights represents a high contrast scene whose dynamic range is greater than that of the camera. One must decide which luminances to favor in the final image. As you note, the order in which you do the recovery and exposure adjustments does not matter, since all these adjustments are concatenated and performed in the preferred order by ACR. As Schewe demonstrates in the tutorial, a curve applied to the highlights can also be useful and can give more control than the sliders.
[a href=\"index.php?act=findpost&pid=194135\"][{POST_SNAPBACK}][/a]
OK- I see from the diagrams we are talking log-linear and that I can intuitively relate to what I observe by adjusting photographs. Thanks.