Ad
Ad
Ad
Pages: [1]   Bottom of Page
Print
Author Topic: Please help clarify this to me.  (Read 3297 times)
Ailan
Newbie
*
Offline Offline

Posts: 17


« on: December 07, 2008, 01:52:32 PM »
ReplyReply

Hi,

Can someone please help me fully understand what the following quoted paragraph means exactly? I so it in another post but a havnt been able to understand it as I would like to.


"things such as "bright, contrast, saturation, curves" should _NOT_ be done in a full feature raw processing utility. Doing these with the raw data (as opposed to post-processed gamma encoded images) seems better done in linear space than after the processing. If you don't handle these functions till AFTER the raw processing (unless you have an ability you don't mention regarding linear output) is, I think, sub-optimal."


many thanks!


Alex
Logged
Slobodan Blagojevic
Sr. Member
****
Offline Offline

Posts: 5548



WWW
« Reply #1 on: December 07, 2008, 03:50:55 PM »
ReplyReply

The author of the quote (Jeff Schewe) is arguing that adjustments such as brightness, contrast, saturation, curves, etc., are better done with the raw data (i.e., by a raw converter) than in post-processing (e.g., in Photoshop). The reason being that a raw converter does those adjustments in linear space, as opposed to gamma-encoded space.

As for the terms linear and gamma-encoded, here is one article that might help (by the late Bruce Fraser, titled: "Raw Capture, Linear Gamma, and Exposure").

Btw, Jeff Schewe and Bruce Fraser are authors of the "Camera Raw with Adobe Photoshop CS3" book.
Logged

Slobodan

Flickr
500px
Panopeeper
Sr. Member
****
Offline Offline

Posts: 1805


« Reply #2 on: December 07, 2008, 03:55:56 PM »
ReplyReply

First of all, Jeff Schewe's post means, that he *does think* that these steps should be done in the raw processing.

The underlying reason is the non-linear nature of mapping the originally linear raw data to the target color space (the color space definitions, unnecessarily, contain the mapping scheme as well).

Let's see the mapping of the 14bit linear data in sRGB; left the linear pixel values from 0 to 16383,, right the corresponding sRGB values, from 0 to 255.

1. The very dark end (apart from a small special segment at the beginning):

0060-0079: 012, 012, 012, 012, 012, 012, 013, 013, 013, 013, 013, 013, 014, 014, 014, 014, 014, 014, 015, 015,
0080-0099: 015, 015, 015, 015, 015, 016, 016, 016, 016, 016, 016, 016, 017, 017, 017, 017, 017, 017, 017, 018,


i.e. every six, later every seven, etc. linear values are mapped to the same sRGB value. After that, it is not possible to make distinction between the originally different values.

2. In the mid range:

3440-3459: 126, 126, 126, 126, 126, 126, 126, 126, 126, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127,
3460-3479: 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127,
3480-3499: 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127,
3500-3519: 127, 127, 127, 127, 127, 127, 127, 127, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128,
3520-3539: 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128,
3540-3559: 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128,
3560-3579: 128, 128, 128, 128, 128, 128, 128, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129,
3580-3599: 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129,
3600-3619: 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129,
3620-3639: 129, 129, 129, 129, 129, 129, 129, 130, 130, 130, 130, 130, 130, 130, 130, 130, 130, 130, 130, 130,


now every 59, 60 linear value gets mapped on the very same sRGB value.

3. At one stop down from the bright end:

8160-8179: 187, 187, 187, 187, 187, 187, 187, 187, 187, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188,
8180-8199: 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188,
8200-8219: 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188,
8220-8239: 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188,
8240-8259: 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188,
8260-8279: 188, 188, 188, 188, 188, 188, 189, 189, 189, 189, 189, 189, 189, 189, 189, 189, 189, 189, 189, 189,


97 different values (from 8169 to 8265) get mapped on the single sRGB value of 188.

4. At the very bright end:


16080-16099: 253, 253, 253, 253, 253, 253, 253, 253, 253, 253, 253, 253, 253, 253, 253, 253, 254, 254, 254, 254,
16100-16119: 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254,
16120-16139: 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254,
16140-16159: 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254,
16160-16179: 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254,
16180-16199: 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254,
16200-16219: 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254,
16220-16239: 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254,
16240-16259: 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255,


144 originally different values will appears as sRGB 254.

