Untitled Document

A recently posted question wondered:

The bigger question in my mind is how many bits can be seen (or measured, for that matter) on a reflective rendering?

We can use a traditional reflection densitometer to derive a D log value for any paper and inks combo. Bits can be mathmatically related to the D log values. Measurements made by MegaVision back in the late 80's when they were considering the making of the first Tessera digital capture device, returned 6.5 bits for a high performing sheet fed press.

It might be interesting to measure some reflective targets to see how they perform with today's technically advantaged rendering methods. Yes, we can send 16 bit files to some devices, but can we really see a difference between an 8 bit and a 16 bit file on the print? Just because the driver will accept the 16 bit file, doesn't necessarily mean that the viewer can see it. It could however, have marketing advantages to the folks who are selling the technology.

If we consider how many individually seperable tones we can see reflected from a print, common sense should tells us we should send a prudent amount more, to make sure we've sent enough. Sending a 16 bit file sounds a lot like printing in 2880, versus 1440. Does this mean that we're going to have to use the 2880 setting to see the 16 bits?

Richard Chang

____________________________________________________________________________

On 9/2/05 9:33 PM, "Dan Margulis" wrote:

I have such a file which I posted on my site for anyone to download. Unless I1ve suffered a major brain fart (or once again, the rules change), its quite clear to me that the 16-bit file is showing vastly superior quality with respect to noise and artifacts compared to the 8-bit file.

The image was shot with a Canon 350D (ISO 100). I used Adobe Camera RAW 3.X with all defaults and auto settings OFF. No sharpening in ACR either. The file was brought into Photoshop in 16-bit in ProPhoto RGB from ACR. Then I duplicated the file and converted the dupe to 8-bit. I applied levels corrections (nothing super radical), USM and a boost in saturation (+20 in Hue/Sat). The IDENTICAL corrections were made on the high bit file (hold down option key and the other key command to call levels, USM etc to get exact values) or drag and drop history from one to the other.

Cache is off In histogram. The 8-bit Histo isn1t awful like I see in Bruce1s book. But there is a very noticeable amount of noise in the 8-bit file not seen in the high bit file. I also converted from ProPhoto into LAB and did the same corrections (well not exactly since levels in LAB can1t be duplicated exactly as you would from an RGB file). Again, the 8-bit file shows severe noise introduced by the corrections that simply don1t show up in the high bit file. At 200% zoom, it shows up like a sore thumb.

I1ve taken a section of the image since in high bit, it1s quite large and cropped it down as the 16-bit ProPhoto RGB file. In the zip archive are screen dumps of the corrections made. I also generated a Photoshop action; one duplicates the 16-bit file, converts to 8-bit and applies the three corrections. The 2nd would be used on the original (doesn1t duplicate) making a bit easier to apply both sets of corrections. After that, zoom into the green (slightly out of focus) bird feeder at 200% and look at the differences. The biggest issues in the 8-bt file appear to show up in shadows which makes sense. This is another reason why even superior quality would be produced on linear encoded data within ACR. It also illustrates the need to 3expose to the right2 for RAW data since the first 2048 steps of data are all within the first stop of highlights.

This is a real world image and the corrections are not severe and identical on each. The Zip archive is about 1.8mb.

I1m seeing this effect on other files shot and processed in this manner. I can of course supply the RAW data but it1s pretty large. If anyone wants it, let me know and I'll put it on my public idisk.

The file is here:

http://www.digitaldog.net/files/16bitchallange.zip

Andrew Rodney

____________________________________________________________________________

Thanks Andrew, I've been looking for a file that demonstrated why it is a bad idea to work in ProPhoto RGB - now you've provided a perfect demonstration.

Unfortunately its not really that clear to me that this demonstrates "vastly" superior quality for a 16 bit workflow unless you need to lighten and saturate severely underexposed images in ProPhoto RGB.

What we have here is a file in ProPhoto RGB that contains no colors that would fall outside of Adobe RGB. Most of the bits available in ProPhoto RGB are not being used in this image. When I convert the 16bit ProPhoto RGB file into 16bit Adobe RGB and run your test I see no difference between the 16bit and the 8bit version!

I've posted a screenshot here:

http://www.varis.com/ColorTheory/16bitchallenge.jpg

What is interesting is that you can see a difference when this operation is conducted in ProPhoto - the fact that the difference is not noticeable in print at a reasonable output size works against your claim that it shows a "vastly" superior quality with respect to noise and artifacts. When shown prints (Epson R2400, image at 240 ppi print @ 2880) of the two versions my 17 year old son (who happens to have better eyesight than me) picked the 8 bit version as better because it seemed a tiny bit sharper!

I will admit though that if you insist on using a workspace that is vastly larger in color gamut than you really need for any type of printed output you'll have smoother results if you do your adjustments in 16bit.

Here is a screenshot demonstrating the difference side by side:

http: //www.varis.com/ColorTheory/16bitchallengeProPhoto.jpg

It is interesting to note how much worse the 8bit ProPhoto file looks than the 8bit AdobeRGB file. I think that its quite possible that if you output a continuos tone print (like a Lightjet) and put a loupe on the print you could see the noise and artifacts on the ProPhoto version.

Here is a screenshot showing ProPhoto vs AdobeRGB versions:

http: //www.varis.com/ColorTheory/8bitProPhotoVS8bitAdobeRGB.jpg

The bottom line -- if you must use ProPhoto RGB stay in 16bits for major adjustments. Otherwise, use Adobe RGB and you can do everything in 8bits.

regards,

Lee Varis

http://www.varis.com

888-964-0024

____________________________________________________________________________

On 9/3/05 5:28 PM, "Lee Varis" wrote:

Bad? Works fine in high bit. If you happen to shoot in RAW, you'll find lots of images that fall way outside say Adobe RGB (1998) but within ProPhoto. So if you are OK clipping color from your capture device go that route. Otherwise, ProPhoto RGB is a better space to contain those colors.

