pcox
Feb 8 2008, 01:28 PM
Hi folks -
I know that's a provocative title, but I'm starting to wonder. I've always been a proponent of 16 bit image processing - fully convinced by the math and happy that I've never had a problem with banding or posterization in any of my images.
I teach workshops and have been drilling into my students - 16 bit, 16 bit, 16 bit. I explained the reasons why, and everyone has gone home happy.
However, I am putting together some teaching materials to show the deficiencies of editing in 8 bit mode... and I can't break the images. I took a few RAW files, processed them each into both 16 and 8 bit images and performed the same exact adjustments on each.
I've pushed, pulled, stretched and abused the 8 bit files to the point they are hugely overprocessed and look truly awful - but no posterization. This included taking some very low-contrast images and stretching the histogram out to the full extent, several sharpening iterations, some shadow/highlight, agressive curves etc.
I applied changes to hugely underexposed images as well, trying to break the shadow areas. No joy.
I did the same things to 16 bit images and got the same results - the 16 bit images were a tiny bit better when seen at 100%, but nothing to write home about.
So am I missing something basic here? Or is the 16 bit advantage only apparent on true edge-case images?
Enlightenment appreciated.
Cheers,
Peter
jerryrock
Feb 8 2008, 02:01 PM
There may be greater differences in color gamut that can not be displayed on the monitor you are viewing the images on.
Arizona
Feb 8 2008, 02:47 PM
Hi Peter, I can run a 8 bit file through a B&W conversion such as Virtual Photographer resulting in a very chopped up histogram that looks like a comb and then run the 16 bit version through any of my other B&W converters which support 16 bit and the histogram is not all chopped up at all but completely smooth. The finely graduated tones are lost in the 8 bit and some posterization occurs. Not so in the 16 bit file.
That can make the sky very blotchy when using 8 bit files and I am sure you loose some of the very fine detail and dimensional quality in a important image in all areas of the image. That is what I see on my computer anyway.
EricM
Feb 8 2008, 02:49 PM
Jonathan Wienke has a nice demonstration of this on his website. Take a look at
Jonathan's website article. Also search on the LuLa forum for his posts relating to 16 bits.
Jonathan Wienke
Feb 8 2008, 04:08 PM
You beat me to it, Eric!
digitaldog
Feb 8 2008, 04:51 PM
EricM
Feb 8 2008, 09:13 PM
QUOTE (Jonathan Wienke @ Feb 8 2008, 04:08 PM)
I guess I just knew where to look.
cn15
Feb 8 2008, 09:56 PM
Even to my unprofessional eyes, I do see a visible drop in dynamic range and less color depth when converting from 16 to 8 bits. I noticed this effect in photoshop when I have to convert raw files to 8 bits in order to save as jpeg files. I suspect it has to do with the capability of the display. I have the NEC 2190uxi. I don't recall seeing any difference between 16 and 8 bits on my old cheapo monitor.
chuong
John Sheehy
Feb 8 2008, 11:17 PM
It really depends on what kind of operations you perform. Some couldn't care less about bit depth. If your image is very noisy or very textured, quantization will be harder to see.
You can totally destroy an 8-bit image in two steps if you try; you can do a gamma of 0.1 and then 10, or visa versa. That will decimate any image that had any kind of smoothness to its gradients. Of course, that is not something one would normally do, but some real things come close. Perhaps you want to expand the contrast of the midtones in Curves and compress the shadows and highlights, but then use the Shadow/highlight tool to bring out details in the shadows and highlights. They will posterize very easily in 8 bit mode.
JeffKohn
Feb 8 2008, 11:44 PM
It also depends on your working space. If you work in a large gamut space such as ProPhoto RGB the damage to an 8-bit file will become apparently more quickly than it would working in sRGB.
papa v2.0
Feb 9 2008, 04:55 AM
QUOTE (digitaldog @ Feb 8 2008, 09:51 PM)
whats this link to do with 16 bit v 8 bit ?
Bruce is talking about a different issue.
Jonathan Wienke
Feb 9 2008, 09:23 AM
QUOTE (papa v2.0 @ Feb 9 2008, 11:55 AM)
whats this link to do with 16 bit v 8 bit ?
Bruce is talking about a different issue.
No he isn't. Do the conversion in 8-bit mode, and you lose 87% of the unique colors in the image due to quantization errors. Convert to 16-bit mode before making the trip to LAB, and the decrease in unique colors from quantization is far less dramatic.
digitaldog
Feb 9 2008, 10:31 AM
QUOTE (papa v2.0 @ Feb 9 2008, 02:55 AM)
whats this link to do with 16 bit v 8 bit ?
Bruce is talking about a different issue.
Yes and no. Do the same tests in 16-bit, you get a decidedly different result.
jbrembat
Feb 9 2008, 01:42 PM
pcox,
there is no chance to see posterization or banding. 16 bit is a true mith.
I investigate it in deep for my editing tools.
People forget to think on difference between bits in a linear space and bits in a compressed space.
People forget that devices work at 8 bit not 16 bit.
People say you must use 16 bit in ProPhoto as it is a huge space. But they forget that for any rendering, on monitor or printer, the colors must be compressed into a smaller space.
People say: the 8 bit histogram is with holes, but they forget that 16 bit histogram is shown compressed. And, in any case, do you look the image or the histogram to judge?
Just a note: apply a curve to see holes in the histogram. save the image as jpg (good quality) and then open the saved image and look at the histogram.
16 bit must be used in raw conversion as starting point is 12/14 bit linear and you are working in a linear space.
As soon as the image is developed you are in a compressed space and 8 bit are more than enough.
EricM wrote:
Jonathan Wienke has a nice demonstration of this on his website. Take a look at Jonathan's website article. Also search on the LuLa forum for his posts relating to 16 bits
No demostration. he worked on linear space.
digitaldog, Bruce Lindbloom is correct, to go to/from Lab I use floating point. PhotoShop use fixed point math.
John wrote:
Perhaps you want to expand the contrast of the midtones in Curves and compress the shadows and highlights, but then use the Shadow/highlight tool to bring out details in the shadows and highlights. They will posterize very easily in 8 bit mode.
There is a very strong confusion on internal algorithm math and image bit dept. Very often the computations must be performed in floating point to have good results.
Jacopo
pcox
Feb 9 2008, 02:43 PM
Thanks for the responses, all.
It looks like I wasn't missing anything basic, then - the advantages are not really there for most images. Certainly there are edge cases where keeping 16 bits throughout the workflow is beneficial, but not the majority.
Jonathan - I had found your example prior to my first post and the adjustments you made to the image are so excessive as to not represent a real world example. Perhaps such radical adjustments would be beneficial in a forensic type scenario where you must extract detail no matter what the cost, but I can't see ever selling an image that needed that much in the way of editing.
Again, I'm going to continue using 16 bits as there are clearly cases where it helps, and storage is cheap. But it's an interesting thing to learn...
Cheers,
Peter
Jonathan Wienke
Feb 9 2008, 03:14 PM
JBrembat is quite wrong when he says "there is no chance to see posterization or banding. 16 bit is a true mith."Calling 16-bit's usefulness a myth is bullshit. 16-bit drivers for printers are available now, and monitors that support >8 bit video inputs are working their way into the marketplace. And even if you are printing to an 8-bit device, you'll still see less posterization from a 16-bit image, because the color space conversion is done in 16-bit mode and then rounded to the nearest 8-bit value afterward. As a result, all 256 levels are possible, in contrast to 8-bit color space conversion where the number of usable levels per channel may b half or less. The same is true when displaying images on 8-bit displays; not all posterization and banding is caused by gamut issues.
Editing in 16-bit mode will not make a noticeable difference in some images, especially if they only require minimal adjustments to be print-ready. Where 16-bit's advantages are most noticeable is in images that require significant tonal adjustments, such as to bring out shadow detail or correct underexposure. Also, in images with large out-of-focus areas or other smooth tonal gradients, 16-bit editing can be crucial to avoid posterization and banding.
I've provided one example where 16-bit editing makes a huge difference. Admittedly, it is a worst-case scenario, But I've seen enough of a difference in real-world images often enough that I've decided it's worth the overhead.
pcox
Feb 9 2008, 03:20 PM
QUOTE
I've provided one example where 16-bit editing makes a huge difference. Admittedly, it is a worst-case scenario, But I've seen enough of a difference in real-world images often enough that I've decided it's worth the overhead.
Jonathan -
Can you post an example of where you've seen this in the real world? I deal primarily in images with smooth tonal gradients and I've been using them in my tests. In areas where I have managed to break the 8 bit image, the 16 bit posterized as well.
I also deal with a lot of images where shadow detail needs to be brought out. Again, processing the RAW files twice, once in 8 bit and once in 16, I was unable to break the image without going so far over the top that the image would not be usable anyway.
Peter
pfigen
Feb 9 2008, 03:27 PM
Jonathon,
Can you post the raw file for the image you used in your example? I think that would be of interest to people wanting to investigate this further.
Jonathan Wienke
Feb 9 2008, 03:35 PM
QUOTE (pcox @ Feb 9 2008, 10:20 PM)
Jonathan -
Can you post an example of where you've seen this in the real world?
I'm currently at Walter Reed Army Medical Center being treated for some neurological problems (see my blog for more details if you're so inclined) and most of my photo archive is still in Germany.
Is the posterization you refer to on-screen or in prints? Does your printer support 16-bit printing, and if so, were you using it.
Another point to consider is that when working with RAW images, even if you output to 8-bit from the RAW converter, you're still doing most of the heavy lifting WRT tonal and exposure adjustments with either 16-bit or floating-point math depending on the internal design of the RAW converter, and are rounding to the nearest 8-bit value as the final step. If you want to see a true 8-bit/16-bit comparison, shoot RAW + JPEG in high DR situations or underexpose a stop or two. Then process the RAW and the JPEG side by side and see which one shows the most posterization, especially in shadow areas.
pcox
Feb 9 2008, 03:39 PM
Jonathan -
For the purposes of these tests I have done no processing in the RAW converter - in fact in some I even darkened and compressed the tones of the images to see if I could stack the decks.
There may well be a difference when dealing with in-camera JPGs, but that's not what I'm concerned about here - I work entirely in RAW, so I wanted to test starting from that point.
Cheers,
Peter
QUOTE (Jonathan Wienke @ Feb 9 2008, 08:35 PM)
I'm currently at Walter Reed Army Medical Center being treated for some neurological problems (see my blog for more details if you're so inclined) and most of my photo archive is still in Germany.
Is the posterization you refer to on-screen or in prints? Does your printer support 16-bit printing, and if so, were you using it.
Another point to consider is that when working with RAW images, even if you output to 8-bit from the RAW converter, you're still doing most of the heavy lifting WRT tonal and exposure adjustments with either 16-bit or floating-point math depending on the internal design of the RAW converter, and are rounding to the nearest 8-bit value as the final step. If you want to see a true 8-bit/16-bit comparison, shoot RAW + JPEG in high DR situations or underexpose a stop or two. Then process the RAW and the JPEG side by side and see which one shows the most posterization, especially in shadow areas.
digitaldog
Feb 9 2008, 04:46 PM
QUOTE (pfigen @ Feb 9 2008, 01:27 PM)
Jonathon,
Can you post the raw file for the image you used in your example? I think that would be of interest to people wanting to investigate this further.
You mean you don't recall the Raw's I mentioned on Dan Margulis silly list years ago Peter? I was pretty sure you subscribed this his list (if no longer, I can't at all blame you).
They are on my iDisk. Bruce Lindbloom has a link on his famous page that dismisses Dan's 16-bit challenge nonsense (http://www.brucelindbloom.com/):
http://www.retouchpro.com/forums/input-out...html#post104205If you read down, you'll get to hear all about Dan's lame reasons why the proof provided didn't suite him (moving the goal posts in mid-game again). He didn't buy the use of "Ultra Wide gamut working spaces" like Prophoto RGB. He wrote:
QUOTE
In early September, Andrew Rodney posted his own "real-world" example of 8-bit vs. 16-bit editing. As soon as it appeared, it was dismissed both by me and by Lee Varis because it depended on an exotic RGB definition, the ultra-wide gamut ProPhoto RGB, where the perceived impact of tiny variations is much larger than in the RGB definitions used by almost everyone. Andrewhas known for at least five years that I consider testing in such RGBs irrelevant--see "The Attempts to Obfuscate" below.
That's the pot calling the kettle black (Dan using the term Obfuscate in terms of the proof).
Anyway, you can read all his bullshit in the link above, the Raw illustrates data loss and image degradation in an 8-bit image that doesn't result in the 16-bit document. Its in a folder called 16bit challenge. You can download the Raws and do all the edits as described or just open a smaller TIFF of the two images processed as described.
My public iDisk:
thedigitaldog
Name (lower case) public
Password (lower case) public
Public folder Password is "public" (note the first letter is NOT capitalized).
To go there via a web browser, use this URL:
http://idisk.mac.com/thedigitaldog-Public Getting back to some recent comments here, some have correctly said, you may (MAY) introduce banding in 8-bit documents at some time, depending on the edits. And that's important as we don't know WHEN or HOW we may take a perfectly good 8-bit document and move it over the edge in terms of an edit that would introduce banding on some output device that may not even be on the market yet. 16-bit insures this will not happen. There's only ONE downside of high bit files today, that's their size. Everything done in a Raw converter is happening high bit. Just about every global tone and color correction on an existing rendered image (and many selective tools) work in high bit. Its an insurance policy that you can send the best 8-bit data to any device today and in the future.
Jonathan Wienke
Feb 9 2008, 04:57 PM
QUOTE (pcox @ Feb 9 2008, 10:39 PM)
Jonathan -
For the purposes of these tests I have done no processing in the RAW converter
That's impossible. Everything a RAW converter does is some kind of processing, unless you regularly work with undemosaiced linear images. You can't avoid 16-bit processing when working with RAWs. Without seeing examples, I have no way of knowing what non-optimal adjustments you made during conversion that had to be "fixed" in 8-bit mode for your tests. Check out Andrew's RAWs for test subject material.
QUOTE
There may well be a difference when dealing with in-camera JPGs, but that's not what I'm concerned about here - I work entirely in RAW, so I wanted to test starting from that point.
And the reason you shoot RAW instead of JPEG, whether you think consciously in such terms or not, has a great deal to do with the >8-bit advantage that RAW workflow offers.
pcox
Feb 9 2008, 05:38 PM
Firstly, apologies for the edits. I had a brain fart, and worked on the wrong source action (one of my own tests).
Seconly, let's try to keep the discussion civil - no need for the testiness and personal nature of some of the recent comments.
I've gone back and run the right action, and here are the results:
8 bit:

16 bit:

I honestly can't see the difference here. This was done by opening the .CRW, accepting the edits in the included .xmp and opening in Photoshop in ProPhoto, 16 bit.
I then ran the actions provided, one to create and process the 8 bit copy and the other on the 16 bit image.
For fun, I also opened the CRW as ProPhoto, 8 bit and ran the basic adjustments on it - no difference (not that I was expecting any).
Jonathan -
You're picking nits - the meaning of my saying 'I have done no processing in the RAW converter' was that I had not moved any sliders, merely accepted the defaults.
The other tests were intended to compress the histogram as much as I could in RAW, and then expand it significantly in Photoshop.
I'm also well aware of the higher-than-8-bit advantage of RAW capture - but capture depth isn't the issue. It's processing in 8 vs. 16 bit that's the subject of this debate.
Cheers,
Peter
digitaldog
Feb 9 2008, 06:12 PM
QUOTE (pcox @ Feb 9 2008, 03:38 PM)
I honestly can't see the difference here. This was done by opening the .CRW, accepting the edits in the included .xmp and opening in Photoshop in ProPhoto, 16 bit.
Well I sure can. Look in the center area of the crop of the two, the opening of the bird feeder. Look at the green bottom of the feeder below that, one's much smoother than the other. Or process both and subtract them. It may not be huge, but its visually there and one can only wonder what further editing on the 8-bit image would produce.
bernie west
Feb 9 2008, 06:23 PM
Qualifier: I work in a large university engineering library which contains 100's of digital signal and digital image processing texts, which I have a habit of browsing through whenever I shelve one.
From my reading I've discovered that humans can only differentiate about 6-bits of grayscale tones. Fiddling around on photoshop using the posterize command I can just start to see posterizing around 7-bits (although I'm not sure how accurate using this command is for the purposes of this argument). What happens when you throw colour into the mix? I'm not sure. But from my reading I recall seeing that normal humans (trichromates) can differentiate about 1 - 3 million or so colours. Now 7-bit RGB can represent about 2 million colours. So I imply from all this that anything much more than 7-bit for VIEWING is most probably wasted.
Now obviously the question is about editing, not viewing. But how much real world editing does it take to reduce an 8-bit image to a 7-bit image (ie. half the number of levels). Some examples have been shown how this can happen, and obviously 16-bit, like Andrew said, will garantee no visible degradation occurs, but in the world of only small edits surely 8-bits is enough.
It's worth remembering that in the end, no matter what bit depth your display or printer is capable of, normal humans are only going to be able to differentiate 6- or 7-bits of data anyway (hopefully my assessment of colour depth was accurate; if not, i'm more than happy to be corrected, as I'm certainly not a colour scientist).
digitaldog
Feb 9 2008, 06:28 PM
QUOTE (bernie west @ Feb 9 2008, 04:23 PM)
It's worth remembering that in the end, no matter what bit depth your display or printer is capable of, normal humans are only going to be able to differentiate 6- or 7-bits of data anyway (hopefully my assessment of colour depth was accurate; if not, i'm more than happy to be corrected, as I'm certainly not a colour scientist).
Indeed and the point is, we want to send the best 8-bits to the printer. If we start with only 8-bits, that's not necessarily going to happen. Or to put another spin in this, we have no guarantee that we'll send 8 good bits to this device. With high bit data, its a non issue.
DarkPenguin
Feb 9 2008, 06:46 PM
I smell the dullest episode of Myth Busters ever.
bernie west
Feb 9 2008, 07:05 PM
QUOTE (digitaldog @ Feb 10 2008, 09:28 AM)
Indeed and the point is, we want to send the best 8-bits to the printer. If we start with only 8-bits, that's not necessarily going to happen. Or to put another spin in this, we have no guarantee that we'll send 8 good bits to this device. With high bit data, its a non issue.
But I guess the question is, what does it take to reduce 8-bits to 7- or 6-bits(one-quarter the levels)? Obviously it can be done, but how likely is it in the normal way of things? Actually, on that Lab thing, Jonathan mentioned that 87% of colours can be lost in a Lab conversion. 13% of 16.7million equals about 2.2million colours, more than enough for human vision. Of course this depends on which colours are lost. If they are equally spaced (probably not the right term) then we can probably wear the 87% loss. However, if they are grouped in some way then this could become a problem. Just some food for thought.
By the way, in case I am inadvertantly placing myself in the Margulis camp, I actually do edit in 16-bit as much as possible, mainly for the reason Andrew said: It garantees no visible degredation.
pcox
Feb 9 2008, 07:36 PM
Andrew -
I grant you there is a very slight degredation of that small part of the image for a pretty hefty gamma and sharpening adjustment, and a modest saturation boost. And that gamma change would have been better done in RAW anyway. Personally, I wouldn't use an image that needed that much processing as neither the 8 nor 16 bit versions have resulted in a good quality image.
I think that there's a lot of hyperbole about this whole issue, and many people take the stance that you _must_ use 16 bits or you lose a whole lot of quality.
We've seen here that this is just not the case.
Only if you are interested in the absolute pinnacle of quality in the most demanding of applications, or if you need to make radical adjustments to an image in order to attempt to rescue it from the bin should you require the use of 16 bits - or if you don't mind using the space and just want to cover your bases.
Now as I said - personally I'm going to keep using 16 bit in my entire workflow (and yes, Jonathan, that includes using 16 bit mode for my Z3100). This is because storage is cheap, and while slim there are advantages to it.
My approach to my students will be to tell them about editing in 16 bit, but state the facts - it's only necessary under very narrow circumstances, and if they can't afford the space that 8 bits is just fine.
Thanks all for your help in figuring this out.
Cheers,
Peter
Panopeeper
Feb 9 2008, 07:47 PM
QUOTE (pcox @ Feb 9 2008, 02:38 PM)
I honestly can't see the difference here
Let's not argue about if the *visible* differences are important enough. There is a principal issue:
a counter-example does not prove, that there can not be other, positive examples by the millions.
If you ignore the existing differences, then you have proven that
this image and these adjustments would not justify 16bit processing.
However, when I start editing an image, I do not know if my following adjustments would justify 16bits or not. So, I start out with 16bits and archive the almost completely processed images in 16bit format.
digitaldog
Feb 9 2008, 08:01 PM
QUOTE (pcox @ Feb 9 2008, 05:36 PM)
And that gamma change would have been better done in RAW anyway.
I totally agree. It reinforces the idea that all the heavy lifting should be done in high bit, linear encoded Raw processing (despite the fellow who dismisses high bit editing and Raw processing).
The point wasn't to suggest otherwise, the point was to dismiss a silly 16-bit challenge that has been going on far too long. And the shocking result was the challenger saying the exercise was faulty due to edits made in an ultra wide gamut space.
QUOTE
Personally, I wouldn't use an image that needed that much processing as neither the 8 nor 16 bit versions have resulted in a good quality image.
And neither would I. This was, if memory serves, the default rendering of the converter. But the challenger this image was addressed to, suggests we SHOULD set the processor in such a default mode, then "fix" the rendered pixels in Photoshop (in 8-bit no less). He also said "anyone who knows what they are doing can fix a JPEG faster and better in Photoshop than a Raw in Camera Raw". Nonsense I say and when I challenged him to prove it, he dismissed this.
Read the original URL from Bruce Lindbloom about this 16-bit challenged, it sums up the nonsense that Dan has proposed from day one. A challenge that changes whenever he sees fit. Once again, the images I uploaded were simply to address this challenge not to suggest it was best practices. We should render the best possible quality from our Raw converters.
QUOTE
I think that there's a lot of hyperbole about this whole issue, and many people take the stance that you _must_ use 16 bits or you lose a whole lot of quality.
The potential to lose quality is there. We don't know when, we don't know why one edit may produce the damage. As I've said from day one, high bit editing is cheap insurance. The other side says "I challenged you to prove there's a benefit" not "I will prove there is no benefit" which is quite a different challenge. Worse, when someone does attempt to prove the point, either using simple math or an image, its dismissed. The math is undeniable. The printed results are not always so clear cut.
QUOTE
Only if you are interested in the absolute pinnacle of quality in the most demanding of applications, or if you need to make radical adjustments to an image in order to attempt to rescue it from the bin should you require the use of 16 bits - or if you don't mind using the space and just want to cover your bases.
If your goal is to produce a catalog of 1000 images of widgets on a white bkdng 3x3 on a 150 linescreen CMYK page, working in high bit probably isn't a good idea. I understand the need to get the job done quickly, based on the final reproduction requirements. If the work is for your portfolio, or a very important image you may not know how you'll ultimately reproduce, then high bit editing is simply good insurance with little penalty. That's not the mindset of the challenger of the 16-bit workflow. He states its simply not necessary. At least he did until some of us attempted to prove him otherwise and now he has modified his stance somewhat to say "sometimes" and points to those who use unnecessary (his words) ultra wide gamut, "dangerious" working spaces like ProPhoto RGB.
QUOTE
My approach to my students will be to tell them about editing in 16 bit, but state the facts - it's only necessary under very narrow circumstances, and if they can't afford the space that 8 bits is just fine.
I'd agree with you on the first part, that its probably necessary under some, narrow circumstances. I don't agree with "just fine" because I don't know what may be fine for you is unacceptable for me. And I don't know when just "fine" becomes not so fine. So, its far easier to simply keep the data in its original bit depth from the capture device and not worry about when "fine" becomes unacceptable.
Panopeeper
Feb 9 2008, 09:15 PM
QUOTE (bernie west @ Feb 9 2008, 03:23 PM)
Qualifier: I work in a large university engineering library which contains 100's of From my reading I've discovered that humans can only differentiate about 6-bits of grayscale tones
1. Perhaps you should contact some of the authors of those papers and ask them, how many squares they can distinguish between in the attached image.
2. If one can distinguish between two adjacent shades, then it is called posterization. A "continuous color" image has to consists of such shades, which can not be distinguished from each others. That way the transitions do not appear as posterizations.
Panopeeper
Feb 9 2008, 09:19 PM
Somehow I did not manage to attach the image. It can be downloaded from
http://www.panopeeper.com/Demo/100DifferentGrayshades.tif
bernie west
Feb 9 2008, 09:47 PM
QUOTE (Panopeeper @ Feb 10 2008, 12:15 PM)
1. Perhaps you should contact some of the authors of those papers and ask them, how many squares they can distinguish between in the attached image.
Not sure what your point is, as 100 shades of gray is between 6- and 7-bits, which is what I have been talking about.
A useful test would be to do 9-bits worth of gray shades and see if we can still distinguish between them.
Panopeeper
Feb 9 2008, 10:30 PM
QUOTE (bernie west @ Feb 9 2008, 06:47 PM)
Not sure what your point is, as 100 shades of gray is between 6- and 7-bits, which is what I have been talking about
1. You mentioned "about 6 bits". 100 is about 7 bits.
2. I tried to make it understandable, that the number of required shades is *much higher* than the number of distinguishable shades.
3. You are totally ignoring the main factor, namely the the question, how high the differences are between the shades. If you are looking at a monitor with contrast ratio 3000:1 (or 10000:1, they are coming), you can distinguish between much more shades, than on a cheap laptop LCD with contrast ratio 200:1.
QUOTE
A useful test would be to do 9-bits worth of gray shades and see if we can still distinguish between them
Yes, on a high-end HDTV.
bernie west
Feb 9 2008, 10:40 PM
[quote=Panopeeper,Feb 10 2008, 01:30 PM]
1. You mentioned "about 6 bits". 100 is about 7 bits.
No, 128 shades is 7 bit. Look at what I wrote. I have been talking about 6 and 7 bit.
2. I tried to make it understandable, that the number of required shades is *much higher* than the number of distinguishable shades.
try writing that next time and I won't have to read your mind anymore. Not sure what you mean anyway. Why would you require more than what you can distinguish? The extra ones won't add anymore information to the image.
3. You are totally ignoring the main factor, namely the the question, how high the differences are between the shades. If you are looking at a monitor with contrast ratio 3000:1 (or 10000:1, they are coming), you can distinguish between much more shades, than on a cheap laptop LCD with contrast ratio 200:1.
I'm not ignoring anything. I'm just making discussion points. Whatever dialogue you've got going on in your head with yourself, I'm happy for you.
Yes, on a high-end HDTV.
Actually, in print would be better.
Jonathan Wienke
Feb 10 2008, 12:35 AM
The real issue:
Starting with 8-bit data, you have more colors than the human eye can distinguish between. That's the reason 8-bit image formats are so common; they are good enough to avoid posterization due to the file format itself. But when editing in 8-bit format, quantization rears its ugly head. A single conversion from RGB to LAB can reduce an image to 13% of its original color count. Curves, levels and other adjustments have wildly variable effects ranging from negligible to drastic depending on the parameters of the adjustments.
If you edit in 16-bit from RAW, you are guaranteed to always have the best possible 8 bits to send to 8-bit devices, whether printers, monitors, or an 8-bit end-use file format like a web JPEG. If you edit in 8-bit mode, you are guaranteed NOT to have the best 8 bits available to the end user, as evidenced by toothcomb histograms. Whether that difference is distinguishable in a final print depends on the image content and the editing steps required to process it. But as the quality of monitors and printers continues to increase (like LCD panels going from 6-bit to 10-bit, and the increasing availability of 16-bit printing solutions), the differences will become more obvious. You may not see the difference now, but in 5 years it may be quite obvious, rather like buying a new set of speakers and hearing a guitar riff in the background of a favorite song you never noticed before.
Ray
Feb 10 2008, 02:27 AM
QUOTE (Jonathan Wienke @ Feb 11 2008, 02:35 AM)
Whether that difference is distinguishable in a final print depends on the image content and the editing steps required to process it. But as the quality of monitors and printers continues to increase (like LCD panels going from 6-bit to 10-bit, and the increasing availability of 16-bit printing solutions), the differences will become more obvious. You may not see the difference now, but in 5 years it may be quite obvious, rather like buying a new set of speakers and hearing a guitar riff in the background of a favorite song you never noticed before.
Jonathan,
Whilst all that is true, is it necessarily going to be an issue in 5 or perhaps 10 years time when perhaps not only will monitors be able to display the full ProPhoto RGB colors, but printers might also be able to take advantager of the full range of the gamut of colors and hues in the ProPhoto color space in 16 bit mode?
If this scenario arises, I might prefer to go back to the original RAW files and reprocess them in 32 bit with the enhanced techniques that Adobe will have presumably provided by then using my own presumably enhanced skills.
There is something to be said for not wasting space and time creating a quality for the future which might be irrelevant at the present time. On the occasions that I took some of my slides and negatives to a professional lab for scanning, I was always asked the question, "What size print do you want to make?"
At first, the question seemed a little odd. Why should I want l
ess than the highest quality scans? But I quickly caught on. For the professional, time is money. A builder doesn't build a house that is stronger than the building regulations require, but an amateur or owner builder might. Likewise, you don't spend the time and money scanning a 35mm slide at 8,000 dpi if all you want is an 8x10 print. However, if your purpose is to archive the film, then you do want the maximum quality.
16 bit processing
does take more time and
does involve more resources but it's not serving any archival purpose. The RAW file is the archive.
bernie west
Feb 10 2008, 03:13 AM
QUOTE (Jonathan Wienke @ Feb 10 2008, 03:35 PM)
But as the quality of monitors and printers continues to increase (like LCD panels going from 6-bit to 10-bit, and the increasing availability of 16-bit printing solutions), the differences will become more obvious.
No they won't if it's true that human resolution is only 7-bit (or even 8-bit)!. High bit rate is good for
editing but will do nothing for
viewing.
NikosR
Feb 10 2008, 03:39 AM
QUOTE (digitaldog @ Feb 10 2008, 02:12 AM)
Well I sure can. Look in the center area of the crop of the two, the opening of the bird feeder. Look at the green bottom of the feeder below that, one's much smoother than the other. Or process both and subtract them. It may not be huge, but its visually there and one can only wonder what further editing on the 8-bit image would produce.
In any such demonstration we are ignoring a variable factor. Jpeg (used for display) is a compressed format. I strongly suspect that the differences you notice result from Jpeg processing behaviour (of course itself based on differences in input - 8bit vs 16bit) than by any posterisation effects directly attributed to 8bit vs 16bit differences.
I'm always suspicious of such comparisons when the demonstration is based on a jpeg final product. I would rather compare TIFF images (rather hard to do on the web).
DPL
Feb 10 2008, 05:36 AM
QUOTE (pcox @ Feb 8 2008, 12:28 PM)
However, I am putting together some teaching materials to show the deficiencies of editing in 8 bit mode... and I can't break the images. I took a few RAW files, processed them each into both 16 and 8 bit images and performed the same exact adjustments on each.
It can be safely assumed that any reasonable Raw converter (whether external or in-camera) will not drop high bit precision from the A/D converter until the main processing steps and final gamma encoding are accomplished:
/> 12 or 14 bpc from the A/D converter
/> high bit Raw processing
/> output set to
a.) 16 bit or
b.) 8 bit
Hence, with any small output space such as sRGB it will be hard to impossible to show that options a.) vs b.) are different "as they are" – unless further editing steps are added outside the Raw converter e.g. in Photoshop:
b1.) 8 bit left at 8 bit
b2.) 8 bit left at 8 bit for adding adjustment layers*, but changed to 16 bit before flattening the layers.
b3.) 8 bit changed to 16 bit
/> followed by further image editing (* with b2)
Now with Levels and Curves, etc. it will be hard but it’s possible to show that b3, b2 have a competitive edge compared to b1. However, very very drastic settings are needed.
But, big but, situation gets clearer once Noise Reduction plus some Re-sharpening are the first things to be done after b1 or b3. With option b3, this will fill the reservoir with 'real' 16 bit data which don’t have an integer 8 bit equivalent any more. Resulting files can tolerate further editing somewhat better before showing posterization. For example, take an image of a blue sky which fades towards overexposed white. Now, try some highlights recovery via the S/H tool. Under the provisions explained here, b3 will often enough outperform b1.
On this basis (!), the more challenging comparison might be between a.) an unbroken high bit pipe, and b3.) recovered high bit depth...
My 2ct.
Hope this is of help.
DPL
--
Jonathan Wienke
Feb 10 2008, 09:46 AM
QUOTE (bernie west @ Feb 10 2008, 10:13 AM)
No they won't if it's true that human resolution is only 7-bit (or even 8-bit)!. High bit rate is good for editing but will do nothing for viewing.
There are still a lot of 6-bit LCD panels out there, and even 8-bit displays displaying 8-bit images in a color-managed setting are still going to have posterization on-screen that doesn't exist in an 8-bit image due to the 8-bit to 8-bit color space conversion. If the display technology has visible posterization even with non-posterized images, a slightly posterized image isn't going to stand out as such because of the limits of the monitor--everything looks slightly posterized, whether the image itself is posterized or not. But once the display itself ceases to be a contributor to the problem, any issues with the file itself become much more obvious. Just like the difference between a 96Kb/s and 256Kb/s MP# might not me noticeable with $5 headphones, but with $200 headphones it's quite distinctive.
GLuijk
Feb 10 2008, 10:51 AM
QUOTE (bernie west @ Feb 10 2008, 01:05 AM)
But I guess the question is, what does it take to reduce 8-bits to 7- or 6-bits(one-quarter the levels)? Obviously it can be done, but how likely is it in the normal way of things?
Hi Bernie, a simple S-shaped curve will make this in the shadows and in the highlights since it will compress into one single level what it was two or more differentiated levels in the original image. You just need to have a slope less or equal to 0.5 for this to happen (red lines are slope 0.5):
Red areas (slope of 0.5 or less) are affected by a compression of 2 to 1 levels or more. Yellow areas (slope between 0.5 and 1.0) are affected by a compression less than 2 to 1 levels. Only the green range (slope greater or equal to 1.0) is free of information loss but it's in it where posterization can become visible.
And I don't think this is a strange curve in real world.
This is specially important in B&W pictures which are much weaker against posterization issues since each pixel colour is defined by only one level value.
I think 8-bit images are more robust than what sometimes we think they are (or maybe human vision is worse than sometimes we think it is), but recalling digitaldog sentence with which I totally agree: "the point is, we want to send the best 8-bits to the printer. If we start with only 8-bits, that's not necessarily going to happen.", I would simply apply common sense: why assume the risk if 16-bit offers guarantees over 8-bit? as simple as that.
Schewe
Feb 10 2008, 01:39 PM
QUOTE (pcox @ Feb 8 2008, 12:28 PM)
So am I missing something basic here? Or is the 16 bit advantage only apparent on true edge-case images?
Editing in 8 bit/channel is fine for many images and for many image corrections. What you've found is that for your examples, you not yet hit upon that set of adjustments on those images that will break them. Once you do, the images are ruined...
Understand that what we are talking about is the ability to maintain "EXTRA" precision for as long as possible while editing. At this point, if you are talking about merely looking at images on a display, then you aren't really stressing the images all that much. A real big stresser is final output. Have you actually gone out to prints to check for banding? That's often where editing 8 bit/channel images show their limitations...
Also, don't forget that editing in 8 vs 16 bit has additional factors...in 16 bit files, not only is your image pixel data in 16 bit, so are your channels and layer masks (note: selections in 16 bit are still only 8 bit selections–it's one of the reasons that layer masks and channels are so important). Doing gradated adjustments in 16 bit will produce finer and more subtle adjustments than 8 bit.
The bottom line is that if you work in 8 bit/channel you may never do adjustments that end up breaking the image. A lot of that depends on the quality of the original 8 bits. If you shoot in raw and convert to 8 bit from Camera Raw, you're getting an optimal 8 bit/channel output from 12-14 bit images processed in 20 bit/channel precision down sampled to the final 8 bits/channel. In the case, you are STILL getting the benefit of high bit depth in the original raw to 8 bit processing.
A better method of testing this would be to shoot in raw & JPEG, process the raw to 16 bit and take the 8 bit JPEG and do an equal series of adjustments-particularly gradated adjustments, then run the final images out to prints and look at the prints.
The problem with editing in 8 bit images is that it's really a question of when the images will break. Photoshop is not mathematically perfect. There are rounding errors and the very act of making adjustments will often throw away data. At what point will the gradations in the image then fail? I don't know...it's really hard to tell what last step will break an image. All i know is that once you break the image (introduce banding) there's really nothing that can be done to fix it.
What I HAVE found is since I started doing all my major tone and color correction in 16 bit–both global and local adjustments–I don't have the same problems with banding than I used to have when working in 8 bits. YMMV depending on YOUR images and YOUR adjustments. For my images, it's 16 bits for as long as I can.
bernie west
Feb 10 2008, 05:08 PM
QUOTE (GLuijk @ Feb 11 2008, 01:51 AM)
Only the green range (slope greater or equal to 1.0) is free of information loss but it's in it where posterization can become visible.
And I don't think this is a strange curve in real world.
Hi Guillermo. The green range isn't really free of information loss, as you have effectively strectched n levels to cover 2n levels. In effect you have halved the information in the green section (by doubling the size of the green section), equivalent to dropping an 8-bit image to a 7-bit image. As for the curve, I dunno, it looks pretty strong to me. Later I will try it with some images and see how they look.
ps. By the way, what's the best way to send you that 5D uni white balance raw?
GLuijk
Feb 10 2008, 05:44 PM
QUOTE (bernie west @ Feb 10 2008, 11:08 PM)
Hi Guillermo. The green range isn't really free of information loss, as you have effectively strectched n levels to cover 2n levels. In effect you have halved the information in the green section (by doubling the size of the green section), equivalent to dropping an 8-bit image to a 7-bit image. As for the curve, I dunno, it looks pretty strong to me. Later I will try it with some images and see how they look.
ps. By the way, what's the best way to send you that 5D uni white balance raw?
Well I think it's all about semantics: in the green range I meant "no information loss" since the previous information doesn't get aggregated because of the curve and remains differentiated, so there is no loss of THAT initial information.
Yes, if we compare the situation of that levels range with what we would find in when applying the same curve in 16-bit, we have half the information. That's why I pointed this would be the area in danger of posterization.
Please send the 5D UniWB through
http://yousendit.com to gluijk(at)hotmail.com
What accuracy did you achieve?
Regards.
bernie west
Feb 10 2008, 08:01 PM
QUOTE (GLuijk @ Feb 11 2008, 08:44 AM)
Well I think it's all about semantics: in the green range I meant "no information loss" since the previous information doesn't get aggregated because of the curve and remains differentiated, so there is no loss of THAT initial information.
Aggregation won't be the problem (in the context of this discussion), but histogram expansion is. If you threw out half the levels in an image and then expanded the histogram to fill from 0-255, the resulting histogram will look like the histogram in your green section. It will effectively now be a 7 bit image. Aggregrating data won't change the bit level of the image as all levels in the aggregated level will remain occupied (if indeed they were in the first place).
QUOTE
Please send the 5D UniWB through
http://yousendit.com to gluijk(at)hotmail.com
What accuracy did you achieve?
I can't remember the accuracy but it was whatever I posted in the other forum about it. From memory I think they were about 1.01
Ray
Feb 10 2008, 08:32 PM
QUOTE (Schewe @ Feb 11 2008, 03:39 PM)
A better method of testing this would be to shoot in raw & JPEG, process the raw to 16 bit and take the 8 bit JPEG and do an equal series of adjustments-particularly gradated adjustments, then run the final images out to prints and look at the prints.
Jeff,
Aren't you adding another factor involving some degradation here? Jpeg is not a lossless compression and the image will have already been processed to some extent in-camera.
A fairer comparison would be, after processing the RAW in Lightroom or ACR, to convert the image twice, once in 16 bit and again in 8 bit. Do whatever further tweaking is necessary in Photoshop, applying the same changes equally to both images, then print both images the same size on the same paper. Get the borders the same width and generally avoid all tell-tale signs that might distinguish one print from the other. Mix the prints up, then see if you can tell which is from the 16 bit file without resorting to the use of a loupe.
I think most people are too busy to take the trouble. It's much easier, if there's any doubt, to just always use 16 bit. If the resources are available and memory is cheap, why not?
Nevertheless, it's an interesting issue as to just how much extreme processing is required before the 8 bit image 'breaks' as you describe it. There are certain processes in CS3E that require a lot of computing power for 16 bit images. My laptop has 2Gb of RAM and a 60GB hard drive partition which is available for the PS scratch disc (but not exclusively. It's probably about half full most of the time.)
I was surprised to find that my laptop doesn't have the resources to stack a number of 16 bit images. I've tried several times, even clearing most of the stuff from the 60Gb partition and defragmenting the drive first, but stacking 9 or so 16 bit images is just impossible. The images have to be in 8 bit.
GLuijk
Feb 10 2008, 09:08 PM
QUOTE (bernie west @ Feb 11 2008, 02:01 AM)
Aggregation won't be the problem (in the context of this discussion), but histogram expansion is. If you threw out half the levels in an image and then expanded the histogram to fill from 0-255, the resulting histogram will look like the histogram in your green section. It will effectively now be a 7 bit image. Aggregrating data won't change the bit level of the image as all levels in the aggregated level will remain occupied (if indeed they were in the first place).
Well aggregation won't be the problem as long as that curve is your last edition process. But if more are coming that could expand again the low/high end of the histogram (for instance a desaturation or a partial de-contrast curve applied just in some area of the image), then you will suffer the effects of the aggregation you provoqued with your previous curve.
In the same way, those holes that were produced in the middle range could again be occupied thanks to the following edition stage, that's why I claimed there is no loss of information in that range, simply a reallocation of data.
But I understand your point.
OK thank you, I would appreciate a lot if you send me the RAW for the 5D so that I can offer it in the
original article for download, of course giving credit to you.
kramer11x
Feb 11 2008, 10:08 AM
So, is the oft quoted recommendation still correct?
Shoot in hi bit RAW.
Use RAW converter in 16 bit for all tonality/color corrections.
Switch to 8 bit if/when required for specific filters or compositing needs and output to external devices.
This seems to be a consensus of many photoshop books.
I currently shoot with camera set to 14 bit RAW. Download to Capture NX for all tonality and color adjustments. Save as 16bit tiff for photoshop elements. Do everything I want to and can in 16 bit. Then switch to 8 bit for any layers/compositing and printing. This seems to be working very well for me. However I still wonder if spending considerably more for the full photoshop and lightroom combo where I could do more in 16 bit is worth the several hundred dollars. If money weren't an issue wouldn't everyone use 16 bit for everything?
Jack
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please
click here.