This enourmous compression is all right with 8bit monitors and printers anyway. However, if you decide to change the image a lot,, for example by decreasing the contrast (reducing the highlights) or by reducing the lightness, then many originally different pixels, which got mapped to the same value  will appear with the same value but darker - although if you had reduced the lightness before mapping, some of those pixels could be distinguished from the others.

This is an irreversible process (a "lossy compression"), thus once you did the conversion, you better don't do aggressive changes any more.
Logged

Gabor
Ailan
Newbie
*
Offline Offline

Posts: 17


« Reply #3 on: December 07, 2008, 04:57:44 PM »
ReplyReply


wow! Many thanks to both of you. I really appreciate. You have clarified it even better then I expected.

cheers,

A


Quote from: Panopeeper
First of all, Jeff Schewe's post means, that he *does think* that these steps should be done in the raw processing.

The underlying reason is the non-linear nature of mapping the originally linear raw data to the target color space (the color space definitions, unnecessarily, contain the mapping scheme as well).

Let's see the mapping of the 14bit linear data in sRGB; left the linear pixel values from 0 to 16383,, right the corresponding sRGB values, from 0 to 255.

1. The very dark end (apart from a small special segment at the beginning):

0060-0079: 012, 012, 012, 012, 012, 012, 013, 013, 013, 013, 013, 013, 014, 014, 014, 014, 014, 014, 015, 015,
0080-0099: 015, 015, 015, 015, 015, 016, 016, 016, 016, 016, 016, 016, 017, 017, 017, 017, 017, 017, 017, 018,


i.e. every six, later every seven, etc. linear values are mapped to the same sRGB value. After that, it is not possible to make distinction between the originally different values.

2. In the mid range:

3440-3459: 126, 126, 126, 126, 126, 126, 126, 126, 126, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127,
3460-3479: 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127,
3480-3499: 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127,
3500-3519: 127, 127, 127, 127, 127, 127, 127, 127, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128,
3520-3539: 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128,
3540-3559: 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128,
3560-3579: 128, 128, 128, 128, 128, 128, 128, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129,
3580-3599: 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129,
3600-3619: 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129, 129,
3620-3639: 129, 129, 129, 129, 129, 129, 129, 130, 130, 130, 130, 130, 130, 130, 130, 130, 130, 130, 130, 130,


now every 59, 60 linear value gets mapped on the very same sRGB value.

3. At one stop down from the bright end:

8160-8179: 187, 187, 187, 187, 187, 187, 187, 187, 187, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188,
8180-8199: 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188,
8200-8219: 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188,
8220-8239: 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188,
8240-8259: 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188, 188,
8260-8279: 188, 188, 188, 188, 188, 188, 189, 189, 189, 189, 189, 189, 189, 189, 189, 189, 189, 189, 189, 189,


97 different values (from 8169 to 8265) get mapped on the single sRGB value of 188.

4. At the very bright end:


16080-16099: 253, 253, 253, 253, 253, 253, 253, 253, 253, 253, 253, 253, 253, 253, 253, 253, 254, 254, 254, 254,
16100-16119: 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254,
16120-16139: 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254,
16140-16159: 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254,
16160-16179: 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254,
16180-16199: 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254,
16200-16219: 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254,
16220-16239: 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254, 254,
16240-16259: 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255,


144 originally different values will appears as sRGB 254.

This enourmous compression is all right with 8bit monitors and printers anyway. However, if you decide to change the image a lot,, for example by decreasing the contrast (reducing the highlights) or by reducing the lightness, then many originally different pixels, which got mapped to the same value  will appear with the same value but darker - although if you had reduced the lightness before mapping, some of those pixels could be distinguished from the others.

This is an irreversible process (a "lossy compression"), thus once you did the conversion, you better don't do aggressive changes any more.
Logged
JeffKohn
Sr. Member
****
Offline Offline

Posts: 1671



WWW
« Reply #4 on: December 07, 2008, 05:32:01 PM »
ReplyReply

Panopeeper, what happens to your example when you convert to 16-bit instead of 8-bit?

Logged

Panopeeper
Sr. Member
****
Offline Offline

Posts: 1805


« Reply #5 on: December 07, 2008, 05:54:52 PM »
ReplyReply

Quote from: JeffKohn
Panopeeper, what happens to your example when you convert to 16-bit instead of 8-bit?
Obviously, you got it (right). Higher precision means less or no loss.

However, AFAIK PS is still working with 15 bits in 16bit mode. I don't know how one could save the real 16 bits in 32bit mode, as you can not import a raw file in 32bit mode.