Lighten, sure. Saturate why not? And if you try corrections other than saturation (like just lighten), you'll see the benefits of the high bit file in reduced noise.

The original argument was, using 8-bit versus high bit on a file (color space not defined nor should it be necessary), show an example where there's a benefit to to doing the same exact corrections on each. Do you see that or not?

The color in the file is immaterial. I'll be happy to shoot a saturated image that also contains dark shadows (gee, that's not hard to find) and illustrate noise in the shadows from the 8-bit corrections that are not produced in high bit.

Agreed, as I tried this in Adobe RGB (1998) as well and like you, saw far less issues. But that's not what the challenge is about, it's to show the benefit of using high bit versus 8-bit identical corrections. Plus why limit the color gamut? Did you try this on a LAB file? It shows the same issues. LAB's going to be also very large and produce the same issues in a different way. The high bit corrections do not exhibit the noise.

You printed it on what device at what size? You've got a tiny section of a full rez file.

Sure it does, look at the noise which produces on edges the look of more contrast. But that's non image data that's being formed due to the edits in 8-bit and it's not a good thing! We're seeing the effects of the edits causing aliasing in the form of noise.

Yes, I and many need this large a working space to contain colors their capture devices produce. Looking at the gamut of my Imacon scanner, it too produces colors outside of Adobe RGB (1998) in many areas. I'd like to keep those colors since I can illustrate output devices that have gamuts that can use some, certainly not all, but some of that gamut. I also want a working space that has a large enough size to define dark colors that can't be kept in something like Adobe RGB (1998). That's a major benefit of such a space. Unlike output devices, the gamut shape of a working space is such that it tapers rather radically as it moves to darker tones. Output devices generally have a much wider gamut shape. When you use a smaller gamut working space, you crunch a good deal of data in those areas and end up printing blobs instead of detail in images that would have say very dark brown tones.

I've got a Fuji Pictrography 4500 and I agree with you, it can be seen.

But that isn't the issue. The issue is I don't have to worry as much about this in high bit by applying the identical edits to this and many other images from this capture device. And I can do even more work with less damage using Adobe Camera RAW in linear encoded editing on high bit. That wasn't even accounted for here since the original post by Dan discussed how in Bruce's book, the two edits on page 24 were apples and oranges. We should see even better quality data first doing the tone mapping I did on the gamma corrected data in high bit instead in ACR.

So you agree that there's some advantage of high bit editing, all corrections being equal? I suspect the forum host doesn't agree with that or at least, has been asking for side by side comparisons. I don't recall the working space being part of this challenge.

Andrew Rodney

http://www.digitaldog.net/

____________________________________________________________________________

Andrew Rodney writes,

First of all, thank you for posting it, I agree that it is a real-world picture with real-world corrections. I have played with it a little bit but won't have any final comments until I get a chance to manipulate it more, which will be after Photoshop World. At that time, I will probably take you up on the offer to provide the raw file, provided you are willing to give me permission to publish it.

It would not surprise me if this or a similar file containing mostly dull colors, if left in ProPhoto RGB, would get a better result from 16-bit correction than 8-bit. I have tested Adobe RGB, ColorMatch RGB, LAB, and sRGB files enough to be highly doubtful that there are any natural color photographs at all where the extra bits would be helpful in any real-world context. However, I've always pointed out that I have *not* extensively tested exotic alternatives, such as 1.0 gamma files, or ultra-wide gamut RGBs such as ProPhoto. The reasons they are not tested are 1) they have limited market presence and 2) I strongly recommend against their use in color correction.

I do have another ProPhoto file where 16-bit definitely produced a better result than 8-bit. However, it was not a real-world exercise in that the file was intentionally sabotaged in Camera Raw by moving the exposure slider all the way to the left when the actual final intent was to lighten the file. We did repeat the same exercise, including the sabotage, with the same file output to Adobe RGB, and there was no problem with the 8-bit correction.

During the tests for the LAB book I was working with Wide Gamut RGB rather than ProPhoto, and it did astonishingly badly in all manner of conversions, from which I surmise that ProPhoto might as well.

In any case, if it turns out that in some cases 16-bit correction works better in ProPhoto RGB, I have no problem admitting it and adding that to the long list of reasons why one should avoid adjusting images in such a space.

Dan Margulis

____________________________________________________________________________

On 9/3/05 7:02 PM, "Dan Margulis" wrote:

Actually I1d like to find an image that is photographically more interesting! You1re only seeing a tiny section but trust me, it1s not at all much to look at in total. I should have no difficulty finding or shooting images with this camera in RAW that shows similar, perhaps even better demonstrations of the two options in processing. I1d also like to see the effects with different ISO settings. With 100 ISO, I1m producing the best possible image quality from this sensor. Lastly, exposure could play a big role here (using the expose to the right dogma).

ProPhoto is certainly a space that contains colors that are way out there. In fact, I1d agree in this context that some of the colors it can define are actually imaginary colors, a term you use in your new book that outside of ProPhoto RGB is a lose term I don1t agree with. In LAB (well CIEXYZ of which LAB is based) as well as the spaces you mention above, the colors are not imaginary but they can certainly be outside of the gamut of a lot of devices. In ProPhoto, there are blues that are outside human gamut which I think are absolutely imaginary (and of course unprintable). There are so called 3imaginary2 colors in Adobe RGB (1998) if the device trying to 3imagine2 them is a four color press.

The reason ProPhoto RGB is so large and why it1s necessary is we are often trying to fit square pegs in round holes if you forgive the analogy. The gamut of a digital camera (which arguably has no real color gamut) can be quite large. There are many, many real world scenes and thus images that fall far outside the gamut of Adobe RGB (1998) but can be contained in ProPhoto RGB. While there are those that say a histogram is an over used diagnostic tool, and I would not totally disagree, the histogram in Adobe Camera RAW provides a very non ambiguous way to see if the scene data falls outside Adobe RGB (1998) but within ProPhoto RGB. One could argue we need a working space with a gamut between the two. However, when I capture a scene, I want to have at my disposal all the color that device can provide. Today, the only way I can do this with a great deal of images is to use ProPhoto RGB. Even though it1s gamut is so large that it falls in some portion outside of human gamut, the other larger areas are necessary to contain other useful and I would submit non-imaginary and reproducible colors (to some devices).

