Luminous Landscape Forum
Raw & Post Processing, Printing => Digital Image Processing => Topic started by: PeterLange on August 06, 2006, 03:30:53 pm
-
While I’m currently looking for a new P&S camera, Micheal’s unbiased review on the Powershot S3 IS was very welcome. One might think that such a camera should offer RAW recording; however, that’s regrettably not the case… Reading the article carefully, it seems that an ‘old’ strategy could gain ground again – which is to set a camera to Low Contrast & Low Sharpening in order to obtain a less ‘baked’ file for further processing in Photoshop.
Following my thoughts, I did some respective comparison tests with my candid G3 (which also supports Raw). Purpose was to see how far said approach could be driven with regard to image quality… Anyway, in this context it was more by mistake that I came across the following effect:
*After* treating an 8 bit file with some ‘heavy’ adjust layers, it was largely possible to avoid a comb-like histogram by changing to 16 bit – *just before* flattening the layers. Without this trip to 16 bit, considerable voids would have been created. Everything properly compared with an updated histogram.
/> 8 bit image file ‘in’ sRGB
/> added some adjust layers in Photoshop
(optionally: /> file saved in psd format)
/> changed to 16 bit precision
/> flattened the layers
/> changed to 8 bit again
(optionally: file saved as JPG or TIFF)
In another discussion some months ago it was concluded that it can make some sense to change an 8 bit file to 16 bit for editing (though there are certainly different opinions). Changing to 16 bit of course doesn’t create real 16 bit precision; however, subsequent processing seems to be carried out in a more precise way… On this basis I find it interesting that it seems to be basically 'enough' to have 16 bit in place just for the moment when the layers are flattened. Above sequence shows that the file was never handled at 16 bit which can be quite time-consuming depending on a computer’s capabilities. Also, no 16 bit file had to be saved which can eat up a lot of storage space.
… just found it worth to report.
Comments would be appreciated.
Peter
--
-
The flaw is that Photoshop adds a bit of noise in the mode change that can alter the appearance of the histogram giving it less combing...check Color Settings under More Options, uncheck the option to Use Dither and repeat any tests. Odds are you'll still see the combing that adding noise removed. Also, the histogram combing is -NOT- an indicator od anything other than a lack of levels at a certain place. It doesn't mean anything other than the image will be more prone to banding, not that the image HAS banding.
-
In my opinion , your " fake 8 - 16 " technique
is another evidence that you should trust your eyes, at least as much as your histogram .
There is another way to improve a "comb histogram " .
Just decrase images size with one or two pixels , and your spikey histogram goes nice and smooth , obviously the image has not improved , but your " histogram aware" customer is happy :-)
-
There is another way to improve a "comb histogram " .
[a href=\"index.php?act=findpost&pid=72724\"][{POST_SNAPBACK}][/a]
A healthy dose of Gaussian Blur will remove any of the combs.
As to the quality of the new edited image.....
-
The flaw is that Photoshop adds a bit of noise in the mode change that can alter the appearance of the histogram giving it less combing...check Color Settings under More Options, uncheck the option to Use Dither and repeat any tests.]
Well – there seem to be two different mechanisms involved.
Photoshop indeed 'dithers' the conversion from 16 bit down to 8 bit.
Just remembered David Dunthorn’s notes on this subject
(though I disagree with many of his opinions):
http://www.c-f-systems.com/Phototips.html (http://www.c-f-systems.com/Phototips.html)
However, doing what you suggest (‘use dither’ disabled)
there’s still less combing with above suggested trip to 16 bit
compared to a pure 8 bit route.
When an adjust layer like e.g. a steep curve is applied with 16 bit precision
(on data which are essentially spread with 8 bit distances)
I would expect that this creates many in-between values on an 8 scale.
Changing back to 8 bit seems to lead to a more proper, gentler rounding
than applying the curve on a pure 8 bit basis… At least this *could* be an explanation.
Also, the histogram combing is -NOT- an indicator od anything other than a lack of levels at a certain place. It doesn't mean anything other than the image will be more prone to banding, not that the image HAS banding.
[a href=\"index.php?act=findpost&pid=72710\"][{POST_SNAPBACK}][/a]
Yep. Perfectly agreed.
I would call it as a kind of 'pre-damage'.
Peter
--
-
Here's a better idea:
1. Open the JPEG in PS.
2. Convert to 16-bit mode.
3. Run Neat Image, Noise Ninja, or other similar noise reduction tool. This will interpret the "all values are divisible by 256" property of the JPEG data as a type of noise, and will adjust the data values so that they are NOT all evenly divisible by 256 after noise removal.
Now you can run your levels, curves, and other adjustments with results about 70-80% as good as working the original RAW, and toothcomb histograms will not be a problem. It's far better than editing in 8-bit mode.
-
Here's a better idea:
1. Open the JPEG in PS.
2. Convert to 16-bit mode.
3. Run Neat Image, Noise Ninja, or other similar noise reduction tool. This will interpret the "all values are divisible by 256" property of the JPEG data as a type of noise, and will adjust the data values so that they are NOT all evenly divisible by 256 after noise removal.
Now you can run your levels, curves, and other adjustments with results about 70-80% as good as working the original RAW, and toothcomb histograms will not be a problem. It's far better than editing in 8-bit mode.
… very clear and comprehensive statement,
much appreciated.
Now for example, let’s take a simple Photoshop technique for color noise reduction:
Option (A.)
1.) Open the JPEG in PS.
2.) Convert to 16-bit mode.
3.) Duplicate the background layer, change to Color blend mode at reduced Opacity of e.g. 75% for a start - in order to apply a Gaussian blur of some pixel width.
4.) Add further adjust layers depending on needs
5.) Flatten the layers
Option (B.) – just differs by the sequence
1.) Open the JPEG in PS.
2.) Duplicate the background layer, change to Color blend mode at reduced Opacity of e.g. 75% for a start - in order to apply a Gaussian blur of some pixel width.
3.) Add further adjust layers depending on needs
4.) Convert to 16-bit mode.
5.) Flatten the layers
Both options are not perfectly the same; however, if my tests are correct: there are said ‘in-between’ data created in both cases; these are really 16 bit (15 bit more precisely) as they don’t have an even-numbered 8-bit-equivalent anymore.
My point is that it seems to be possible to introduce parts of the 16 bit charm at a quite late stage (when Photoshop really applies & executes the layers for flattening).
Peter
--
-
And mine is that for many editing operations, especially levels, curves, and sharpening, going to 16-bit mode immediately has many tangible benefits. You're giving up a lot by procrastinating.
-
... You're giving up a lot by procrastinating.
Strictly referring to a PS layer structure
-
let’s agree to disagree.
Peter
--
-
Strictly referring to a PS layer structure
-
let’s agree to disagree.
--
[a href=\"index.php?act=findpost&pid=72857\"][{POST_SNAPBACK}][/a]
You can only disagree on the subjective importance, but the facts of arithmetic are that if you edit images in 8-bit mode, they become less and less a representation of the subject, and more and more a collection of mathematical/sampling artifacts that loosely resemble the subject.
-
... but the facts of arithmetic are that if you edit images in 8-bit mode, they become less and less a representation of the subject, and more and more a collection of mathematical/sampling artifacts that loosely resemble the subject.
John,
This is not a Dan Margulis discussion. So far no one advocated for 8 bit only. The question was about how to deal with a given 8 bit file and in particular when to introduce 16 bit.
Here’s a numerical example:
1.) Create a new file in 8 bit mode (sRGB)
2.) Fill this background layer with one single color of RGB= 200, 100, 100.
Option (A.)
3.) Change to 16 bit mode.
The ‘16 bit’ readings from the info pallet should indicate: 25700, 12850, 12850
4.) Add a New layer to fill it with another color of RGB= 201, 101, 101
The ‘16 bit’ readings from the info pallet should indicate: 25829, 12979, 12979
5.) Set this layer to 50% Opacity.
6.) Flatten the layers
The final ‘16 bit’ readings from the info pallet should indicate: 25765, 12915, 12915
Option (B.)
3.) Add a New layer to fill it with another color of RGB= 201, 101, 101
4.) Set this layer to 50% Opacity.
5.) Change to 16 bit mode.
6.) Flatten the layers
The final ‘16 bit’ readings from the info pallet should indicate: 25765, 12915, 12915
Both options produce the same result. The final numbers represent the arithmetic average of both original colors. The resulting numbers are really high bit as they don’t have an integer 8-bit-equivalent anymore.
It was not necessary to create the colors in 16 bit mode. The only important thing was to have 16 bit precision in place just when the layers are flattened. Needless to say that many more examples can be created with Levels, Curves, etc…
In summmary: You could take the 8 bit file, add all adjust layers needed (for Smoothing, Sharpening, Levels, Curves, etc.), save it as psd file…- …and when you then change to 16 bit mode in order to flatten the layers, it yields real high bit precision.
Peter
--
-
This is not a Dan Margulis discussion.
--
[a href=\"index.php?act=findpost&pid=72892\"][{POST_SNAPBACK}][/a]
Thank goodness. That's a painful experience.
-
The only important thing was to have 16 bit precision in place just when the layers are flattened.
…
In summmary: You could take the 8 bit file, add all adjust layers needed (for Smoothing, Sharpening, Levels, Curves, etc.), save it as psd file…- …and when you then change to 16 bit mode in order to flatten the layers, it yields real high bit precision.
...
--
[a href=\"index.php?act=findpost&pid=72892\"][{POST_SNAPBACK}][/a]
I assume that the same is true when merging layers as well (Merge, Merge Up, Merge Visible, etc.)?
This would suggest that for people who like to 'Merge Up' alot while editing, the conversion to 16-bit would have to occur earlier than later.
-
It was not necessary to create the colors in 16 bit mode. The only important thing was to have 16 bit precision in place just when the layers are flattened. Needless to say that many more examples can be created with Levels, Curves, etc…
In summmary: You could take the 8 bit file, add all adjust layers needed (for Smoothing, Sharpening, Levels, Curves, etc.), save it as psd file…- …and when you then change to 16 bit mode in order to flatten the layers, it yields real high bit precision.
Nonsense. Try taking those colors and do several level or curve adjustments in 8-bit mode, with some sharpening and color corrections added in, like fixing a scan of an underexposed daylight-balanced film negative exposed under fluorescent lighting., flatten, and then do the same sequence of operations in 16-bit mode and flatten, and see if the numbers still match. I have an example of this you can play with here (http://visual-vacations.com/Photography/16_vs_8.htm). There's a 16-bit TIFF image you can download, and a Photoshop action that performs the operations. Run the action on the image in 8-bit mode, then do so again in 16-bit mode. The difference is obvious; run the test for yourself if you don't believe the comparison images I posted of the results.
The problem with your premise is that noise reduction and sharpening cannot be done by adjustment layers, and should be done (at least capture sharpening) immediately following RAW conversion in 16-bit mode for best results. By starting out in 8-bit mode, you are screwing up some of the most critical steps in the image editing process. By starting with a JPEG, you have to accept some compromise of final image quality, but you can minimize those compromises with the steps I mentioned earlier. Your proposed editing method does nothing to solve these issues.
Take my sample TIFF, convert it to 8-bit mode, and add adjustment layers to it to make it look as good as possible, then open another copy, leave it in 16-bit mode, add the same set of adjustment layers, and compare the images. I guarantee they won't look the same, and that the 16-bit image will look much better, especially in the shadows.
-
PeterLange wrote:
>> This is not a Dan Margulis discussion. …<<
Thank goodness. That's a painful experience.
Well – I guess I was too optimistic.
Peter
--
-
In summmary: You could take the 8 bit file, add all adjust layers needed (for Smoothing, Sharpening, Levels, Curves, etc.), save it as psd file…- …and when you then change to 16 bit mode in order to flatten the layers, it yields real high bit precision.
[a href=\"index.php?act=findpost&pid=72892\"][{POST_SNAPBACK}][/a]
Uh, wrong...this will never produce "real high bit precision"...the ONLY thing you'll get is the marginal benefit of doing adjustments in 16 bit on 8 bit images which is indeed marginal.
Note: an adjustment layer created in 8 bit whose file is mode changed to 16 bit will flatten in 16 bit with 16 bit precision of the adjustment, however, if you to a layer mask while in 8 bit, then mode change, the layer mask in 16 bit will only be 8 bit precise. Also, ANYTHING you do with "pixels" while in 8 bit will also be mode changed to 16 bit and suffer the same only marginal benifit.
But in no way can any of this be construed as having "real high bit precision"...the ONLY mild benefit you would get is 16 bit precision adjustments to 8 bit/channel data which is simply not the same as real high bit precision. Face it, if all you start with is 8 bits/channel, the best you'll EVER have is 8 bit precision...
-
Nonsense. ...
Simple ideas are often most challenging to understand.
In Photoshop, all adjustments and all decisions made by the user are either on an 8-bit scale (0 to 255) or even more roughly ranging from 0 to 100. I mean who in the world sets the anchor points of a curve with 16-bit precision.
Nonetheless, the operations itself – upon being applied to the image data - can anytime create real high bit values (see above example). Executing the adjust layers in 8-bit mode leads to a cumulative rounding error. Executing the adjust layers in 16-bit mode simply prevents this. But there is NO need to create or store the adjust layers in 16-bit mode.
In short: there’s no need to write down your order in calligraphy – it just has to be executed as precisely as possible.
There's a 16-bit TIFF image you can download, ... Take my sample TIFF, convert it to 8-bit mode, and add adjustment layers to it to make it look as good as possible, then open another copy, leave it in 16-bit mode, add the same set of adjustment layers, and compare the images.
You’re changing the rules while the game is running. We were starting with an 8 bit file. Also, you persistently refuse to consider the sequence I suggest (layers first, 16 bit then, flatten last).
The problem with your premise is that noise reduction and sharpening cannot be done by adjustment layers
LOL.
See color noise reduction as suggested above / here:
http://www.luminous-landscape.com/tutorial...-gremlins.shtml (http://www.luminous-landscape.com/tutorials/color-gremlins.shtml)
See all kinds of layer-based sharpening techniques:
http://ronbigelow.com/articles/sharpen4/sharpen4.htm (http://ronbigelow.com/articles/sharpen4/sharpen4.htm)
http://www.pixelgenius.com/tips/schewe-sharpening.pdf (http://www.pixelgenius.com/tips/schewe-sharpening.pdf)
from: http://www.pixelgenius.com/tipsandtechniques.html (http://www.pixelgenius.com/tipsandtechniques.html)
Peter
--
-
...
But in no way can any of this be construed as having "real high bit precision"...the ONLY mild benefit you would get is 16 bit precision adjustments to 8 bit/channel data which is simply not the same as real high bit precision. Face it, if all you start with is 8 bits/channel, the best you'll EVER have is 8 bit precision...
8-bit is not simply 8-bit; it’s 8-bit-gamma-encoded.
Face it, camera engineers know what they do (mostly). Starting with the initial analogue-to-digital conversion, the usual precision of 12 bit per channel is maintained through all steps of in-camera processing including gamma encoding. The following equation shall serve for illustration:
RGB_8bit_gamma-encoded = 255 x (RGB_12bit-linear / 4095)^(1/2.2)
Here’s the translation to 8-bit-gamma-encoded (left) from 12bit-linear (right):
0 <-/ 0
6 <-/ 1
8 <-/ 2
10 <-/ 3
11 <-/ 4
12 <-/ 5
13 <-/ 6
14 <-/ 7
15 <-/ 8
16 <-/ 9
17 <-/ 10
17 <-/ 11
18 <-/ 12
19 <-/ 13
19 <-/ 14
20 <-/ 15
21 <-/ 16
21 <-/ 17
22 <-/ 18
22 <-/ 19
23 <-/ 20
…
You see that you really need every single 12 bit level (linear) to get an almost unbroken scale with 8-bit-gamma-encoded in the shadows (where it really counts). Even, it would be better to have a 14 or 16 bit input to meet the needs of said 8-bit-gamma-encoded scale.
That is why some people say that 8-bit-gamma-encoded is as much worth as 12-bit-linear.
On this basis, it’s also very nice to reconsider the comparison of levels vs. f-stops…
Peter
--
-
8-bit is not simply 8-bit; it’s 8-bit-gamma-encoded.
[a href=\"index.php?act=findpost&pid=73015\"][{POST_SNAPBACK}][/a]
Uh, actually, if you are talking about 8 bit jpgs from a camera, wrong again...while you may end up with preserved luminance data in a camera jpg, the amount of compression going on in color means you actually end up with more like 7.5 bits of prescision in a camera jpg.
You seem hellbent on trying to convince yourself that camera jpgs are less bad than they are and that somehow, majically, converting to 16 bit for edits gives you something. It gives you a "little bit" of enhanced precision only in the color/tone adjustments but nowhere near "high bit precision". About all you can say is it's less bad than pure 8 bit editing...but not by much.
-
8-bit is not simply 8-bit; it’s 8-bit-gamma-encoded.
Face it, camera engineers know what they do (mostly).
[a href=\"index.php?act=findpost&pid=73015\"][{POST_SNAPBACK}][/a]
Yes, they know that the camera will still sell if its JPEGs are not good representations of the sensor capture.
8-bit gamma adjusted data can have a tremendous amount of DR. Its highest value with 2.2 gamma is about 196,000x as high as its lowest value, as opposed to about 4000:1 for 12-bit RAW data. Unfortunately, JPEGs made by cameras simply don't use it very well, because they are made not to capture DR but to look good subjectively, while saving storage space. The shadows are typically posterized, blocky, and have color biases near black. A stop or more of RAW highlights are typically clipped away for the JPEG. The 12-bit linear RAW data is a much better place to start from, with user-control in a converter optimized for the shot.
-
Simple ideas are often most challenging to understand.
Obviously, or we wouldn't still be having this discussion.
You’re changing the rules while the game is running. We were starting with an 8 bit file. Also, you persistently refuse to consider the sequence I suggest (layers first, 16 bit then, flatten last).
I'm not changing the rules, I'm pointing out a glaring flaw in your editing method, and offering a much better alternative. If you take my 16-bit sample TIFF, convert it to 8-bit, and then duplicate the action steps via adjustment layers as you suggest, the resulting image is going to have heavily posterized shadows, just like the JPEG posted on my web site showing the result after running the action in 8-bit mode. So your proposal accomplishes nothing. OTOH, if you convert my sample TIFF to 8-bit or start out with the JPEG, convert to 16-bit, run a Neat Image pass, and then run the action or apply the equivalent stack of adjustment layers, you'll get a result that won't be as good as the one derived from RAW processed 100% 16-bit, but will be much better than anything processed in 8-bit mode, whether via actions or ajdustment layers.
LOL.
See color noise reduction as suggested above / here:
http://www.luminous-landscape.com/tutorial...-gremlins.shtml (http://www.luminous-landscape.com/tutorials/color-gremlins.shtml)
See all kinds of layer-based sharpening techniques:
http://ronbigelow.com/articles/sharpen4/sharpen4.htm (http://ronbigelow.com/articles/sharpen4/sharpen4.htm)
http://www.pixelgenius.com/tips/schewe-sharpening.pdf (http://www.pixelgenius.com/tips/schewe-sharpening.pdf)
from: http://www.pixelgenius.com/tipsandtechniques.html (http://www.pixelgenius.com/tipsandtechniques.html)
Peter
You're confusing image layers and adjustment layers; the techniques you cited save the results in separate layers so you can adjust the intensity of the edit by changing the opacity of the layer, but there is no such thing as a "Neat Image noise reduction adjustment layer" or "unsharp mask adjustment layer" in Photoshop's adjustment layer palette. Just because a tool saves its results in a separate layer does NOT mean it uses an adjustment layer to create the result.
Image layers contain actual image data; adjustment layers do not--all they are is an instruction to perform a specific adjustment (level, curve, hue/saturation, etc.) on whatever image layer(s) are below them in the layer stack, with an optional layer mask to limit the adjustment to specific areas of the image if desired.
-
...
You seem hellbent on trying to convince yourself that camera jpgs are less bad than they are...
Here’s an inspiring article:
http://www.robgalbraith.com/bins/multi_pag...cid=7-6468-7844 (http://www.robgalbraith.com/bins/multi_page.asp?cid=7-6468-7844)
‘All of Majoli's pictures are captured in JPEG format…’
Why not just saying that Photoshop is an excellent tool to make the best of a non-ideal situation like JPGs from in-camera conversion.
Honestly, I would not like to see Photoshop as a plug-in for Camera Raw.
In particular IF I decide to buy a Powershot S3 IS.
... and that somehow, majically, converting to 16 bit for edits gives you something. It gives you a "little bit" of enhanced precision only in the color/tone adjustments but nowhere near "high bit precision". About all you can say is it's less bad than pure 8 bit editing...but not by much.
For example, let’s take a ready processed Raw file in ProPhoto RGB at 16 bit. Provided that there are no out-of-sRGB colors, do you see a difference on screen when you convert to sRGB and then change to 8 bit mode?
I guess not. Because the 8-bit data are skillfully arranged through gamma-encoding. And, the sRGB gamut is small enough to avoid perceivable 8-bit quantization errors.
So why should an 8-bit JPG released from a camera bear the end of days. Some highlight details are probably missing due to the S-curve which is applied during in-camera processing (to accomplish an output-referred rendition), but situation should improve when the shot is done with the camera set to Low Contrast. Sure, there are further issues to address like noise, a lack of sharpness…
But e.g. with a first step of noise reduction in PS – whether done this way or that way, as long as executed at 16 bit – you have high bit data again (which don’t have an integer 8 bit equivalent anymore) to work with…
Peter
--
-
8-bit gamma adjusted data can have a tremendous amount of DR. Its highest value with 2.2 gamma is about 196,000x as high as its lowest value, as opposed to about 4000:1 for 12-bit RAW data.
Uh, would you mind to disclose the equations behind these insights.
Be sure that some math would be no problem.
--
-
If you take my 16-bit sample TIFF, convert it to 8-bit, and then duplicate the action steps via adjustment layers as you suggest, the resulting image is going to have heavily posterized shadows, just like the JPEG posted on my web site showing the result after running the action in 8-bit mode. So your proposal accomplishes nothing.
OTOH, if you convert my sample TIFF to 8-bit or start out with the JPEG, convert to 16-bit, run a Neat Image pass, and then run the action or apply the equivalent stack of adjustment layers, you'll get a result that won't be as good as the one derived from RAW processed 100% 16-bit, but will be much better than anything processed in 8-bit mode, whether via actions or ajdustment layers.
So your option uses Neat Image and mine does not.
And btw, where are the 16 bit with my option.
Nice comparison.
--
-
Uh, would you mind to disclose the equations behind these insights.
Be sure that some math would be no problem.
--
[a href=\"index.php?act=findpost&pid=73075\"][{POST_SNAPBACK}][/a]
255^2.2 = 196964.7
1^2.2 = 1
-
255^2.2 = 196964.7
1^2.2 = 1
Uhh......
Gamma encoding uses normalized data, always divided by (2^bpc –1); with bpc = bits per channel. Also the exponent is the inverse of that what is commonly called gamma:
255 x (255_linear / 255)^(1/2.2) = 255_encoded
255 x (128_linear / 255) ^(1/2.2) = 186_encoded
255 x (53_linear / 255) ^(1/2.2) = 128_encoded
255 x (0 /_linear / 255)^(1/2.2) = 0_encoded
You see that the lowest value of zero and the highest value of 255 don’t change when you go from a linear to a gamma encoded state. Just the distribution of data in-between changes significantly.
IF you follow the equations as suggested by Norman Koren (http://www.normankoren.com/digital_tonality.html), you will find that a 12 bit A-to-D converter can adequately describe a potential dynamic (input) range of about 9 f-stops; which means a contrast ratio of 2^9 :1 = 512 :1 (not talking about noise here).
Same is still approximately correct for an 8-bit file (gamma-encoded) due to above explained trick (http://luminous-landscape.com/forum/index.php?showtopic=11729&view=findpost&p=73015): gamma-encoding on a 12 bit basis first, reduction to 8 bit then. This leads to a kind of ideal distribution of levels per f-stop; i.e. there are 69 levels in zone 1, 50 in zone 2, and so on. In the deepest shadows there’s nearly a 1:1 maintenance of levels (see my post above, or again Norman Koren’s table).
Possible concerns about missing levels fall apart considering that the output dynamic range is smaller anyway; e.g. 85 cd/m2 : 0.34 cd/m2 = 250 : 1. And that’s the real problem: DR compression from e.g. a luminous landscape of DR 10000 : 1 to an output of e.g. 250:1.
Recommended reading (http://www.color.org/ICC_white_paper_20_Digital_photography_color_management_basics.pdf) (authored by Andrew Rodney et al.).
In practice this means that the representation on screen is much darker than reality. Again, this has nothing to do with ‘gamma’ or bit precision. It’s a physical thing: the white luminance of a monitor is easily 100x darker than a reflective white on a sunny day.
That’s why all Raw conversion software (also in-camera) likes to apply a brightening S-curve. Note, the pronunciation lies on ‘brightening’; in order to achieve a pleasing output-referred rendition. The S-shape can be seen as a minimum-damage strategy. However, if the upper shoulder compresses the highlights too much (loss of perceivable distances), it’s time to outsource this curve to Photoshop in order to add a Contrast mask (or, to consider HDR from multiple exposures).
As a personal note: There are really good reasons to shoot Raw. I would list Chromatic aberration correction among the first. Also white balance is easier to handle on the basis of native linear data. Hey, I'm mostly shooting Raw. But wrong reasoning and Raw arrogance won't be accepted .
Peter
--
-
Here’s an inspiring article:
http://www.robgalbraith.com/bins/multi_pag...cid=7-6468-7844 (http://www.robgalbraith.com/bins/multi_page.asp?cid=7-6468-7844)
‘All of Majoli's pictures are captured in JPEG format…’
Why not just saying that Photoshop is an excellent tool to make the best of a non-ideal situation like JPGs from in-camera conversion.
Honestly, I would not like to see Photoshop as a plug-in for Camera Raw.
In particular IF I decide to buy a Powershot S3 IS.
I've never said that one can't get reasonably good results from editing Camera JPEGs in Photoshop. They won't be as good from a technical perspective as 100% 16-bit edited RAWs, (which is why most technically astute photographers shoot RAW) but that doesn't mean they're worthless, either. However, the best way to process JPEGs well is not to do the major edits in 8-bit mode, even with adjustment layers as was originally proposed. You'll get a lot closer to the technical quality of 100% 16-bit edited RAWs if you convert your 8-bit image to 16-bit as soon as you open it, then edit.
For example, let’s take a ready processed Raw file in ProPhoto RGB at 16 bit. Provided that there are no out-of-sRGB colors, do you see a difference on screen when you convert to sRGB and then change to 8 bit mode?
I guess not. Because the 8-bit data are skillfully arranged through gamma-encoding. And, the sRGB gamut is small enough to avoid perceivable 8-bit quantization errors.
No, because all of the edits have been done while in 16-bit mode, and the only quantization errors left in the data are the +/- 0.5 level rounding errors inherent to the conversion from 16-bit to 8-bit anyway.
The gamut of sRGB is just small enough that 8 bits per color channel is enough to avoid visible posterization, but when using larger color spaces like ProPhoto, 16 bits are needed to avoid visible posterization and banding. Since many common subjects contain colors well outside sRGB (fall foliage, car shows, rock formations, concerts and theatrical events with colored stage lighting, flowers, fireworks, sunsets, etc), limiting yourself to 8-bit sRGB is a good way to cripple yourself as a photographer. Why bother, when 16-bit mode is just a menu click away?
So why should an 8-bit JPG released from a camera bear the end of days. Some highlight details are probably missing due to the S-curve which is applied during in-camera processing (to accomplish an output-referred rendition), but situation should improve when the shot is done with the camera set to Low Contrast. Sure, there are further issues to address like noise, a lack of sharpness…
But e.g. with a first step of noise reduction in PS – whether done this way or that way, as long as executed at 16 bit – you have high bit data again (which don’t have an integer 8 bit equivalent anymore) to work with…
This is why I shoot RAW. Yes, you can reduce the amount of highlight detail thrown away by the camera by setting the contrast as low as possible, and minimize sharpening artifacts by setting in-camera sharpening as low as possible. You can even reduce the amount of edit-induced posterization and banding by immediately switching to 16-bit mode and running noise reduction before performing any edits. But all of these are second-best compromises. Even with contrast set to minimum, the camera will still throw away highlights you might prefer to keep. And 16-bit interpolations of 8-bit data can never be as good as the original 16-bit data.
-
Even with contrast set to minimum, the camera will still throw away highlights you might prefer to keep.
[a href=\"index.php?act=findpost&pid=73134\"][{POST_SNAPBACK}][/a]
With the 20D I've determined this to be about 0.3 stops green, 0.7 stops blue, and 1.2 stops red with daylight WB and -2 contrast. Even what is retained just below the clipping point, however, is extremely posterized in terms of its real-world luminance, so you really want to use this shoulder area for catching highlights to be viewed as-is as a JPEG; not as a medium for extreme ETTR.
-
The gamut of sRGB is just small enough that 8 bits per color channel is enough to avoid visible posterization, but when using larger color spaces like ProPhoto, 16 bits are needed to avoid visible posterization and banding.
Yep.
Since many common subjects contain colors well outside sRGB (fall foliage, car shows, rock formations, concerts and theatrical events with colored stage lighting, flowers, fireworks, sunsets, etc), limiting yourself to 8-bit sRGB is a good way to cripple yourself as a photographer.
"Bear in mind that the in-camera conversions almost certainly don't use straight matrix profiles, rather they all use highly proprietary gamut compression techniques that the camera vendors definitely consider part of their crown jewels."
Quoted from here (http://www.adobeforums.com/cgi-bin/webx?14@@.3bbf17f1/9) (post #10).
And that’s not the only trick as far as I can tell. In order to reach a pleasing rendition, colors are moved in 3D on a per hue basis; at least regarding saturation + brightness (aside from the tone curve). Interesting chapter, and I would love to know if and what kind of Color Appearance Models are standing behind…
Sure, sRGB is a tiny space. No need to enter into gamut comparisons, etc.
Peter
--
-
I’ve just tortured a Granger rainbow (http://www.colorremedies.com/realworldcolor/downloads/GrangerRainbow.tif.zip) a little bit (starting w/8-bit, sRGB assigned) by adding two nice adjust layers:
1. layer) Applied a Gaussian blur of 4 pixel width on a Duplicated layer in Color blend mode (though there’s probably less need for color noise reduction on a Granger rainbow).
2. layer) Levels’ adjust layer w/Shadows 20, Mids 5.0, Highlights 220 (OK, that’s strong).
The image at 100% magnification shows dark blotch and a kind of posterization along the black border at the bottom. However, these irregularities disappear instantly when changing to 16-bit mode... !!
It’s even possible to go back and forth on the History palette to repeat this effect. And also the updated histogram is worth a look, respectively.
In a reference test, there was however no additional benefit from changing the Granger rainbow immediately to 16 bit mode, before creating both layers.
For me, this short trip to 16-bit is still a nice trick - in the sense of an ‘insurance’ with regard to real-world images.
That said, there are also limitations. For example, any functional layer which is created via New layer + merge visible layers. Or, the use of third-party software like e.g. NoiseNinja or PK Sharpener. In such cases it’s certainly best to change from 8 to 16-bit immediately, from the beginning.
Peter
--
-
Uhh......
Gamma encoding uses normalized data, always divided by (2^bpc –1); with bpc = bits per channel. Also the exponent is the inverse of that what is commonly called gamma:
255 x (255_linear / 255)^(1/2.2) = 255_encoded
255 x (128_linear / 255) ^(1/2.2) = 186_encoded
255 x (53_linear / 255) ^(1/2.2) = 128_encoded
255 x (0 /_linear / 255)^(1/2.2) = 0_encoded
You see that the lowest value of zero and the highest value of 255 don’t change when you go from a linear to a gamma encoded state. Just the distribution of data in-between changes significantly.
Nope. Zero is irrelevant. One is the lowest meaningful "step", not zero. Zero is The Joker, The Fool, and has no relevance to DR.
Now, you may not want to count exactly from 1, since there is nothing to resolve below it, but the fact of the matter is, if you translate 12-bit linear data to 8-bit 2.2-gamma-adjusted data, the linear values are very sparse relative to the gamma-adjusted ones, in the deepest shadows, so even if you choose the third or fourth lowest recorded level as the center of your usable lowest value, it is still quite a bit denser in the 8-bit gamma-adjusted scale, regardless of whether you use 4095 or 2048 (standard) as the whitepoint for the 12-bit linear. Here is the correspondence of the first 26 2.2-gamma-adjusted values (grey column is 8-bit, white column is scaled to 4095 linear values):
.
[a href=\"index.php?act=findpost&pid=73120\"][{POST_SNAPBACK}][/a][/quote]
How can my saying that 8-bit gamma-adjusted data can convey more DR than RAW can, be interpretted as "RAW arrogance"?
-
... if you translate 12-bit linear data to 8-bit 2.2-gamma-adjusted data, the linear values are very sparse relative to the gamma-adjusted ones, in the deepest shadows ... (grey column is 8-bit, white column is scaled to 4095 linear values):
I’m glad to see that the math (table) is now correct and corresponds to mine; according to (http://luminous-landscape.com/forum/index.php?showtopic=11729&view=findpost&p=73015):
RGB_8bit_gamma-encoded = 255 x (RGB_12bit-linear / 4095)^(1/2.2)
Purpose was to illustrate that a 8-bit-gamma-encoded scale even can hold the deepest shadows of an 12-bit-linear scale. As a tradeoff, there are less levels dedicated to the highlights where it’s visually less important. It’s simply a skillful distribution, making the best of limited resources – under consideration of human vision (though gamma-encoding was never meant to comply to human vision; it was invented to compensate for the non-linear input/output relationship of CRTs).
If you’re really picky, you would now have to consider that sRGB does not represent a regular 2.2 gamma. The TRC tags in fact hold a curve which starts significantly less steep, then goes up to a ‘simplified gamma’ of 2.2 (the latter is what the custom profile function in PS indicates). The equation in detail can be found somewhere at Bruce Lindbloom’s and/or Gernot Hoffmann’s website.
Anyway, this will almost solve the problem which you now see with the ‘sparse’ linear scale.
... You can easily get at least 2, maybe 3 stops more DR from the 8-bit, if the source of data can provide it.
Breaking up the DR into zones is not the most useful way of looking at things, IMO. It is an easy way for people who are not good with math to repeat what they read, though.
Nope. It’s just the other way round.
A contrast ratio is a quite poor tool to describe DR. Because minor changes of the denominator drastically change the ratio. For example let’s take two monitors with different black points of 0.25 and 0.5 cd/m2. In one case you get 85 cd/m2 : 0.25 cd/m2 = 340 : 1. In the other case the result is 170 : 1. The same image on both monitors won’t look as different as the ratios seem to suggest. White luminance is much more important than such fluctuations around the black point.
Coming back to the input DR of cameras, Norman Koren’s procedure and table are completely valid: Calculate through the zones, do it right, and decide if you have enough levels per zone for a meaningful description with regard to perception. The Weber-Fechner law is a reasonable starting point, though it’s not valid in the shadows (there are less levels needed).
A 12 bit A-to-D converter is good for about 9 zones.
8-bit-gamma-encoded data can hold this barely.
However, output DR with monitors & prints is the limiting factor anyway.
How can my saying that 8-bit gamma-adjusted data can convey more DR than RAW can, be interpretted as "RAW arrogance"?
Peter wrote: “Face it, camera engineers know what they do (mostly).”.
John wrote: “Yes, they know that the camera will still sell if its JPEGs are not good representations of the sensor capture.”
Anyway, the whole question is not, if Raw is better. We’ve gone though this: it is, in terms of ultimate image quality. The challenge is to understand why JPG captures can be to some extend surprisingly reasonable, less worse than maybe expected. Or, what are the core strengths of Raw, and which JPG issues can be easily overcome with a little bit Photoshop wizardry…
And in this context, it might not be wrong to risk a look at different opinions:
/> Tom Niemann on his rich website (http://www.epaperpress.com/psphoto/index.html) (‘So for my purposes I shoot sRGB JPEGs’).
/> Ken Rockwell’s polarizing point of view (http://www.kenrockwell.com/tech/raw.htm).
/> Noel Carboni, whom former RG-members will certainly remember (http://actions.home.att.net/dSLR_Tools.html).
/> Ron Bigelow, after writing a three-parts article (http://ronbigelow.com/articles/raw3/raw3.htm) on his understanding of the Raw advantage, finally comes out with an example which I my eyes could rather be suited to show the opposite (see the purple flower).
/> Canon seems to be extremely proud on their Digic II processor and picture styles (http://www.canon.co.jp/Imaging/picturestyle/shooting/file/index.html).
/> And finally – he may apologize to be listed here - Michael Reichmann liked to review the Powershot S3 Pro IS (http://www.luminous-landscape.com/reviews/cameras/canon-s3-review.shtml) though it does not offer Raw recording.
Peter
--