I convert all relevant raw images in 16bit ProPhoto before transferring to Photoshop (if ProPhoto, then NEVER 8bit). Typical case: frames of a panorama; they undergo extensive interpolation as the result of the warping, just like one would cause with for example "free transform" in Photoshop.
Logged

Gabor
JeffKohn
Sr. Member
****
Offline Offline

Posts: 1671



WWW
« Reply #6 on: December 07, 2008, 10:53:29 PM »
ReplyReply

Quote from: Panopeeper
Obviously, you got it (right). Higher precision means less or no loss.
The thing is, IMHO the original poster's question is still valid and unanswered. You gave a great argument against converting to and editing in 8-bit. But I haven't really seen a good explanation of why we should do as much as possible in linear space, especially if the editing tools for linear space are less effective or flexible compared to a more full-featured environement such as Photoshop. Some people seem to think that linear data itself is wonderful just because it's linear. I kind of think linear data sucks - who wants to cram half your data points into the last stop of highlights? Linear data is what we're stuck with for image capture because of the nature of sensors, but to me that in itself is not an argument for editing in a linear space. A gamma-corrected space more evenly distributes the data points across the entire range which to me seems like a good thing.

Quote
However, AFAIK PS is still working with 15 bits in 16bit mode. I don't know how one could save the real 16 bits in 32bit mode, as you can not import a raw file in 32bit mode.
True, but 2048 levels is still a heck of a lot more than 255, and the vast majority of data loss in a 15-bit conversion is going to be in the highlights where we're never going to notice that they're gone.

Quote
I convert all relevant raw images in 16bit ProPhoto before transferring to Photoshop (if ProPhoto, then NEVER 8bit). Typical case: frames of a panorama; they undergo extensive interpolation as the result of the warping, just like one would cause with for example "free transform" in Photoshop.
I'm with you there, I always edit in 16-bit. I wasn't really trying to argue with you, and if there is truly a compelling reason for doing all the editing in the raw converter (or at least as much as possible) I'm willing to be swayed. I just don't think it's a foregone conclusion. For me the final results are what matter, and I can get better results with post-processing. ACR 5.2 certainly expands the editing capabilities over previous versions, but you have to admit the gradient and local/targeted adjustments are still pretty crude compared to what's available in Photoshop.
Logged

Ailan
Newbie
*
Offline Offline

Posts: 17


« Reply #7 on: December 07, 2008, 11:03:25 PM »
ReplyReply

Hi, Many thanks for all this information. I appreciate it.

The RAW conversions I will be doing are from .FFF files produced in a Imacon X5 scanner. This files have to be processed in Flexcolor. Hasselblads software. Or exported as DNG's. And I wasnt sure if I should do the least or minimum is Flexcolor, then the rest in Photoshop. Or the opposite. It will be much better in PS regarding having a layered file, but my question is regarding quality. Which of both will produce the optimum quality image? Both ways the file will be prophoto 16 bit.

Another question is regarding the information provided is: if I edit in 16 bit prophoto I can make more aggressive corrections, but how more agressive the corrections can be in camera raw or other raw processor compared to 16 bit prophoto if any significant difference exists?

Many thanks.!



Quote from: JeffKohn
The thing is, IMHO the original poster's question is still valid and unanswered. You gave a great argument against converting to and editing in 8-bit. But I haven't really seen a good explanation of why we should do as much as possible in linear space, especially if the editing tools for linear space are less effective or flexible compared to a more full-featured environement such as Photoshop. Some people seem to think that linear data itself is wonderful just because it's linear. I kind of think linear data sucks - who wants to cram half your data points into the last stop of highlights? Linear data is what we're stuck with for image capture because of the nature of sensors, but to me that in itself is not an argument for editing in a linear space. A gamma-corrected space more evenly distributes the data points across the entire range which to me seems like a good thing.

True, but 2048 levels is still a heck of a lot more than 255, and the vast majority of data loss in a 15-bit conversion is going to be in the highlights where we're never going to notice that they're gone.


I'm with you there, I always edit in 16-bit. I wasn't really trying to argue with you, and if there is truly a compelling reason for doing all the editing in the raw converter (or at least as much as possible) I'm willing to be swayed. I just don't think it's a foregone conclusion. For me the final results are what matter, and I can get better results with post-processing. ACR 5.2 certainly expands the editing capabilities over previous versions, but you have to admit the gradient and local/targeted adjustments are still pretty crude compared to what's available in Photoshop.
Logged
Panopeeper
Sr. Member
****
Offline Offline