If you have a decent DSLR and Adobe Camera RAW, it isn1t too hard to open an image and find clipping of some or all primary colors in Adobe RGB (1998) by viewing the ACR histogram. Toggle to ProPhoto RGB and those colors can be contained when rendered and encoded into that working space.

Many of us have advised the use of high bit color with very wide gamut editing spaces and based on this one test, I think that1s a good call. It also shows the advantages of high bit data!

I don1t think ProPhoto RGB (previously known as ROMM RGB and around almost as long as Adobe RGB (1998)) is exotic. Anyone working with RAW files from digital cameras can find it a useful color container. It1s one of the four options in Adobe Camera RAW. As more images are captured digitally in RAW, if anything, the use of such a space will grow.

ROMM RGB has been thoroughly tested and has been used for years. With the exception of using it with 8-bit files, the real downside I see is it could contain colors that fall well outside display gamut. But that1s true for 98% of every display on the market when you substitute Adobe RGB (1998) for ProPhoto RGB. I1d also rather have colors I might be able to use on output and perhaps not fully see on a display then throw away colors I know my various output devices can use just to see every color. And we both know that even with wide gamut displays, there are CMYK colors they can1t reproduce even if we started with a much smaller color space. In this context, those colors are imaginary but reproducible on press.

In this file, I simply used the default settings but without the auto check boxes. The file does look dark on the Artisan but I didn1t have to do anything radical with levels to make the image look better. I would certainly have done this in ACR but then if I made the RAW to rendering file look as good as I could by simply clicking on the auto check boxes or using a custom setting, the data, even in 8-bit would look great and there would be little need to edit the file.

As Lee pointed out, in Adobe RGB from the RAW data, the same corrections do not produce the level of obvious noise in 8-bit. But I want and do use ProPhoto RGB for reasons discussed as do many other users.

Well that1s certainly a good step forward. NOW we need to test what ProPhoto brings to the party but we have to do so with current output technology (meaning more than four color ink on paper) and with an eye on future print technology.

Andrew Rodney

http://www.digitaldog.net/

____________________________________________________________________________

Andrew,

Thanks for posting this. As one of those who have looked at the 16bit/8bit issue in some depth I know how difficult it is to put this information together. I also experienced myself the problems (and some pitfalls) in doing my tests and so wanted to look at yours closely. I'll leave it to others to debate whether this shows a benefit to editing in 16 bits, although I was surprised at how much sharpening separated the 2 files. It certainly shows a difference (although this isn't contested anyway), and I do think the dark greens look better in 16 bits at high magnifications. Here's what I see:

1). Unedited: 8 bit converted w/ & w/out dither preference. Based on your seeing a difference between the unedited 16 and 8 bit files I assume you had dither on. At 1600% I can see a difference between the two 8 bit files. The 8 bit file converted w/out dither looks virtually identical to the 16 bit file (to my eyes).

2). There is a much bigger difference after editing, of course: @ 400% can see big difference in dark greens. If go back to step before sharpening the difference is more subtle. @ 1600% the difference is more obvious. However, the 16 bit file looks softer. I'm not sure you would sharpen a 16 bit file and an 8 bit file identically if you were looking at both on screen? Surprisingly to me, the sharpening step makes the biggest difference, and going back one step they are more similar.

At 800% looking at just the 16 bit file and the "no dither" 8 bit file, I would say the 16 bit file looks softer, but with more discrete tones. I would say the darkest greens look more "realistic" in the 16 bit file. however the midtones look softer and I would suspect might not look as sharp in a print. At 400% the tones driven darker are very obvious in the 8 bit file. However, as I said the 16 bit file always looks softer. If I do as little as add 2 levels of Threshold the files become much more similar.

3. The image at 240 dpi is only about 2 x 2.3 inches. I doubt any repro method would show a difference. However, I know some people need to interpolate up their digital files. So assuming someone had this image and needed it reproduce it at a reasonable size I upsized 400% using Bicubic Smoother. Here I would say the dark greens would probably look better in a print from the 16 bit file. However, I still think the midtones look sharper (and better) in the 8 bit file. Now we're getting into the area of whether we could do a better looking correction for both files which I think is the real point. There are many unexplored variables in this test. For example, I would not normally consider ProRGB to be a suitable 8 bit editing space. What happens if both files are converted to AdobeRGB before editing? Perhaps I'll look at this later.

I looked up the Canon 350D and I believe it's the Rebel version of the 20D (which I've used). I know it's a very nice camera, but not up to the D1s, which isn't up to the top medium format single shot backs, which aren't quite as good as the 4 shot capture backs (because of uninterpolated color) which probably aren't quite as good as a scanning back (although I don't use these because I believe the limitations aren't worth dealing with except perhaps for museum archiving work). My point being that it's the images that count. If you want to agonize over a few lost bits then go for the best capture to begin with. This reminds me of when I first started to do photography as a hobby. I loved the work I saw that was shot with large format cameras. I wanted to take pictures like that but all I had was a 35mm camera. I shot with slow film on a tripod and processed in fine grain developers. I spent hours in the darkroom working to bring out a widest tonal range I could. My landscapes still looked like shit compared to something shot in 4x5 or 8x10. However, when I stopped trying to make my pictures look like large format and started taking the kinds of pictures that 35mm was suited for my pictures got a lot better. Later when I had a chance to work with large format film I could achieve the results I was looking for.

I'll be interested in hearing other's views.

Ric Cohn

____________________________________________________________________________

Prhophoto is a space excesivaly big to be usefull ¿Don't you think so? It has far more number for colors than usefull colors, so the actual amount of "numbers" you can "assign to real colors" is prerttysmall. Wide gamut spaces are so unpractical!!

