Pages: [1] 2 3 ... 5   Go Down

Author Topic: Separating 'RAW' functions in a RAW converter  (Read 37948 times)

NikosR

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 622
    • http://
Separating 'RAW' functions in a RAW converter
« 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?
« Last Edit: April 30, 2008, 04:26:15 am by NikosR »
Logged
Nikos

John.Murray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 886
    • Images by Murray
Separating 'RAW' functions in a RAW converter
« Reply #1 on: April 30, 2008, 11:55:09 am »

It's my understanding that the colorspace in ACR is a combination of Prophoto gamut in a linear space.
« Last Edit: April 30, 2008, 12:05:33 pm by Joh.Murray »
Logged

Schewe

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 6229
    • http:www.schewephoto.com
Separating 'RAW' functions in a RAW converter
« Reply #2 on: April 30, 2008, 11:56:57 am »

Quote
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?

:~)
Logged

madmanchan

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2115
    • Web
Separating 'RAW' functions in a RAW converter
« Reply #3 on: April 30, 2008, 08:37:42 pm »

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.
Logged
Eric Chan

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
Separating 'RAW' functions in a RAW converter
« Reply #4 on: April 30, 2008, 09:03:41 pm »

Quote
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
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

Panopeeper

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1805
Separating 'RAW' functions in a RAW converter
« Reply #5 on: May 01, 2008, 12:13:10 am »

Quote
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.
Logged
Gabor

The View

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1284
Separating 'RAW' functions in a RAW converter
« Reply #6 on: May 01, 2008, 12:56:33 am »

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?
« Last Edit: May 01, 2008, 12:57:33 am by The View »
Logged
The View of deserts, forests, mountains. Not the TV show that I have never watched.

Denis de Gannes

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 319
Separating 'RAW' functions in a RAW converter
« Reply #7 on: May 01, 2008, 07:37:40 am »

Quote
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.
« Last Edit: May 01, 2008, 07:38:29 am by Denis de Gannes »
Logged
Equip: iMac (Ret. 5K,27"Mid 2015),macOS 10.15.6

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
Separating 'RAW' functions in a RAW converter
« Reply #8 on: May 01, 2008, 08:51:12 am »

Quote
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?
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
Separating 'RAW' functions in a RAW converter
« Reply #9 on: May 01, 2008, 08:59:03 am »

Quote
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.
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

NikosR

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 622
    • http://
Separating 'RAW' functions in a RAW converter
« Reply #10 on: May 01, 2008, 11:43:04 am »

Quote
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]

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
« Last Edit: May 01, 2008, 12:20:44 pm by NikosR »
Logged
Nikos

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
Separating 'RAW' functions in a RAW converter
« Reply #11 on: May 01, 2008, 11:58:49 am »

Quote
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 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.
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

Panopeeper

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1805
Separating 'RAW' functions in a RAW converter
« Reply #12 on: May 01, 2008, 11:59:15 am »

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

Quote
(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?

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

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

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

Quote
What proof of (counter)-concept can you offer?

English is my third language, but I would not write such a sentence.

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

Quote
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"?
Logged
Gabor

seangirard

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 55
Separating 'RAW' functions in a RAW converter
« Reply #13 on: May 01, 2008, 12:05:49 pm »

Quote
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
Logged

NikosR

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 622
    • http://
Separating 'RAW' functions in a RAW converter
« Reply #14 on: May 01, 2008, 12:14:10 pm »

Quote
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.
« Last Edit: May 01, 2008, 12:21:52 pm by NikosR »
Logged
Nikos

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
Separating 'RAW' functions in a RAW converter
« Reply #15 on: May 01, 2008, 12:17:04 pm »

Quote
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.
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

NikosR

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 622
    • http://
Separating 'RAW' functions in a RAW converter
« Reply #16 on: May 01, 2008, 12:26:32 pm »

Is it possible to have a polite disagreement without resorting to quarrels? Please?
Logged
Nikos

Schewe

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 6229
    • http:www.schewephoto.com
Separating 'RAW' functions in a RAW converter
« Reply #17 on: May 01, 2008, 12:49:01 pm »

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

Schewe

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 6229
    • http:www.schewephoto.com
Separating 'RAW' functions in a RAW converter
« Reply #18 on: May 01, 2008, 01:01:23 pm »

Quote
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]


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.

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

The View

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1284
Separating 'RAW' functions in a RAW converter
« Reply #19 on: May 01, 2008, 05:37:15 pm »

Quote
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 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)
« Last Edit: May 01, 2008, 05:37:39 pm by The View »
Logged
The View of deserts, forests, mountains. Not the TV show that I have never watched.
Pages: [1] 2 3 ... 5   Go Up