Posts: 1805


« Reply #8 on: December 07, 2008, 11:27:29 PM »
ReplyReply

Quote from: JeffKohn
I haven't really seen a good explanation of why we should do as much as possible in linear space
That way you can work the largest possible amount of information. The issue is not only that it is linear, but it is in the stage, where the opriginal information is still available. Once it is converted in a non-linear space, much of the info is lost.


Quote
Some people seem to think that linear data itself is wonderful just because it's linear. I kind of think linear data sucks - who wants to cram half your data points into the last stop of highlights?
Actually, you seldom get to see the data "linearly"; it looks horrendeously. The point is, that the software can work with the most detailed data.

Think for example of the so-called S-curve. The application of that makes the darkest and brightest regions practically contrastless, i.e. the differences between pixels in tthose regions get eliminated. If you change your mind later, you can't retrieve that any more. For example if you increase the brightness, those pixels from the very shadow are supposed to "come forward" - but where is the contrast? It's gone forever.

Quote
True, but 2048 levels is still a heck of a lot more than 255, and the vast majority of data loss in a 15-bit conversion is going to be in the highlights where we're never going to notice that they're gone.

Those are 32768 levels (in a 15bit space); should not have mentioned it, for it is really irrelevant in most cases. However, the precision is a real issue in interpolations. In certain cases the conversion in 32bit can be justified.

Quote
if there is truly a compelling reason for doing all the editing in the raw converter (or at least as much as possible) I'm willing to be swayed. I just don't think it's a foregone conclusion. For me the final results are what matter, and I can get better results with post-processing
I too am using ACR as a preprocessor, always finishing in PS.  However, I am trying to avoid very large adjustments, like saturation, overall contrast and brightness, and changing WB is  a no-no, even though ACR makes it now possible.
Logged

Gabor
Panopeeper
Sr. Member
****
Offline Offline

Posts: 1805


« Reply #9 on: December 07, 2008, 11:35:42 PM »
ReplyReply

Quote from: Ailan
if I edit in 16 bit prophoto I can make more aggressive corrections, but how more agressive the corrections can be in camera raw or other raw processor compared to 16 bit prophoto if any significant difference exists?

1. IIRC, ACR is working always in ProPhoto, I guess in 16bit. Your selection relates only to the output.

2. If you have to/want to make certain corrections, then make them as early as possible, and in as few steps as possible (i.e. without creating a file and working on it later again). This means: whatever you can do in the raw conversion, do it.

However, IMO you should not see these suggestions as the Ten Commandmends, only as a way to possibly enhance the final result.

As it costs me nothing to do this in ACR, I seldom change the brightness and contrast in PS, the colors even less. However, I often separate the sky and make heavy adjustments on it in PS, for that is not as sensitive as other areas are.
Logged

Gabor
BernardLanguillier
Sr. Member
****
Offline Offline

Posts: 7778



WWW
« Reply #10 on: December 07, 2008, 11:58:43 PM »
ReplyReply

Quote from: Panopeeper
I too am using ACR as a preprocessor, always finishing in PS.  However, I am trying to avoid very large adjustments, like saturation, overall contrast and brightness, and changing WB is  a no-no, even though ACR makes it now possible.

You are saying that you are doing these large adjustements in ACR, right?

Cheers,
Bernard
Logged

A few images online here!
Panopeeper
Sr. Member
****
Offline Offline

Posts: 1805


« Reply #11 on: December 08, 2008, 12:24:32 AM »
ReplyReply

Quote from: BernardLanguillier
You are saying that you are doing these large adjustements in ACR, right?
Yes, of course. I am doing all the adjustments I find necessary, no matter if they can cause such "side effects", but I am trying to minimize those unwanted effects by doing the adjustments in the initial stage.

Sharpening is an exception, of course.
Logged

Gabor
BernardLanguillier
Sr. Member
****
Offline Offline

Posts: 7778



WWW
« Reply #12 on: December 08, 2008, 01:49:54 AM »
ReplyReply

Quote from: Panopeeper
Yes, of course. I am doing all the adjustments I find necessary, no matter if they can cause such "side effects", but I am trying to minimize those unwanted effects by doing the adjustments in the initial stage.

OK, thanks. That's what I thought but I wasn't sure I had read you well. I am mostly doing the same thing.

Cheers,
Bernard
Logged

A few images online here!
Pages: [1]   Top of Page
Print
Jump to:  

Ad
Ad
Ad