/*--------------------------------------*/

"If quality is important, sRGB is not an option"

(From the European Color Initiative web page www.eci.org)

Francisco Bernal Rosso

Luz-color-fotografia

Redacción y traducción

____________________________________________________________________________

On 9/3/05 10:32 PM, "Ric Cohn" wrote:

Dither is used for color space conversions which can be turned on or off in color settings and only affects 8-bit data. I did no color conversions. The file went from RAW to ProPhoto RGB in ACR. You might want to try converting after the edits on both to some output color space to see if things in 8-bit get even worse.

Strange effect I've never noticed before. While this looks like dither is introduced, it's not the same as above and unless Adobe is doing something as they convert to 8-bit, I'm at a loss to explain it. But you can see it when you toggle between the two bit depths at 1600%.

The effect of the aliasing (which is not good) produces the appearance of sharpness due to the increase in contrast. But this isn't something we want! I have similar captured files where I see this in dark gray clouds and it's pretty ugly. This isn't a contrast of edges as we'd see in typical USM, it's banding that is somewhat uncontrollable and affected by tone (and I suspect some colors as well). Take an unsharpened file, use the Add Noise filter and I'll bet it appears a bit sharper. I don't know anyone advocating the use of noise to make images look sharper <g>

In this case no because sharpening would make the noise even more visible. This is why the discussion of using masks from the image itself to sharpen was something I raised before. ANY global sharpening no matter the color mode is pretty discriminant. An image mask can hold back sharpening in smooth areas or dark areas like the one's we are seeing that have noise. The noise is there in 8-bit far more than 16-bit which is the issue. At this point, sharpening should be conducted on either or both with the utmost control. Using a true Grayscale image mask made from the image can accomplish this.

Exactly. That's what I'm seeing. That explains why the 8-bit looks "sharper" and why it's a problem because subtle continuous tone is now going away. What happens when we use other edits or convert to an output color space? Compounded issues are possible and the reason proponents of high bit editing exist! We don't know how much worse this will all get down the line.

...or further edit the file, output to a high rez, continuous tone device and so forth. Bottom line is, the high bit file has more editing potential. Something Bruce mentions in his book.

More or less yes. The CMOS chip may be a bit newer but its the same size. The processing may be different too. They should be pretty close. Yes, there are substantially better quality digital capture devices which may show the benefits of high bit more (or not). Keep in mind that only 3-4 years ago, this was state of the art in DSLR technology.

Andrew Rodney

____________________________________________________________________________

On 9/4/05 5:14 AM, "Francisco Bernal" wrote:

It1s very useful if you want to contain colors your capture device (in this case my Canon) is able to capture. I can provide many images that fall outside of Adobe RGB (1998) that are fully contained in ProPhoto RGB. I can also show you output devices (the new Epson 2400 at a mere $800 is one) that can reproduce colors that fall outside Adobe RGB (1998) but are fully contained in ProPhoto RGB.

There are no prefect working spaces or we1d only need one! The advantage of bigger spaces is holding onto colors we can capture and ultimately reproduce. To do this, we need in big honking gamut spaces to hold colors that fall outside the simple shapes of all working spaces. All RGB working space are synthetic constructions and have simple shapes, especially compared to output color spaces. If you want to hold all the captured colors you can possibly output (even to a device made in 2005), you need a really big working space shape and ProPhoto fits the bill. Just do the editing in high bit, the point of this discussion.

Andrew Rodney

____________________________________________________________________________

On Sep 4, 2005, at 7:56 AM, Andrew Rodney wrote:

Unfortunately ProPhoto RGB is like using a sledge hammer to drive finishing nails. Besides, all this discussion about containing very saturated colors is a little bit like talking about how many angels fit on the head of a pin.

Everybody is obsessing over a small subset of very saturated colors!

For the most part we should be more concerned with color relationships and tonal compression. Until we have high dynamic range backlit displays being used for final output, images printed on paper should be our primary concern. Images printed on paper are evaluated in the context of that paper! Making images that have a range of tones and colors that look good to a human observer does not require working in ProPhoto RGB or 16bits. Advocates of wide gamut/high bit color spaces always end up talking about real colors that you could capture and "contain" - humans respond much more to contrast than color. Color contrast is more important than color gamut or hue. Wasting data by spreading it out in a huge erratically shaped color space just to "hit" a saturated color that falls well outside of an editing environment seems to me to be counter productive because it does nothing to make it easier to work within the constraints of fairly small output spaces.

I've never seen anyone complain about the colors of a Lightjet photographic print yet the Lightjet has a color gamut slightly smaller than sRGB!

We're not trying to "contain" color but to translate it so that it works in a completely different context.

To that end the only thing I find "useful" about ProPhoto RGB are the individual channels for the purpose of B+W conversions and luminosity blending NOT color "containment". Having a huge color space helps to render grayscale channels with more tonal detail (avoids clipping highlight and shadow detail in saturated colors) and this tonal detail IS more easily manipulated for grayscale images and luminosity blending techniques into smaller color workspaces. The ProPhoto grayscale channels CAN be brought into 8bit very successfully when you're not concerned with color!

So the best thing about ProPhoto RGB is grayscale imaging not color!

regards,

Lee Varis

http://www.varis.com

888-964-0024

____________________________________________________________________________

On Sun, 4 Sep 2005 09:49:48 -0700 Lee Varis wrote:

Dear Lee, have you tried taking images of flowers, red roses, for example?

Best regards,

ib

____________________________________________________________________________

On 9/4/05 10:49 AM, "Lee Varis" wrote:

Sorry Lee but that's just silly talk. Surely you have RAW digital files you can examine in ACR to show you saturated colors captured that fall outside Adobe RGB (1998) but could and can be output on an $800 ink jet printer among others. If you want such RAW files from a lowly $900 Canon 350 Rebel let me know.

That's like saying a photographer who prefers the look of Velvia is obsessing over saturated colors that can't be produced on Ekatchrome. Are you really proposing that? Because I think I can fill a room at PhotoPlus Expo with shooters who would gladly obsess over that added saturation in a chrome they can't possibly place on a four color press (but might on a Ciba). Digital capture can represent a far wider color gamut than any E-6 film.

I need all the colors to DECIDE what to compress. If you throw them away from the start, I can't do that.

No but at this point, I have the option of containing the colors or throwing them away forever. In ProPhoto, I can decide today or in the future how I want to hand out those colors. In Adobe RGB (1998) it's gone. Yes I can go back to my RAW file but that's akin to going back to my color negative and making another custom print, spotting it and so forth. Why do this twice?

There's no waste. Throwing away the color is a waste. It's not erratically shaped. It's shaped this way for a very good reason. My proposition in photo centric terms is, if you shoot an 8x10, it's silly to now process the image and take scissors to the it and crop it down to 4x5.

And you did this with a ProPhoto RGB image as well with a scene that contained data outside of sRGB? If not, I can fully understand why no one would complain. Talk about imagery colors!

And Lee, whatever profile you used to compare the Lightjet to sRGB is crap. It's absolutely not smaller. I have profiles made for a Lightjet at Pictopia. There's quite a nice slice of many colors that fall outside sRGB like yellows, greens and magentas. Less so in Adobe RGB (1998) but even with that color space, the Lightjet produces colors outside it's gamut (yellow and magenta).

If you can't contain them, you can't use them or translate them.

Andrew Rodney

____________________________________________________________________________

On 9/3/05 7:02 PM, "Dan Margulis" wrote:

I1ve uploaded this RAW file (CRW_0775.CRW) to the same location as the other files (I1ve over-written the original ZIP archive and it is now 9.5mb). The ZIP archive still contains all the other files in addition to this RAW file and the XMP data used to define it in ACR (you should be able to import this to set my ACR settings on this RAW or simply turn everything off there). The full image isn1t quite as ugly in total (it1s a shot of my new office being constructed). I still want to shoot other scenes but this should do for the time being.

To download:

http://www.digitaldog.net/files/16bitchallange.zip

The other interesting item is while this doesn1t at all appear to be a scene containing saturated colors, in ACR, I do see clipping when I set the output color space to Adobe RGB (1998) but not ProPhoto RGB. You1ll see that there1s a pretty large blue clip on the far left of the histogram in Adobe RGB (1998), none when you toggle to ProPhoto RGB. This is the yellow flowers in the foreground. The camera is rendering the RAW file such that these colors are outside the gamut of Adobe RGB (1998).

An interesting exercise in this respect can be seen using the new crop tool. Crop a small area of the total image (say 25%), move it around from the yellow flowers to the blue sky as you toggle the various color spaces while viewing the histogram. A solid color clipping will show the complementary color falling out of gamut. White would be full clipping (all three color channels). Lower the saturation slider and see how the fully saturated colors that clip are affected. Another poster asked of Lee 3do you shoot flower2? This isn1t by any stretch of the imagination a scene one would say has bright, saturated colors and yet, if the goal is to at the very least contain and possibly use colors captured, encoding into Adobe RGB (1998) would clip our yellow flowers.

Then next logical question would be, can you use those yellow colors? The answer is, it depends. I converted the RAW in both Adobe RGB (1998) and ProPhoto and using ColorThink, I can actually plot the colors of an actual image on top of the gamut of an output device. Very cool feature. Anyway, using my Epson 2400, there1s a significantly larger amount of yellow I can actually use from the ProPhoto file. I1ve placed a screen capture in the Zip archive. You1re seeing the gamut of the Epson 2400 in actual color. In the bottom you can see the yellows. The red dots are the gamut of the image (cropped to just flowers) in Adobe RGB (1998). The green is the same image but in ProPhoto RGB. You1ll see there ARE yellow colors that fall outside the printer gamut. Yet far more greens dots (ProPhoto RGB) fall within gamut compared to Adobe RGB (1998) which can1t hold colors that the wider gamut file can use for output.

If the yellow in this image isn1t important to you, then neither is the use of ProPhoto. However, if the yellow (and other colors) are important, the output device can use them with the wider gamut color space. You can also see the amount of yellow gamut we would throw away by going directly to Adobe RGB (1998) instead of simply holding onto them by using ProPhoto RGB.

Enough color theory, time to grill burgers.

Andrew Rodney

____________________________________________________________________________

On Sep 4, 2005, at 10:08 AM, Iliah Borg wrote:

Yes.

regards,

Lee Varis

http://www.varis.com

888-964-0024

____________________________________________________________________________

On Sep 4, 2005, at 10:48 AM, Andrew Rodney wrote:

I'm not going to respond to any more of your objections as you pointedly refuse to understand the points I'm making and instead reiterate your first and only rant about color gamut, throwing away colors, etc... We get it... we've all heard this time and time again - someday sometime in the future it might mean something - right now I've got work to do getting some images to look good on a piece of paper. Don't worry, I'm holding on to my raw files though I expect that the carefully crafted prints I'm saving for my grandkids will be worth more money 30 years from now when they're considered collectable because they are done using some antique process by the original artist!

Over and out!

regards,

Lee Varis

http://www.varis.com

888-964-0024

____________________________________________________________________________

Andrew Rodney wrote:

I've been following this forums discussions about bit depth for some time. I am gald that after all you found one situation that proofs you right. I have great respect for your knowledge, only, I wonder where you guys take the time to go through such length to prove your (religious) beliefs.

Thanks anyway for the entertainment you offer to the readers of the list! I have to stop here. Got to correct 63 files for print until this afternoon. I guess I'll go for 8 bit this time...

Werner Tschan

____________________________________________________________________________

On Sep 4, 2005, at 10:55 AM, Andrew Rodney wrote:

Indeed the preference does say it's for 8 bit transforms, but my experience and my results suggest that Photoshop applies the dither in the 16 bit to 8 bit conversion if this preference is checked. I'd say this behavior should at least be acknowledged. It's not always bad as I personally experienced the advantages in reducing banding when I did my 16 Bit vs. 8 Bit comparison a few years ago.

Take an unsharpened file, use the Add Noise filter and I'll bet it appears a bit sharper. I don't know anyone advocating the use of noise to make images look sharper <g>

Not sharper per se, but I sometimes add noise to my digital captures. I frequently find that the digital captures smoothness (I'd say Unnatural smoothness) rather ugly. I like variations and imperfections and believe that a smooth histogram can be a sign of trouble, but not in the way that those that hate gaps mean. What would be interesting to me would be to look at the histograms of images (both paintings and photographs) I find beautiful or emotionally affecting. I remember a similar study of music tonal variations from my college days that was very revealing.

Ric Cohn

___________________________________________________________________________

Thanks to Andrew's test pointing out the dangers of wide gamut working spaces when working in 8 bits, I've been thinking again about which space is best for working in 8 bits. I'm interested in containing enough color gamut for any existing process without getting any bigger than needed. Since very little of my work is high croma with super saturated colors I don't buy into the "capture everything and stay in 16 bit" argument. IMO AdobeRGB is OK, but it's mostly an accidental working space and I can't help feeling there are others that are better shaped. I have used Bruce Lindblooms BestRGB http://brucelindbloom.com/ when doing scans and it might fit the bill. I know CIE has an RGB space and there's a space called (I think) LStarRGB. I don't know enough about the ramifications of any of these spaces to evaluate their superiority to AdobeRGB.

BTW, when I am shooting for clients and the images color fits within ColorMatchRGB, and I'm supplying RGB files, I use that. Sometimes just sending clients images in a wider gamut space even when the captures are well contained can cause problems if they muck with the files- too easy to make something that looks good on screen and can't be printed. I think this is less of a problem now that more retouchers and printers are getting used to RGB.

What do people think would be the chosen working space for 8 bit if we could all start over without the existence of any current working spaces? ProRGB seems fine for 16 bits. It has almost all the lab colors- of course, it also has a big area outside even LAB.

Ric Cohn

___________________________________________________________________________

My first post, so I've picked a nice thorny subject - bit depth!

I work mainly in 8 bit, largely because of the high-resolution and multi-layered nature of my work. Even on fast G5s with lots of RAM I still find Photoshop bogs down in 16 bit. Plus, I've never seen visible improvements through wrestling with a 16 bit workflow - except for one little detail...

My clients generally want major changes from reality - masked and multi-layered retouches, composites and colour changes. Towards the end of a given job some smooth-ish gradients - artificially added or enhanced flare, dark or darkened natural skies and shadow areas on skin, for example - can exhibit banding. Usually a little noise in the right spots does the trick, but sometimes it's more stubborn.

I've found that almost all of these problems can be safely ignored while working and then totally eliminated by simply promoting the finished, multi-layered 8 bit PSD work-file to 16 bit BEFORE flattening, THEN flattening, then going straight back to 8 bit. It only costs you the time to do one simple calculation in 16 bit (the flattening) and I have seen real, visible improvements in problem areas of the same file flattened normally in 8 bit and then flattened this way. (At least, improvements on screen and Matchprints - I've always treated problem files in this way before going to print.)

Are these problems caused purely by 8 bit rounding errors? In my work- around, is the 16 bit math really helping, or am I just seeing the result of two applications of the fine dithering Photoshop adds during mode changes?

Does Photoshop do any kind of dithering during normal flattening?

Would these problems even make it through to press?

I understand that certain moving-picture film-compositing packages allow the user to force the math into a higher depth than the working image data, or even to "float", where values can temporarily exceed the usual 0 and 255 clipping points. Would Photoshop benefit from doing something like this internally by default?

Ben Richardson

P.S. I note that Dan generally recommends getting source files from scanners, etc. in their native 16 bit and then converting to 8 bit in Photoshop as a first step (rather than taking scanner 8 bit output - see Professional Photoshop 4th ed. pp. 316-318). Might this make an occasionally useful and equivalent last step?

____________________________________________________________________________

From: "Ben Richardson"

...

This is almost certainly due to the fact that Photoshop adds about 1/2 bit of noise when converting from 16 bit to 8 bit.

...

Certainly. For example, using the RGB or CMYK composite curve introduces a level of quantization, caused by an additional table lookup. This can be avoided by combining the curves using floating point before generating a single look up table. People who work on software worry about this sort of thing, and the result may be beneficial, from a mathematical standpoint, but it is doubtful whether anyone will see this in the final image.

Personally, I use 8 bits and sRGB for almost all of my work, but as a tool writer I fully support those who chose to do otherwise, for whatever reason.

Mike Russell

www.curvemeister.com

____________________________________________________________________________

On Sep 19, 2005, at 8:07 AM, Ben Richardson wrote:

All good questions. Some answers don't seem to be fully documented for PS.

How PS handles gradients in things like Masks and Alpha Channels is of interest to me. I noticed some of issues you raised about working with these in 8 bit and also when converting these from 16 bit to 8 bit. I'm particularly interested in your statement:

I've found that almost all of these problems can be safely ignored

while working and then totally eliminated by simply promoting the

finished, multi-layered 8 bit PSD work-file to 16 bit BEFORE

flattening, THEN flattening, then going straight back to 8 bit.

If this is indeed the case, then moving to 16 bit when creating certain kinds of masks might make sense for me when working with files that require this. Perhaps like Lab we'll discover that 16 bit has unexpected uses! I'd like to hear more from others who agree or disagree.

Ric Cohn

____________________________________________________________________________

Ric Cohn wrote in reply to the post from Ben Richardson :

Generating a CG radial mono gradient seems to be the most taxing test in Photoshop, if not real world photographic. I have not tested in CS2, but this should show banding, with or without the gradient tool dither option, if anything would (not sure if video card plays an issue or if it is in output too).

On a similar point, but more real world than a CG gradient:

An old technique to alter tone, is to desaturate a RGB duped layer, invert it, blend in overlay at X% opacity and apply a large gaussian blur to suit. This blurred monotone channel can show banding when performing the large blur (again, not sure if a monitor artifact in all cases). Again, if memory serves me correct, this time blurring in high bit does help smooth things out a little compared to regular bit processing (and one has dither added going back to 8bpc).

An alternative to blurring in high bit, would be to add minor noise to the blurred layer (perhaps protecting the endpoints). This is more aggressive noise when compared to the bit switch dither, but one can make it minimal or strong to suit without having to process in high bits.

Stephen Marsh.

____________________________________________________________________________

On Sep 20, 2005, at 8:23 AM, Stephen Marsh wrote:

This is what I've always done when banding of these channels is a problem. I usually use the Blend-If sliders to keep pure blacks and whites clean (i.e. protect the endpoints). This almost always does it, but there are rare occasions where the noise creates its own problems and protecting the endpoints can take longer than switching in and out of 16 bit if this would fix it. The question is whether it would. I haven't done extensive tests myself, but would like to hear others experiences.

Ric Cohn

____________________________________________________________________________

Prior to my trip to Photoshop World, Andrew Rodney posted a link to an image as part of his never-ending attempt to explain how his business partners can say that correcting in 16-bit is what differentiates a professional from a recreational user, how it creates a night and day difference, how the advantage is totally obvious to everyone who looks, etc., etc. Lee Varis posted a response with which I concur, but I did not myself have time to look at the image closely and said I would do so in future weeks.

As I indicated in my first brief response, the example is meaningless, because it assumes a condition that I have always excluded, and that wasn't even known at the time his partners said those things. I have always made clear that exotic RGB definitions, such as 1.0 gamma, or ultra-wide gamut RGBs, are not tested because, first, almost nobody uses them, and second, those knowledgeable about color correction would be unlikely to edit in them except under very unusual circumstances.

Andrew's test depends on using such a space, an ultra-wide gamut RGB known as ProPhoto. This space was not installed in Photoshop until 2003, and since his partners made the remarks about night and day differences and professionals and recreational users long before that, they cannot possibly have been referring to it.

The image is an outdoor scene. A laborer, on his knees, is laying a cement deck or patio. There is greenery and yellow flowers in the foreground; the patio takes up almost a third of the picture. The laborer is relatively small. His face is in shadow. The background ground cover is yellowish. On the whole one would describe the colors as subdued. The picture isn't ridiculously dark but it certainly needs to be lightened.

Lee Varis correctly characterized such RGB spaces as "like using a sledge hammer to drive finishing nails". By that, he meant that the are too imprecise to be used in serious image manipulation, because most of their possible color values are either well out of any reproduction gamut or totally imaginary. This image is a perfect example: the large patio is basically gray, however there is a certain amount of variability, with some parts slightly redder and others cooler. During the correction process, we need to be sure that these colors don't get out of hand so that the patio looks like a rainbow rather than cement. Doing so is no sweat in any rational RGB. We just try to have the three RGB values be approximately equal throughout the area, understanding that exactly equal isn't going to happen.

But in an ultra-wide gamut RGB, it's much more difficult, as the values have to be kept much closer to absolute equality, because colors get brilliant very rapidly in such a space. Consequently, maintaining neutrality in such an image during correction is a nasty problem in an ultra-wide gamut RGB and no problem at all in LAB, CMYK, or a rational RGB.

Because any small variation in an ultra-wide gamut RGBs is actually a huge variation in output color, the tiny differences between a file prepared in 8-bit and one in 16-bit are magnified. In realistic RGBs, these differences are so slight that nobody notices them no matter how much they are affected by later edits. But in an ultra-wide gamut RGB, it is at least conceivable that certain images will look better if they are worked on in 8-bit and others will look better if done in 16-bit.

In Andrew's procedure the image is not edited in Camera Raw, but is exported to 16-bit ProPhoto. The test calls for making a second copy which is then converted to 8-bit. Then, to both, one master-channel Levels command is applied, followed by one increase to master saturation in the Hue/Saturation command, followed by one unsharp mask filter.

In examining the image, I looked at not just these two variants, but several others in ProPhoto, as well as 8-bit and 16-bit Adobe RGB using exactly the same commands, and 8-bit sRGB where I used the same commands but attempted to strengthen them to match the look of the ProPhoto files.

The error in Andrew's method is in his final step. After the levels and Hue/Sat moves, the two versions can't be told apart without great difficulty. However, his sharpening settings have a Threshold (noise reduction) of 0. This causes a problem specific to ultra-wide gamut RGBs.

Any file corrected in 8-bit will be very slightly grainier than one corrected in 16-bit. In rational RGBs, this difference is so imperceptible that it makes no difference in the sharpening process. In an ultra-wide gamut RGB, it can be seen IF you specifically use a zero threshold. In that case, you will see two definitely different images, as we do in this case. (Andrew concedes that when these same moves are applied in Adobe RGB, the two images are the same for all practical purposes).

In the ProPhoto version the difference manifests itself in a more active-looking 8-bit file. It has more noise in shadow areas, particularly in the worker's face and in an area of the background. I agree that these things are bad. However, it has slightly more believability in the foreground greenery and in the concrete, which are more prominent items. I believe that this is the reason that when Lee Varis printed out the two files and showed them to another observer without explaining which was which, the observer picked the 8-bit version as being better.

While it's arguable whether the image taken as a whole is better or worse, certainly Andrew is entitled to object to the graininess. What he is not entitled to do is, when there are several equivalent ways available with no extra effort, intentionally choose the one that magnifies the effect that he says he doesn't like. In the sharpen filter, the Amount and Threshold commands work in tandem. A higher Threshold slightly diminishes the sharpening effect, and we compensate by raising the Amount. Minute changes are possible, so that there are, in effect, many different ways of creating substantially the same effect. By raising the Threshold even to 1 (although I would choose 2) and adding a corresponding increase in Amount, the 8-bit and 16-bit images are again qualitatively equal regardless of which of the three settings is used for the 16-bit file. I also experimented with much larger sharpening Amounts with the same result.

It should also be pointed out that the graininess is more a function of the ultra-wide gamut RGB than it is of the bit depth. As noted, I did another version in 8-bit sRGB. It's impossible to duplicate the 16-bit ProPhoto exercise exactly, as much stronger corrections are required in sRGB to achieve the same look. But I got as close as I could, including sharpening with a zero Threshold. The 8-bit sRGB file looked smoother than the one done in 16-bit ProPhoto.

In short, this image does not show an advantage, because the part of it that Andrew complains about could have been avoided with no extra effort and no loss in quality. Intentionally choosing an inappropriate sharpening setting is not a real-world move.

What *would* constitute an advantage? As I indicated in my first post, a list member showed one. An overly dark image needed to be lightened. However, it was deliberately sabotaged in Camera Raw by turning the exposure control all the way down. Then, it was exported into 8- and 16-bit ProPhoto and Adobe RGB, where simple curves were applied to lighten the image grossly. In Adobe RGB there was no preference between the two versions. In ProPhoto, however, serious noise developed in the sky in the 8-bit version that wasn't present in the 16-bit. Now, unlike Andrew's image where it might reasonably be argued that the 8-bit version was *better,* in this one everybody would agree that it was worse, no question. And, unlike Andrew's image, there was no means of avoiding the problem in the same number of steps. The 8-bit picture would have to be corrected further to match the quality of the 16-bit.

The image showing 16-bit superiority isn't real-world because it was sabotaged in Camera Raw. Andrew's image, which wasn't so sabotaged, doesn't show superiority. OTOH, it wasn't corrected particularly brutally either. So, I would have to suspect that it would be possible to find a real-world image that is somewhere in the middle--that is, no sabotage, but a more extreme correction, causing clear superiority in the 16-bit version. Similarly, one would expect to find certain files that would correct better in 8-bit than 16-bit.

If you are misguided enough to work in an ultra-wide gamut RGB, that is.

To summarize: working with actual images is a useful exercise, and we should thank Andrew for making this one available. It does not actually show an advantage for 16-bit manipulation in ProPhoto RGB, but in all probability he could have constructed an image that did if he had worked harder at it. If somebody wishes to produce such an image, I will be happy to note it parenthetically in the next edition of Professional Photoshop, but I am not interested in further testing of ultra-wide gamut RGBs as correction spaces myself, as their disadvantages are such that their use can be recommended only in highly specialized situations.

At bottom, though, it's just another attempt to blow smoke over the inability to back up his partners' extravagant claims. Granted, this time it's not a histogram or a gradient or a sabotaged image. But still, it requires a certain revision of the original 2001-2002 claims. Perhaps Andrew will allow us to revise them: instead of saying that there is a night-and-day, totally obvious to everyone who looks, professional vs. recreational user difference when correcting color photographs in 16-bit, we can modify it as follows:

"If you correct in 8-bit rather than 16-bit, you are not currently a recreational rather than professional user, and you will not currently see a night-and-day, totally-obvious-to-anyone-who-looks difference, but if you continue to do so, in two or three years when ProPhoto RGB is introduced into Photoshop, you *will* be a recreational rather than professional user, by God, and you *will* see a night-and-day, totally-obvious-to-anyone-who-looks difference, unless you are one of the 99.9% of users intelligent enough not to attempt major edits in an ultra-wide gamut RGB."

If Andrew can live with that as a resolution, I certainly can.

Dan Margulis

____________________________________________________________________________

On 9/23/05 10:54 AM, "Dan Margulis" wrote:

With all due respect Dan, thatxs nonsense. Nobody uses the? The edits here are unusual? Many professional users, many digital photographers use ProPhoto RGB. Every edit in Adobe Camera RAW no matter what color space encoding you select or what bit depth happens in ProPhoto RGB with a 1.0 gamma prior being presented to the user.

I can (and I think did) illustrate that to anyone that wants to examine the image in Adobe Camera RAW, the scene gamut cannot be fully exploited in Adobe RGB (1998) and can in ProPhoto in 16-bit (as it can in 8-bit with obvious appearing noise).

I didnxt expect this scene or any additional scenes I can capture with this sub $1000 camera to xfitx your criteria since once again, that seems to be a moving target. So Ixve come to the conclusion that no matter what one does to try to show the advantage of high bit editing, it will fall on at least two deaf ears. Others who wish to download the image can clearly see for themselves the downside of using 8-bits compared to high bit with the example I posted. They can decide for themselves that there ARE real world, non synthetic images that fall outside Adobe RGB (1998) gamut (as does my $800 Epson 2400) that benefit from high bit editing.

Dan, you can see the effect of the noise in the 8-bit version without any USM. NONE was applied in ACR, the image is in serious need of sharpening but none the less, the noise is present without it. More editing will produce a greater effect of showing this. We have no idea what will happen with future editing, conversions to other color spaces for output, resizing etc. As Ixve stated in the past, the use of high bit simply provides more editing headroom. To dismiss the obvious effect of this noise by saying that xthis or that editx isnxt kosher when the edits do not show degradation in the high bit file is simply another effect of sticking onexs head in the sand. This is and has always been the advantage of high bit editing!

Noiser in shadows with a very odd speckling? Yes, I see that. Thatxs not a useful attribute to induce on a file unless you want such an effect. Itxs not seen on the high bit file.

Yes I do, with a significant amount of color information I can use tossed away in the process. It sounds like youxre in favor of using ultra-small gamut RGB working spaces in 8-bit.

Dan, you can apply a Gaussian blur to the image and remove the noise but no one is suggesting this is a good way to remove the noise or smooth out a histogram. Bottom line is one editing routine doesnxt produce this effect of noise, the other does. I