16 bit summation | Photoshop

Home -> Adobe training -> Photoshop training -> Professional Photoshop training with Dan Margulis

Dan Margulis Applied Color Theory

16-Bit Summation, 2005

Date: Thu, 1 Sep 2005 10:18:38 -0700

From: Richard Chang

Subject: 16 bit printing

A recently posted question wondered:

A question with a look to the future: I have heard some speculation

that at some point printers might support 16-bit files directly. Would that be a case

where there might be some advantage?

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

____________________________________________________________________________

Date: Sat, 03 Sep 2005 09:56:47 -0600

From: Andrew Rodney

Subject: Re: Eighteen Questions about Dan's new LAB book

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

DM: "I repeatedly asked him whether he had ever personally run a test (or

seen anyone else perform such a test) where the same exact corrections were

applied in both 8- and 16-bit modes to a real-world color photograph, and

compared

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

____________________________________________________________________________

Date: Sat, 3 Sep 2005 16:28:41 -0700

From: Lee Varis

Subject: Re: Eighteen Questions about Dan's new LAB book

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

____________________________________________________________________________

Date: Sat, 03 Sep 2005 19:12:24 -0600

From: Andrew Rodney

Subject: Re: Eighteen Questions about Dan's new LAB book

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

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

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.

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.

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?

What we have here is a file in ProPhoto RGB that contains no colors

that would fall outside of Adobe RGB.

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.

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!

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.

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.

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

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!

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.

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.

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.

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.

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.

The bottom line -- if you must use ProPhoto RGB stay in 16bits for

major adjustments.

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/

____________________________________________________________________________

Date: Sat, 3 Sep 2005 21:02:39 EDT

From: Dan Margulis

Subject: Re: Eighteen Questions about Dan's new LAB book

Andrew Rodney writes,

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.

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

____________________________________________________________________________

Date: Sat, 03 Sep 2005 21:40:54 -0600

From: Andrew Rodney

Subject: Re: Eighteen Questions about Dan's new LAB book

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

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.

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

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.

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!

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.

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.

The reasons they are not tested are 1) they have limited market presence and 2) I strongly

recommend against their use in color correction.

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.

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.

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.

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.

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.

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.

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/

____________________________________________________________________________

Date: Sun, 04 Sep 2005 00:32:55 -0400

From: Ric Cohn

Subject: Re: Eighteen Questions about Dan's new LAB book

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

____________________________________________________________________________

Date: Sun, 4 Sep 2005 13:14:47 +0200

From: "Francisco Bernal"

Subject: Re: Eighteen Questions about Dan's new LAB book

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

____________________________________________________________________________

Date: Sun, 04 Sep 2005 08:55:39 -0600

From: Andrew Rodney

Subject: Re: Eighteen Questions about Dan's new LAB book

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

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.

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.

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

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

However, the 16 bit file looks softer.

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>

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.

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.

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.

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.

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.

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

I looked up the Canon 350D and I believe it's the Rebel version of the

20D (which I've used).

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

____________________________________________________________________________

Date: Sun, 04 Sep 2005 08:56:02 -0600

From: Andrew Rodney

Subject: Re: Eighteen Questions about Dan's new LAB book

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

Prophoto is a space excesivaly big to be usefull

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

____________________________________________________________________________

Date: Sun, 4 Sep 2005 09:49:48 -0700

From: Lee Varis

Subject: Re: Eighteen Questions about Dan's new LAB book

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

It's 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.

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

____________________________________________________________________________

Date: Sun, 04 Sep 2005 13:08:07 -0400

From: Iliah Borg

Subject: Re: Eighteen Questions about Dan's new LAB book

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

So the best thing about ProPhoto RGB is grayscale imaging

not color!

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

Best regards,

____________________________________________________________________________

Date: Sun, 04 Sep 2005 11:48:23 -0600

From: Andrew Rodney

Subject: Re: Eighteen Questions about Dan's new LAB book

On 9/4/05 10:49 AM, "Lee Varis" 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.

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.

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

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.

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.

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

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.

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?

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.

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.

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!

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

We're not trying to "contain" color but to translate it so that it

works in a completely different context.

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

Andrew Rodney

____________________________________________________________________________

Date: Sun, 04 Sep 2005 12:58:39 -0600

From: Andrew Rodney

Subject: Eighteen Questions about Dan's new LAB book (16-bit challenge)

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

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.

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

____________________________________________________________________________

Date: Sun, 4 Sep 2005 20:05:14 -0700

From: Lee Varis

Subject: Re: Eighteen Questions about Dan's new LAB book

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

Dear Lee, have you tried taking images of flowers, red

roses, for example?

Yes.

regards,

Lee Varis

http://www.varis.com

888-964-0024

____________________________________________________________________________

Date: Sun, 4 Sep 2005 20:19:28 -0700

From: Lee Varis

Subject: Re: Eighteen Questions about Dan's new LAB book

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

Sorry Lee but that's just silly talk.

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

____________________________________________________________________________

From: Werner Tschan

Date: MonÊSepÊ5,Ê2005Ê 4:53 am

Subject: Re: [colortheory] Eighteen Questions about Dan's new LAB book

Andrew Rodney wrote:

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.

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

____________________________________________________________________________

From: Ric Cohn

Date: MonÊSepÊ5,Ê2005Ê 12:30 pm

Subject: Re: [colortheory] Eighteen Questions about Dan's new LAB book

On Sep 4, 2005, at 10:55 AM, Andrew Rodney 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.

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

___________________________________________________________________________

Date: Wed, 07 Sep 2005 17:41:38 -0400

From: Ric Cohn

Subject: Ideal 8 bit working space?

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

___________________________________________________________________________

Date: Mon, 19 Sep 2005 14:07:43 +0200

From: Ben Richardson

Subject: 8 vs. 16 bit and banding

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?

____________________________________________________________________________

Date: Mon, 19 Sep 2005 12:02:05 -0700

From: "Mike Russell"

Subject: Re: 8 vs. 16 bit and banding

From: "Ben Richardson"

...

I've found that almost [banding] 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.

...

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.

...

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?

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

____________________________________________________________________________

Date: Mon, 19 Sep 2005 16:07:07 -0400

From: Ric Cohn

Subject: Re: 8 vs. 16 bit and banding

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

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?

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

____________________________________________________________________________

Date: Tue, 20 Sep 2005 22:23:18 +1000

From: Stephen Marsh

Subject: Re: 8 vs. 16 bit and banding

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

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.

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.

____________________________________________________________________________

Date: Tue, 20 Sep 2005 11:31:25 -0400

From: Ric Cohn

Subject: Re: Re: 8 vs. 16 bit and banding

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

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.

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

____________________________________________________________________________

Date: Fri, 23 Sep 2005 12:54:31 EDT

From: Dan Margulis

Subject: Response to Andrew Rodney's test

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

____________________________________________________________________________

Date: Fri, 23 Sep 2005 11:49:50 -0600

From: Andrew Rodney

Subject: Re: Response to Andrew Rodney's test

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

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.

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.

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.

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!

Any file corrected in 8-bit will be very slightly grainier than one corrected

in 16-bit.

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.

(Andrew concedes that

when these same moves are applied in Adobe RGB, the two images are the same

for all practical purposes).

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 want the color available for output without the noise, I can accomplish this in high bit.

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.

While it's arguable whether the image taken as a whole is better or worse,

certainly Andrew is entitled to object to the graininess.

Well I consider that some progress <g>

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.

Indeed it is. The scene and the file require this wide gamut space since I can, will and want to use those colors to the output devices I have available today. In the future, I would expect even wider gamut devices to be at my disposal. Other than the file being twice the size, whatxs the problem?

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

The same effect can be seen in LAB which is a ultra wide gamut space! I can clearly see similar noise issues in 8-bit LAB versus high bit LAB.

At bottom, though, it's just another attempt to blow smoke over the inability

to back up his partners' extravagant claims.

Anyone other than Dan taking this statement at face value should consider looking at the RAW file, converting both ways and using whatever corrections they wish. Therexs no smoke here. The data is there for anyone to see. But since once again, the rules of this silly challenge have changed, I have to join the ranks of those such as Bruce Lindbloom as someone that finds more smoke in Danxs challenge than anything else. So know we have to show a difference between the two using what gamut working space?

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

I think that quote about recreational users is someone else's however, I still agree that itxs pretty obvious in the current example that therexs a visible and obvious benefit of the high bit editing versus the 8-bit editing. And if you can back up the statement that 99.9% of users do not use ProPhoto RGB, Ixd love to see some empirical data to back that up. Once again, you appear to the one blowing smoke by implying you have the xear of the industryx by saying that less than 1% of users are working in this space. I have no statxs to provide but I do know of many digital photographers are working in this space. I certainly would not go on record as you have to say itxs a mere 1% and all of them are lacking intelligence.

Once again, Ixve provided empirical data to show that many scenes captured with just a prosumer digital camera fall way outside Adobe RGB (1998) gamut as does a number of Prosumer desktop printers. If those colors are not important to you, fine. The challenge is so undefined and moving that you should really add that the xtestsx have to be done in this or that space, using this or that edit, using this or that RAW converter. The effects of the edits on an 8-bit file ARE visible in synthetic images and have always been so but that didnxt wash with you. Now, with a real world image that is basically a snapshot, the issue is the working space. What next?

Andrew Rodney

____________________________________________________________________________

Date: Fri, 23 Sep 2005 14:36:10 -0400

From: Ric Cohn

Subject: Re: Response to Andrew Rodney's test

Dan,

Thanks for the thorough and thoughtful posting. However, I fear the fox is already among the chickens. ProPhotoRGB is now essentially a "sanctioned" Photoshop workspace. It is one of the 4 output choices for Camera Raw, and I have seen it heavily promoted as a digital output space since it loses no potential capture colors. I have seen few warnings about using it in 8 bit, which isn't that surprising since virtually everyone who advocates this workspace also advocates editing in 16 bits. I suspect it's very presence in Camera Raw is somewhat related to the power (good or bad I don't really know) that this group has over the Photoshop development team. AFAIK, there is no warning if you want to process Raw files to 8 Bit ProRGB although I think it's clear from Andrew's test that working with ProRGB in 8 Bit is a dangerous thing to do. I would not be surprised to see it added at one of the choices from the Color Preferences dialog box. In any case, it's presence in Camera Raw virtually guarantees that significant numbers of Amateurs with digital cameras will be doing most or all of their image editing in ProRGB.

Your contention that small moves in ProRGB make very large and less controllable changes to a file make it sound like Lab. Of course, for Lab you have always stated that it is excellent for making large changes, but that for maximum quality you should expect to make final adjustments in RGB or CMYK. Andrew, Bruce Fraser, and other ProRGB advocates must either be ignorant of this or disagree with you on this because it is quite clear from their writings that they stay in ProRGB all the way through to output or conversion. I'm sure if they disagree we will hear from them, and I look forward to another educational exchange of ideas- hopefully without vitriol from either side!

I've looked at ProRGB with Lab conversions and it seems totally unsuitable to the manipulation of imaginary colors as discussed in Canyon. Since ProRGB also contains these imaginary Lab colors they get converted back to white or near white! From my limited testing I'd say a ProRGB workflow and using Lab for these kinds of corrections are mutually exclusive.

Finally, this brings me back to my question about an "ideal" RGB working space. I think it is reasonable to find sRGB and ColorMatchRGB unsuitable for some images. They both limit colors that are viewable on existing good monitors and printable with existing output devices. AdobeRGB does get most of these colors, but I'm not convinced it's an ideal space either. It was created by accident and it seems possible to construct a space that is both smaller and contains virtually all currently printable colors. A number of color geeks have created other working spaces which attempt to address these issues. However, no space is likely to get wide acceptance unless it is adopted by Photoshop the way ProPhotoRGB has been. Do any color space/gamut experts on this list feel one space is clearly superior? The ones I can think of off the top of my head are: L-StarRGB, BetaRGB, BestRGB and DonRGB, I'm sure there are many others.

Ric Cohn

____________________________________________________________________________

Date: Fri, 23 Sep 2005 13:30:04 -0600

From: Andrew Rodney

Subject: Re: Response to Andrew Rodney's test

On 9/23/05 12:36 PM, "Ric Cohn" wrote:

Finally, this brings me back to my question about an "ideal" RGB

working space.

No such space exists or wexd all be using one.

It was created by accident and it seems possible to

construct a space that is both smaller and contains virtually all

currently printable colors.

It was created by accident, a funny story but a bit off topic. Since 1988, itxs behaved quite well despite the mixup in chromaticity values. Anyway, there are output devices whoxs gamuts fall outside of Adobe RGB (1998). As I mentioned I have one sitting here that cost less than $800.

Do any color space/gamut experts on this list

feel one space is clearly superior?

Depends on your goals. If you want to contain all the colors you can capture, itxs ProPhoto RGB. If you are sending files to a PC user how hasnxt a clue about ICC aware applications, sRGB. For a Mac user, ColorMatch RGB. As you can see, there is no one size fits all, prefect space. If I begin with ProPhoto RGB to attempt to have a file I can actually work with from RAW data, I can then convert to a smaller space. I canxt go the opposite direction.

Andrew Rodney

____________________________________________________________________________

Date: Fri, 23 Sep 2005 16:57:32 -0400

From: "Iliah Borg"

Subject: Re: Response to Andrew Rodney's test

On Fri, 23 Sep 2005 13:30:04 -0600 Andrew Rodney wrote:

If you want to contain all the colors you can capture,

I'm afraid I do ot understand that. We capture colours with digital cameras as gray levels. We reconstruct those colours at raw convertion stage. This reconstruction often includes inventing colours, as far as I see it.

Best regards,

____________________________________________________________________________

Date: Fri, 23 Sep 2005 17:13:42 -0600

From: Andrew Rodney

Subject: Re: Response to Andrew Rodney's test

The rendering produces colors based on the color mixing function of the chip from the RAW Grayscale data.

You can easily see if the rendering exceeds or doesnxt exceed the gamut of the working space you select in Adobe Camera RAW by looking at the Histogram as you toggle from one to the other supported space. I find all kinds of scene data rendered such that therexs one or more colors clipping in a smaller working space like Adobe RGB (1998) and fully contained in ProPhoto. Of course you can alter the rendering before the color space encoding all you wish. If you saw clipping in Adobe RGB (1998) you could lower the saturation. Or the opposite; raise the saturation to an ugly level such that you might very well produce one or more colors clipping even in ProPhoto RGB. But I donxt know why youxd make the file over saturated and ugly on purpose. Point is, the scene data and the color mixing function is such that you can produce a color appearance you desire in any of the working space supported but introduce clipping in sRGB, ColorMatch RGB and Adobe RGB (1998) but NOT in ProPhoto RGB. Youxve now contained the colors in that working space you would have toss away in the other three. I donxt see why thatxs a useful practice if you want to use those colors. Of course, I would suggest you do so in 16-bit, the point of this entire post.

Andrew Rodney

____________________________________________________________________________

Date: Fri, 23 Sep 2005 18:56:40 -0600

From: Ron Kelly

Subject: Re: Response to Andrew Rodney's test

Andrew:

This sounds analagous to shooting everything with a wide angle lens because "you never know if you might need it in the future for cropping purposes" type of thing. Your final quality is hurt by the fact that you had to crop the picture so much.

Obviously the analogy is not apt in that as photographers we can shoot things many ways but we're unlikely to use multiple workspaces.

However, I think that it is applicable in that there is some truth to the idea that using an overly wide gamut space has it's downsides. Capturing all the colours that a device can get is not as important for the type of work that I do as getting good control of the colours I have.

In other words, I'd rather not obsess over potentially missing mice in my picture(s) when I'm trying to concentrate on the elephants walking through it.

Ron Kelly

____________________________________________________________________________

Date: Fri, 23 Sep 2005 18:02:33 -0700

From: Peter Figen

Subject: Re: Response to Andrew Rodney's test

There seems to be an obsession with range of colors, as if that were the only thing that validated the image. Maybe that's why most of my favorite images have been shot on Tri-X.

Peter Figen

____________________________________________________________________________

Date: Fri, 23 Sep 2005 19:20:28 -0600

From: Andrew Rodney

Subject: Re: Response to Andrew Rodney's test

On 9/23/05 6:56 PM, "Ron Kelly" wrote:

This sounds analagous to shooting everything with a wide angle lens

because "you never know if you might need it in the future for

cropping purposes" type of thing.

As a Photographer, I find that a poor analogy. I would most certainly lose something by using a wide angle and then cropping like crazy when I could have used a longer lens.

A better analogy would be always shooting in 8x10 because you have one big honking piece of film. While thatxs true, there are all kinds if scenes I simply canxt shoot in 8x10 and in fact, 35mm with a motor drive is the way to go (I shot the 84 Olympics for the LAOOC and without fast lens, motor drives and 35mm, Ixd have lost a lot of good shots).

However, I think that it is applicable in that there is some truth to

the idea that using an overly wide gamut space has it's downsides.

In 8-bit, yes which has been my point. There are colors that fall outside display gamut you canxt see. Thatxs getting better with wide gamut technologies but I donxt know wexll ever see something as wide as ProPhoto. But the alternative is to toss away the colors which can be output. If you look at the 3D plots I made of that scene and ProPhoto using ColorThink, youxll see that the scene isnxt approaching the edges of that huge working spaces gamut. But itxs larger in some areas than the edges of Adobe RGB (1998). The colors outside that space still fall within the Epson gamut. So while I might be able to use something slightly larger than Adobe RGB (1998) and quite a bit smaller than ProPhoto, Ixm not going to build custom working spaces based on every image. I can stick with the larger gamut working space in high bit and only suffer a file thatxs twice the size.

Capturing all the colours that a device can get is not as important

for the type of work that I do as getting good control of the colours

I have.

Ixm not proposing that ProPhoto RGB or any similar super wide gamut space is ideal for all or has no downside. But I will say that therexs a benefit of using high bit editing which my samples clearly show. If all we had to work with was ProPhoto or Adobe RGB (1998) itxs possible we could dictate that 8-bit editing is safe with that space although since we have no idea how a file might be edited in the future and that by keeping the file in high bit, we donxt have to worry about anything other than a file thatxs twice as large. Like Ixve said from day one, high bit editing is about headroom and possible insurance.

This argument is two fold. One says that therexs no examples of real world images that show the benefit of high bit editing. So far, no one has said thatxs not being illustrated with my simple example. Now the rules are changed and saying xit canxt be a wide gamut working spacex which is unfair. There are those that work with spaces larger than Adobe RGB (1998) and smaller than ProPhoto and until someone goes about doing a heck of a lot of science, we donxt know where to draw the line. Or we can simply edit in high bit, live with the file size and not worry. And as yet, Ixve yet to hear how converting a file into LAB circumvents what could be called a wide gamut editing space. Itxs very, very large. If you convert the RAW file into ProPhoto and then go into LAB, the issues still show up. If you convert from RAW into sRGB and into LAB, well youxve tossed a lot of colors away that were in the original. So itxs quite possible to pretend that therexs no benefit to high bit editing and as yet, aside from file size, I havenxt seen it fail to produce better data in this example.

Andrew Rodney

http://www.digitaldog.net/

____________________________________________________________________________

Date: Fri, 23 Sep 2005 23:57:33 -0400

From: Ric Cohn

Subject: Re: Response to Andrew Rodney's test

Andrew,

So far no one has addressed the issues I raised here:

On Sep 23, 2005, at 2:36 PM, Ric Cohn wrote in response to Dan's post:

Your (Dan's) contention that small moves in ProRGB make very large and less

controllable changes to a file make it sound like Lab. Of course, for

Lab you have always stated that it is excellent for making large

changes, but that for maximum quality you should expect to make final

adjustments in RGB or CMYK. Andrew, Bruce Fraser, and other ProRGB

advocates must either be ignorant of this or disagree with you on this

because it is quite clear from their writings that they stay in ProRGB

all the way through to output or conversion. I'm sure if they disagree

we will hear from them, and I look forward to another educational

exchange of ideas- hopefully without vitriol from either side!

I've looked at ProRGB with Lab conversions and it seems totally

unsuitable to the manipulation of imaginary colors as discussed in

Canyon. Since ProRGB also contains these imaginary Lab colors they get

converted back to white or near white! From my limited testing I'd say

a ProRGB workflow and using Lab for these kinds of corrections are

mutually exclusive.

I am very interested in your response to this. Dan's suggestion that edits in ProPhotoRGB are inherently less accurate (or at the very least requiring more accurate placement of edit points?) is to me a fairly serious one. If more colors are created at the expense of control I'd say this is important. If it is a false claim I'd like to hear it disputed.

You said "But I will say that theres a benefit of

using high bit editing which my samples clearly show."

Well, this is not strictly true. What your test shows is that there are changes to an 8 bit file that are not desired and that it does not happen to a 16 bit file. Now we're in the realm of deciding what makes a better picture- which is always a more subjective decision. I'm not saying it's not possible that an artistically better result can result from 16 bit editing- from your test I suspect there may be examples out there for which this would be true- I'm just saying that I don't think the argument for working in ProPhotoRGB and using 16 bit editing has been made.

You also said "Ive yet to hear how converting a file into LAB circumvents what could be called a wide gamut

editing space. Its very, very large."

Actually, Dan goes into considerable detail on this topic in "Canyon". Perhaps you wouldn't agree with his analysis. He seems convincing to me, but I don't claim to be an expert. If you have access to a copy I'd be very interested in your response.

Finally, I'm not familiar with your finest photographic work. Maybe your work is absolutely incredible and would clearly show the merits of working with an extended tonal range. Maybe you know others who's work is vastly superior because of working in 16 bit to anyone who is using only 8 bits. I think the proof would be in the images. I don't want to be blind to the advantages, but so far I don't see them for 99.9% of the images being produced. On the other hand I suspect that 90% of those using ProRGB aren't either knowledgeable enough or careful enough to avoid making edits that are worse than they would make in a smaller space. What's needed is probably impractical: A group of equally talented image makers in a classroom situation creating, editing and outputting images in 8 bit or 16 bit and seeing if the 16 bit images are found better than the 8 bit images. Something like what Dan describes for his classes perhaps. Now, would the participants also be the judges?

Although I've addressed this to Andrew, I hope anyone with knowledge or opinions will chime in- including Dan!

Regards,

Ric Cohn

____________________________________________________________________________

Date: Sat, 24 Sep 2005 12:49:40 +0100

From: "Bob Frost"\

Subject: Re: Response to Andrew Rodney's test

Dan,

As one of the 'misguided', I felt I should comment on one or two points you made.

Bruce Fraser was using ProPhotoRGB back in 2000 (http: //www.creativepro.com/story/feature/8582.html), as was I (a mere enlightened or misguided amateur).

It seems that the space was actually produced in 1999 by Kodak as their ROMM (Reference Output Medium Metric), and was designed to be compatible with Photoshop 5 and to work closely with the ICC PCS.(http: //www.kodak.com/global/plugins/acrobat/en/professional/products/software/colorFlow/romm_rgb.pdf).

I downloaded it from the Kodak website back in 2000, I believe.

Bob Frost.

____________________________________________________________________________

Date: Sat, 24 Sep 2005 10:32:35 EDT

From: Dan Margulis

Subject: User practices--RGB definitions

From time to time, the question arises of what people are actually using as their RGB definition, setting aside the question of whether their practices make any sense.

I am interested in this topic, too, so I have surveyed my classes at the last two Photoshop Worlds with a view to finding out what the current trends are in terms of sRGB v. Adobe RGB. In each case, I would estimate that I asked around 500 people. In each case, around a third of the audience identified themselves as being professional photographers either now or in the past.

These are of course guesstimates of the response. When I say "1%", though, it's pretty accurate--somewhere between 2 and 6 people.

The question was: What is your customary RGB workspace, as defined in your Color Settings dialog?

Answers Vegas, 3/05

Don't Know, or Don't Understand the Question: 18%

sRGB: 40%

Adobe RGB: 40%

Anything Wider Gamut than Adobe RGB: Nobody

None of the Above: 2%

Answers Boston, 9/05

Don't Know, or Don't Understand the Question: 8%

sRGB: 40%

Adobe RGB: 50%

Anything Wider Gamut than Adobe RGB: 1%

None of the Above: 1%

Personally, I was mildly surprised at the sRGB v. Adobe RGB vote, because I thought that it might be more like 60-40 in favor of sRGB. I was *really* surprised by the poor showing of None of the Above, because I thought a lot of people were using either ColorMatch RGB or something home-cooked. The Don't Know and wide gamut responses were about what I thought they would be.

Dan Margulis

____________________________________________________________________________

Date: Sat, 24 Sep 2005 08:35:00 -0600

From: Andrew Rodney

Subject: Re: Response to Andrew Rodney's test

On 9/23/05 9:57 PM, "Ric Cohn" wrote:

I am very interested in your response to this. Dan's suggestion that

edits in ProPhotoRGB are inherently less accurate (or at the very least

requiring more accurate placement of edit points?) is to me a fairly

serious one.

ProPhoto RGB like all working space is a container (a color space). Images don't have to fill it but you need a set boundary (the scale of the three primaries) to fit a range of color. So an image might have colors that fall outside saturated green in Adobe RGB (1998) that fit within ProPhoto or a larger space. Sorry if this is obvious but it's important. FWIW, LAB is also a huge space but falls into the same rules.

If you're working with an 8-bit file, the space between the bits in sRGB is much smaller (tighter) than ProPhoto RGB. That's why you need high bit. The discussion here is going in two directions one of which is the pluses (and one is saying issues) with wider gamut spaces.

There's nothing false about the color and the container has to be a size in which you either contain it and hopefully use it or toss it away. With the 3D gamut maps I produced in ColorThink, you can see actual image colors and how they compare to the gamut of the output device. What's false about such colors?

Well, this is not strictly true. What your test shows is that there are

changes to an 8 bit file that are not desired and that it does not

happen to a 16 bit file.

Exactly, the original challenge. That's the first part of this long set of posts (see my summary below because we're getting to the point of beating a dead horse).

Now we're in the realm of deciding what makes

a better picture- which is always a more subjective decision.

Yes especially if you prefer random noise <g>

I'm not saying it's not possible that an artistically better result can result

from 16 bit editing- from your test I suspect there may be examples out

there for which this would be true- I'm just saying that I don't think

the argument for working in ProPhotoRGB and using 16 bit editing has

been made.

Working in ProPhoto RGB in these examples (I have plenty) shows random noise in 8-bit and not in 16-bit. Now the question is, should you use a wide gamut space like ProPhoto RGB? My response is yes if you want to output colors in the scene that are reproducible and important to you that can't fit in a smaller working space.

You also said "I‚ve yet to hear how converting a file into LAB

circumvents what could be called a wide gamut

editing space. It‚s very, very large."

Actually, Dan goes into considerable detail on this topic in "Canyon".

Perhaps you wouldn't agree with his analysis. He seems convincing to

me, but I don't claim to be an expert. If you have access to a copy I'd

be very interested in your response.

I have not got that far but will skip ahead. But I have said if you start with a smaller gamut original and go into LAB, you're going to find a much bigger difference than starting with a larger gamut original. You can see this using my RAW file.

Finally, I'm not familiar with your finest photographic work. Maybe

your work is absolutely incredible and would clearly show the merits of

working with an extended tonal range.

Kind of immaterial.

Maybe you know others who's work

is vastly superior because of working in 16 bit to anyone who is using

only 8 bits.

Like the extra colors I can capture and use that are important to me, not producing random noise in shadows is also important to me. It might not be for others. That's a judgment call. It doesn't change the facts, the math and the evidence that producing the edits in high bit DOES NOT PRODUCE THE NOISE! That's been the debate since the earth started cooling around this list.

I think the proof would be in the images. I don't want

to be blind to the advantages, but so far I don't see them for 99.9% of

the images being produced.

That's very possible. I'd ask if you're processing RAW digital files. I'd ask that if that 1% is important to you at the expense of a larger file. I'd ask if the edits and output in the future are well defined or not. Again for the 99th time, high bit editing is insurance and headroom. If you don't care about that, don't use it. But saying there's no cases where using high bit editing on real world images produces a benefit compared to 8-bit isn't true and I've illustrated it.

On the other hand I suspect that 90% of

those using ProRGB aren't either knowledgeable enough or careful enough

to avoid making edits that are worse than they would make in a smaller

space.

Well those of us, including DM should be telling them to edit in high bit! Or we can continue to believe that this space will go away, your an idiot for using it and that all high bit editing provides no benefit. I don't see that being something educators should do.

This idea that with some special odd captures and working spaces and users that high bit editing is voodoo rings of a digital imaging "higher intelligence" mind set.

The signal to noise ratio here is such that I feel I need to paraphrase where we’ve been. There are two issues here; the benefit of high bit editing versus it’s downside and the benefit of wide gamut working space and their downside. The two are linked but let’s not confuse the original challenge.

DM: Show us a real world image where editing in 16-bit provides a benefit. AR: Here's a snapshot in it’s truest sense from a $900 digital camera which shows less noise.

DM: Yes I see that.

DM: Your edits are poor, it’s a wide gamut space, doesn’t count.

AR: The space allows me to contain colors I can output on my $800 ink jet of which there are probably tens of thousands sitting on users desktops. Lots of people edit files in lots of ways, some better than others. The high bit file doesn’t show the noise, the 8-bit does. There might be ways to edit the file so less noise (perhaps no noise) is seen. Unless every edit is done to the high level of DM, we have to assume that it’s possible the edits on an 8-bit file will produce this noise and yet, by simply accepting a file twice as large, it’s no longer an issue. But we don’t live in a prefect world and the high bit file allows more headroom in the edit and doesn’t show the noise.

DM (and others): There’s no reason to use ultra wide gamut working space and those that do are not intelligent plus far and few between.

AR: The scene and many such scenes contain these colors, I can use them and I want them. If you don’t, fine. But in using these colors, there’s a visual difference in quality using high bit. If you’re scanning images and you want something that can hold the Ektachrome gamut, ProPhoto RGB is it.

Bottom line. There are no prefect working spaces, there are probably fewer prefect Photoshop users. There are images that can exhibit image degradation in 8-bit that don’t show this in high bit with the downside being a larger file. You’ll see less issues with a smaller gamut working space but you also have potentially less color than you can output. If you don’t mind this fact, fine.

One other point. All the edits could have been done in the RAW converter, saved out in a wide gamut space in 8-bit with no noise. Why? The converter is working on linear encoded data in high bit and all editing is global using what could be considered a proxy image. It’s very fast and very flexible. So while my original example needed some tweaks, I could have done this all in the RAW converter faster to produce even better image quality. IOW, why take a RAW file, bring it into Photoshop in high bit or 8-bit and edit it? Yes, the editing in high bit produces superior quality. Again, not a prefect world and we have to accept that some will provide files that need global editing after RAW conversion.

Andrew Rodney

____________________________________________________________________________

Date: Sat, 24 Sep 2005 10:35:40 EDT

From: Dan Margulis

Subject: Re: Response to Andrew Rodney's test

Andrew Rodney writes,

Dan, you can see the effect of the noise in the 8-bit version , etc.

Irrelevant. I conceded in that post that *in an ultra-wide gamut RGB,* it is probably possible to have a real-image series of corrections that demonstrate an advantage for correcting in 16-bit. I concede the same thing about correcting in 1.0 gamma. That's why I don't bother to run extensive tests on either one, and why they don't qualify for the challenge.

Since I have conceded this for at least five years, it should not be terribly surprising, but if you need to quote me on it, there it is.

There1s no smoke here. The data is there for anyone to see. But

since once again, the rules of this silly challenge have changed...

You and your business partners were hyperaggressively touting 16-bit as the only sensible approach to editing, and bashing as unprofessional fools any users who dared to disagree, in roughly the period 2000-2001, which is when I first started asking for any evidence that 16-bit was even slightly superior, let alone the enormous difference that you and your partners were claiming.

Now, you come up with an example that depends completely on the use of a color definition that didn't even exist in Photoshop until three years later, and accuse *me* of changing the rules.

So know we have to show a

difference between the two using what gamut working space?

In view of the clear move in the marketplace since then toward either sRGB or Adobe RGB, I would suggest one of those.

And if you can back up the statement that 99.9% of users do not use

ProPhoto RGB, I1d love to see some empirical data to back that up.

I made no such statement. I said that 99.9% of users do not make MAJOR EDITS in ProPhoto RGB. And, if you'd like to see some empirical data, yes, I have some, but as the question of what people *do* use is not the same as what they *ought to* use, I've posted it as a separate message with a different header.

Dan Margulis

____________________________________________________________________________

Date: Sat, 24 Sep 2005 11:11:20 EDT

From: Dan Margulis

Subject: Re: Response to Andrew Rodney's test

Ric writes,

Thanks for the thorough and thoughtful posting. However, I fear the fox

is already among the chickens. ProPhotoRGB is now essentially a

"sanctioned" Photoshop workspace.

Not yet. By default, it isn't even visible as an option within Color Settings--you have to check More Options to see it.

I have seen it heavily promoted as a digital output

space since it loses no potential capture colors. I have seen few

warnings about using it in 8 bit, which isn't that surprising since

virtually everyone who advocates this workspace also advocates editing

in 16 bits. I suspect it's very presence in Camera Raw is somewhat

related to the power (good or bad I don't really know) that this group

has over the Photoshop development team.

The speculation is probably correct. The fantasy of an ultra-wide gamut RGB as a solution to imaging ills was heavily touted by Kodak in the late 1980s-early 1990s, using exactly the same naive arguments that Andrew Rodney and his partners make today: you're throwing away colors! Irretrievable data loss! By 1996 you're going to want those colors! And, best of all, once you have the file containing all these colors that will be available in 1996, there's no problem repurposing it for something that's much narrower-gamut, like a newspaper--you just press a button, and presto, there's your newspaper file!

That editing in such a space would be exceedingly difficult was not seen as a problem. Kodak's workflow assumed NO editing at all. The perfect scan goes into the perfect RGB, and then is converted by the perfect algorithm into the perfect CMYK file. This was the workflow that was referred to by me at the time as "calibrationism" and by admirers of the system as "pushbutton color".

This solution in search of a problem was a laughingstock by the time of Photoshop 4, for obvious reasons. It was therefore not heard of until Kodak reemerged with it five years later and hired one of Andrew's partners, who happened also to have Adobe's ear, to help them promote it.

Your contention that small moves in ProRGB make very large and less

controllable changes to a file make it sound like Lab. Of course, for

Lab you have always stated that it is excellent for making large

changes, but that for maximum quality you should expect to make final

adjustments in RGB or CMYK.

Yes. In a wide-gamut colorspace, there isn't enough editing precision to set perfect endpoints, among other things. In that respect, ultra-wide RGBs and LAB are alike. The difference is that LAB allows certain types of moves that aren't available in any RGB, and allows easy control of neutrality throughout the entire range of the image, somethiing that, as Iliah Borg has pointed out, is notoriously difficult in any RGB. An ultra-wide gamut RGB operates like any other RGB, except that all moves need to be cut in half to avoid major color shifts, something that is easier said than done.

Similarly, the danger of an ultra-wide gamut colorspace is that colors can be thrown out of gamut. In LAB, an experienced user is not troubled by this--the color is kept separate, and it's easy to see potential problems as they develop. In an ultra-wide gamut RGB it's much more difficult.

So, yes. LAB has certain advantages and certain disadvantages. So does sRGB. An ultra-wide gamut RGB combines all the disadvantages of LAB and most of the disadvantages of sRGB into one bloated package without giving us anything in return, which is why it was so decisively rejected in the early 1990s.

Finally, this brings me back to my question about an "ideal" RGB

working space.

There isn't one. It depends on the user's needs. It also depends on the era. Something like ColorMatch RGB made a lot more sense ten years ago than it does today. If the only thing you ever output to is newspaper CMYK, it still *does* make sense.

I think it is reasonable to find sRGB and ColorMatchRGB

unsuitable for some images. They both limit colors that are viewable on

existing good monitors and printable with existing output devices.

AdobeRGB does get most of these colors, but I'm not convinced it's an

ideal space either. It was created by accident and it seems possible to

construct a space that is both smaller and contains virtually all

currently printable colors.

All very true. Nevertheless, as I point out in a separate post, sRGB and Adobe RGB together account for well over 90% of Photoshop users today. There is a lot of merit in sticking with the same definition that other people use, even if it's clearly second-best.

A number of color geeks have created other

working spaces which attempt to address these issues. However, no space

is likely to get wide acceptance unless it is adopted by Photoshop the

way ProPhotoRGB has been.

Be careful what you ask for. Photoshop is a great program, but its history of making changes in color handling is not a happy one. A lot of your reasoning is the same as what was used by Adobe in 1998, when they torpedoed the existing standard. That existing standard wasn't a particularly good one, but thanks to the way it was replaced, we now have *two* standards, one of which is clearly worse than the previous standard, and the other one a lopsided RGB designed by mistake. In the interim, we had five years of chaos.

My view is that finally we have gotten back to a system that actually works--not well, but it works. In view of history, if Adobe plus Andrew and his partners try to make it better, there's a high likelihood that we'll get something that *doesn't* work, as we have in the past. So, I would leave well enough alone.

Dan Margulis

____________________________________________________________________________

Date: Sat, 24 Sep 2005 10:59:24 -0600

From: Andrew Rodney

Subject: Re: Response to Andrew Rodney's test

On 9/24/05 8:35 AM, "Dan Margulis" wrote:

Irrelevant. I conceded in that post that *in an ultra-wide gamut RGB,* it is

probably possible to have a real-image series of corrections that demonstrate

an advantage for correcting in 16-bit.

Not probably, absolutely. The math (not theory) and now the images make this pretty clear.

I concede the same thing about

correcting in 1.0 gamma. That's why I don't bother to run extensive tests on

either one, and why they don't qualify for the challenge.

So when the tree falls in the forest and no one is around, the sound is non existent....

You and your business partners were hyperaggressively touting 16-bit as the

only sensible approach to editing, and bashing as unprofessional fools any

users who dared to disagree, in roughly the period 2000-2001, which is when I

first started asking for any evidence that 16-bit was even slightly superior,

let alone the enormous difference that you and your partners were claiming

There have been wide gamut spaces from some digital cameras and certainly high end scanners well before 2001. As already posted, ROMM RGB predates that. That ProPhoto RGB didnxt get installed in Photoshop prior to that date is again, an attempt to hide from the reality. As for hyperaggressively touting 16-bit I can say that both myself and Bruce Fraser have always said that using such a file provides editing headroom. Thatxs always been backed up by simply science but if you must use the intelligent design mindset to ignore the math, at least we have actual images today that show this. Ixm not going to try to defend what I feel is an enormous difference versus what you or anyone else feels is enormous. Some would find the noise in the image I present an enormous issue, others would totally ignore it. Should you be the former user, you can reduce or eliminate it using more than 8-bits.

Now, you come up with an example that depends completely on the use of a

color definition that didn't even exist in Photoshop until three years later,

and accuse *me* of changing the rules.

Yes I do. At least Ixd expect you to:

1. Admit that real world images exist and are common that show degradation in 8-bit that do not in high bit (youxve actually said this recently).

2. That there are those that for whatever rational find it necessary to use wide gamut spaces (the Kodak engineers didnxt design it to entertain themselves).

3. That high bit files provide editing headroom illustrated in my example and by virtue of simple math. In certain workflows, even ones YOU many never use, the higher bit data provides a lack of (in this case) random noise.

I will admit:

If you work with a small(er)gamut space, the need for high bit editing is reduced and possibly a non issue. I'll add that since I donxt have a crystal ball, have no idea who might edit that file and at what skill level that it is possible they could introduce data loss that might be visible on some output devices. All insurance comes at a cost. In the case of high bit, itxs a bigger file. IF this is a severe problem for you AND you are working in a small gamut space AND know itxs very, very unlikely if impossible youxll gain any benefit from high bit, please donxt use it.

With the right tools, you CAN edit an 8-bit wide gamut file with no degradation getting the best of both worlds (do the work in your RAW converter which of course is doing the job behind the scenes in high bit).

I said that 99.9% of users do not make MAJOR EDITS

in ProPhoto RGB.

Ixd love to know how you can come up with such stats. Is a major edit a simple color space conversion? Applying USM? Why even worry about what might cause the noise issue when it can be ignored by working a file twice itxs 8-bit size?

And, if you'd like to see some empirical data, yes, I have

some, but as the question of what people *do* use is not the same as what they

*ought to* use, I've posted it as a separate message with a different header.

I saw it, donxt find it all empirical and would suggest you donxt give up your day job to become a pollster <g>.

Ixm not sure we need to go much farther in this discussion unless we both agree to the points above. Real world, non synthetic images exist that show a benefit to high-bit editing but there are also images (many) that do not. In the end, each user has to decide if they want to use one process versus the other. But I hope you are not suggesting that there are no workflows, images or users who would benefit from high bit editing IF they donxt mind the larger file size.

Andrew Rodney

____________________________________________________________________________

Date: Sat, 24 Sep 2005 13:17:07 -0400

From: "Iliah Borg"

Subject: Re: Response to Andrew Rodney's test

I'm afraid that we are discussing design decisions made for ACR programming. It is hard for me to understand why ProPhoto is needed to be the destination space for conversion of raw data, but if Adobe had chosen so, we are to face both sides of the coin.

Best regards,

____________________________________________________________________________

Date: Sat, 24 Sep 2005 13:31:49 -0400

From: "jc castronovo"

Subject: Re: Response to Andrew Rodney's test

Well - we've come to some kind of agreement I think, but I'd like a clarification on one point: Is there any scenario where it would be necessary to temporarily take an 8 bit file into 16 bits for editing?

____________________________________________________________________________

Date: Sat, 24 Sep 2005 16:11:13 EDT

From: Dan Margulis

Subject: Re: Response to Andrew Rodney's test

Bob Frost writes,

Bruce Fraser was using ProPhotoRGB back in 2000

Yes, he was. This has zero bearing on the statement that you appear to be trying to refute, which reads: "This space was not installed in Photoshop until 2003".

Bruce was using ProPhoto then because Kodak had hired him to help in its design and promotion. Prior to that, he had been advocating a narrower-gamut space known as BruceRGB. Photoshop users did not have access to ProPhoto unless they downloaded it from somewhere, as it was not installed by Photoshop itself until Photoshop CS (2003).

In 2001, Bruce wrote, "If you really start out with a RAW image in high-bit form and a raw image downsampled to 8 bits, the difference really is night and day...it's totally obvious to anyone who looks that it's very advantageous to do the big moves on high-bit data." His partners wrote even more emphatically, flaming any users who challenged their view. These comments offer no indication that the night-and-day, totally-obvious-to-anyone-who-looks advantage is limited to an RGB that wouldn't appear in Photoshop for two more years.

Dan Margulis

____________________________________________________________________________

Date: Sat, 24 Sep 2005 17:09:59 EDT

From: Dan Margulis

Subject: Re: Andrew Rodney's test--consensus

Andrew Rodney writes,

I will admit:

If you work with a small(er)gamut space, the need for high bit editing is

reduced and possibly a non issue.

As also noted by John Castronovo, it appears that for all the noise, we may actually be getting close to a consensus, which would be a useful thing.

Therefore, I will back off the thread for the moment, and hope to post again about what was said in a few days.

Dan Margulis

____________________________________________________________________________

Date: Sat, 24 Sep 2005 23:06:32 -0400

From: "Michael Demyan"

Subject: RE: Andrew Rodney's test--consensus - My One Vote

I for one - photograph, scan, work and edit in 8 bit Adobe 1998. (sometimes detour into LAB :) )

I also print using an Epson 4000 using Ultrachrome inks that have a gamut close to Adobe 1998.

Michael Demyan

Fine Photography & Digital Graphic Design

www.mikedemyan.com

610-758-9769

____________________________________________________________________________

Date: Sun, 25 Sep 2005 02:20:21 -0400

From: Ric Cohn

Subject: Re: Andrew Rodney's test--consensus

On Sep 24, 2005, at 5:09 PM, Dan Margulis wrote:

As also noted by John Castronovo, it appears that for all the noise, we may

actually be getting close to a consensus, which would be a useful thing.

I fear that the usefulness of ProPhotoRGB will be the next horizon: Assume a Wide Gamut RGB workflow makes sense and you need 16 bit.

Despite Dan's insistence that using ProRGB as your general RGB working space makes no sense, I am still on the fence. I'm afraid wide gamut editing spaces must be taken into consideration in coming to a consensus on 8 bit vs 16 bit editing, and may actually prove to be a more important question. I believe Dan's strongest argument against wide gamut RGB workspaces it that it's difficult-to-impossible to place edit points as accurately as in smaller workspaces (maybe there are also other important questions). I'd like to see this proven or disputed with facts that can be tested. It's interesting that while Dan very convincingly shows the error in accepting a purely mathematical explanation for the benefits of 16 bit editing or for the insanity of editing in Lab and needing to convert back and forth between color spaces, I believe I've only seen a mathematical explanation for why Wide Gamut RGB spaces make no sense. Unlike editing in 16 bit which is mainly inconvenient, I believe there is a very real possibility that working In ProPhotoRGB could, if these arguments are valid, actually lead to a generally lower quality of images even with expert editing. However, if these arguments are not valid and the benefits really do matter then there is also a potentially much greater benefit from working in ProPhotoRGB than from working in 16 bits.

IMHO testing whether there are benefits (that outweigh the disadvantages) to working in a wide gamut color space for a "maximum quality" workflow seems much more difficult than it was for me to look at 16 bit vs. 8 bit editing. Image quality that matches my vision is obviously important to me. I spent a good bit of time a few years ago looking for a 16 bit advantage because I wanted it to be true- who wouldn't want significantly better quality for just the price of bigger files? However, I was able to prove to my own satisfaction that, for my workflow at least, there is no benefit to working in 16 bit as long as I first got the images into the ballpark of my final version (I believe this last part may be where I differ with Dan?). For me this mainly means scanning flat in 16 bit (due to the limitations of my scanner) and making my first corrections in 16 bit. Sometimes (rarely) if I will be making major changes to a digital shot I also output my digital files in 16 bit and do my first corrections there. I know Andrew will argue that one never knows if major changes will be made later, but I believe that a clean 8 bit file can take virtually anything that a 16 bit file can take and that it doesn't make a difference whether a poor scan or digital capture is in 16 or 8 bits.

For me to do all my layering, blending, retouching, saving, backing up, etc. etc. on a needlessly bloated file does not make sense to me. Considering the loss in image quality now or in the future has been shown to be at the most very slight, and virtually always correctable, even if the time saved from working in 8 bit only saved the time to do one more picture a year I think it's a waste not to do that one more picture! When I look at pictures I corrected only a couple of years ago (sometimes days ago ;-)) I frequently see areas I would treat differently today. When I have reason to output these images again for a new use I will frequently rework parts of them. The idea of using 16 bit because it is "more perfect" doesn't make sense here and the idea of leaving headroom for later also IMO doesn't hold up because I'm much more likely to either rework the image in ways that are less damaging rather than more damaging (as I get better) or make such radical changes that whether it's 16 bit or 8 bit is immaterial.

Unfortunately, AFAIK none of these arguments work for ProPhotoRGB. And if one accepts ProRGB as a reasonable space, then I believe you're pretty much stuck with 16 bit. For example, maybe there are colors which would be important to me that I can't get with AdobeRGB. Since I probably can't see the colors on my screen it's hard to say. Bright super saturated color is not typical in my images, but I think there may be colors I might want that are not in AdobeRGB. Maybe my pictures would be better... insecurity works wonders.

This is, in a sense, a subtler argument than the 16 bit issue and unless the sense of working in ProPhotoRGB can be proven or disproved I fear it's just the beginning of another round of heated discussions. Doing identical big sets of corrections on 2 versions for a 16 bit vs 8 bit test is one thing-- and we've seen how difficult that can be! Doing 2 sets of very subtle corrections on 2 files and then outputting them to look for subtle differences isn't so easy. Especially since, if you don't see a difference, it could just be due to the way your printer has been profiled. I guess first you need to output targets in the larger space and build excellent profiles, then confirm that if the image's colors are within the smaller space's gamut the prints are identical. Then print images where you believe the wider gamut is important and have unbiased viewers rate the different pictures. What if you first edit in 16 bit and repeat in 8 bit and the 16 bit files look better? Well, maybe the 8 bit file only needed some subtle differences in the edits to be superior. Or suppose you first edit in 8 bit and then repeat the moves in 16 bit- if there's no difference or the 8 bit images are preferred the same argument applies. Maybe by reworking the files several times we can come to a consensus and maybe ProPhotoRGB edited images will turn out to be preferred a significant percentage of the time, in that case working in ProPhotoRGB would be vindicated for some work flows. Of course, even if there is no consistent pattern it doesn't mean that a benefit doesn't exist, it could just be that our test uses the wrong output device or the wrong images, or the wrong profiles... Now we're getting into the realm of faith-- "evolution vs Intelligent Design".

I'd really like to see it proven that ProPhotoRGB makes no sense (or sense under only certain limited and predictable circumstances) so I can ignore it and move on to more important things- like making pictures.

My (long winded) 2¢.

Ric Cohn

____________________________________________________________________________

Date: Sun, 25 Sep 2005 09:00:49 -0400

From: "jc castronovo"

Subject: Re: Andrew Rodney's test--consensus

Thanks for your thoughts Ric. I believe that ProPhotoRGB is far too large a space to be useful for the vast majority of images that are dealt with, yet I've seen to my satisfaction that many saturated colors would be clipped by using sRGB or even Adobe1998. Possibly this doesn't matter for typical output, but I feel that we shouldn't knowingly and automatically limit the color gamut of what we archive. For many years, we've used Don Hutcheson's DonRGB which is a wide gamut color space, but not nearly as wide as ProPhotoRGB and I think it's been an excellent compromise as it allows a wide gamut without the problems that have been associated with ProPhotoRGB.

____________________________________________________________________________

Date: Sun, 25 Sep 2005 09:06:20 EDT

From: Dan Margulis

Subject: Re: Response to Andrew Rodney's test

John Castronovo writes,

Well - we've come to some kind of agreement I think, but I'd like a

clarification on one point: Is there any scenario where it would be

necessary to temporarily take an 8 bit file into 16 bits for editing?

Yes, but most of them are very obscure. Doing it can be helpful in certain LAB maneuvers, but I didn't even mention it in the book because anybody who's capable of figuring out when those maneuvers are necessary is also capable of figuring out that converting to 16-bit may help.

The most common everyday reason for doing it is, you are given an 8-bit RGB file containing computer-generated gradients, particularly blue ones. You have to convert it into CMYK. No, it's not the way the client should have done it, but too late now, this is the file you have.

In that case, it's helpful to convert the file to 16-bit, do something innocuous to fill the extra bits with random data (e.g. Gblur radius .1; upsample the file by 5%; rotate the file by 5% and then rotate it back) and THEN convert to CMYK and back to 8-bit.

Dan Margulis

____________________________________________________________________________

Date: Mon, 26 Sep 2005 01:00:12 -0700

From: Richard Wagner

Subject: RE: Andrew Rodney's test--consensus - My One Vote

Boy, it's been tough to sit back and even follow this thread... Most pro photographer colleagues of mine shoot with high-end cameras in RAW, process in 16-bit into ProPhoto or Adobe RGB depending on the primary intended use (AdobeRGB for stock sales/agency work and ProPhoto for fine art printing), and convert to sRGB for web use. Most of us are also comfortable converting to/working in CMYK. As for the results of the polls from Dan's workshops, I'd be interested to know how long those attendees have been shooting digitally, because they sound like a very inexperienced and uneducated group. I highly doubt that you would get comparable answers from, say, the Nikon D1scussion listserve membership or a poll on Rob Galbraith's forums.

Michael, the gamut of Ultrachrome inks clearly exceeds that of Adobe RGB (1998), as does the gamut of Fuji Velvia film. You might get even better results than you're getting now if you changed your workflow, although if you're satisfied with what you have, great. I would suggest that you read the scanning guide referenced below.

I have actually been going back through my files and re-scanning in high-bit, then assigning a custom G-M ProfileMaker profile generated from a HutchColor HCT target, and converting to ProPhoto (rather than AdobeRGB). The improvement I get in prints on my Epson 9600 is often dramatic and justifies the effort. Of course, Don Hutchison also recommends scanning in 16-bit, but what does he know about color... (http://www.hutchcolor.com/PDF/Scanning_Guide.pdf)

If you're happy with 8-bit sRGB, so be it. There are a lot of us, however, who won't even waste our time with the high-bit/wide-gamut discussion, nor would we be likely to attend a workshop where an 8-bit, small gamut workflow is advocated. It simply doesn't make sense. Andrew, you should have taken Bruce Lindbloom's advice! I don't anticipate spending any more time on this discussion, but I felt bad lurking and not voicing a vote.

I haven't finished reading Canyon yet (fortunately the binding is still holding up), nor have I even started reading Andrew's new book, which on a quick look appears to be well-written and well-bound. I have my own book to get through publication (on venomous animals, not digital technique), and my hope is that it will be well-bound as well.

--Rich Wagner (certified ColorTheory lurker)

<><><><><><><><><><><><><><>

Richard Wagner

WildNaturePhotos, L.L.C.

www.WildNaturePhotos.com

Member ASMP | NANPA | PIA/GATF

<><><><><><><><><><><><><><>

____________________________________________________________________________

Date: Mon, 26 Sep 2005 07:57:28 -0700

From: David Cardinal

Subject: RE: RE: Andrew Rodney's test--consensus - My One Vote

Richard--One thing I've learned from running a site & forums for pro & serious amateur photographers is that there are few statements that apply to most of them.

In the case of color & workingspaces, they are all over the map. Many of the top Wedding & Event photographers shoot Raw & go straight to sRGB because they find it works most easily & quickly with their output workflow.

Obviously many use the two options you describe above (Raw->16-bit->AdobeRGB or ProPhoto), especially those in the high-end of the commercial or fine art fields, but many also never leave 8-bit because of size & speed issues (some shoot upwards of 1000 images/day covering sports/events/wildlife so it adds up). For the same reason, quite a few make a living shooting nothing other than JPEGs.

Personally I've found that my workflow has grown more splintered over the last couple years. I love the flexibility of shooting JPEG+Raw on the new Nikons and I love what I can do with Raw files, but there are a lot of projects where JPEG is quicker & works well. On working spaces, I'm one of those waffling. I tend to look at the particular image in ACR and decide whether I feel I need to use ProPhoto/16-bit to capture the colors I want or I can live with AdobeRGB/8-bit and keep the file smaller and faster.

--David Cardinal

http://www.nikondigital.org

____________________________________________________________________________

Date: Mon, 26 Sep 2005 08:51:54 -0700

From: J Walton

Subject: Re: RE: Andrew Rodney's test--consensus - My One Vote

I think we need to differentiate between scanning and editing.

To be fair, I believe Dan recommends scanning in 16-bit as well, if the scanner allows it. The question in front of us is not scanning, but *correcting* in 16-bit.

Don Hutcheson is certainly a respected expert in his field, which is why my company hired him as a consultant a few years ago. Although he did want us to use the working space he named after himself :-), he did not push 16-bit editing. I don't know if he's changed his tune since, but I rather doubt it.

8-bit editing in AdobeRGB is fine with me, if we're tallying votes or something.

I remember another color guy we hired mentioned something about making an RGB working space that is just big enough to contain SWOP, but not much bigger. I'd probably go with GRACOL, but it sounds like a good idea to me.

____________________________________________________________________________

Date: Mon, 26 Sep 2005 12:52:56 EDT

From: Dan Margulis

Subject: Re: RE: Andrew Rodney's test--consensus - My One Vote

J writes,

To be fair, I believe Dan recommends scanning in 16-bit as well, if

the scanner allows it. The question in front of us is not scanning,

but *correcting* in 16-bit.

Right. Scanning and correcting are two different animals.

Dan Margulis

____________________________________________________________________________

Date: Mon, 26 Sep 2005 13:57:54 EDT

From: Dan Margulis

Subject: Re: Andrew Rodney's test--consensus

Ric writes,

I'd really like to see it proven that ProPhotoRGB makes no sense (or

sense under only certain limited and predictable circumstances) so I

can ignore it and move on to more important things- like making

pictures.

This is exactly backwards.

Whoever is advocating adopting a workflow that has obvious disadvantages bears the burden of making a compelling case that there are advantages that outweigh them. I say you should sometimes work in LAB. It is inconvenient to do that, because you have to make two color mode shifts and work in a dangerous color environment. It is not up to anybody else to prove that you *shouldn't* work in LAB. It is up to me to prove that you *should*, by showing compelling examples of how its benefits outweigh its disadvantages. If anybody else doesn't like my examples, they can try to shoot them down.

Camera Raw has disadvantages, too. It takes a lot longer to open the image and the controls are crude. If anybody says that we should use Camera Raw rather than just a JPEG from the camera, it isn't up to you or me to prove that we shouldn't--it's up to that person to prove that we *should*, by compelling examples of how its benefits outweigh its disadvantages.

To the great detriment of the community at large, Andrew Rodney and his partners believe that this simple concept does not apply to them. They claim the right to dictate inconvenient workflows without any backup at all. They have explicitly said that they do not have to demonstrate the validity of their claims and that it is up to the rest of the world to prove them wrong--which the rest of the world has a history of doing.

And so, we got the claim that multiple adjustment layers give a better output result than multiple applications of simple commands. We got the claim that converting from RGB to LAB causes "catastrophic damage" to the file. We got the claim that editing in 16-bit creates a "night and day" "totally obvious to anyone who looks" difference and that anyone who doesn't do it is not a professional. We were advised that combed histograms produce inadequate reproduction.

In each case, we now know better, but meanwhile we've wasted a whole lot of everybody's time trying to prove negatives, which is notoriously difficult. Nobody can ever show that these claims of data loss are *never* valid unless they work on every type of image that could possibly be produced multiplied by every possible kind of edit. Yet people get taken in by these claims and as a result I've had to blow some 20 full pages in my last three books showing samples large enough to back up my own position, which is that AFAIK there's nothing to worry about.

It's not clear to me whether they are advocating ultra-wide gamut RGBs as exchange spaces or storage spaces. If the latter, no problem--they'll do as well as any other reasonable alternative. If, as I suspect, they are advocating actually doing major edits in them, this is a naive workflow that has been thoroughly discredited for more than a decade.

If you're faced with that claim, you should say, look. You guys have provided a lot of valuable services to the industry for which we all should be grateful. However, every time you've gotten involved with matters involving arithmetic or color theory or anything that looks to you like data loss, you have been proven wrong time and again. Plus, you're heavily tied in with various of the vendors who happen to benefit from your claims. So, if you have anything to back up these statements besides theoretical mumbo-jumbo that you've proven you don't understand, let's see it, and then we'll see whether we think it makes up for the obvious disadvantages of editing in so clumsy a space, let's see it.

But for God's sake, Ric, now that this 16-bit nightmare is almost over, don't even think about saying that somebody has to prove that editing in an ultra-wide RGB *isn't* useful. The burden is on the other side to prove that it *is.*

Dan Margulis

____________________________________________________________________________

Date: Mon, 26 Sep 2005 10:11:28 -0600

From: Ron Kelly

Subject: Re: RE: Andrew Rodney's test--consensus - My One Vote

On 26-Sep-05, at 8:57 AM, David Cardinal wrote:

For the same reason, quite a few make a living shooting nothing other

than JPEGs.

Yes, there are quite a few of us I suspect.

We believe that the advantages of shooting RAW do not stack up against the crushing disadvantages.

We believe that care taken at the time of image capture is time far better spent than time spent fixing/fiddling with everything downstream. Couldn't be bothered to set a good white balance when you're shooting? No problem, camera RAW will fix it. Couldn't be bothered to get a good exposure? No problem,. . . etc.

Shooting in RAW and editing in 16 bit are similar in that there is little or no advantage real-world advantage to doing so.

For some reason, quite a few are willing to accept any myth that software authors and equipment vendors are willing to foist on them, without testing to see if it makes any difference.

Ron Kelly

____________________________________________________________________________

Date: Mon, 26 Sep 2005 14:32:09 EDT

From: Dan Margulis

Subject: Re: RE: Andrew Rodney's test--consensus - My One Vote

David Cardinal writes,

One thing I've learned from running a site & forums for pro &

serious amateur photographers is that there are few statements that apply to

most of them.

Plus, these two groups constituted Photoshop *users*, the universe of which does not begin and end with serious photographers. Professional photographers constituted, as I said, only about a third of the group.

Nevertheless, a thousand Photoshop users is a fairly substantial sample, and it certainly shows that neither sRGB nor Adobe RGB is going away in the foreseeable future.

Dan Margulis

____________________________________________________________________________

Date: Mon, 26 Sep 2005 14:11:08 -0400

From: Denton Taylor

Subject: Re: My One Vote

Hi Ron:

I completely agree with you about getting the image right in the first place, and that applies whether you are using RAW, JPEG, or film. (years of shooting color chromes taught me that!) But assuming one does this, I see nothing but disadvantages in shooting jpegs, particularly given the lossy compression vs. non-lossy in RAW. I don't want algorithms messing with my image and tossing out data. Unless you are converting the jpegs to tiff or PSD to edit, then back to jpeg. And if you do that, you may as well go RAW=>TIFF.

I don't even use the RAW capabilities in PShop, I use the camera mfgr's RAW software to view the images and send the ones I like to Pshop in TIFF format, where I can do my work.

Because I try and get it right the first time, I try and do as little photoshop work as possible, which is probably why I am not an expert. A little levels, maybe a black or white point set, maybe minor curves, a bit of cropping and sharpening. If I spend more than five minutes on an image, it generally means I didn't get it right the first time.

That's actually why I'm getting a big kick out of Dan's LAB book; the ability to do a lot in a little time.

Denton

____________________________________________________________________________

Date: Mon, 26 Sep 2005 11:38:28 -0700

From: "Mike Russell"

Subject: Re: RE: Andrew Rodney's test--consensus - My One Vote

From: "Ron Kelly"

....

For some reason, quite a few are willing to accept any myth that

software authors and equipment vendors are willing to foist on them,

without testing to see if it makes any difference.

Absolutely. These are interesting times, and many of the workflow ideas that are accepted as common wisdom are destined to simply vanish.

Not too long ago, on Adobe's ACR forum, I read a post from a studio photographer who batch converts 1800 raw images to tiff each and every day. It took hours. His question was not about the validity of this workflow (which AFAIK takes no advantage of raw edit capabilities), but whether he should buy a second G5, or upgrade his existing system to dual processor.

I like to say you can't see the woods for all the naked emperors. One of said emperors has literally sold us all a bridge :-)

Mike Russell

www.curvemeister.com

____________________________________________________________________________

Date: Mon, 26 Sep 2005 13:32:09 -0600

From: Ron Kelly

Subject: Re: My One Vote

It *would* seem to be a bad idea to toss out data.

However, as I'm sure you and everyone else on this list is aware, there are levels of jpeg compression. I am of course referring to the highest quality (least compression).

The point is simply this: why keep bigger files than necessary? In the top quality jpeg I can find no loss of image quality. Try it for yourself, if you haven't already.

Let's put it another way: if you're so concerned about quality, why don't you get a better lens, camera, scanner etc.? These things *will* have an effect on image quality.

My guess is that real world results are the determining factor for only some. Time and again when referring to an indistinguishable differences (ie one that therefore is nil) people will say something like "I'm keeping my date intact because someday when the Smithsonian want to access my files the extra data will be relevant." Meanwhile, they get to carry around an extra 10 pounds of lead in their shorts.

Ron Kelly

____________________________________________________________________________

Date: Mon, 26 Sep 2005 12:58:37 -0600

From: Andrew Rodney

Subject: Re: RE: Andrew Rodney's test--consensus - My One Vote

On 9/26/05 12:38 PM, "Mike Russell" wrote:

Not too long ago, on Adobe's ACR forum, I read a post from a studio

photographer who batch converts 1800 raw images to tiff each and every day.

It took hours.

The actual processing or hours for the photographers sitting in front of the computer? There is a difference. From the standpoint of the user, I could process 1800 similar images in a few minutes and let the computer process all the RAWs over night. In the batch, I could add EXIF data, sharpen, rename, resize etc without touching the computer. So I think we need to define processing.

With Bridge and Adobe Camera RAW, you can crank through RAW processing and in some respects, do this far faster than opening individual JPEGs and applying corrections. And I could be working in Photoshop all while ACR and Bridge do the work.

The tools are there, we just need to define what needs to be down and some of the better ways to conduct the work. Computers are supposed to do routine, multiple tasks for us and they can. Of course, there are all kinds of imaging tasks that only a human can produce.

Andrew Rodney

http://www.digitaldog.net/

____________________________________________________________________________

Date: Mon, 26 Sep 2005 14:58:23 -0600

From: Ron Kelly

Subject: Re: RE: Andrew Rodney's test--consensus - My One Vote

If all these 1800 images are similar?

That sounds like they were shot at the same time in the same conditions. If they aren't, then the potential advantages of processing them automatically are lost. You'd have to sit there overnight along with your computer, making choices.

If they were shot in similar conditions, then it would have been better to capture them more carefully. Many professional cameras have auto white balance which works very well, and when it doesn't there are usually other options that need to be selected at the time of the photography. A simple test shot can help you here.

So, if you're getting chased by a grizzly bear, then auto white balance is likely to work well in that environment even if you can't take time to think about it. On the other hand, if you are shooting in an area that is lit by flourescent lights, you're not likely to be eaten by grizzlies and you should be able to take a little more care with the white balance. Time spent at image capture can save you tons of downstream effort.

Automated RAW workflows seem to me to be akin to the eject button on the DVD player.

You don't get the supposed benefit that RAW promises, because you're automating the batching. And if you are determined to try for every ounce on every image, you have to sit there and fiddle each and every time because if you don't, you'll quite likely get a result that may be worse than using auto-white balance and jpegs.

Ron Kelly

____________________________________________________________________________

Date: Tue, 27 Sep 2005 10:26:43 +1000

From: Dean Wilmot

Subject: Re: User practices--RGB definitions

Hi Guys,

Ive been reading all your responses, with interest, the last few days.

As a photographer (fairly new to high end digital systems- 22MP multishot backs) I must say I am still abit daunted about what colour space I should be viewing images in.

I have calibrated my Apple 20" cinema display (first version) using the Gretag Macbeth Eye One Photo screen calibration unit...I thought this would get me in the ballpark...and let my pre-press retoucher tweak the final Master files.

However since reading all this info I wonder if I should be using the profile this Eye one unit has generated or use the Photoshop built in color setting of Adobe RGB (1998) or ProPhoto....since all my RAW hi res files come in off my digi camera systems as 16 bit RAW RGB TIFF files.

The difference between both profiles is Huge.

Please forgive my ignorance but can someone point me in the right direction.???

Another point of note is that recently Most of the biggest magazine publishers and Advertising agencies in Australia are demanding that photographers ONLY supply RAW RGB files, as there have been some photographers who profess to supply pre-press ready CMYK files, but in truth they are not set-up properly and thus these clients want to do everything themselves.

These same Advertising agencies and Publishers are also implementing a new consortium Proofing system (very expensive) called 3DAP...its Australia specific...to combat any "color CMYK cowboys" so the point of the sword of responsibility lies with the photographer.

Any thoughts??

Alot of clients don't trust photographers as they are not color Guru's (such as you guys) with extensive pre-press knowledge of CMYK (although there are some photogs who are realising the scope of knowledge now required), would you suggest that supplying clients (often ignorant to current technology) RGB files and let them do the CMYK conversions?

Or take the bull by the horns and supply CMYK and a proof for ALL shoots that are going to be supplied to a client as digital files?

Thanks for your feedback.

From my own point of view I wish I could afford to bring Dan Margulis to Australia (ive looked in to it) to educate the Entire Australian photographic world, but currently the local market has to find some depth in their pockets.

Kind Regards

Dean Wilmot

Sydney, Australia

____________________________________________________________________________

Date: Mon, 26 Sep 2005 15:29:27 -0600

From: Andrew Rodney

Subject: Re: RE: Andrew Rodney's test--consensus - My One Vote

On 9/26/05 2:58 PM, "Ron Kelly" wrote:

That sounds like they were shot at the same time in the same

conditions. If they aren't, then the potential advantages of

processing them automatically are lost. You'd have to sit there

overnight along with your computer, making choices.

Absolutely. However, even if all the images are dissimilar, you can still in many cases apply a similar camera RAW correction and produce quite acceptable color appearance. Just as you can ask the in-camera processing to do this and toss the RAW files. It all depends on how much adjusting you need to do on an image by image basis from the RAWs. Plus the new Auto settings in ACR, especially when tweaked by the user (calibrate tab) can produce pretty good looking images. I1m assuming that the multiple scenes are well exposed. The issue then becomes the white balance. If the camera embeds a decent white balance with EXIF data and it1s something ACR can read, better yet.

Many professional cameras have

auto white balance which works very well, and when it doesn't there

are usually other options that need to be selected at the time of the

photography.

Right and hopefully that1s not encrypted and kept from ACR. It can still apply it1s own 3auto2 (as shot) white balance or you can override this. So it1s kind of like having the benefits of in camera processing but you can tweak, go back to the RAW and end up with high bit or 8-bit files and not necessarily in JPEG.

In camera processing is what it is, we hope it1s good. That1s all up to the manufacturer. But you1re stuck with what you get. You can apply the same rules to RAW and with a converter like ACR, you have a lot of options.

Automated RAW workflows seem to me to be akin to the eject button on

the DVD player.

Why would the auto adjustment on a RAW converter be worse than in camera processing? At least you can go back and redo it if you like. With in-camera processing, you1re stick with a certain rendering based on the white balance and you1re stuck with an 8-bit JPEG. In the converter, you can adjust anything you wish; only exposure plays a role. Seems to be infinitely more flexible. And with ACR, you have very good highlight recovery which isn1t available with the in camera processing. You can turn off sharpening, you can convert into a number of color spaces and you can pick the resolution. Go back to the RAWs and alter all of those anytime you wish. Like high bit editing, it1s all about flexibility and headroom. That isn1t to say there are not those who can benefit from a JPEG workflow. It is still faster no question. But it1s highly inflexible with no safety net.

The beauty of making multiple ACR corrections is these are simple text files. The RAW data is never touched. So you can select 400 images in Bridge and pick one saved setting. The thumbnails update and the EXIF data that will define the ultimate corrections are all there but no processing. Then pick 300 other images and select another setting. When you1ve roughed this all out, you can apply all corrections and batch process while you are watching Desperate Housewife1s and the computer does all the work. You don1t even have to open Photoshop (or any of those 700 files). They are all processed into a folder you wish.

Be cool if you could select the same images from JPEG in Bridge and apply corrections this way; you can1t. That1s what1s so cool about RAW. You pick the rendering edits, see the effects but you1re never touching, at least at this point the full rez data. You1re never touching the RAW so if you do something dumb, the original data is all there to work with. It can be a fast process but it1s certainly a very safe and flexible process.

Andrew Rodney

____________________________________________________________________________

Date: Mon, 26 Sep 2005 18:56:07 -0600

From: Andrew Rodney

Subject: Re: User practices--RGB definitions

On 9/26/05 6:26 PM, "Dean Wilmot" wrote:

However since reading all this info I wonder if I should be using the

profile this Eye one unit has generated or use the Photoshop built in color

setting of Adobe RGB (1998) or ProPhoto....since all my RAW hi res files

come in off my digi camera systems as 16 bit RAW RGB TIFF files.

The two are totally separate and do different things. The display profile defines how your display behaves. Photoshop uses it to produce it1s previews of all files in all color spaces (RGB, CMYK, you name it). Just leave it alone (well, update you calibration and build a new profile once a month or so).

The working space profile defines the color space of the image. That information AND your display profile are both used to show you the file. So, you could have a file in sRGB, ProPhotoRGB, U.S. Web Coated (SWOP) v2 all open at the same time and each window is being previewed using the display profile and the embedded profile within each document.

Another point of note is that recently Most of the biggest magazine

publishers and Advertising agencies in Australia are demanding that

photographers ONLY supply RAW RGB files, as there have been some

photographers who profess to supply pre-press ready CMYK files, but in truth

they are not set-up properly and thus these clients want to do everything

themselves.

Boy, I1m not comfortable giving clients a RAW file. It1s like giving them your negs. I will say if they have you over a barrel, I1d convert to the .DNG format. For one, you can embed all kinds of useful metadata like your copyright and other stuff. You can apply a default rendering for Adobe applications like Bridge or Camera RAW so at least you could provide the RAW file with a 3look2 you like. Otherwise, it1s a digital neg so to speak. Otherwise, you can1t embed any information into a RAW file (its read-only). The .DNG file allows you to write some data into that format.

Or take the bull by the horns and supply CMYK and a proof for ALL shoots

that are going to be supplied to a client as digital files?

Possible as long as you1re proofing the work correctly. Sending a nice RGB file to your ink jet isn1t based on any CMYK reality. So it1s useless. IF you have a profile for the CMYK process, you CAN produce a very close color match to an ink jet. The key is that CMYK description that is used to make your printer (say an Epson) simulate another print process. Useful!

From my own point of view I wish I could afford to bring Dan Margulis to

Australia (ive looked in to it) to educate the Entire Australian

photographic world, but currently the local market has to find some depth in

their pockets.

Well I'll be there speaking in December (in my favorite city; Sydney).

Andrew Rodney

http://www.digitaldog.net/

____________________________________________________________________________

Date: Mon, 26 Sep 2005 20:59:21 -0400

From: "Gene Palmiter"

Subject: Re: User practices--RGB definitions

Can I take a stab at some of this? It's sort of learning by teaching. I may get it all wrong and by doing so will raise more questions and clear up some points I don't have down yet. Like previsualisation with film a lot depends on final use. Can we assume that with that set-up you are shooting for glossy magazines? A step back from that is your pre-press retoucher...he will need, in the best of all worlds, a profile for the printer that is to be used. Assuming its an off-set press then all he really needs is a color space that will be just enough to provide what the printer can print. I would suppose that a bit bigger color space is better than a bit smaller...and almost any color space is bigger than an offset press can handle. My guess would be AdobeRGB as its pretty standard and will do the job. If you have to repurpose then your RAW files still have all the information they ever had.

How an image looks to you is unimportant as you have no say in how it will look printed...that's up to the retoucher. So...don't make your job any harder than it has to be...send them what they want and take their checks. This will all change when you want to show some of your work in a gallery and have to retouch it and print it yourself. But, right now you have experts (supposedly) doing the part we are discussing so they should be the ones reading all this.

(I work differently as I am the photog, retoucher, photoeditor, and paginator for a small mag. Still only get one check though...darn it!)

____________________________________________________________________________

Date: Mon, 26 Sep 2005 18:46:58 -0700

From: David Cardinal

Subject: RE: RE: Andrew Rodney's test--consensus - My One Vote

Why would the auto adjustment on a RAW converter be worse

than in camera processing?

At least in the case of high-end Nikon D-SLRs, there is at least one structural reason:

The camera has the advantage of an external WB sensor which is not accessible to any current third party software (I'm not even sure whether it is recorded in the image or merely an input to the camera's algorithm and discarded)

As smarter CMOS cameras evolve additional WB sensing technology will be incorporated, which might make this issue even more apparent.

This isn't an argument against Raw or ACR, just a comment on one reason why the camera does have some "advantages" in the current system.

--David Cardinal

____________________________________________________________________________

Date: Mon, 26 Sep 2005 18:38:14 -0700

From:David Cardinal

Subject: RE: User practices--RGB definitions

Otherwise, you can1t embed any information into a RAW file

(its read-only).

Well, not entirely. Several different programs including ours (DigitalPro for Windows) will caption Raw files with IPTC meta-data since they are often mildly modified TIFF formats. There is some thin ice involved because the formats are not documented, but it is a very popular capability for many photographers who archive their raw files and use them as their image catalog.

Adobe (probably wisely given their position in the market) chooses not to caption the Raw files because they are not documented.

Perhaps more upsetting to those who think that by getting a Raw file they have some assurance of "truth", it isn't all that hard to synthetically generate a Raw image (we do this for testing) or to modify a raw image. We don't ship those capabilities since they don't have many valid uses, but I'm sure we'll read of raw file spoofs and hacks before too long.

--David Cardinal

Pro Shooters LLC

http://www.nikondigital.org

http://www.proshooters.com

____________________________________________________________________________

Date: Mon, 26 Sep 2005 20:19:54 -0600

From: Andrew Rodney

Subject: Re: User practices--RGB definitions

Yes, I stand corrected. I should have been more clear by saying that Adobe doesn1t modify files it can1t directly write to. This is based more on a philosophical rather than a technological reason. Once you create a .DNG file, they are fine modifying the metadata.

Andrew

____________________________________________________________________________

Date: Mon, 26 Sep 2005 20:49:51 -0700

From: Alain Briot

Subject: Re: Digest Number 1556

Dan,

And so, we got the claim that multiple adjustment layers give a better output

result than multiple applications of simple commands. We got the claim that

converting from RGB to LAB causes "catastrophic damage" to the file. We got the

claim that editing in 16-bit creates a "night and day" "totally obvious to

anyone who looks" difference and that anyone who doesn't do it is not a

professional. We were advised that combed histograms produce

inadequate reproduction.

It's interesting to note that I've never heard this statement, or anything close to it, from a fine art photography printer. I myself follow the exact workflow you seem to despise: multiple layers. I read all your books but there comes a time when global adjustments just stop working and when local adjustments are necessary. If you disagree, I am willing to send you one of my files, complete with local adjustment layers, and you can prove me wrong by doing it all with your approach. Personally, I can't. What better evidence is there that your system is the better approach?

Alain Briot

Beaux Arts Photography

http://www.beautiful-landscape.com

800-949-7983 or 623-561-1641

____________________________________________________________________________

Date: Tue, 27 Sep 2005 13:20:54 EDT

From: Dan Margulis

Subject: Re: Adjustment Layers

Alain writes,

It's interesting to note that I've never heard this statement, or

anything close to it, from a fine art photography printer.

Nor have I, only from professional "experts" with close ties to various vendors.

I myself follow the exact workflow you seem to despise: multiple layers.

At some point I will understand, although I do not as yet, how a book that is so obviously full of adjustment layers, layer blending options, and layer masks provokes people into saying that I am against the use of layers.

Be that as it may, reading your "multiple layers" to mean "multiple adjustment layers", because my statement referred only to them, then if you, like me, use multiple adjustment layers because you think that you may need the flexibility to be able to edit them at a later time, it is not a despicable but a commendable practice.

If you, however, do *not* require such future flexibility, and are going to the trouble of saving the extra layers solely because you have read that flattening a file containing multiple adjustment layers provides better data than a file in which the adjustments were applied consecutively without layers, then I do not despise this either, but permit me to advise that the two resulting files would in fact be identical, not varying from one another by so much as a single pixel.

I do not despise people who misunderstand certain aspects of Photoshop, as I am but a poor sinner in that respect myself, and I do not despise authors who occasionally dispense advice that is later proven to be incorrect, as I have been guilty of that also. I look down my nose at, but do not despise, the practice of dispensing incorrect advice in print when the correctness of the advice can easily be proven or disproven but the person giving it is too lazy to do so.

I *do* despise the practice, however, of calling nonexpert users fools, unprofessionals, or other unpleasant names based on concepts that the namecaller has been too lazy to test for himself, particularly if it turns out that the namecaller is wrong.

I read all your books but there comes a time when global adjustments

just stop working and when local adjustments are necessary.

There does indeed, which is why I spend so many pages in my latest book discussing selection technique. I do, however, adhere to the view that as one's skill increases the amount of local selection that is needed decreases, and respectfully suggest the following guidelines:

1) When starting work on an image, it should be immediately apparent whether local corrections seem likely to be necessary. Discovering midway through the process that one needs to correct locally is a mark of bad technique.

2) All the local corrections in the world will not make a competitive image out of one whose global values are inadequate.

3) The objective is to improve the image, not to frighten it to death by one's knowledge of Photoshop technique.

Dan Margulis

____________________________________________________________________________

Date: Tue, 27 Sep 2005 14:13:04 -0600

From: Chris Murphy

Subject: Re: Response to Andrew Rodney's test

On Sep 23, 2005, at 10:54 AM, Dan Margulis wrote:

The following two statements comprise a single full paragraph. I separate them for effect.

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.

This two statements present seemingly conflicting facts:

You state a correlation between gamut size and the increasing difficulty of maintaining neutrality. That is, larger gamut space means it will be more difficult to maintain neutrality. You've previously said ProPhoto RGB is an ultra-wide gamut space.

Yet you then say this maintaining neutrality problem does not occur at all in LAB. How do you explain this in lieu of the fact that encoded LAB defines a gamut that is larger than the ultra-wide gamut ProPhoto RGB?

Either the neutrality problem relates to gamut, or it relates to something else. You seem to imply, simultaneously that it does and does not depend on gamut. If it depends on gamut it would be at least as much a problem in LAB as in ProPhoto RGB.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

____________________________________________________________________________

Date: Tue, 27 Sep 2005 13:47:56 -0600

From: Chris Murphy

Subject: Re: Andrew Rodney's test--consensus

On Sep 26, 2005, at 11:57 AM, Dan Margulis wrote:

But for God's sake, Ric, now that this 16-bit nightmare is almost over,

don't even think about saying that somebody has to prove that editing in an

ultra-wide RGB *isn't* useful. The burden is on the other side to prove that it *is.*

In the context of a photographer using Adobe Camera RAW, there are advantages to editing in a wide gamut RGB space. I consider it like walking on a balance beam at 15 feet above the ground. Will you die if you fall? Unlikely. Will you get hurt? Maybe. The better you get at walking the beam the less likely you will fall. So it's going to take some getting use to, in order to make lighter, less aggressive edits than in another space. Perhaps in a few days?

Camera RAW uses an internal linear gamma color space with ProPhoto RGB primaries. Thus all edits done in Camera RAW are by definition performed in a wide gamut space. Even if you select sRGB within Camera RAW, *all* edits are performed in 1.0 gamma ProPhoto and then converted to sRGB after the edits are applied, and some of the most useful and basic features of Camera RAW easily constitute "major edits", but to my knowledge there is no agreed upon definition or metric for what is or is not a major edit. The implicit workflow here is to do any necessary major edits in Camera RAW, and have far fewer edits to do in Photoshop proper once the RAW file is processed.

Clearly it's not inherently dangerous to edit in wide gamut spaces or there'd be many hundreds of thousands of totally screwed up images as a result of such a workflow that you say:

If, as I suspect, they are advocating actually doing major edits in

them, this is a naive workflow that has been thoroughly discredited

for more than a decade.

I agree that the burden of proof must be placed on those who make a claim, and those who claim that editing in wide gamut RGB spaces has merit should present a compelling case demonstrating the usefulness of a technique. The use of a wide gamut RGB space for editing is a technique. But likewise someone who makes a statement as you have, that it's a naive and discredited workflow, has set himself up for an substantial burden to cite or demonstrate such a grand, thesis-level statement. You say it despite the large number of Camera RAW users doing exactly what you describe has been discredited, as though it is or ought to be common knowledge.

Now it's possible I've extracted this quote out of context, but it was in a short paragraph with no other qualifiers related to major edits in a wide gamut RGB space. Perhaps the qualifiers are found in other email postings? The output of wide gamut images has various problems depending on the output device (and profiling technology) used, but the context wasn't output. So this statement is quite a revelation.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

____________________________________________________________________________

Date: Tue, 27 Sep 2005 18:45:26 EDT

From: Dan Margulis

Subject: Re: Response to Andrew Rodney's test

Chris Murphy writes,

You state a correlation between gamut size and the increasing

difficulty of maintaining neutrality. That is, larger gamut space

means it will be more difficult to maintain neutrality.

Yes, it does, *within the same color model*. An imaginary CMYK that has the same approximate gamut as ProPhoto RGB nevertheless controls neutrality much more effectively, because the presence of a permanently neutral channel, the black, acts as an anchor. This imaginary CMYK, however, is harder to control than ordinary CMYK. Adobe RGB is slightly harder to control than sRGB but much easier than ProPhoto RGB.

Yet you then say this maintaining neutrality problem does not occur

at all in LAB. How do you explain this in lieu of the fact that

encoded LAB defines a gamut that is larger than the ultra-wide gamut

ProPhoto RGB?

The problem occurs in LAB as it does in any colorspace, but LAB controls neutrality more effectively than either CMYK or RGB because color is treated independently of contrast, so you can flatten the color reproduction curve near the center, a move that has no analog in other colorspaces.

Dan Margulis

____________________________________________________________________________

Date: Tue, 27 Sep 2005 17:54:03 -0700

From: "Mike Russell"

Subject: Re: Response to Andrew Rodney's test

From: "Chris Murphy"

...

Yet you then say this maintaining neutrality problem does not occur

at all in LAB. How do you explain this in lieu of the fact that

encoded LAB defines a gamut that is larger than the ultra-wide gamut

ProPhoto RGB?

ProPhoto's primaries define a larger gamut than Lab. This is not subtle, and may be demonstrated by creating any white to pure red, green, or blue gradient in ProPhotoRGB, and viewing color values in Lab mode.

You'll see the a or b channel hit the wall well before the gradient reaches 100 percent saturation. The same is true for pure cyan, magenta, and yellow.

Labmeter also shows this. As you adjust the bright end of the "Click to set L" adjustment layer, you'll see various areas, notably blue and yellow, where ProPhoto RGB extends outside of Lab.

http: //www.curvemeister.com/downloads/LabMeter/CurvemeisterLabMeter.zip

Either the neutrality problem relates to gamut, or it relates to

something else. You seem to imply, simultaneously that it does and

does not depend on gamut. If it depends on gamut it would be at least

as much a problem in LAB as in ProPhoto RGB.

Although neither color space is that suitable for fine color adjustments, Lab is actually a more finely grained gamut than ProPhoto RGB.

Mike Russell

www.curvemeister.com

____________________________________________________________________________

Date: Tue, 27 Sep 2005 20:19:15 -0600

From: Andrew Rodney

Subject: Re: Response to Andrew Rodney's test

On 9/27/05 6:54 PM, "Mike Russell" wrote:

ProPhoto's primaries define a larger gamut than Lab.

The blue primary yes, the others no.

Although neither color space is that suitable for fine color adjustments,

Lab is actually a more finely grained gamut than ProPhoto RGB.

I1m not so sure. Maybe. But if you1re working with a RAW file, going from ProPhoto to LAB doesn1t appear to be a great idea just to confine the blue primary inside human gamut. There are a lot of colors outside ProPhoto RGB in Lab. It1s not an apples to apples comparison. The overall shape of each is quite different. Lots of colors within ProPhoto RGB are in a smaller gamut compared to LAB.

Andrew Rodney

____________________________________________________________________________

Date: Wed, 28 Sep 2005 13:10:57 EDT

From: Dan Margulis

Subject: Re: Andrew Rodney's test--consensus

Chris Murphy writes,

Camera RAW uses an internal linear gamma color space with ProPhoto

RGB primaries. Thus all edits done in Camera RAW are by definition

performed in a wide gamut space.

By your definition, not mine. To me, it's roughly like declaring that when you assign a profile to an RGB file you have edited it in LAB.

The implicit workflow here is to do any necessary major edits in Camera

RAW, and have far fewer edits to do in Photoshop proper once the RAW file is

processed.

Right. As I understand Andrew's position, in a logical workflow one would tend not to make major edits in ProPhoto once the file hits Photoshop proper, because it would have been done in Camera Raw.

Clearly it's not inherently dangerous to edit in wide gamut spaces or

there'd be many hundreds of thousands of totally screwed up images

There are many hundreds of thousands of totally screwed up images that got that way without the benefit of ultra-wide gamut RGB.

Photoshop 2.5 is capable of creating outstanding images even though it doesn't allow layers. Outstanding images can also result from large edits to ProPhoto RGB files. Neither approach is sensible if a rational alternative is available.

Dan Margulis

____________________________________________________________________________

Date: Wed, 28 Sep 2005 12:35:46 -0600

From: Andrew Rodney

Subject: Re: Andrew Rodney's test--consensus

On 9/28/05 11:10 AM, "Dan Margulis" wrote:

Right. As I understand Andrew's position, in a logical workflow one would

tend not to make major edits in ProPhoto once the file hits Photoshop proper,

because it would have been done in Camera Raw.

In 8-bit, probably not based on the files I provided. In high bit, not an issue. From a 3logical2 workflow, you1d do the major global corrections in Camera RAW because it1s faster, you have some benefits of working with a linear encoded gamma in high bit and you can do a lot of this in a batch.

I find that working in Camera RAW to do the 3big edits2 a bit like doing the corrections at the scan stage. It1s fast because you1re basically working on a proxy and you can apply all the edits and convert the RAW data while you1re sleeping. You don1t have to open every 13 mega-pixel file to apply tone and color corrections.

I still don1t know why you feel that doing such edits at 3the scan stage2 versus in Photoshop (the toolset being basically equal) is different.

Andrew Rodney

____________________________________________________________________________

Date: Wed, 28 Sep 2005 13:45:38 -0700

From: "Mike Russell"

Subject: Re: Response to Andrew Rodney's test

From: "Andrew Rodney"

The blue primary yes, the others no.

All three of ProPhoto's primaries substantially exceed Photoshop's Lab encoding range of -128 to 127 in either the a or b channel. Green is out of range for both the a and b channels.

I1m not so sure. Maybe. But if you1re working with a RAW file, going from

ProPhoto to LAB doesn1t appear to be a great idea just to confine the blue

primary inside human gamut. There are a lot of colors outside ProPhoto RGB

in Lab. It1s not an apples to apples comparison. The overall shape of each

is quite different.

Lab will always have areas that no RGB space can represent, but that does not mean it has a larger gamut, or even that it is coarser grained than every RGB space. I think my point stands. ProPhoto, has a substantially larger gamut than Photoshop's implementation of Lab.

Lots of colors within ProPhoto RGB are in a smaller gamut compared to LAB.

Interesting. I've spot checked a few and not found this to be the case. Which colors would these be?

---

Mike Russell

www.curvemeister.com

____________________________________________________________________________

Date: Wed, 28 Sep 2005 15:29:00 -0600

From: Andrew Rodney

Subject: Re: Response to Andrew Rodney's test

On 9/28/05 2:45 PM, "Mike Russell" wrote:

All three of ProPhoto's primaries substantially exceed Photoshop's Lab

encoding range of -128 to 127 in either the a or b channel. Green is out of

range for both the a and b channels.

Yes, the primaries are but due to it1s shape, there appear to be lots of colors that fall within a smaller gamut, at least from what I1m seeing in ColorThink. More of that round peg in square hole mismatch in shape.

Lab will always have areas that no RGB space can represent

That1s what I1m saying above.

ProPhoto, has a substantially

larger gamut than Photoshop's implementation of Lab.

Is there something unique about Lab as far as Photoshop1s implementation?

Andrew Rodney

____________________________________________________________________________

Date: Thu, 29 Sep 2005 09:33:55 +1200

From: Nick T

Subject: RGB Working spaces

Hello List

On Sep 26, 2005, at 8:00 PM, Richard Wagner wrote:

Boy, it's been tough to sit back and even follow this thread... Most

pro photographer colleagues of mine shoot with high-end cameras in

RAW, process in 16-bit into ProPhoto or Adobe RGB depending on the

primary intended use (AdobeRGB for stock sales/agency work and

ProPhoto for fine art printing), and convert to sRGB for web use.

Most of us are also comfortable converting to/working in CMYK. As

for the results of the polls from Dan's workshops, I'd be interested

to know how long those attendees have been shooting digitally,

because they sound like a very inexperienced and uneducated group.

I highly doubt that you would get comparable answers from, say, the

Nikon D1scussion listserve membership or a poll on Rob Galbraith's

forums.

Richard that has not been my experience.

I run a user group for 300 users of Imacon (now Hasselblad) digital backs , and I think it fair to say that they are a fairly sophisticated bunch; all full time professionals, and many supplying CMYK. My poll is a very small sample (only 80 have replied so far) but I would expect the results to be borne out by the remaining 220.

I certainly don't think it would be in any way correct to label them "a very inexperienced and uneducated group".

The question was "What RGB working space do you use?"

The results:

Adobe RGB 1998

Users: 50 (80%)

srgb

Users: 1 (1%)

Colourmatch RGB

Users: 5 (8%)

ProPhotoRGB

Users: 4 (6%)

Other

Users: 2 (3%)

It is worth noting that two of the Prophotorgb users actually stated that they use AdobeRGB for commercial work and Prophotorgb only for fineart inkjet.

Regards

Nick Tresidder

Nick Tresidder Photography

http://www.nick-t.com

____________________________________________________________________________

Date: Thu, 29 Sep 2005 00:03:42 -0700

From: Richard Wagner

Subject: re: RGB Working spaces

Nick,

I think that you (and perhaps David Cardinal) misunderstood my response. On Sat, 24 Sep 2005 10:32:35 EDT Dan Margolis wrote, in describing his survey:

The question was: What is your customary RGB workspace, as defined in your

Color Settings dialog?

Answers Vegas, 3/05

Don't Know, or Don't Understand the Question: 18%

I would find it astonishing that nearly 20% of a group of pro photographers would not know what working space they used. I would not consider them to be very experienced in digital file manipulation. I am not at all surprised that 80% of photographers using Imacon digital backs use AdobeRGB as their working space. What percentage of them work in 8-bit? I would bet very few...

Photographers generally optimize their workflow for their intended output. Other than fine-art printing, most photographic output today does not benefit from a wide-gamut color space. But that is very different from the claims on this list by some that there are *no* advantages to wide-gamut color spaces, and that the people who use them are fools. Some photographers derive benefit from shooting JPEG rather than RAW, 6 MP rather than 20, and sRGB rather than AdobeRGB. It all depends on what you ultimately need to do with your images and the conditions you shoot under. As some photographers who once used Nikon's lossy "compressed NEF" format discovered, though, once data is thrown out you're outta luck if you later decide that you need it. Likewise, if you archive your images in AdobeRGB and later try to output to a device with a larger or non-overlapping gamut, you're stuck with AdobeRGB, and you cannot take advantage of the full gamut of the output device. This is why I've gone back to re-scan slides into ProPhotoRGB - without question, I often get much better prints on my Epson 9600 than I did with the image in Adobe RGB. Otherwise, I wouldn't waste the time it takes to rescan. A significant portion of the gamut of a Velvia scan exceeds the gamut of AdobeRGB (i.e., is out-of-gamut). Why clip or compress this, when it may fall within the gamut of your output device? You can see it visually here, in a page I made over a year ago:

http://www.wildnaturephotos.com/WNP/Html/GamutFS.html

The situation is even worse for digital capture, which has a wider gamut than film. (I know, technically digital capture has no gamut...)

--Rich Wagner

____________________________________________________________________________

Date: Thu, 29 Sep 2005 11:02:52 +0100

From: "Bob Frost"

Subject: Re: Response to Andrew Rodney's test

Mike,

Gingerly dipping a toe into this murky world of real and non-real colors, isn't your phrase "Photoshop's implementation of Lab' the crux of this argument? Lab has real colors and non-colors that are outside Photoshop's cut-down version of Lab.

So isn't it correct to say that ProPhotoRGB is contained within Lab, but not within Photoshop's 'reduced Lab'?

Bob Frost.

____________________________________________________________________________

Date: Thu, 29 Sep 2005 04:07:44 -0700

From: "Mike Russell"

Subject: Re: Response to Andrew Rodney's test

From: "Bob Frost"

Gingerly dipping a toe into this murky world of real and non-real colors,

isn't your phrase "Photoshop's implementation of Lab' the crux of this

argument? Lab has real colors and non-colors that are outside Photoshop's

cut-down version of Lab.

Yes, and in sacrificing some gamut, the Lab values become more closely spaced.

So isn't it correct to say that ProPhotoRGB is contained within Lab, but not

within Photoshop's 'reduced Lab'?

I think that's accurate, but as a practical matter Photoshop's tiny Lab space is what we have to work with.

In that truncated color space, Lab lavishes data values on its color space. This is largesse compared to the diet of thin gruel that ProPhoto RGB grudgingly gives the same colors .

I believe this has been demonstrated several ways: the spacing of the primaries, the gradient experiment, and the fact that ProPhoto RGB often requires 16 bits for a given operation, when Lab does not. If anyone is not convinced, I'm all ears.

Here's an effect I have not been able to explain. If you convert a ProPhoto white to pure blue gradient to Lab, there is a significant dark band in the darker areas of ProPhoto. This does not happen in green, where significantly more clipping occurs, or red, which is about as bad as blue. Can anyone explain this?

Mike Russell

www.curvemeister.com

____________________________________________________________________________

Date: Thu, 29 Sep 2005 07:54:43 EDT

From: Dan Margulis

Subject: Re: Re: Response to Andrew Rodney's test

Dennis writes,

One of my favorite techniques for editing color and tonality is to use 2 Curves

adjustment layers, one set to "color" blending and the other set to

"luminosity". I am curious if this gives me a decent approximation of the ability

you mention below even though I am editing in an RGB color space.

This is a highly sophisticated workflow that in many cases surpasses what LAB has to offer and in many cases doesn't. In this particular case (nearly gray object that varies a lot in darkness, and which already shows a certain amount of color variation), LAB is better.

Even if you are on a color layer in RGB, the object falls in a relatively long range in the curve. All three curves need to interrelate; if the blue is correct but you change the green, you may have to readjust the blue. And, if you adjust the green, you likely will also change the color of trees, which are of the same darkness as the gray areas.

In LAB, these problems don't exist. The grayish areas occupy a tiny area of the A and B curves, isolated from the green. Plus, the channels are independent. If you get the A right, you don't have to worry about it any more. Nothing you can do to the B will change it, as would be the case in RGB.

Nevertheless, it's still a powerful workflow.

Dan Margulis

____________________________________________________________________________

Date: Fri, 30 Sep 2005 09:29:12 +1200

From: Nick T

Subject: Re: re: RGB Working spaces

On Sep 29, 2005, at 7:03 PM, Richard Wagner wrote:

I would find it astonishing that nearly 20% of a group of pro

photographers would not know what working space they used. I would

not consider them to be very experienced in digital file

manipulation.

Hi Richard

That sample was of Photoshop users not just Photographers:

Here's what Dan wrote on the 27th of September:

Plus, these two groups constituted Photoshop *users*, the universe of which

does not begin and end with serious photographers. Professional photographers

constituted, as I said, only about a third of the group.

Regards

Nick-T

Nick Tresidder Photography

http://www.nick-t.com

____________________________________________________________________________

Date: Thu, 29 Sep 2005 15:58:31 -0700

From: Steve Upton

Subject: Re: Response to Andrew Rodney's test

Lab does have "real" colors outside of the -128->127 a/b limitations in the Lab that Photoshop uses.

This is NOT an inherent Photoshop limitation, however, but one imposed by the ICC in their choice of the Lab coordinates for the profile connection space (PCS). The fact that Adobe chose to follow the same "space" as the ICC makes sense.

Yes, and in sacrificing some gamut, the Lab values become more closely

spaced.

this doesn't make sense to me. The fact that the Lab in Photoshop is constrained makes the values closer together? Or are you talking about a working space here?

So isn't it correct to say that ProPhotoRGB is contained within Lab, but

not within Photoshop's 'reduced Lab'?

I think that's accurate,

yes and no. The primaries are convertible to Lab values but they are not perceivable colors so it doesn't really matter.

but as a practical matter Photoshop's tiny Lab

space is what we have to work with.

true, but what is so tiny about Photoshop's Lab? It contains almost all the colors the eye can see and certainly contains all the colors that can be produced on a metameric system. (more below)

In that truncated color space, Lab lavishes data values on its color space.

in terms of 8 bit Lab, there is more resolution available, yes. The Lab values are not placed any closer together though.

This is largesse compared to the diet of thin gruel that ProPhoto RGB

grudgingly gives the same colors .

only in terms of 8 bit. in 16 bit there is plenty of tonal resolution available.

I believe this has been demonstrated several ways: the spacing of the

primaries, the gradient experiment, and the fact that ProPhoto RGB often

requires 16 bits for a given operation, when Lab does not. If anyone is not

convinced, I'm all ears.

there are a number of different reasons why the above may occur. I am in agreement that ProPhoto cannot typically contain gradients - all the way out to the most saturated real colors - in 8 bit. How those gradients are going to be reproduced is another huge issue but it's true.

Here's an effect I have not been able to explain. If you convert a ProPhoto

white to pure blue gradient to Lab, there is a significant dark band in the

darker areas of ProPhoto. This does not happen in green, where

significantly more clipping occurs, or red, which is about as bad as blue.

Can anyone explain this?

here's the danger with synthetic color tests. If we think of primaries and gradients in terms of sRGB then 255 blue, for instance, is a saturated but real and perceivable blue. A gradient from there to white is not likely to occur in nature in any way (which is one reason why I'm not a big fan of this type of synthetic gradient) but they are all real colors and can be gamut mapped and printed.

A gradient from 255 blue in ProPhoto, however starts in the imaginary, and on it's way to white moves into the real.

I guess the best question to ask is what color should an imaginary blue map to? And how valid a test is a gradient that is partially outside our vision? Is it reasonable that the range of numbers that are not real colors doesn't necessarily fit into a normal gradient? I would think so.

ProPhoto, has a substantially

larger gamut than Photoshop's implementation of Lab.

This merits more discussion. First I wonder about the term substantially. It is a bit bigger but not much in terms of the gamut of human perception. So while the primaries are "out there", WE'RE not out there. They are only out there so that the triangle is large enough to contain real colors that we want.

There is a calculated gamut that shows the most saturated colors that a metameric system can create - that being a system of 3 or more colorants that are mixed to produce a range of colors, reflective or emissive. I'm afraid I can't show this gamut to you right now but rest assured that it fits entirely inside the 0->100, -128->127, -128->127 range of Lab that the ICC and Adobe use for Lab.

So, for all practical considerations - as in imagery that we might want to capture or create and then display and/or print - the Lab in Photoshop is fine. The rest is interesting color science but outside the range of image reproduction.

Also, if Photoshop allowed for a larger Lab, it would mean nothing to the rest of our workflow as the ICC PCS would truncate it to the lower range anyway. Photoshop is not the place to look for answers.

does this make sense?

Regards,

Steve

________________________________________________________________________

o Steve Upton CHROMiX www.chromix.com

o (hueman) 866.CHROMiX

o ColorGear ColorThink ColorValet ColorSmarts ProfileCentral

____________________________________________________________________________

Date: Thu, 29 Sep 2005 22:08:54 -0700

From: "Mike Russell"

Subject: Re: Response to Andrew Rodney's test

Steve,

You bring up some interesting questions, but the topic seems to have lost most of the original participants. I would suggest that you start a thread in the sci.engr.color newsgroup, or if you wish I'll be happy to respond offline.

BTW - the PCS is not subject to clipping.

Mike Russell

www.curvemeister.com

____________________________________________________________________________

Date: Fri, 30 Sep 2005 10:34:56 +0100

From: "Bob Frost"

Subject: Re: Response to Andrew Rodney's test

Mike,

Why not continue discussing it here? It is the "Colortheory" group, is it not (although ColorPractice might have been a better choice of title for Dan to use). Just change the title to widegamut spaces.

Bob Frost.

____________________________________________________________________________

Date: Fri, 30 Sep 2005 03:07:30 -0700

From: "Mike Russell"

Subject: Re: Response to Andrew Rodney's test

Hi Bob,

It is an interesting topic, and your questions are good ones. I'm hitting a busy patch right now, so perhaps others will join in.

Mike Russell

www.curvemeister.com

____________________________________________________________________________

Date: Fri, 30 Sep 2005 12:18:55 EDT

From: Dan Margulis

Subject: Re: Response to Andrew Rodney's test

Bob Frost writes,

Why not continue discussing it here? It is the "Colortheory" group, is it not (although ColorPractice might have been a better choice of title for Dan

to use).

You have brought up the point of the name of the list previously, and Stephen Marsh replied that it is called the *APPLIED* Color Theory list. Over the last two or three years, the conventional wisdom has changed rather greatly as "experts" have discovered that how color theory is applied and how it might work in a vacuum are very different things.

This particular thread discussed characteristics of LAB vs. ProPhoto RGB, a wide-gamut RGB space. It was noted that both contain many colors that either can't be reproduced or don't exist at all, yet can be defined. These are certainly topics of concern to us as they have important ramifications for color correction. It then turned to the question of exactly which of the definition-only colors that don't in fact exist may theoretically appear in one colorspace and not the other. That question has no relevance to practical image manipulation, so Mike was right to suggest taking it to another group that concerns itself with color science.

This month has already broken the list's previous record for the number of messages, which I do not consider a good thing. I'd rather stay tightly focused, with a more manageable number of posts. OTOH, unlike past months with high message volumes where there has been a lot of off-topic stuff and posturing, it doesn't seem to me that any of it has been so lengthy or so off-topic that we needed to step in and stop it. The sort of self-policing exemplified by Mike is most welcome. (That's also why I haven't posted anything further on 16-bit, waiting for volume to die down.) I trust we will also see some self-policing on the User practices-RGB definitions thread, which seems to have run its course and has become more of a woulda-shoulda-coulda thread, not to mention overly personal.

For the next week, I'm off and the list will largely be handled by Darren, Andrew, and Stephen.

Dan Margulis

____________________________________________________________________________

Date: Fri, 30 Sep 2005 18:35:36 +0100

From: "Bob Frost"

Subject: Re: Response to Andrew Rodney's test

Dan,

You have brought up the point of the name of the list previously, and Stephen

Marsh replied that it is called the *APPLIED* Color Theory list.

Your memory is very good. But it isn't actually called the 'AppliedColorTheory' list according to Yahoo or the messages that I get. It is called 'ColorTheory'. So that, to my mind, entitles us to talk about theoretical spaces, theoretical advantages of highbit working, etc, etc.. If you really do want to confine it to Applied topics, why not change the name. Other lists change their names to update themselves every now and again.

This particular thread discussed characteristics of LAB vs. ProPhoto RGB, a

wide-gamut RGB space. It was noted that both contain many colors that either

can't be reproduced or don't exist at all, yet can be defined. These are

certainly topics of concern to us as they have important ramifications for color

correction.

But what I was suggesting is that there might be more than one 'Lab'. As far as I can see, there is 'theoretical' LAB and 'practical' LAB, and I thought, perhaps misguidedly, that this might have accounted for some of the discrepancies between the arguments in previous posts. OK, 'practical' LAB is what we have to work with in PS/CS, as Mike pointed out, but the more I read of the ICC specification of the PCS, the more variable it all seems to become.

I'm not trying to be awkward; I read this list to try and find out more about the finer nuances of the theory behind what we do in PS/CS, not what one has to do to print on a printing press. There are loads of lists that talk about the practical aspects of color management; I thought this was the only one (or nearly) that discussed the current theory behind all these recipes for color processing that we find in book after book after book.

That question has no relevance to practical image

manipulation, so Mike was right to suggest taking it to another group that concerns

itself with color science.

What is the difference then between a group on 'color theory' and a group on 'color science'?

Bob Frost.

____________________________________________________________________________

Date: Fri, 30 Sep 2005 12:00:55 -0600

From: Andrew Rodney

Subject: Re: Response to Andrew Rodney's test

On 9/30/05 11:35 AM, "Bob Frost" wrote:

What is the difference then between a group on 'color theory' and a group on

'color science'?

A color science list would spend more time discussing how many ICC profiles can dance on the head of a pin and lots of math would be involved.

A color theory, especially an applied color theory list in my mind should discuss LAB, various flavors of LAB and so forth (as we1re doing now).

I don1t know why there needs to be some limit on the number of posts per day as long as they don1t go OT or get nasty. Is there a bandwidth issue? It1s quite easy to unsubscribe, filter emails and so forth so I personally would love to hear others discuss this topic (like most, I1ve still got LOTS to learn on the subject).

Andrew Rodney

http://www.digitaldog.net/

____________________________________________________________________________

Date: Fri, 30 Sep 2005 12:04:32 -0600

From: Chris Murphy

Subject: Re: Response to Andrew Rodney's test

On Sep 28, 2005, at 2:45 PM, Mike Russell wrote:

All three of ProPhoto's primaries substantially exceed Photoshop's Lab

encoding range of -128 to 127 in either the a or b channel. Green is out of

range for both the a and b channels.

Apparently ColorThink displays either ProPhoto or LAB incorrectly as it shows ProPhoto as fitting entirely within LAB. Converting the XYZ values in ProPhoto to LAB yield bogus values (at least for 8-bit integer encoding), for all three primaries. Interestingly enough, Apple's 3D gamut viewer built into the ColorSync Utility appears to do this correctly. I'd characterize the red primary as being slightly outside of LAB, and green and blue as being substantially outside of LAB. I would not characterize ProPhoto RGB in its entirely as being substantially larger than LAB, or vice versa, rather the gamut shape is considerably different. Visually, if this plot is to be trusted, the gamut volume favors LAB by quite a bit.

Lab will always have areas that no RGB space can represent, but that does

not mean it has a larger gamut, or even that it is coarser grained than

every RGB space.

Well, not really. RGB spaces use XYZ as the PCS, not LAB. XYZ and LAB are different. You can think of LAB as being a subset of XYZ, based on how they get encoded. There isn't a direct or overlapping relationship between the two spaces. So I think you could conceivably define an RGB space with a volume larger than encoded LAB.

I think my point stands. ProPhoto, has a substantially

larger gamut than Photoshop's implementation of Lab.

I'd like to know what metric you are using to come to this conclusion.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

____________________________________________________________________________

Date: Fri, 30 Sep 2005 14:26:49 -0600

From: Chris Murphy

Subject: Re: Andrew Rodney's test--consensus

On Sep 28, 2005, at 11:10 AM, Dan Margulis wrote:

By your definition, not mine. To me, it's roughly like declaring that when

you assign a profile to an RGB file you have edited it in LAB.

It's not my definition, but by definition of how the application was designed and works. It's a fact, not an opinion. All of the edits that can be applied are performed after demosaicing, on data that's in a linear ProPhoto RGB space. Your analogy totally doesn't work.

There are many hundreds of thousands of totally screwed up images that got

that way without the benefit of ultra-wide gamut RGB.

Photoshop 2.5 is capable of creating outstanding images even though it

doesn't allow layers. Outstanding images can also result from large edits to

ProPhoto RGB files. Neither approach is sensible if a rational alternative is

available.

I say "cars get people from point A to B safely all the time, they aren't inherently dangerous" and you response with "people get hurt by cars all the time, cars 40 years ago were capable of hurting or not hurting people." You haven't said anything relevant at all, and have actually totally skirted the issue at hand.

You've implied, but not directly stated, that editing in wide gamut RGB spaces is inherently dangerous and has been completely rejected the better part of a decade ago. I say such a statement has to date been unsupported. Clearly it's not inherently dangerous or there would be hundreds of thousands of totally screwed up images *traceable* to the fact they were edited in a wide gamut RGB space.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

____________________________________________________________________________

Date: Sat, 1 Oct 2005 09:07:07 EDT

From: Dan Margulis

Subject: Re: Andrew Rodney's test--consensus

Chris Murphy writes,

It's not my definition, but by definition of how the application was designed and works. It's a fact, not an opinion.

That it looks like a duck, walks like a duck, and quacks like a duck is fact. That it is actually a moose is your opinion.

If you wish to see why it's not a moose, perform the following simple test:

1) With a copy of the image, go into preferences and change the internal computation space of Camera Raw from ProPhoto to LAB or some rational RGB.

2) Call up the channel by channel curves and apply edits to your taste.

3) Return the preference to Prophoto and duplicate the test as best you can with the original image. Then, if it's truly an editing program, you should be able to see the difference.

I would do the test for you, but I am having a little trouble finding where commands 1 and 2 are located in Camera Raw, and I'm going to be off for a week starting now.

You've implied, but not directly stated, that editing in wide gamut

RGB spaces is inherently dangerous and has been completely rejected

the better part of a decade ago.

It's no more dangerous than LAB, but unlike LAB, it has no advantages. What I stated directly is that it is a naive approach, a solution in search of a problem, that was completely rejected *more* than a decade ago, because it was found that its Kodak proponents' histograms and promises of greatly increased color gamuts by 1997 for which existing RGBs wouldn't be good enough, did not quite make up for saddling the world with such a clumsy editing space. Also, the Kodak promise of the magic profile that would convert wildly out of gamut colors accurately into any output condition never quite was fulfilled.

Dan Margulis

____________________________________________________________________________

Date: Sat, 01 Oct 2005 08:19:20 -0600

From: Andrew Rodney

Subject: Re: Andrew Rodney's test--consensus

On 10/1/05 7:07 AM, "Dan Margulis" wrote:

1) With a copy of the image, go into preferences and change the internal

computation space of Camera Raw from ProPhoto to LAB or some rational RGB.

Not possible! You can change the encoding from ProPhoto to three other RGB

working spaces. You cannot change the internal processing. As Chris and I

both pointed out, all internal process is done in 1.0 gamma encoded ProPhoto

RGB.

I would do the test for you, but I am having a little trouble finding where

commands 1 and 2 are located in Camera Raw, and I'm going to be off for a week

starting now.

There are no such commands.

Andrew Rodney

____________________________________________________________________________

Date: Sat, 01 Oct 2005 14:59:18 -0000

From: "dmargulisnj"

Subject: Re: Andrew Rodney's test--consensus

Andrew Rodney writes,

There are no such commands.

I am shocked--shocked!!! to find that GAMBLING is going on here!

Dan Margulis

____________________________________________________________________________

Date: Sat, 1 Oct 2005 12:50:35 -0400

From: Terry Wyse

Subject: Re: Andrew Rodney's test--consensus

On Oct 1, 2005, at 9:07 AM, Dan Margulis wrote:

1) With a copy of the image, go into preferences and change the internal

computation space of Camera Raw from ProPhoto to LAB or some rational RGB.

How/where can you do this? Never mind changing the internal space, you can't even change the external/rendering space to LAB as far as I know.

Terry

____________________________________________________________________________

Date: Sat, 1 Oct 2005 10:43:03 -0700

From: Lee Varis

Subject: Re: Andrew Rodney's test--consensus

Hi all,

I was getting a bit tired of this thread but it seems like some things need to be clarified here regarding camera raw:

Chris Murphy writes:

All of the edits

that can be applied are performed after demosaicing, on data that's

in a linear ProPhoto RGB space.

I see no reason to suspect that this is not true - it makes perfect sense. The camera chip captures high-bit luminance data through red, green and blue "filters". That data could (and often does) have a higher scene referenced (real world) dynamic range than can normally be encoded in any RGB workspace. A linear gamma ProPhoto RGB colorspace would ensure that you have enough room to perform color edits and transforms to arrive at the best idealized color data for the standard gamma encoded colorspaces in Photoshop proper.

Dan writes:

That it looks like a duck, walks like a duck, and quacks like a duck is fact.

That it is actually a moose is your opinion.

and

1) With a copy of the image, go into preferences and change the internal

computation space of Camera Raw from ProPhoto to LAB or some rational RGB.

2) Call up the channel by channel curves and apply edits to your taste.

3) Return the preference to Prophoto and duplicate the test as best you can

with the original image. Then, if it's truly an editing program, you should be

able to see the difference.

Sorry Dan, while this is kind of humorous, its not particularly relevant. First, regarding steps 1 & 2 this is not possible in Camera Raw. Second, When you select different color spaces in Camera Raw you are only determining what colorspace you are transforming the raw data into not what colorspace you are conducting calculations in. You can think of Camera Raw more like a scanner that is capturing an image and opening it into Photoshop in the workspace of your choice.

You do have some powerful control over color but the original data transforms occur in a kind of black-box operation involving interpolation between 2 color temperature extremes and de-mosaicing algorithms, sort of rocket science kind of stuff. In practice the main color controls in ACR (Adobe Camera Raw) behave in a similar manner to LAB moves - color temp changes occur along a blue-yellow axis using a slider. Fine tuning uses a "tint" slider which adjusts along a magenta-green axis. There are crude luminance controls in exposure (white point) brightness (levels) and contrast sliders. There is now a very nice luminance "curve" control as well as more fine tuning slider controls that adjust RGB hue and saturation kind of like the Hue/Saturation adjustment in PS.

The fact that all of this operates in a high dynamic range, wide gamma, high-bit colorspace is besides the point and does not pertain to the question of whether one should stay in a wide gamma, hi-bit colorspace for further editing in Photoshop. That's like saying that you should edit your files in wide gamma 16 bit because your scanner scans in 16 bit. AFAIK, no one questions the validity of scanning in 16 bit to arrive at a good 8 bit file.

(Andrew, the following is a rhetorical question and does not require your standard response)

Once you are in a gamma encoded standard colorspace the question becomes: Is there any advantage, beyond bragging rights, to staying in a colorspace that lavishes bits on colors that are not visible on your monitor or printable on any output space? Does holding on to invisible colors while you are editing help you achieve better control over printable colors especially if you can't see them, or evaluate them during edits? The exact methods that Camera Raw uses in its internal color transforms really have no bearing on this question.

regards,

Lee Varis

http://www.varis.com

888-964-0024

____________________________________________________________________________

Date: Sat, 01 Oct 2005 17:06:10 -0600

From: Andrew Rodney

Subject: Re: Andrew Rodney's test--consensus

On 10/1/05 11:43 AM, "Lee Varis" wrote:

(Andrew, the following is a rhetorical question and does not require

your standard response)

I'll try a non standard response since you seem to be missing a key point:

Once you are in a gamma encoded standard colorspace the question

becomes: Is there any advantage, beyond bragging rights, to staying

in a colorspace that lavishes bits on colors that are not visible on

your monitor or printable on any output space?

The colors ARE printable, that1s the entire point. At least with ACR, I1ve demonstrated for anyone that wants to look at the gamut plots of actual image and working space in ColorThink that there ARE colors contained in ProPhoto RGB I can output to my 2400 that are lost in Adobe RGB (1998). This isn1t theory, it1s fact.

Does holding on to

invisible colors while you are editing help you achieve better

control over printable colors especially if you can't see them, or

evaluate them during edits?

I don1t need to seem them on screen. I can, do and want to use them on the output device. Again, examine the gamut plots. In a very simple and not exotic image lacking what most would consider a very saturated scene, there are colors I can output to my $800 ink jet but ONLY if I use ProPhoto from RAW.

Andrew Rodney

____________________________________________________________________________

Date: Sat, 01 Oct 2005 18:12:18 -0700

From: Marco Ugolini

Subject: Re: Re: Andrew Rodney's test--consensus

In a message dated Sat, 01 Oct 2005 14:59:18, Dan Margulis wrote:

I am shocked--shocked!!! to find that GAMBLING is going on here!

Then it might very well be the beginning of a beautiful friendship...

--------------

Marco Ugolini

Mill Valley, CA

____________________________________________________________________________

Date: Sat, 1 Oct 2005 22:48:01 -0500

From: "Maris V. Lidaka Sr."

Subject: Re: Re: Andrew Rodney's test--consensus

Time for a Google search for the casino nearest to Mill Valley, CA <g>

Maris

____________________________________________________________________________

Date: Sun, 2 Oct 2005 00:37:14 -0700

From: "Mike Russell"

Subject: Re: Re: Andrew Rodney's test--consensus

LOL. Someone give the man his winnings!

Mike Russell

www.curvemeister.com

____________________________________________________________________________

Date: Sun, 2 Oct 2005 06:15:41 -0700

From: Richard Wagner

Subject: Re: Andrew Rodney's test--consensus

Lee Varis wrote:

I was getting a bit tired of this thread but it seems like some

things need to be clarified here regarding camera raw:

Lee, you are absolutely correct, and you did an outstanding job of summarizing the functionality of ACR.

Once you are in a gamma encoded standard colorspace the question

becomes: Is there any advantage, beyond bragging rights, to staying

in a colorspace that lavishes bits on colors that are not visible on

your monitor or printable on any output space?

Perhaps not, but there *are* colors in ProPhoto that are outside the gamut of AdobeRGB (1998) and sRGB that *are* within the gamut of some current output devices. Does one want to throw those colors out, or not? In addition, there are a lot of colors present within the gamut of scanned films like Fuji Velvia that are out of gamut in AdobeRGB and sRGB that are in gamut in ProPhoto **as well as many current output devices.** Are these colors important to you, or not? If they are, therein lies one very good justification for using a wide-gamut colorspace like ProPhotoRGB. Unlike the internal computational module of ACR, this is not rocket science.

If someone doesn't believe this, the data is right here, with thanks to Steve Upton for making the comparisons so easy using ColorThink.

http://www.wildnaturephotos.com/Public/Gamut.html

--Rich Wagner

____________________________________________________________________________

Date: Sun, 2 Oct 2005 13:19:30 -0700

From: Lee Varis

Subject: Re: Andrew Rodney's test--consensus

Warning - long post ahead!

On Oct 1, 2005, at 4:06 PM, Andrew Rodney wrote:

I'll try a non standard response since you seem to be missing a key point:

He then proceeds to offer his standard response:

The colors ARE printable, that’s the entire point.

I will try, one last time to explain the point I'm trying to make which is not the point that Andrew keeps responding to. On Sept 4th I wrote:

For the most part we should be more concerned with color

relationships and tonal compression...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...- humans respond much more to contrast than

color. Color contrast is more important than color gamut or hue...

making a point here about the relative importance of color vs tone (lightness/darkness) Tone is something we can see and make decisions about in almost any color space but it becomes hard to see accurately in wide gamut color spaces because color clipping (on the display) distorts the rendering of lightness and darkness in the more compressed color space. Because we can't see the tonal shape in colors that are outside the gamut of our display we have to guess- this is what I mean by saying that wide gamut colorspaces do...

nothing to make it easier to work within the constraints of

fairly small output spaces.

To which Andrew responds:

I need all the colors to DECIDE what to compress. If you throw them away

from the start, I can't do that.

This thread started in the context of processing from digital camera raw files - since I never advocated throwing away the raw data I'm not sure what he's talking about here but apparently Andrew can make decisions about colors he can't see (some sort of faith in intelligent design) because he also says:

I don’t need to seem them on screen.

pretty sure he means "see" them on screen...

I offered a creative use of the individual grayscale channels in ProPhoto RGB as a way of controlling the rendering of out-of-gamut colors into a more compressed color space. I'm merely advocating that you arrive at that colorspace earlier rather than later so you have the opportunity to exercise some control over the rendering of your colors. The point here is that if you follow the "wide gamut until the bitter end workflow" you won't know what happens to the color until you make the print. If the color "relationships" don't work out the way you guessed they would you have to make some kind of blind edit and try again.

Andrew has faith that the out-of gamut colors that "are not printable" on the output device will "not" affect the rendering of the colors that "are printable" during the gamut re-mapping that occurs in the profile conversion. I have seen too many instances of tonal compression in saturated colors (especially greens) in Adobe RGB going to an Epson printer to have the same kind of faith. I'm certainly wary of ProPhoto RGB if there's any chance that any colors may be out-of-gamut for the output device. Colorthink gamut maps don't tell you which parts of an image are out-of gamut and by how much - you have to guess. This is a kind of gambling that I'm not good at.

Apparently, Andrew's decision making process revolves around whether to use perceptual rendering or relative colorimetric - both things are hard-wired into the profile and offer no user intervention beyond the basic choice. Thats fine, I just require more.

This kind of decision making is comfortable for photographers - a group that I must admit I'm also a member of. In the good old days of film we shot what we got from Kodak or Fuji and handed it off to the lab- what you got was what you got. You never had any opportunity to see colors until it was too late to do anything about it. Once you had your film that was it unless you re-shot it. Your only control was over exposure or a crude color filter- all of you creative decisions were made before you pressed the shutter release. Photographers do develop an ability to pre-visualize the result but generally exercise very little control "during" the process.

Over the years of development of photography most photographers developed a reverence for the rendered image. It was way better than a painting at capturing a realistic image. Somehow the photo of a thing carried a kind of truth that was sacrosanct. We don't dare challenge (or change) it. This is an accepted attitude that finds its way into news photography where no one is allowed to modify the image in Photoshop (beyond traditional darkroom controls). Many photographers like Ansel Adams went to herculean efforts to exercise control over the rendering of the image but nobody had the kind of control available to the average photographer today. I think that many photographers have yet to learn the extent of that control and remain content with a system that approximates what they learned from the past.

The fantasy that the colors "contained" in ProPhoto RGB are somehow truthful to the original scene leads one to treat these colors as if it was of the utmost importance to preserve them at all costs. We struggle to somehow get a one-to-one mapping between these scene referenced colors into a print referenced context with scientific accuracy. It has been my observation that the more successful you are in maintaining this accuracy the more likely you are going to get a boring image. Of course there are exceptions, brilliant exceptions, where the struggle pays off. We can guess at the situations where this is likely to be true. Most of the times the exact hue/saturation rendering of a specific color in an image is less important that the emotional impact that color and tonal "relationships" within the image have. I find it impossible to judge color/tone relationships that are not at least close to visible and I prefer to make these decisions before I get to a finished print as I have to pay for all my ink and paper.

I guess it all depends on your comfort level with things unseen. Over the years Photographers have learned to be comfortable with the latent image. I am not so comfortable nowdays but I don't have the benefit of faith that Andrew has. Please forgive me. If you are going to have faith in wide gamut RGB colorspaces you should do all editing in 16 bits because you never know whether some move you make might generate some unseen artifact that might find its way into a more constrained printspace! This has been demonstrated very effectively in Andrews examples.

I am working on providing some visual examples to help illustrate the concepts outlined above but you'll have to wait a little while longer.

regards,

Lee Varis

http://www.varis.com

888-964-0024

____________________________________________________________________________

Date: Sun, 02 Oct 2005 17:26:51 -0600

From: Andrew Rodney

Subject: Re: Andrew Rodney's test--consensus

Lee, there are all kinds of colors in CMYK (as well as about any output color space) that you can't see, that fall way outside sRGB (the gamut of about 99.5% of every display in the world). Lab too. So this isn't a compelling argument.

Andrew Rodney

____________________________________________________________________________

Date: Sun, 02 Oct 2005 17:40:06 -0600

From: Andrew Rodney

Subject: Re: Andrew Rodney's test--consensus

On 10/2/05 2:19 PM, "Lee Varis" wrote:

The fantasy that the colors "contained" in ProPhoto RGB are somehow

truthful to the original scene leads one to treat these colors as if

it was of the utmost importance to preserve them at all costs.

ProPhoto RGB is output referred by it's very nature and design (as is very working space) and not scene referred. I've never implied nor should you assume I'm saying that ProPhoto RGB or any such rendering and encoding is Colorimetrically correct (which IS ugly and not what most users want). In no way is ProPhoto or for that matter any color space that doesn't look quite ugly truthful to the scene (I don't even know what truthful means but I do know and can define what colorimetric color means).

We struggle to somehow get a one-to-one mapping between these scene

referenced colors into a print referenced context with scientific

accuracy.

We struggle to render the image in our mind into output referred color. Your idea of what that should look like is probably quite different from mine just as with the same color neg, we are unlikely to produce the same color appearance on print in a darkroom.

I find it impossible to judge color/tone relationships

that are not at least close to visible and I prefer to make these

decisions before I get to a finished print as I have to pay for all

my ink and paper.

The reference media of your display and your print are not the same.

If you are going

to have faith in wide gamut RGB colorspaces you should do all editing

in 16 bits because you never know whether some move you make might

generate some unseen artifact that might find its way into a more

constrained printspace!

We are in total agreement here and this has always been my original point (this discussion of wide gamut spaces like ProPhoto RGB started due to the my point about editing in high bit, something that a few here have said isn't necessary nor can be proven in a real world image).

Andrew Rodney

____________________________________________________________________________

Date: Sun, 2 Oct 2005 16:42:52 -0700

From: "Mike Russell"

Subject: Re: Andrew Rodney's test--consensus

Well said, Lee.

I would add that, with all the talk of wide gamuts, the importance of touching terra firma once in a while, in the form of actual image examples that use these colors, is as rare as it is important. I look forward to your examples.

Consensus in any interesting topic, by definition, is not possible, but cordiality is. Iit is possible to clearly state a position, as you have done, and be content that those individuals who are ready for it will pick up on it.

Mike Russell

www.curvemeister.com

____________________________________________________________________________

Date: Sun, 2 Oct 2005 22:46:46 -0600

From: Ron Kelly

Subject: Re: Andrew Rodney's test--consensus

In following this thread I'm wondering if these statements are true:

1. If you clip colors because your editing space is too small that could be bad and you could lose detail that would be difficult or impossible to regain by further manipulation so you should use a wide enough editing space to retain detail;

2. If the gamut of the picture you're working with is smaller than a wide editing space then a smaller editing space is better, which is "tighter" to the gamut of the subject;

3. Same as number 2, except that the gamut of the picture *is* clipped but the lost colours are unimportant to the picture and so you are better off editing in a smaller space even if you've lost some detail which is insignificant.

Ron Kelly

____________________________________________________________________________

Date: Mon, 03 Oct 2005 01:56:35 -0700

From: Marco Ugolini

Subject: Re: Andrew Rodney's test--consensus

The problem of working with images some of whose colors one cannot see -- but are still being affected by one's edits in ways that are not directly verifiable on-the-fly -- is one which we have all experienced and banged our heads against on more than one occasion.

I agree with Lee that it is definitely a *real* problem to work with colors that one cannot see on one's display, and that it becomes a matter of disorienting guesswork to figure out what happens to them as a consequence of an edit, all the more so in a wide-gamut colorspace.

Hence I understand that many photographers would feel safer working in AdobeRGB using, say, a profiled NEC SpectraView LCD monitor, which is able to display most -- or perhaps even all -- of the colors in the AdobeRGB space. There is comfort in knowing that what one is seeing bears close resemblance to what one is to expect.

I also perfectly understand, and respect, Andrew's justified concern with preserving all the colors present in an image, specially a particularly important one that one hopes to be able to produce more effectively using technologies that have not yet been developed, but may be in a near future. We should not dismiss this as empty "perfectionism": there is nothing wrong with "perfectionism" that is used capably and with a conscious vision.

This can be transformed into an obsession, though, just as rapidly. When I printed my personal B&W in the darkroom many years back, I did not spend tons of time going around around trying *all possible combinations* of paper, developer, enlarger, lens, filters, and god knows what other countless variables. To make my life as simple as one must make it if anything at all is eventually to get made within one's lifetime, I made a choice of enlarger, paper and developer relatively early on, and stuck with it for a long time. And, as an artist, I also remained happy with the results for a long time.

As a recent Ansel Adams retrospective made amply clear, printing is very subjective even for the same person at different times in one's life: a print that Adams created with certain results early on in his life he made again with visibly different results years later (a few such examples were on view). Adams kept experimenting, but my point is that even if one sticks to one particular combination, the results change over time because one's sensibility itself, along with technical prowess, change and evolve even if nothing else does.

I wish to make very clear that I am *not* advocating that the master of an important image is better preserved in a narrower-gamut RGB space. What I *am* saying is that real-world limitations such as *monitors that cannot display colors that we can print* make many people understandably uncomfortable, and unwilling to risk wasting time and money on tedious and often confusing print tests, whereas a smaller color space may prove more "user-friendly," and still give them results that have the desired artistic integrity, although they may be scientifically short of a perfect ideal.

I will never need to go back to a traditional darkroom, and I sincerely love the boundless control afforded in today's digital darkroom. But I also know from personal experience that it's easy to lose oneself in the pursuit of things that only a few years back never caused us to lose much sleep, even as artists. But, to make it all more confusing, it's also true that the newer technologies can be, and indeed are being, used as artistic tools by those who wish to do so, opening new vistas that did not exist in earlier times.

I hope not to be misunderstood and seen as taking sides. I'm not. If anything, mine is a call to consider the ramifications of both the "AdobeRGB solution" and the "wide-gamut solution": each offers advantages and presents shortcomings, so that which is suitable for one's particular needs is a choice still to made on an individual basis, the way one used to choose whether to shoot Ektachrome, or Velvia, or Cibachrome. Some of us shoot catalogs, for which gamut and fidelity may be the foremost values, while others create very personal art, for which the rules are often there to be broken. Obviously, one size does *not* fit all.

--------------

Marco Ugolini

Mill Valley, CA

____________________________________________________________________________

Date: Mon, 03 Oct 2005 09:09:49 -0600

From: Andrew Rodney

Subject: Re: Andrew Rodney's test--consensus

On 10/2/05 10:46 PM, "Ron Kelly" wrote:

1. If you clip colors because your editing space is too small that

could be bad and you could lose detail that would be difficult or

impossible to regain by further manipulation so you should use a wide

enough editing space to retain detail;

Yes. And this is especially true for detail in dark areas of an image, not just super saturated colors you might be able to reproduce.

Bruce Fraser as usual, elegantly summed it up here (the last paragraph is key):

-----------------------

Bruce Fraser - 12:02pm Jun 3, 05 PST (#11 of 46)

If you look at RGB matrix spaces (i.e., those defined by a white point,

primaries, and gamma-defined tone curves) in a 3D lab plot like those

offered by the ColorSync utility or Steve Upton's indispensable ColorThink,

you'll see that they all reach their maximum saturation at a fairly high

luminance level. The gamut narrows dramatically at lower luminances,

tapering to a point at black.

Print spaces plotted the same way have a different shape, where maximum

saturation is achieved at lower luminance levels. (In an RGB space, you make

more saturation by adding light, on a printer you make more saturation by

adding ink, so this makes sense.)

So an RGB matrix space that has a wide enough gamut at lower luminances to

hold the printer gamut has to have extremely wide primaries that may not

represent anything that's physically possible. Obviously, that leads to the

space containing non-realizable colors. It's the trade-off you make when you

want to create an RGB matrix space that contains all the realizable colors

from your printer, and that's why ProPhoto is so large.

Then there's the question of clipping. It's not at all hard to capture

colors that are outside Adobe RGB. Many of the dark greens and yellows that

are prevalent in nature are outside Adobe RGB, and if you convert to Adobe

RGB, or a smaller space, gradations of those colors get clipped to solid

blobs. There's already been at least one such problem image posted on this

forum. So the advantage of ProPhoto isn't about retaining all those

out-of-gamut colors per se, it's about maintaining the distinctions between

them, so that you can map them into printable space as gradations rather

than blobs.

http: //www.adobeforums.com/cgi-bin/webx?128@521.6gG0eygTNGy.52@.3bbabc37

---------------

2. If the gamut of the picture you're working with is smaller than a

wide editing space then a smaller editing space is better, which is

"tighter" to the gamut of the subject;

I'd say yes to that.

Andrew Rodney

____________________________________________________________________________

Date: Mon, 3 Oct 2005 12:48:33 -0600

From: Ron Kelly

Subject: Re: Andrew Rodney's test--consensus

Could you elaborate a bit more? Why is it better to have an edit space that is big enough, but not any bigger than necessary?

Ron Kelly

____________________________________________________________________________

Date: Mon, 3 Oct 2005 12:15:52 -0600

From: Chris Murphy

Subject: Re: Andrew Rodney's test--consensus

On Oct 1, 2005, at 11:43 AM, Lee Varis wrote:

The fact that all of this operates in a high dynamic range, wide

gamma, high-bit colorspace is besides the point and does not pertain

to the question of whether one should stay in a wide gamma, hi-bit

colorspace for further editing in Photoshop.

Yes to everything in this post except one item in the above paragraph with respect to high dynamic range. ProPhoto RGB has a considerable gamut, but it isn't a high dynamic range space. Minimum we need 16bpc *floating point* for that, although at least in Photoshop and elsewhere the trend appears to be toward 32bpc floating point for HDR support.

This has the potential to get confusing rather quickly, as we can have values blacker than black and whiter than white, and color values outside of the primaries, of a color space. The ICC also has no support for HDR at the present time either, so there are some workarounds for the moment. (If you save out an HDR image with Adobe RGB (1998) as the profile for example, what's embedded are just the primaries. The image gamma goes to 1.0 in any case.)

Anyway, HDR is a different world and is in many respects beyond the capability of ICC-based color management for the time being. We'll have to see how this plays out in terms of the popularity of HDR, what new tools we will see to manage the display and printing of such images where such dynamic range isn't reproducible, etc.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

____________________________________________________________________________

Date: Mon, 3 Oct 2005 12:45:47 -0600

From: Chris Murphy

Subject: Re: Andrew Rodney's test--consensus

On Oct 2, 2005, at 10:46 PM, Ron Kelly wrote:

1. If you clip colors because your editing space is too small that

could be bad and you could lose detail that would be difficult or

impossible to regain by further manipulation so you should use a wide

enough editing space to retain detail;

The tense is subjunctive, therefore the answer is always yes because there will always be someone who will have an edit space that's too small, given the prevalent spaces of today. It "could" be bad - absolutely it could be. Is it? Well, that's another question. You might not care about the detail or color lost. But that is not a technical question, rather an artistic one.

2. If the gamut of the picture you're working with is smaller than a

wide editing space then a smaller editing space is better, which is

"tighter" to the gamut of the subject;

With the controls we have today, it will give you finer control because moderate moves in a small space can have less of an effect on the image than small moves in a very wide space. If such editing behavior is "better" in your view, then it's better. If you have the granularity you need in a wide space, then it's no better or worse in this example.

If the exact same image colors are in ProPhoto RGB (wide gamut space), or sRGB (small gamut space), the color conversion yields the same result. The CMMs used today defer gamut compression entirely to the destination profile (when they are tabled based, such as output device profiles). Since the pixel data of the ProPhoto RGB and sRGB versions of the same image have the same equivalent LAB values, the destination profile will convert them the same. It's not like you get more gamut compression because the source space is bigger. This is what I mean by prebaked output profiles. The gamut compression is precomputed, at the time the profile is built, not at the time the profile is used.

3. Same as number 2, except that the gamut of the picture *is*

clipped but the lost colours are unimportant to the picture and so

you are better off editing in a smaller space even if you've lost

some detail which is insignificant.

Same as the answer for 2. If you don't care about the lost data, then the question is about the editing behavior of the smaller versus larger space, and the granularity difference implied by each.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

____________________________________________________________________________

Date: Mon, 03 Oct 2005 13:40:43 -0600

From: Andrew Rodney

Subject: Re: Andrew Rodney's test--consensus

First off, I seriously doubt youxll find a perfect (even near perfect) mate between the two based on the unique shapes of synthetic working spaces. In a perfect world, the working space and output space would be as close as possible, especially in 8-bit. Yes, there are colors in a lot of color spaces that fall outside display gamut. It would be nice if we could see all colors we are editing. As I mentioned to Lee, there are colors in something relatively small like SWOP CMYK that you canxt see on about 99%+ of every display in existence. The smaller the working space, the closer the same 256 data points are to each other so again, bigger space, more need for high bit capture/editing. Then therexs the issue of gamut mapping from working space to output space. What intent? Do you use gamut clipping or gamut compression? The closer the two are to each other, the less all of this becomes an issue (issue probably isnxt the right word).

We donxt live in a perfect world. We sometimes know we will edit a file once and only once for a certain output. Ixd be perfectly happy to work in even ColorMatch RGB in 8-bit if I knew the image was only going to SWOP. Personally, many of the images I shoot are going out to a much larger gamut printer and I donxt know where I'll print them in the future. I can see scene color captured that falls outside Adobe RGB (1998) on an image by image basis, so I select ProPhoto RGB in 16-bit due to my unknown goals for the file. But I donxt always use that space and I donxt think too many are advocating using only such a space.

Andrew Rodney

____________________________________________________________________________

Date: Mon, 3 Oct 2005 17:11:05 -0600

From: Ron Kelly

Subject: Re: Andrew Rodney's test--consensus

"Granularity"? What does this mean?

Ron Kelly

____________________________________________________________________________

Date: Mon, 3 Oct 2005 14:15:34 -0600

From: Chris Murphy

Subject: Re: Andrew Rodney's test--consensus

On Oct 1, 2005, at 7:07 AM, Dan Margulis wrote:

I would do the test for you, but I am having a little trouble finding where

commands 1 and 2 are located in Camera Raw, and I'm going to be off for a week

starting now.

The test is useless and you know it. But you have demonstrated that you don't know how Camera RAW works.

*All* edits, regardless of settings occur after demosaicing in a 16bpc integer RGB space with ProPhoto RGB primaries and a 1.0 image gamma. This is the internal editing space of Camera RAW and there is no user selectable option to change it.

The choice of color space and bit depth is a *destination* profile after all edits are applied, thus a conversion occurs from ProPhotoRGB' (which is ProPhoto RGB primaries using a 1.0 image gamma) to whatever you've selected.

Edits do not occur in the selected destination profile space.

It's no more dangerous than LAB, but unlike LAB, it has no advantages.

That's more clear, but actually one step back and a fair two steps sideways from the previous statement:

September 26th, Dan Margulis writes:

It's not clear to me whether they are advocating ultra-wide gamut RGBs as

exchange spaces or storage spaces. If so, no problem--they'll do as well as any

other reasonable alternative. If, as I suspect, they are advocating actually

doing major edits in them, this is a naive workflow that has been thoroughly

discredited for more than a decade.

Rephrased: If wide gamut RGB is used for exchange or storage, there is no problem, for such a purpose they do as well as another suitable space. However if edits are being done, they will not do as well (i.e. inferior to), and such a workflows has been discredited for more than a decade.

By singling out exchange/storage as doing as well as alternatives, but not putting editing in the same context, you've poo poo'd editing in wide gamut spaces, and using as your example wide gamut RGB workflows which depended on heavy use of 8bpc because good 16bpc support is recent. What's been discredited isn't editing in wide gamut RGB spaces alone.

Also, the

Kodak promise of the magic profile that would convert wildly out of gamut

colors accurately into any output condition never quite was fulfilled.

Converting wide gamut RGB images to print space does present challenges depending on the output device, and this is an area I suspect we will continue to have problems until there is a smarter color management system for converting such imagery rather than what we have now, which is prebaked rendering tables in device profiles. This needs to become dynamic.

There are three such technologies on the horizon, two of which are shipping:

ColorIQ is a company making a smart CMM for Mac OS X. The Tiger version isn't out yet.

Imation CMM has been resurrected and the Tiger version should be shipping by now or any day now.

And Microsoft's proposed WCS which not only appears to include pluggable gamut mapping models but also pluggable color appearance models.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

____________________________________________________________________________

Date: Mon, 3 Oct 2005 14:15:34 -0600

From: Chris Murphy

Subject: Re: Andrew Rodney's test--consensus

On Oct 3, 2005, at 5:11 PM, Ron Kelly wrote:

"Granularity"? What does this mean?

Fineness of control. You can make finer edits in a smaller gamut space, than a very larger one where small moves make big and perhaps unwanted changes. Since the space is big, there is a limitation on how fine the edits can be. This is related to bit depth. Even if the image is 16bpc, you lack the granularity at least in Photoshop because the tools use an interface that's still based on working on 8bpc images. If there were a "fine tune" mode when working in 16bpc, this would solve the problem.

For example, even when working in 16bpc, the curves dialog still uses a 0-255 scale even though the actual scale behind the scenes is 0-32768 (15bpc+1 is Photoshop "16bcp").

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

____________________________________________________________________________

Date: Mon, 3 Oct 2005 23:05:07 -0700

From: Lee Varis

Subject: Re: Andrew Rodney's test--consensus

On Oct 3, 2005, at 11:15 AM, Chris Murphy wrote:

ProPhoto RGB has a considerable

gamut, but it isn't a high dynamic range space.

Yes... sorry, I wasn't implying that ACR is doing any kind of HDR processing just that digital cameras typically capture a wider dynamic range than can be reproduced comfortably in normal workspaces and it can help to have a 1.0 gamma workspace to carry out calculations in. Its definitely not true high dynamic range.

This has the potential to get confusing rather quickly

Agreed... probably the less said about HDR in this context the better

Anyway, HDR is a different world and is in many respects beyond the

capability of ICC-based color management for the time being.

Yes... again, sorry for the confusion.

regards,

Lee Varis

http://www.varis.com

888-964-0024

____________________________________________________________________________

Date: Mon, 3 Oct 2005 23:23:42 -0700

From: Lee Varis

Subject: Re: Andrew Rodney's test--consensus

On Oct 3, 2005, at 1:15 PM, Chris Murphy wrote:

ColorIQ is a company making a smart CMM for Mac OS X. The Tiger

version isn't out yet.

Imation CMM has been resurrected and the Tiger version should be

shipping by now or any day now.

And Microsoft's proposed WCS which not only appears to include

pluggable gamut mapping models but also pluggable color appearance

models.

This is very interesting - I always thought the Imation CMM was a step in the right direction as it gave you some control over how black generation occurred in profile conversions -it disappeared before it had an adequate chance to develop. I'm even more intrigued by "pluggable color appearance models". Soft proofing or appearance simulation needs a serious overhaul - is anyone doing any interesting work in this area?

regards,

Lee Varis

http://www.varis.com

888-964-0024

____________________________________________________________________________

Date: Mon, 3 Oct 2005 23:17:13 -0700

From: Lee Varis

Subject: Re: Andrew Rodney's test--consensus

On Oct 3, 2005, at 11:45 AM, Chris Murphy wrote:

The CMMs used today defer gamut compression entirely to

the destination profile (when they are tabled based, such as output

device profiles). Since the pixel data of the ProPhoto RGB and sRGB

versions of the same image have the same equivalent LAB values, the

destination profile will convert them the same. It's not like you get

more gamut compression because the source space is bigger. This is

what I mean by prebaked output profiles. The gamut compression is

precomputed, at the time the profile is built, not at the time the

profile is used.

I've always been confused by this. What kind of gamut compression is assumed in the destination profile. I've noticed the effect where if colors are reasonably in gamut in even a wide source space they don't shift as much as I'd expect- certainly not with say ProPhoto to CMYK with perceptual rendering. So what IS going on? Do profiles effect some kind of sliding scale compression based on how far out of gamut the color is or do they simply assume a one-size-fits all compression. It bugs me that I can't really predict what's going to happen with an out-of-gamut color.

regards,

Lee Varis

http://www.varis.com

888-964-0024

____________________________________________________________________________

Date: Tue, 4 Oct 2005 10:57:38 -0600

From: Chris Murphy

Subject: Re: Andrew Rodney's test--consensus

On Oct 4, 2005, at 12:23 AM, Lee Varis wrote:

This is very interesting - I always thought the Imation CMM was a

step in the right direction as it gave you some control over how

black generation occurred in profile conversions -it disappeared

before it had an adequate chance to develop. I'm even more intrigued

by "pluggable color appearance models". Soft proofing or appearance

simulation needs a serious overhaul - is anyone doing any interesting

work in this area?

Microsoft of all companies. We'll just have to see what gets delivered. I think it will be a step in the right direction. Essentially what they've released publically at the last two WinHEC conferences is a color management system that uses measurement data only profiles, and pluggable color appearance and gamut mapping models. So instead of having a separate application for building profiles in, you have pluggable gamut mapping and color appearance mapping models. Presumably Microsoft includes a few of each sort for at least RGB and CMYK transforms, but leaves the door open for vendors to build their own. We'll just have to wait and see how all of this plays out. If it doesn't work well, then it will be ignored. If it works well, then color management implementation is going to get really different in such a paradigm, and will be really contingent on the user interface.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

____________________________________________________________________________

Date: Tue, 04 Oct 2005 22:45:55 -0000

From: "dmargulisnj"

Subject: Re: Andrew Rodney's test--consensus

Chris Murphy writes,

The test is useless and you know it. But you have demonstrated that Ê

you don't know how Camera RAW works. *All* edits, regardless of settings

occur after demosaicing in a 16bpc integer RGB space with ProPhoto RGB

primaries and a 1.0 image gamma. This is the internal editing space of

Camera RAW and there is Êno user selectable option to change it.

Holy Lecherous Leg-puller, Batman, whaddaya mean there isn't an option? If that were true, and Camera Raw were an "editing package", then it wouldn't be a question of "editing" in Camera Raw in a sensible colorspace vs. an inferior one, it would be a question of using an inferior one vs. not using Camera Raw at all, in which case your whole post would make no sense. So the command is obviously there, and you just haven't found it yet.

Similarly, with respect to the color curves: you're the one whose saying Camera Raw is a serious editing tool, as opposed to something more like a profiling or a scanning tool. Now this ultra-wide RGB that you seem to be advocating was obsolete more than ten years ago, so it would be unfair to compare Camera Raw to state-of-the-art editing packages in 1995. But surely, if it's really a serious editing tool, it has to be competitive with packages of *twenty* years ago!

Call Camera Raw an "editing package" if you like, Batman, but Holy Outdated Oxymoron, you can't have an editing package without curves! They would have laughed at such a thing even in 1985! Photoshop can edit text, but that doesn't make it a word processor.

So again--that command is certainly there. You need to go back and look for it.

Rephrased: If wide gamut RB is used for exchange or storage, there Ê

is no problem, for such a purpose they do as well as another suitable Ê

space. However if edits are being done, they will not do as well Ê

(i.e. inferior to), and such a workflows has been discredited for Ê

more than a decade.

Fair enough summary.

By singling out exchange/storage as doing as well as alternatives, Ê

but not putting editing in the same context, you've poo poo'd editing Ê

in wide gamut spaces, and using as your example wide gamut RGB Ê

workflows which depended on heavy use of 8bpc because good 16bpc Ê

support is recent.

Bit depth has nothing to do with it. The problem is that when half the colorspace is taken up by nonexistent colors only half can be devoted to those that do exist, so that any curve or similar adjustment being applied has to be twice as accurate to avoid an unacceptable result. That makes serious color correction very difficult. At a minimum, if one wanted to achieve the precise control of endpoints that is needed for professional-quality color, one would have to do the first edits in an ultra-wide gamut RGB and then convert and fine-tune in a more rational RGB, which would suggest the question of why not save a step by working in a rational RGB from the get-go.

I'm back to vacationing.

Dan Margulis

____________________________________________________________________________

Date: Tue, 04 Oct 2005 19:21:24 -0400

From: "Gene Palmiter"

Subject: Re: Re: Andrew Rodney's test--consensus

I'm back to vacationing.

Dan Margulis

Well...you may be good a color theory...but you don't seem to be very good at vacationing. GETOUTAHERE!

____________________________________________________________________________

Date: Wed, 5 Oct 2005 13:42:33 -0600

From: Chris Murphy

Subject: Re: Andrew Rodney's test--consensus

On Oct 4, 2005, at 12:17 AM, Lee Varis wrote:

I've always been confused by this. What kind of gamut compression is

assumed in the destination profile. I've noticed the effect where if

colors are reasonably in gamut in even a wide source space they don't

shift as much as I'd expect- certainly not with say ProPhoto to CMYK

with perceptual rendering. So what IS going on? Do profiles effect

some kind of sliding scale compression based on how far out of gamut

the color is or do they simply assume a one-size-fits all

compression. It bugs me that I can't really predict what's going to

happen with an out-of-gamut color.

It's one size fits all gamut compression. At the time the output device profile is built, there is a reference color space, proprietary to each vendor, that they use to predicate gamut compression. If they make it too aggressive, such as for a large source space, it will do well with large gamut source spaces but will over compress images that are in smaller spaces such as sRGB. This is one of the reasons why RelCol+BPC works best with most kinds of images, whereas with others, notably those that are ProPhoto RGB, perceptual can sometimes work better. But it does depend on image content.

If you have an image completely contained in sRGB, then make a copy, convert to ProPhoto RGB, by definition the ProPhoto RGB version contains a "LAB equivalent" of the sRGB version. The color appearance of the two is the same, even though one is in a larger space. If you convert both to a particular destination, they will be converted the same so long as you use the same CMM and rendering intent.

However, if there are substantially out of gamut colors in a ProPhoto RGB image, it is possible those colors are so far out of gamut that the gamut compression assumptions made by the profiling software didn't take them into account and you can get a variety of odd renderings. You can get very saturated blues that render to near black, or you can get posterization, etc.

Because an ICC output device profile has to work with so many sources, and therefore make so many compromises, is why I've been a big proponent of dumping that whole method of color management and getting to a point where we have measurement only device profiles and gamut compression and color appearance mapping on a per image basis. That way the amount of gamut compression is specific to the colors in the image as well as the capabilities of the output device.

This could still be done in an ICC construct but the ICC improves things at a glacial pace. Supposedly major improvements occur in half-decade increments, which take another half-decade to disseminate and maybe another half-decade for it to affect the mainstream users. Color management improvement measured in decades is impressive, but not in a good way.

The ICC now has the v4 specification which supposedly does more to define the colorimetric intent as being closer to measurement data than it is now (which it can't be exactly because the measurement data has to be interpolated in order to get it to fit into a uniform grid), and also defines a perceptual reference medium so that perceptual intents can work more consistently regardless of the source space. Yet I have yet to see any difference between v2 and v4 profile performance in practice.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

____________________________________________________________________________

Date: Wed, 5 Oct 2005 18:09:33 -0700

From: Lee Varis

Subject: Re: Andrew Rodney's test--consensus

On Oct 5, 2005, at 12:42 PM, Chris Murphy wrote:

It's one size fits all gamut compression. At the time the output

device profile is built, there is a reference color space,

proprietary to each vendor, that they use to predicate gamut

compression.

Thanks Chris, that explains a lot! So the compression assumptions made by the various venders can account for, say, one vender does a better job with Adobe 98-> SWOP v2 but another handles ProPhoto -> Epson better.

Because an ICC output device profile has to work with so many

sources, and therefore make so many compromises, is why I've been a

big proponent of dumping that whole method of color management and

getting to a point where we have measurement only device profiles and

gamut compression and color appearance mapping on a per image basis.

That way the amount of gamut compression is specific to the colors in

the image as well as the capabilities of the output device.

I heard similar things proposed by others - I not sure that I understand what is meant by "measurement only device profiles" but it sure would be nice to get gamut compression specific to the colors in an image by image basis sooner rather than later.

regards,

Lee Varis

http://www.varis.com

888-964-0024

____________________________________________________________________________

Date: Wed, 05 Oct 2005 21:28:56 -0700

From: Marco Ugolini

Subject: Re: Andrew Rodney's test--consensus

In a message dated Wed, 5 Oct 2005 18:09:33, Lee Varis wrote:

I heard similar things proposed by others - I not sure that I

understand what is meant by "measurement only device profiles"

I would assume that "measurement-only device profiles" would mean storing inside the profile nothing but the spectral measurements for each patch measured with one's spectrophotometer, probably at a resolution of either 10 or 20 nanometers.

Currently the values stored inside a device profile for each measured patch are Lab-referenced LUTs (one A2B-B2A set for each of 3 rendering intents), specific to a particular device. Using Lab values lacks the much more detailed and flexible description that spectral measurements provide.

*Some* profiles already *do* store spectral values. Both "Default" and "Large" device profiles made with ProfileMaker 5 contain the reference data (tag DevD) as well as the spectral measurement data (tag CIED), the latter from 380 to 730nm, at intervals of 10nm. That is convenient, because one can drop a ProfileMaker profile back into an open PM application window, and all the data necessary to create a fresh profile are there already, without any need for separate measurement or reference data.

Apparently, though, those spectral values are not yet being used in ways meaningful to the color management workflow by the current ICC procedures. They seem to be there more for the benefit of the profiling software -- to make it easier to re-create the profile -- than for other reasons, like for example creating Lab equivalents on-the-fly that are more appropriate to a specific situation than the pre-baked, one-size-fits-all ones we get in today's ICC profiles.

That would be my understanding of what constitutes a "measurement-only device profile." Perhaps Chris would care to either confirm or correct me.

--------------

Marco Ugolini

Mill Valley, CA

____________________________________________________________________________

Date: Thu, 6 Oct 2005 02:22:57 -0400

From: "jc castronovo"

Subject: Re: Andrew Rodney's test--consensus

Yes Lee. Maybe Chris can tell us more about this method of profiling?

I've got an image that I'm working on right now that depends on the differentiation between very saturated greens. ProPhotoRGB can contain the necessary colors, but I'd like to have better control over how it gets translated to the printer's gamut. Neither relative nor perceptual rendering can do the job of translating these greens properly. One clips and the other squishes everything together which is just as bad. I know that the printer can't reproduce the greens exactly, but we should be able to represent the relative differences better, even if it's at the sacrifice of color accuracy on the other side of the spectrum, which would be acceptable in this case.

john castronovo

____________________________________________________________________________

Date: Thu, 06 Oct 2005 07:18:42 -0600

From: Andrew Rodney

Subject: Re: Andrew Rodney's test--consensus

On 10/5/05 10:28 PM, "Marco Ugolini" wrote:

Apparently, though, those spectral values are not yet being used in ways

meaningful to the color management workflow by the current ICC procedures.

Exactly. It1s just to make it easier to rebuild profiles without having to dig up the measured data or do it over again. ProfileMaker Pro does use the spectral data in some unique ways to build the profiles (like detecting optical brighteners). It will also import other1s profiles (how I1m not sure but it works).

Andrew Rodney

http://www.digitaldog.net/

____________________________________________________________________________

Date: Thu, 6 Oct 2005 07:52:42 -0700

From: Lee Varis

Subject: Re: Andrew Rodney's test--consensus

Bringing this thing a little more back into the realm of this list:

On Oct 5, 2005, at 11:22 PM, jc castronovo wrote:

Neither relative nor perceptual rendering

can do the job of translating these greens properly. One clips and the other

squishes everything together which is just as bad. I know that the printer

can't reproduce the greens exactly, but we should be able to represent the

relative differences better

This is why I use ProPhoto primarily for grayscale info in the various channels. You can do various luminosity calculations back into a duplicate image, after it is converted into a more limited gamut colorspace, to retrieve some separation in tones that got squished or clipped together - the biggest problem for ProPhoto-> Epson (or just about any normal workspace)! This is sort of a manual perceptual conversion to repair the damage caused in the initial translation from the wide gamut space to output gamut space. Most of the time I can avoid doing too much of this by simply adjusting/processing raw digital camera files into something a little more constrained like Adobe RGB - the gamut compression handled in the adjustment from the raw data into RGB. Occasionally, if you suspect the presence of important out-of-gamut colors (that are just too far out to convert properly) you can resort to the ProPhoto conversion/repair thing.

I'm going to try and work up some examples to illustrate this but it will have to wait until after next week!

regards,

Lee Varis

http://www.varis.com

888-964-0024

____________________________________________________________________________

Date: Thu, 6 Oct 2005 13:53:38 -0600

From: Chris Murphy

Subject: Re: Andrew Rodney's test--consensus

Incidentally the gamut compression is contingent on the CMM when converting between simple matrix-based profiles like editing spaces. All of those dinky 4k profiles are matrix profiles. The v2 variety don't have separate rendering intent tables in them, so the gamut compression (or lack thereof) isn't based on the profiles themselves because that information isn't in them. They defer to the CMM. So changing CMM's will get you different results with such conversions.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

____________________________________________________________________________

Date: Thu, 6 Oct 2005 13:44:07 -0600

From: Chris Murphy

Subject: Re: Andrew Rodney's test--consensus

On Oct 5, 2005, at 7:09 PM, Lee Varis wrote:

Thanks Chris, that explains a lot! So the compression assumptions

made by the various venders can account for, say, one vender does a

better job with Adobe 98-> SWOP v2 but another handles ProPhoto ->

> Epson better.

Yes exactly. And there was a product a while ago, Color Savvy (? it was the company bought by Pictographics, anyone?) that would let you choose the reference space before building an output profile. So you could predicate gamut compression on a particular space. The problem with doing this though, is that in a case of ProPhoto RGB, it's so frigging huge that the software doesn't know that real captures are unlikely to fill even 1/2 of ProPhoto yet it would presumably attempt to compress all of ProPhoto.

One of the changes in ICC v4 is that there is a defined perceptual PCS reference medium, which means there is "something much closer for profile vendors to agree on." It's more technical than that, but the idea is for ICC v4 profiles to allow image state changes (scene-referred to output-referred) when using the perceptual intent, and not do image state changes (as is currently the case) with either colorimetric intent.

So instead of one size fits all, you get a smarter conversion based on source and destination profiles used if both of them are v4 profiles. But I still think this is going to be insufficient. A CMS really needs the ability to know what volume within a color space a particular image takes up, as well as surrounding colors that AREN'T part of the image (such as a background). That's why a gamut mapper separate from color appearance is important.

You can have a company logo on four different colored backgrounds using the exact same logo artwork and each will appear different because of simultaneous contrast and other visual effects. We know how those effects work and they can be predicted by color appearance models. Apply a CAM to this process would cause each logo to have slightly different renderings so that they all *appear* to look the same despite being printed with different background colors.

I heard similar things proposed by others - I not sure that I

understand what is meant by "measurement only device profiles" but it

sure would be nice to get gamut compression specific to the colors in

an image by image basis sooner rather than later.

A measurement only device profile has no gamut mapping performed. The data is raw, measurement data, it's not massaged by a profiling application to make it fit into a matrix grid. There's a lot going on when building a profile. 1000 measurements is maybe 14k of data. That's 16-bits per channel for 7 channels (CMYK + LAB). An ICC profile is not 14K in size, they're much bigger because there's interpolation and creation of data points. You only measure 1000 patches, but a 33 x 33 x 33 matrix used in large profiles contains over 35,000 entries. Not all get filled, but the grid holds that many points so there's a lot of interpolation to get from 1000 entries to maybe 10,000-15,000.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

____________________________________________________________________________

Date: Thu, 6 Oct 2005 13:50:44 -0600

From: Chris Murphy

Subject: Re: Andrew Rodney's test--consensus

On Oct 6, 2005, at 12:22 AM, jc castronovo wrote:

Yes Lee. Maybe Chris can tell us more about this method of profiling?

I've got an image that I'm working on right now that depends on the

differentiation between very saturated greens. ProPhotoRGB can contain the

necessary colors, but I'd like to have better control over how it gets

translated to the printer's gamut. Neither relative nor perceptual rendering

can do the job of translating these greens properly. One clips and the other

squishes everything together which is just as bad. I know that the printer

can't reproduce the greens exactly, but we should be able to represent the

relative differences better, even if it's at the sacrifice of color accuracy

on the other side of the spectrum, which would be acceptable in this case.

The dilemma of prebaked gamut mapping. Is this a custom profile? Do you have the measurement data? If you have a profiling package or access to one, rebuild using a different perceptual rendering setting. Both gmb ProfileMaker Pro and Monaco Profiler have such options.

Otherwise, consider converting it to some other space first, like Adobe RGB (1998), and then to printer space. The destination profile is clearly making the wrong assumptions about the colors actually contained in the image, and it can only make assumptions because these profiles don't work intelligently at all at the present time. If I wasn't running Tiger, I'd run it through ColorIQ's IQMatch CMM and see what it can do, but they are still working on a Tiger version last time I checked.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

____________________________________________________________________________

Date: Thu, 6 Oct 2005 13:46:26 -0600

From: Chris Murphy

Subject: Re: Andrew Rodney's test--consensus

On Oct 5, 2005, at 10:28 PM, Marco Ugolini wrote:

That would be my understanding of what constitutes a "measurement-only

device profile." Perhaps Chris would care to either confirm or

correct me.

That's correct.

A profile containing measurement data only could be either spectral or XYZ or LAB or any combination thereof. The main idea is not so much what form the data is in, but rather it's based on actual measurements, not interpolation or extrapolation.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

____________________________________________________________________________

Date: Thu, 6 Oct 2005 19:55:59 -0700

From: "Paul D. DeRocco"

Subject: RE: Andrew Rodney's test--consensus

From: Chris Murphy

A CMS

really needs the ability to know what volume within a color space a

particular image takes up, as well as surrounding colors that AREN'T

part of the image (such as a background). That's why a gamut mapper

separate from color appearance is important.

I agree, but it's non-trivial. I used ColorThink to examine the colors in an image, and was surprised to find some very saturated colors that I couldn't actually see anywhere. Turns out it was just speckles of color noise. Some level of averaging would be needed.

You can have a company logo on four different colored backgrounds

using the exact same logo artwork and each will appear different

because of simultaneous contrast and other visual effects. We know

how those effects work and they can be predicted by color appearance

models. Apply a CAM to this process would cause each logo to have

slightly different renderings so that they all *appear* to look the

same despite being printed with different background colors.

Is that really the domain of color management? It would seem to me that one would expect to look at the company logo on those backgrounds in Photoshop, see what those differences are, and then manually edit them to deal with the psychovisual effects. When printing, you basically want the print to look as much like what you see while editing as possible, not do your editing for

you.

Ciao, Paul D. DeRocco

____________________________________________________________________________

Date: Fri, 7 Oct 2005 06:54:41 -0500

From: Bob Smith

Subject: Re: Andrew Rodney's test--consensus

On Oct 6, 2005, at 2:44 PM, Chris Murphy wrote:

And there was a product a while ago, Color Savvy (? it

was the company bought by Pictographics, anyone?) that would let you

choose the reference space before building an output profile.

ColorSynergy is the package you're thinking of. You picked an assumed origination space as part of the profile building process and that would determine how much gamut compression would be applied in the perceptual rendering part of the profile.

Bob Smith

Accurate Image • Bob Smith Photographer • Waco Texas USA

http://www.accurateimage.org

____________________________________________________________________________

Date: Fri, 7 Oct 2005 11:14:52 -0700

From: "Andrew Engelhardt"

Subject: request to end thread - Andrew Rodney's test--consensus

Hi group, on behalf of the moderators, we request also that this thread is brought to an end in the next 24 hours or so, as it too has become more of a discussion of the merits of third-party profiling packages, and is of little or no relevance to the purpose of this group. Your co-operation is appreciated. Thanks

Andrew Engelhardt

Group Co-moderator

____________________________________________________________________________

Date: Fri, 7 Oct 2005 12:56:53 -0600

From: Chris Murphy

Subject: Re: Andrew Rodney's test--consensus

On Oct 6, 2005, at 8:55 PM, Paul D. DeRocco wrote:

Is that really the domain of color management?

It hasn't really ever been about color management, but appearance management. What's lacking in color management is predicting what we actually see. It's not uncommon for "color management" to say two color samples match when they don't. They do in isolation, but human beings don't work with colors in isolation, we work with color in context. Color appearance better predicts color in context; color management doesn't at all.

It would seem to me that one

would expect to look at the company logo on those backgrounds in Photoshop,

see what those differences are, and then manually edit them to deal with the

psychovisual effects. When printing, you basically want the print to look as

much like what you see while editing as possible, not do your editing for

you.

Today you do the editing manually because that's the only way to get it done, not because it's the best way to solve the problem. If there were another way, that didn't involve ten people to get it done, three hours, and five proofs, then I think people will choose the faster method.

And this isn't really a case for an edit because the logo isn't being reproduced incorrectly. The "problem" is that the appearance is different in context. If a CMS can predict the effect correctly, why would you not want it to take care of it in such a context? I suppose if you really want to manually edit the logo four times for four different backgrounds, pull four proofs and not get it right the first, second or third time...

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

____________________________________________________________________________

Date: Fri, 7 Oct 2005 17:26:45 -0400

From: Henry

Subject: Re: Andrew Rodney's test--consensus

On Oct 7, 2005, at 2:56 PM, Chris Murphy wrote:

Today you do the editing manually because that's the only way to getÊ

it done, not because it's the best way to solve the problem. If thereÊ

were another way, that didn't involve ten people to get it done,Ê

three hours, and five proofs, then I think people will choose theÊ

faster method.

Rounds of editing are expected when trying to achieve printed color accuracy of a logo. If a method were developed to avoid this, well then I would love to see this. People(1st variable) evaluate the results in Context(s)(2nd variable(s)) including Lighting(3rd variable). Never mind the practical aspects of the drifting during a run that occurs even with tight process control (theory vs. practice).

I seem to recall that it has been recently asserted by respected folks on this list that such an undertaking is not within the realm of profiling and color management - even given sufficient gamut of ink etc. Something big must have been discovered.

Even an approach that limits these variables so that recipes for colorimetric matches can be accurately produced under specified conditions would be a huge advance.

Henry Davis

____________________________________________________________________________

Date: Fri, 7 Oct 2005 16:38:24 -0700

From: "Paul D. DeRocco"

Subject: RE: Andrew Rodney's test--consensus

From: Chris Murphy

And this isn't really a case for an edit because the logo isn't being

reproduced incorrectly. The "problem" is that the appearance is

different in context. If a CMS can predict the effect correctly, why

would you not want it to take care of it in such a context? I suppose

if you really want to manually edit the logo four times for four

different backgrounds, pull four proofs and not get it right the

first, second or third time...

Because you have the same "context", meaning the background color, whether you're looking at the print or at the screen. It seems to me that the purpose of a color management engine that uses profiles to translate from one color space to another is to reduce differences between the different image domains (display, print, scan, etc.), not deal with psychovisual effects that occur equally in all domains. But then, all I do is edit and print photographs, not logos.

Ciao, Paul D. DeRocco

____________________________________________________________________________

Date: Sat, 08 Oct 2005 10:42:17 -0400

From: Lee Clawson

Subject: Re: Andrew Rodney's test--consensus

on 10/7/05 2:56 PM, Chris Murphy wrote:

...but human beings don't work with colors in isolation, we work with color

in context. Color appearance better predicts color in context; color

management doesn't at all.

I'm with Paul on this. Human beings may not see or work in isolation but we think about using this as a design concept.

Today you do the editing manually because that's the only way to get

it done, not because it's the best way to solve the problem. If there

were another way, that didn't involve ten people to get it done,

three hours, and five proofs, then I think people will choose the

faster method.

Your other way could easily have ruined 4 projects we did in the last year. I use this all the time.

And this isn't really a case for an edit because the logo isn't being

reproduced incorrectly. The "problem" is that the appearance is

different in context. If a CMS can predict the effect correctly, why

would you not want it to take care of it in such a context? I suppose

if you really want to manually edit the logo four times for four

different backgrounds, pull four proofs and not get it right the

first, second or third time...

For each example you see "problem" I can show you 3 times more that I've used this in graphic and packaging designs as a color effect. Anyone who had to sit through 1 semester of Alber's Color probably uses it to the good as well. This is one thing I don't want running behind the scenes trying to out guess my color intent.

Lee

____________________________________________________________________________

Date: Fri, 07 Oct 2005 21:10:54 -0700

From: Marco Ugolini

Subject: Re: Andrew Rodney's test--consensus

In a message dated Fri, 7 Oct 2005 17:26:45, Henry Davis wrote:

Rounds of editing are expected when trying to achieve printed color

accuracy of a logo. If a method were developed to avoid this, well

then I would love to see this. People(1st variable) evaluate the

results in Context(s)(2nd variable(s)) including Lighting(3rd

variable). Never mind the practical aspects of the drifting during a

run that occurs even with tight process control (theory vs. practice).

I seem to recall that it has been recently asserted by respected folks

on this list that such an undertaking is not within the realm of

profiling and color management - even given sufficient gamut of ink

etc. Something big must have been discovered.

Color Appearance Models (CAMs), while not yet actively present in current color technologies (except for the yet unverified claims of Microsoft's Windows Color System for the Vista operating system), are at an advanced state of research.

Wonder no more whether whether "something big [has] been discovered." It has, and the person foremost in the conceptualization and refinement of CAMs, Mark D. Fairchild, of R.I.T., describes the subject at length in the book "Color Appearance Models" (2nd edition, Wiley & Sons, 2005). <http: //www.amazon.com/exec/obidos/tg/detail/-/0470012161/qid=1128743646/sr= 2-1/ref=pd_bbs_b_2_1/002-6344868-1680045?v=glance&s=books>

You can also visit Dr. Fairchild's site at:

<http://www.cis.rit.edu/fairchild>

Please click on the "iCAM" link for more info, and for free downloads of specialized studies.

Best regards.

--------------

Marco Ugolini

Mill Valley, CA

____________________________________________________________________________

Date: Fri, 13 Jan 2006 11:53:02 EST

From: Dan Margulis

Subject: Call for 16-bit example

I don't wish to reopen discussion on a very sore topic, but in preparation for the next edition of Professional Photoshop, I feel I must ask if anyone can produce a real-world color photograph where 16-bit correction is demonstrably better than the same corrections in 8-bit. If such an example exists, I will make room for it in the book.

I am not expecting any examples to show up, because if such images existed, they would have at some time in the last six years. I have run many pages of examples in Professional Photoshop 4E and in Canyon Conundrum comparing results of massive corrections in 8- and 16-bit. I do not wish to waste that amount of space on them this time. Unless something comes up, I will put copies of the all the pertinent threads from this list on the book's CD, refer to it in text, and simply state that while nobody says that working in 16-bit does any harm, there is no reason to think that it does any good either when color-correcting photographic images.

**********

If you wish to try to refute this, the following are the requirements.

1) You must be willing to release the image for publication for the limited purpose of discussing 16-bit vs. 8-bit correction, including allowing it to go on the book CD so that others can test it for themselves.

2) The image(s) must be real-world color photograph(s). This means any photograph that could conceivably be used in any professional context. If it is a cropped piece of a larger photograph, the piece must be large enough that it could conceivably be used on its own.

3) Any correction method can be used, but the moves must be such that they can by any stretch of the imagination be interpreted as an attempt to improve the image. The corrections do not have to be competently executed but there cannot be outright sabotage. That includes deliberately acquiring the image in a known incorrect fashion, or moves that are plainly designed to damage rather than improve the image, such as repeated lightening followed by repeated darkening.

4) All corrections should be documented so that I can reproduce them.

5) You should have applied identical corrections to an 8-bit and a 16-bit file, and it should be your opinion that almost everyone would agree that the 16-bit image is better *overall*, not in some small area.

**********

The following types of images are not of interest.

1) Black and whites. It has been demonstrated that the smoother appearance of 16-bit corrections can be perceived in real-world corrections of B/W images. I have some B/W images that actually look better if corrected in 16-bit, although more look better if corrected in 8-bit. They don't tell us much about doing the work in color, because the effect is hidden by having more channels.

2) Computer-generated artwork such as gradients, or any photograph that has been modified to such an extent that it is effectively computer-generated.

3) Images worked in an exotic colorspace definition, such as a nonstandard gamma, or an ultra-wide gamut RGB.

4) Images that have been placed into 8-bit by scanner or camera software, as opposed to converting 16-bit to 8-bit in Photoshop. We know that certain acquire modules convert into 8-bit badly, and we have examples where identical corrections to such an 8-bit file compared to the same module's 16-bit look worse. However, in all cases, where the 16-bit was converted to 8-bit in Photoshop, there has been no significant difference.

5) Images that the user hasn't tested himself but is sure will show the effect.

6) Images that are deliberately acquired incorrectly in Camera Raw or similar module. (Photographs that are actually underexposed by the photographer are welcome.)

**********

The following types of *discussion* are not of interest.

1) Assurances that the speaker personally knows that 16-bit works better in certain types of image and has seen the effect for himself. I have probably corresponded with a hundred such individuals in the last six years. Not a single one has ever run a side-by-side test. Not a single claim can be verified, and I and others have spent weeks trying. While I enjoy the dialog, at this point I would have to regretfully say that unless someone has actual images with which to demonstrate a superiority, any argument they may have in favor of it is irrelevant.

2) References to websites or books that purportedly prove it. I've been to every one. They're all histograms and gradients.

3) Histograms and gradients, or other explanations of why it is mathematically certain that 16-bit is better.

Anyone who wishes to participate needs to at least let me know by the end of the month so that we can arrange shipping.

Dan Margulis

___________________________________________________________________________

Date: Fri, 13 Jan 2006 13:05:58 -0700

From: Ron Kelly

Subject: Re: Call for 16-bit example

On 13-Jan-06, at 9:53 AM, Dan Margulis wrote:

I don't wish to reopen discussion on a very sore topic, but in preparation

for the next edition of Professional Photoshop, I feel I must ask if anyone can

produce a real-world color photograph where 16-bit correction is demonstrably

better than the same corrections in 8-bit.

I read your invite with some interest, although I have no intention of participating by providing files.

You've overlooked one point, however: how is *better* determined? I don't see that you've addressed this point specifically, and maybe you feel it's implied.

It has to be printed. It has to show up on the page, and not just be something visible on the screen.

We can see all kinds of insignificant "detail" in scans and digital files that make no difference in the final print. Conclusion - insignificant detail is insignificant.

So whether it's inkjet, lightjet, or some kind of off-set, it doesn't matter. On screen - not a definitive example.

I would therefore add the proviso that any improvement in 8 vs. 16 bits should have to show up *in printed form* to be considered real and conclusive.

Ron Kelly

___________________________________________________________________________

Date: Fri, 13 Jan 2006 15:47:51 -0500

From: "Warren L. Parsons"

Subject: Re: Call for 16-bit example

Hi Ron,

I have to take some issue with this position. I don't believe that whether something shows up in print is the "final word" on whether a difference between methods is "significant." It is becoming increasingly common for digital display to be the "final form" of an image, in which case readily visible differences in output *are* significant, regardless of whether they show up in print.

That said, I do not expect any advantage to working in 16-bit will make itself known. As Dan stated, if 16-bit were demonstrably better, it would have been demonstrated by now.

Regards,

Warren L. Parsons

___________________________________________________________________________

Date: Fri, 13 Jan 2006 14:27:46 -0700

From: Ron Kelly

Subject: Re: Call for 16-bit example

With respect, Warren, I disagree.

On-screen images usually have been and still substantially an intermediate product. They're something you show to someone so they can get a sense of it. Once they see something they like, they buy a print.

The exception to this is pictures that are made for the web, or a presentation. Such pictures are scrutanized far, far less critically than most printed images. In these cases image quality is still important, but the pictures typically don't appear for long because the viewer in these mediums demand movement, lest they be bored.

How many times have you sat and looked at a picture on the web for more than a few seconds? How long do you show a single image in a presentation? Two seconds? Three? Five maybe, if you use some panning a la Ken Burns. Not much time to really see more than: "What's this?" and "Do I like it, or not?"

Contrast that with how much time you'd spend on a fine photograph in a gallery, pore over a movie poster or magazine spread, or even examine an interesting newspaper photo.

Ron Kelly

___________________________________________________________________________

Date: Fri, 13 Jan 2006 18:18:43 -0500

From: "Mark Segal"

Subject: Re: Call for 16-bit example

Dan,

There are a couple of problems with your rules. What is your definition of an ultra-wide gamut RGB? Does ProPhoto fit that definition? If it does I can't send you anything because I work in ProPhoto. I work in ProPhoto because an Epson 4800 can reproduce certain colours that are outside ARGB98 gamut but inside ProPhoto. It has been claimed that 16 bit depth is preferable to 8 bit depth in such a colour space in order to mitigate banding and posterization risk (more levels relative to the space size). So if you rule out the one editing context where 16 bit may show some superiority, it would seem that the rules pre-determine the result.

Secondly, I am confused about item (4) below. A professional DSLR (e.g. a 1Ds) acquires images in 12 bit (4096 levels) - not 8, not 16. In Camera Raw, one then has the choice to convert them into 8 or 16 bit for further processing in Photoshop. So this first decision about bit depth is made at the Camera Raw stage, not the Photoshop stage, and either choice differs from the bit depth the RAW file contains. Anyone using a RAW converter would make the 8 versus 16 decision once and for all at the raw conversion stage, and not tinker with it thereafter in Photoshop except at the end of the adjustment process for printing or web output - if even then in the case of printing. Hence what you say in item (4) below does not reflect this reality and makes it very unclear what workflow process qualifies or disqualifies for sending you samples.

I shall be grateful if you would clarify.

Cheers,

Mark Segal

___________________________________________________________________________

Date: Fri, 13 Jan 2006 14:47:36 -0800

From: Marco Ugolini

Subject: Re: Call for 16-bit example

In a message dated 1/13/06 1:27 PM, Ron Kelly wrote:

On-screen images usually have been and still substantially an

intermediate product. They're something you show to someone so they

can get a sense of it. Once they see something they like, they buy a

print.

FYI, filmless, or virtual proofing (i.e., proofing using displays, without laminated proofs, for output that goes directly to plate) has become mainstream already. Time Magazine, for one, already--and famously--does its business this way.

The exception to this is pictures that are made for the web, or a

presentation. Such pictures are scrutanized far, far less critically

than most printed images. In these cases image quality is still

important, but the pictures typically don't appear for long because

the viewer in these mediums demand movement, lest they be bored.

I don't wish to sound either preachy or testy, but imaging is a rapidly evolving field, and statements that may have been supportable even recently have to be constantly requalified and reformulated.

Yes, pictures destined for the web are meant to be viewed on displays, and are indeed scrutinized less closely than ones for print. But it's not a sound logical leap to go from that to saying that the only people interested in using a display to evaluate images are solely those whose content is aimed for the web. At least not any longer.

Regards.

--------------

Marco Ugolini

Mill Valley, CA

___________________________________________________________________________

Date: Fri, 13 Jan 2006 23:02:11 +0000

From: Francis Corvin

Subject: Re: Call for 16-bit example

In order for the 8 v. 16 bit debate to be fruitful, it should be established that the additional 8 bits do effectively contain useful information --- significantly more than noise. Is this now an accepted point, or is there still some debate on this? Sorry if the question appears quite basic, this stuff is still new to me, and apologies if it's going over old ground.

Regards,

Francis Corvin

___________________________________________________________________________

Date: Fri, 13 Jan 2006 20:31:14 -0800

From: J Walton Subject: Re: Call for 16-bit example

Time Magazine is using virtual proofing as a replacement for conventional contract proofs. They aren't charging people two dollars to come read the magazine on a monitor.

Ron's statement that on-screen images are now substantially an intermediate product is not disproven by Time's workflow, but rather proven. They use the monitor to show what the ad is supposed to print like, and then they print it and sell it all over the world. It is that printed piece which is the end product and that will be examined more carefully.

I do agree that our field is a rapidly changing one. It is difficult to make a statement and not have to adjust it later. The evolution of Dan's conditions on the 8-bit vs. 16-bit test is an example of this. The core argument is still sound, but workflows change so much that small segments on the edge of his focus find some exceptions.

___________________________________________________________________________

Date: Fri, 13 Jan 2006 21:48:38 -0800

From: Marco Ugolini

Subject: Re: Call for 16-bit example

In a message dated 1/13/06 8:31 PM, J Walton wrote:

Time Magazine is using virtual proofing as a replacement for

conventional contract proofs.

Yes. I said that myself. So we agree?

They aren't charging people two dollars to come read the

magazine on a monitor.

Geez... Should I call that a low blow or just silly?

Ron's statement that on-screen images are now substantially an intermediate

product is not disproven by Time's workflow, but rather proven. They use the

monitor to show what the ad is supposed to print like, and then they print

it and sell it all over the world. It is that printed piece which is the end

product and that will be examined more carefully.

What is seen on the display in this sort of workflow is assumed to reflect and accurately preview the printed results. Millions of dollars' worth of work hinges on that assumption and on keeping the system in good enough working order to guarantee those results. The printed piece is the result, but the virtual proofing is the terrain on which decisions are made.

Bottom line:

Monitor displays (a) of good enough quality, (b) properly calibrated and profiled, and (c) in the hands of skilled operators (d) working in concert with properly color-managed applications, *are* good enough to make decisions which directly affect and very closely reflect the printed results.

Regards.

--------------

Marco Ugolini

Mill Valley, CA

___________________________________________________________________________

Date: Sat, 14 Jan 2006 09:09:28 -0800

From: J Walton

Subject: Re: Call for 16-bit example

On 1/13/06, Marco Ugolini wrote:

Yes. I said that myself. So we agree?

On most things, yes.

Geez... Should I call that a low blow or just silly?

I'd go for the latter, since I have nothing against you. It merely makes the point that the monitor is an intermediate step, that's all.

Bottom line:

Monitor displays (a) of good enough quality, (b) properly calibrated and

profiled, and (c) in the hands of skilled operators (d) working in concert

with properly color-managed applications, *are* good enough to make

decisions which directly affect and very closely reflect the printed

results.

All of that is true, and a good reflection of the statement you made earlier, that our industry has changed quite a bit and will continue to change.

Let's not forget the context of this conversation. It is not about color or contrast or saturation or the quality of monitors these days. It is about 16-bit editing and whether or not results on a monitor should be included in a discussion on the superiority of one over the other.

Virtual proofing does show that what things look like on a monitor is becoming increasingly important, but does not relate to our 16-bit discussion right now. No one at Time is evaluating the difference between 8-bit and 16-bit edits on screen.

J Walton

___________________________________________________________________________

From: Dan Margulis

Date: Sat Jan 14, 2006 8:38 am

Subject: Re: [colortheory] Call for 16-bit example

Ron Kelly writes,

You've overlooked one point, however: how is *better* determined? I

don't see that you've addressed this point specifically, and maybe

you feel it's implied.

"Better" in real life is determined by whether your client thinks it's better.

For purposes of our discussion, if disinterested parties look at alternate versions of an image in the setting and size for which they are intended, without being told which version is which, and 90% or more pick one version as being better, I conclude that that version is better. If the vote is not as decisive I conclude that it's a matter of taste.

It doesn't take a really big difference to trigger a vote for "better". In PP4E I described a test where a jury was given numbered originals produced by each of three models of high-end scanner. In most cases the versions were hard to tell apart without careful examination, yet in many cases the vote was unanimous as to which of the three was best, including the one shown as Figure 15.3.

I would say that if there's a finding of "better" it would probably be true in all contexts, so I don't think we need to be specific about what type of print is needed.

Dan Margulis

___________________________________________________________________________

From: Steve Fuller

Date: Sat Jan 14, 2006 11:22 am

Subject: Re: Call for 16-bit example

I am new to this forum and I received via another route the apparent lead message in this thread. While I have many years of photography under my belt, I am primarily a scientist and professor. Mr. Margulis' post defies logic. How can one posit an apparently logical scientific question and then place rules that effectively rule out logic and place the "proof" solely on the subjective view of one individual?

The logical mathematical treatment is trivial as is the practical demonstration of its truth. I have readily demonstrated with four slider moves on PS CS2 in 8 bit and 16 bit versions of the same image that the difference in results is apparent to anyone anywhere.

Then, on reading the "rules", there are many subjective criteria that can be pulled from his hat to invalidate the practical demonstration of the truth of the logic virtually at whim. I dare say that many of the well known Ansel Adams images could not have been printed if he had been confined to the equivalent of a truncated 8 bit processing range.

Why does anyone waste their time tilting at this windmill? Why not add to the volume of knowledge instead of the volume of mythology?

Regards,

Steve Fuller

___________________________________________________________________________

From: onno de jong

Date: Sat Jan 14, 2006 10:36 am

Subject: Re: [colortheory] Call for 16-bit example

Dan,

This is a general comment from having read an old copy of your professional photoshop (I think during the time of Photoshop version 5, possibly two or more versions behind the current one, and of currently working though your canyon book)

You seem to paint yourself into a comfortable box, which is fine, and works for you. There are reasons to work in 16 bit in the creation and retouching of an image (not that I always use them or necessarily swear by them).

1) as I work on retouching images for advertising, there is preciously little that is still virgin photograph. I control the entire image, often reconstructing much of it, with tools that work fine in 8 bit, but at times provide me with more flexibility in 16 while I am working. Do you consider this a computer generated image? I obviously go well beyond optimizing an image for print.

Printing is another matter, and once I finish I concur with you entirely. The bandwidth of printing is so narrow that the strategy of how to make each bit look good far outshines whatever nuanced color information you might have gained).

2) with increase in processor speed, it really will not matter for very much longer. Ten years from now, who cares.

Otherwise, I am greatly indebted to your having sharing your knowledge with me, and thank you for it,

onno de jong

___________________________________________________________________________

Date: Sat, 14 Jan 2006 08:56:12 EST

From: Dan Margulis

Subject: Re: Call for 16-bit example

Mark Segal writes,

There are a couple of problems with your rules. What is your definition of

an ultra-wide gamut RGB?

Anything significantly wider in gamut than Adobe RGB.

Does ProPhoto fit that definition?

Yes.

It has been claimed that 16 bit depth is preferable to 8 bit depth in such

a colour space in order to mitigate banding and posterization risk (more

levels relative to the space size).

Not relevant for my purposes, as I categorically recommend against major edits in such spaces.

So if you rule out the one editing context where 16 bit may show some

superiority, it would seem that the rules pre-determine the result.

AFAIK it is not conceded that this is correct. It appears that some 16-bit advocates now admit that there is no superiority even in a wide gamut space like Adobe RGB, but some are still insisting that there's a night and day difference when last I checked. I agree that, since we have had so many trials in the past, it is unlikely at this point that any image meeting the test's specifications will emerge showing 16-bit superiority.

Secondly, I am confused about item (4) below. A professional DSLR (e.g. a

1Ds) acquires images in 12 bit (4096 levels) - not 8, not 16. In Camera Raw,

one then has the choice to convert them into 8 or 16 bit for further processing

in Photoshop. So this first decision about bit depth is made at the Camera

Raw stage, not the Photoshop stage, and either choice differs from the bit depth

the RAW file contains. Anyone using a RAW converter would make the 8 versus

16 decision once and for all at the raw conversion stage, and not tinker with

it thereafter in Photoshop except at the end of the adjustment process for

printing or web output - if even then in the case of printing. Hence what you say

in item (4) below does not reflect this reality and makes it very unclear what

workflow process qualifies or disqualifies for sending you samples.

The starting point is one (1) 16-bit Photoshop file. How it got there is no concern of ours except that one is not permitted to sabotage the acquisition process by, say, grossly darkening the image before opening it in Photoshop.

The test is to be performed on both the 16-bit file and on a file produced by immediately converting the 16-bit file to 8-bit *in Photoshop*. 8-bit files that have been converted to 8-bit in any other fashion are excluded.

Dan Margulis

___________________________________________________________________________

Date: Sat, 14 Jan 2006 14:31:12 EST

From: Dan Margulis

Subject: Re: Call for 16-bit example

Francis Corvin writes,

In order for the 8 v. 16 bit debate to be fruitful, it should be

established that the additional 8 bits do effectively contain useful

information --- significantly more than noise. Is this now an

accepted point, or is there still some debate on this?

A very good question. There has been little discussion of the point. The 16-bit advocates, who tend to be buffaloed by numbers, never really consider the possibility that the extra numbers are meaningless.

Cameras are more accurate in certain regions than in others. I believe that the midrange of the green channel contains more than 8 bits of useful information. However, in the areas that are always cited as those where 16-bit correction has an advantage, skies and deep shadows, I think it's obvious that not even the first 8 bits are accurate, and the extra bits are nothing but random numbers, noise. I have suggested that this noise can have a beneficial effect in certain cases.

Dan Margulis

___________________________________________________________________________

Date: Sat, 14 Jan 2006 19:12:34 -0000

From: "colorman042000"

Subject: Re: Call for 16-bit example

Hi Ron,

Allow me to disagree with you.

--- In Ron Kelly wrote:

You've overlooked one point, however: how is *better* determined? I

don't see that you've addressed this point specifically, and maybe

you feel it's implied.

It has to be printed. It has to show up on the page, and not just be

something visible on the screen.

1- If it is visible on the screen then it is significant because it *exists*...! It might not be printable by to-day's technology but it might be by next month's new Super Epson Printer. It might not show up under certain printing conditions and it might show up under others.

We can see all kinds of insignificant "detail" in scans and digital

files that make no difference in the final print. Conclusion -

insignificant detail is insignificant.

2- I have generally seen the opposite, I have seen details that I could not *readily* see on the screen show up on prints. How do you define *insignificant details* ?

So whether it's inkjet, lightjet, or some kind of off-set, it

doesn't matter. On screen - not a definitive example.

I would therefore add the proviso that any improvement in 8 vs. 16

bits should have to show up *in printed form* to be considered real

and conclusive.

3- Unrealistic condition. Nobody has the time and/or the energy to test for all the conditions where a significant detail that is visible on the screen would (or would not) appear with significance under certain printing conditions.

Andre Dumas

___________________________________________________________________________

Date: Sat, 14 Jan 2006 13:09:58 -0500 (EST)

From: MARK SEGAL

Subject: Re: Call for 16-bit example

Dan,

Thanks for the clarifications. I now understand the rules and with that understanding I now know that I should definitely not participate in this exercise because the workflow specifications are of no interest to me.

Firstly, my own results indicate that IN PRACTICE there is generally nothing wrong with editing in Pro Photo colour space (and along with it in 16 bit mode); as well it insures that the printer will deliver everything it can. There is wisdom in being pragmatic about the choice of colour space, using ProPhoto unless problems occur that nothing else but reversion to ARGB98 corrects. That happens, but infrequently.

Secondly, the idea of taking a 12 bit RAW file, opening it in 16 bit, then reconverting it back to 8 bit before image editing seems like a circuitous procedure when Camera Raw allows one to open the same file in 8 bit then go back to the same RAW file and re-open it in 16 bit, then work each of those files. This way one preserves the integrity of normal workflows that start from a RAW file in ACR and convert directly to the mode one would use for image editing. I don't see the point of testing a workflow one normally wouldn't adopt.

Mark Segal

___________________________________________________________________________

Date: Sat, 14 Jan 2006 15:44:10 -0400

From: Lee Clawson

Subject: Re: Re: Call for 16-bit example

on 1/14/06 12:22 PM, Steve wrote:

Mr. Margulis' post defies logic. How can one posit an apparently logical

scientific question and then place rules that effectively rule out logic and

place the "proof" solely on the subjective view of one individual?

Steve,

There's much background to the simple intro when Dan says....

I don't wish to reopen discussion on a very sore topic, but in preparation

for the next edition of Professional Photoshop, I feel I must ask if anyone

can produce a real-world color photograph where 16-bit correction is

demonstrably better than the same corrections in 8-bit. If such an example

exists, I will make room for it in the book.

I don't know how this can work either. Do you have concepts that can help

make this more objective ???

I was dismayed ( a mild expression for what I'd like to say) when I saw this

thread begin again. You check our archives and see what's been going on

since the end of August 2005 (Andrew Rodney's posts restarted the thread)

through November 15.

Lee Clawson

2/\V/\7 Studio

___________________________________________________________________________

Date: Sat, 14 Jan 2006 16:42:58 -0600

From: "Steve Fuller"

Subject: RE: Call for 16-bit example

RE:

The test is to be performed on both the 16-bit file and on a file produced by

immediately converting the 16-bit file to 8-bit *in Photoshop*. 8-bit files

that have been converted to 8-bit in any other fashion are excluded.

Dan Margulis

Does this imply that when Photoshop converts 16 bit to 8 bit that it dithers

the LSB? Or does it truncate at the LSB? This is an important distinction.

Regards,

Steve Fuller

___________________________________________________________________________

Date: Sat, 14 Jan 2006 15:13:03 -0800

From: Marco Ugolini

Subject: Re: Call for 16-bit example

In a message dated 1/14/06 9:09 AM, J Walton wrote:

...the monitor is an intermediate step, that's all.

I don't wish to be pedantic, but that is not "all". There is more. For the sake of accuracy, one has to remember that, no matter how often it does prove otherwise valid, this statement is not *universally* valid. For one, in virtual proofing the monitor is *the* point of decision. It's not intermediate.

Let's not forget the context of this conversation. It is not about color or

contrast or saturation or the quality of monitors these days.

It became a discussion on the use of monitor displays when Ron Kelly stated that a file "has to be printed. It has to show up on the page, and not just be something visible on the screen" (message of Jan. 13, 2006).

It is about 16-bit editing and whether or not results on a monitor should be

included in a discussion on the superiority of one over the other.

My point is that, if one uses a properly prepared and competently run system, the 8-bit-vs-16-bit comparison *can* be made effectively using a monitor display (except for the colors that exceed the monitor's gamut: but that is a different issue).

Virtual proofing does show that what things look like on a monitor is

becoming increasingly important, but does not relate to our 16-bit

discussion right now.

I respect that as *your* opinion, with which I respectfully disagree.

No one at Time is evaluating the difference between 8-bit and 16-bit edits on

screen.

Do you know of anyone there who has done it and concluded it was pointless?

Regards.

--------------

Marco Ugolini

Mill Valley, CA

___________________________________________________________________________

Date: Sat, 14 Jan 2006 21:34:25 -0000

From: "colorman042000"

Subject: Re: Call for 16-bit example

Hello Steve,

Next week our magazine is going to the printers, the quality of our images has to be better than in the last issue and when it hits the street I will wait with some apprehension about the comments of our editor and the feedback from our advertising director.

This 16 bit affair means a lot more work, more copies of my files, more disk space etc..., but I do it "just in case" the image will turn out to be better and the editor will be proud of my work. That's important to me.

Right now, and "just in case", I do sizing, cropping, straightening and sharpening in 16 bit, sometimes I also do most of my color correction also in 16 bit and when necessary I keep an extra copy of everything in 16 bit, "just in case" I need to start over with the image.

As far as *I* am concerned, what Dan Margulis is trying to determine is the very opposite of mythology or any imaginary demonstration of scientific facts, it is simply this: is it worth my time and energy to go through all this extra work and will it make a detectable difference in the final output of our magazine. Yes or No? His *real world* findings on the subject are important to me.

I haven't seen your demonstration nor have I seen any *evidence* anywhere that "the difference in results is apparent to anyone anywhere" as you claim. Would you be willing to supply this evidence so I may benefit from your knowledge. In some circles it is appropriate to pontify on scientific evidence, but in my case, I'm more worried about how my images will print and if you can show me some actual proof of your findings I will be grateful to you for freeing me from always having to ask myself if doing things in 16 bit is worth it or not.

Andre Dumas

___________________________________________________________________________

Date: Sun, 15 Jan 2006 00:46:32 -0800

From: J Walton

Subject: Re: Call for 16-bit example

On 1/14/06, Marco Ugolini wrote:

the monitor is an intermediate step, that's all.

I don't wish to be pedantic, but that is not "all". There is more.

Marco, you should be ashamed of yourself. To clip a direct quote and thereby distort its meaning is entirely unfair and inappropriate. I normally rather enjoy reading your posts. You can do better than that.

For the

sake of accuracy, one has to remember that, no matter how often it does

prove otherwise valid, this statement is not *universally* valid.

That doesn't make any sense.

For one, in virtual proofing the monitor is *the* point of decision. It's not intermediate.

If the monitor is one of several steps on the way to a final destination (a magazine), that's called intermediate. Just because you want to focus on step 4 of 15 doesn't make step 4 the finish line.

It became a discussion on the use of monitor displays when Ron Kelly stated

that a file "has to be printed. It has to show up on the page, and not just

be something visible on the screen" (message of Jan. 13, 2006).

It became a discussion on the use of monitor displays to evaluate the difference between 8-bit and 16-bit corrections. It got to be about monitors and Time magazine and virtual proofing a bit later.

My point is that, if one uses a properly prepared and competently run

system, the 8-bit-vs-16-bit comparison *can* be made effectively using a

monitor display (except for the colors that exceed the monitor's gamut:

but that is a different issue).

Funny thing, I agree with you on this. I'm not sure how we got to circling around a point we agree on but somehow it has taken place. I don't think it's necessary to spit out a proof to see the difference, *provided* you are experienced enough to know what something on a monitor is going to look like on press.

Virtual proofing does show that what things look like on a monitor is

becoming increasingly important, but does not relate to our 16-bit

discussion right now.

I respect that as *your* opinion, with which I respectfully disagree.

Fair enough.

No one at Time is evaluating the difference between 8-bit and 16-bit edits

on screen.

Do you know of anyone there who has done it and concluded it was

pointless?

I assume by that question that you believe that part of the virtual proofing strategy at Time magazine is to identify files on-screen that were corrected in either 8 or 16-bit. Unless you are just being difficult.

Regards.

Yeah, yeah, yeah, we'll be friends again in no time. : -)

J Walton

___________________________________________________________________________

Date: Sun, 15 Jan 2006 11:33:13 -0000

From: "Stephen Marsh"

Subject: Re: Call for 16-bit example

Steve Fuller writes:

Does this imply that when Photoshop converts 16 bit to 8 bit that it dithers

the LSB? Or does it truncate at the LSB? This is an important distinction.

Not sure on LSB Steve (LHS, HSB), but yes, inside Photoshop (not sure on ACR) - there is dither introduced in the bit depth conversion from high to low. More on this smart dither can be found in this archived thread:

ledet.com/margulis/ACT_postings/ACT-Banding-16%20bit-8-bit.html

For more on the long and hot debate on Dan's 16bit challenge, follow these two archives:

ledet.com/margulis/ACT_postings/ACT-8-bit-16-bit.html

ledet.com/margulis/ACT_postings/ColorCorrection/ACT-16-bit-2002.htm

The questions being raised here are good ones: Does the 8bpc channel RAW export contain dither, or not? Or do we have to take a high bit processed ACR file into Photoshop and convert to 8bpc to get this minor but valuable random noise? Does it matter?

This can be answered by running a 16bpc > 8bpc converted lossless compressed processed image from ACR inside Photoshop through an app that can show such info (not Photoshop). Then one would compare the same ACR settings/file processed directly inside ACR as 8bpc and measure that file. If one contains dither and the other does not then this will be evident by comparing the files.

With luck somebody can say if ACR does indeed use dither, but I am guessing that this may need to be tested as I have never heard this mentioned before and I would think that I would remember.

You raise an important point Steve, in that the realistic workflow for most users who do only require 8bpc output from ACR would simply select the 8bpc option inside camera raw, rather than processing into high bit and then dumbing it down directly afterwards inside Photoshop on the processed data that came out of ACR. Do these users miss out on dither? Does it matter? We can introduce dither with a colour mode change while retaining bit depth, but this seems less ideal than the high to low bit depth switch.

I can't speak for Dan, but perhaps he is not looking to make things more complex than they currently are. By ruling out ACR 8bpc generated files and only Photoshop 8bpc files from 16bpc this makes testing easier. This is not to say that the questions here are not valid, it would be good to know if ACR adds dither to 8bpc processed images, but this ACR variable has never been a part of Dan's testing to this date that I know of.

Stephen Marsh.

___________________________________________________________________________

Date: Sun, 15 Jan 2006 11:50:36 EST

From: Dan Margulis

Subject: Re: Call for 16-bit example

Onno writes,

You seem to paint yourself into a comfortable box, which is fine, and

works for you. There are reasons to work in 16 bit in the creation

and retouching of an image (not that I always use them or necessarily

swear by them).

I am certainly willing to be persuaded of this, but not by words, only by images.

as I work on retouching images for advertising, there is

preciously little that is still virgin photograph. I control the

entire image, often reconstructing much of it, with tools that work

fine in 8 bit, but at times provide me with more flexibility in 16

while I am working. Do you consider this a computer generated

image? I obviously go well beyond optimizing an image for print.

If you are introducing gradients, or vector graphics, or filtering the image so savagely that it loses its essential character as a photograph, then I'd consider it a computer-generated graphic. If you are just doing heavy-duty retouching, then I have not been able to verify a benefit from using 16-bit, so if you can show a side-by-side comparison that demonstrates the superiority, I'd be very happy to look at it.

Dan Margulis

___________________________________________________________________________

Date: Sun, 15 Jan 2006 11:53:13 EST

From: Dan Margulis

Subject: Re: Re: Call for 16-bit example

Steve Fuller writes,

While I have many years of photography

under my belt, I am primarily a scientist and professor. Mr.

Margulis' post defies logic.

Yes, it must certainly seem illogical to a scientist that a hypothesis claiming that a certain result can be achieved with real-world images and methodologies should be tested with real-world images and methodologies rather than with theoretical constructs. What an unscientific concept!

As for being a professor, things must have changed since I was in school. Back then, when a scientist put forward a hypothesis, it was not up to everyone else to prove it wrong, but rather it was up to him to prove himself right. The reasons for this rule were that a) it prevented a lot of stupid hypotheses by people who didn't understand their field, and b) it was thought in those ancient times to be difficult to prove negatives. I do not know why all this has changed.

The logical mathematical treatment is trivial as is the practical

demonstration of its truth. I have readily demonstrated with four

slider moves on PS CS2 in 8 bit and 16 bit versions of the same image

that the difference in results is apparent to anyone anywhere.

Let me guess, professor. It's a gradient, right? Or else some other distraction that you are going to claim proves by analogy what must happen in the real world? Surely you are aware that many top experts have spent weeks working with real images under real conditions trying to find this superiority that you say is there, and nobody has been able to. If you find it so easy to make this demonstration with a real image, what's so hard about sharing it with the rest of us?

Then, on reading the "rules", there are many subjective criteria that

can be pulled from his hat to invalidate the practical demonstration

of the truth of the logic virtually at whim.

A bit premature, wouldn't you say, professor? You haven't actually said that you have an image that *you* think meets the rules.

If you don't claim to have this kind of image--and AFAIK, nobody in the world currently claims to have one--then grousing about the subjectivity of the rules is irrelevant, an obvious effort to divert attention from the fact that your belief is religious and not intellectual in nature.

If you are saying that you do have such an image, but that I can't be trusted to evaluate it, there's an easy solution. A number of people on this list have spent a good deal of time studying this subject, and are quite independent of me. Why don't we have one of them, or maybe a group of three of them, examine your image to see whether *they* think it meets the test conditions? Jim Rich, for example, is a world-renowned expert of unquestioned probity. Why not let *him* see what you've got?

Why does anyone waste their time tilting at this windmill? Why not add to

the volume of knowledge instead of the volume of mythology?

This is the typical response of an academic who knows that he doesn't have the goods. Your hypothesis predicts one result. All experimental evidence to date, and there's a lot of it, shows another. But the new academic method, as I understand it, goes like this:

1) I have a hypothesis that involves how real-world images will behave in real-world circumstances.

2) I am not obliged to test my hypothesis by direct experimentation with the category of images that it is supposed to apply to, because my hypothesis is obviously correct and can be proven by analogy.

3) Any experimental evidence casting doubt on my hypothesis is irrelevant, because my hypothesis is so obviously correct that no amount of contrary evidence can disprove it.

Actually, now that I think of it, it isn't so new in academe--I believe it was common doctrine 500 years ago. Come to think of it, professor, how *would* you deal with someone who assures you that the world is flat, says that its flatness is too obvious to require any proof, and says that no amount of contrary evidence can ever disprove it?

Meanwhile, do let us know if you come up with a real-world color photograph, with real-world corrections, that you believe meets the stated requirements. You say it's trivial--now back it up.

Dan Margulis

___________________________________________________________________________

Date: Sun, 15 Jan 2006 08:19:29 -0600

From: "Steve Fuller"

Subject: RE: Re: Call for 16-bit example

Stephen Marsh wrote:

Not sure on LSB Steve (LHS, HSB), but yes, inside Photoshop (not sure

on ACR) - there is dither introduced in the bit depth conversion from

high to low.

If dither is being introduced by Photoshop then the 8 bit file converted in Photoshop from the 16 bit file does contain more information than a file converted to 8 bit in an application that truncates. That means that, per the "rules", the test will be done on a file "better" than a truncated file. Is it that last few dB of dynamic range that makes Dan's hypothesis viable much of the time? Entirely possible.

As to Andre's comments, I think it is likely that most of the commercial photography being done by experienced professional photographers for "routine" work will not suffer appreciably from being tweaked in 8 bit. If, however, you are trying to make a gallery print that requires tweaking where you will move the otherwise hidden shadow detail to where it can be seen, then use 16 bit editing.

There is a test that you can run yourself to see if there is important detail in the lower bits. Turn on the 16 bit mode in the Photoshop "Info" tab. In an untweaked file you will probably see some highlights between 16,000 and 32,000. That says you are using the high bits. Now, if you see detail below 255, then you will know you are using the lower 8 bits. If that detail is important to you then you must edit in 16 bit mode. I have done this and there is detail and not noise in my D2X raw files.

The whole thing boils down to you, your photo and its intended purpose, not an inflexible workflow or someone else's rule.

Regards,

Steve Fuller

___________________________________________________________________________

Date: Sun, 15 Jan 2006 11:35:59 -0800 (PST)

From: Mike Bevans

Subject: RE: Re: Call for 16-bit example

As much as I fear entering into religious debates, here I go... I have not found the grail. I have yet to see a difference between 16 bit and 8 bit images... that is not to say it does not exist, I just haven't seen it yet, even with extensive editing.

I have seen what happens to an image when you have less than 8 bits.

Working with a look-up table converter, I tried lower bit depths in order to save space and speed up processing. I used an image with a lot of sky in the shot to test results. 7 bits is okay, with very slight posterization in the sky. Certaily not acceptable for professional photographers, but for consumer applications it was passable. The lower the bit depth gets, the more posetrization with 5 bits making very crunchy images.

From this, one could hypothesize that the greater the bit depth, the lower the risk of posterization in gradients.

From my experience 8 bits is the magic number, but based on the above hypothesis, 16 bits would be better, at least theoretically. As has been mentioned in this discussion and the previous debates, 16 bits per channel used to be daunting from a storage and RAM standpoint, but now and days it is less of an issue.

It would still be nice to have a true believer present a sample shot demonstrating the visual superiority of 16 bit images. It would finally put this discussion to rest.

-Mike Bevans

www.tribecalabs.com

___________________________________________________________________________

Date: Mon, 16 Jan 2006 11:48:19 +0300

From: Vladimir Yelisseyev

Subject: Re: Call for 16-bit example

Dan Margulis wrote:

The following types of images are not of interest.

3) Images worked in an exotic colorspace definition, such as a nonstandard

gamma, or an ultra-wide gamut RGB.

Dan,

does that also include LAB?

Vladimir Yelisseyev

___________________________________________________________________________

Date: Mon, 16 Jan 2006 09:28:39 -0600

From: "Steve Fuller"

Subject: RE: Re: Call for 16-bit example

Dan Margulis writes;

Yes, it must certainly seem illogical to a scientist that a hypothesis

claiming that a certain result can be achieved with real-world images and

methodologies should be tested with real-world images and methodologies

rather than with theoretical constructs. What an unscientific concept!

Your "real-world images" seems to be defined as a capricious, arbitrary and time variant SUBSET of REAL WORLD IMAGES. Do not real world images include gallery exhibition images? It does not seem "unscientific" to use simple math to disprove an hypothesis or to be the basis for a demonstration of the fact that math works in the real world.

As for being a professor, things must have changed since I was in school.

Back then, when a scientist put forward a hypothesis, it was not up to

everyone else to prove it wrong, but rather it was up to him to prove himself

right.

Exactly! Thank you! I think we all eagerly await your proof of your hypothesis.

Let me guess, professor. It's a gradient, right?

Do not the great preponderance of commercial photographic images in the "real-world" depend almost exclusively on gradients of light and color? (It was not a non-linear gradient process that I used for demonstration.)

A bit premature, wouldn't you say, professor? You haven't actually said

that you have an image that *you* think meets the rules.

If I said I had an image that meets the rules it would be based on a subjective decision of mine since the rules are not precise and are predicated on your subjective views of the image and the process.

This is the typical response of an academic who knows that he doesn't have

the goods. Your hypothesis predicts one result.

Have I made an hypothesis? I think not. I have "predicted" nothing.

1) I have a hypothesis that involves how real-world images will behave

in real-world circumstances.

2) I am not obliged to test my hypothesis by direct experimentation with

the category of images that it is supposed to apply to, because my

hypothesis

is obviously correct and can be proven by analogy.

3) Any experimental evidence casting doubt on my hypothesis is

irrelevant, because my hypothesis is so obviously correct that no amount of

contrary evidence can disprove it.

One bit shy of truth.

Regards,

Steve Fuller

___________________________________________________________________________

Date: Mon, 16 Jan 2006 11:00:27 -0600

From: "Sabo, Lori"

Subject: Re: Call for 16-bit example

Just curious, does the same thing hold true for hi-res digital scanning backs (like Betterlight for a 4x5 camera), which although usually used for reproduction of artworks, can and have been also used for creating digital photographs as well? Certainly there is some noise, different types depending on what iso and scan-line-time you set up and I suppose whether it is a newer more sensitive sensor model. I suppose the useful-bitness would be similar to a regular digital camera?

Lori Sabo

___________________________________________________________________________

Date: Mon, 16 Jan 2006 17:13:54 +0000

From: Francis Corvin

Subject: Re: Re: Call for 16-bit example

For one-pass scans, probably. Multiple-pass scans would add useful bits (e.g., 2 passes=1 bit; 8 passes=3 bit). However, this depends very how the averaging is done.

Regards,

Francois Corvin

___________________________________________________________________________

Date: Mon, 16 Jan 2006 10:14:05 -0800

From: "Paul D. DeRocco"

Subject: RE: Re: Call for 16-bit example

Actually, it's a square root function, so four passes adds one bit, and 16 passes adds two.

Ciao, Paul D. DeRocco

___________________________________________________________________________

Date: Mon, 16 Jan 2006 17:34:44 -0800

From: "marty"

Subject: RE: Directions to look for 16 bit samples

I too think the idea that 16 bits buys any significant advantage is way overstated. However, I think people are looking in the wrong places for examples. It's not the low luminance areas.

The most likely scenes to exhibit real differences between 16 bit and 8 bit images are ones showing high luminance with lots of smooth gradients. Snowdrifts in a winter scene come to mind where the highlight detail is enhanced. Sensor noise is far lower than the 8 bit digitization error since at high exposure levels there is effectively only 7 bits of data in the aRGB98 8 encoded bits and in 16 bit linear space the sensor rms error is around .2% of full scale at ISO 100 on a 1DsII.

Now, if only I didn't live in SoCal.

Martin Gray

___________________________________________________________________________

Date: Mon, 16 Jan 2006 21:12:10 -0600

From: "Howard Smith"

Subject: Re: Re: Call for 16-bit example

Steve, this has been a fascinating discussion, but I fear I've lost the point you're trying to make. Still, not being a professor I'm not as interested in theoretical considerations as in practical results. Your question about real world images leads me to suspect that you either have some of these real world images with which to establish the superiority of 16-bit editing over 8-bit, or that you have access to such images. Disregarding Dan's limits for the moment, could you please post some samples of these images so all of those non-theoreticians among us can see for ourselves? As no self-respecting mad scientist ever accepts a claim that anything is impossible, I'm genuinely intrigued by your arguments. If you can, indeed, establish the superiority of 16-bit image editing with images that artists and photographers are likely to encounter in their own real world, this would be a very interesting demonstration. So far no one seems to have been able to do this other than with the kinds of images that are so unique that most of us would have little to gain from routinely using 16-bit images just in case we encounter one of these rare examples. If, on the other hand, you are arguing for the sake of argument with little concern for the practical applications, let the arguments continue and never mind the images.

Howard Smith

___________________________________________________________________________

Date: Mon, 16 Jan 2006 22:22:13 -0500 (EST)

From: MARK SEGAL

Subject: RE: Directions to look for 16 bit samples

How does the statement below cohere with the fact that the 1Ds MkII captures 12 bit data, not 16?

Mark Segal

marty wrote:

Sensor noise is far lower than the 8 bit digitization error since at high exposure levels there is effectively only 7 bits of data in the aRGB98 8 encoded bits and in 16 bit linear space the sensor rms error is around .2% of full scale at ISO 100 on a 1DsII.

___________________________________________________________________________

Date: Mon, 16 Jan 2006 20:58:55 -0800

From: "marty"

Subject: RE: Directions to look for 16 bit samples

When the RAW file (12 bit linear samples) is converted to, say, Adobe 16 bit, the matrix math combined with Bayer interpolation creates samples that are actually 16 bits, not 12. One can even run a histogram of these and get fairly large bucket fills. Of course the information content isn't increased so one shouldn't be deceived by the histogram. The bottom 4 bits are almost, but not entirely, noise. This is further mangled by Gamma compression. Most understand that "16 bits" is the resolution of the colorspace, not actual information.

Marty gray

___________________________________________________________________________

Date: Tue, 17 Jan 2006 07:09:50 -0500

From: "Iliah Borg"

Subject: Re: Directions to look for 16 bit samples

Dear Marty,

Samples are not always 12 bit, they can be as low as 7 bit and as high as 16 bit. In some 12-bit cameras first 128 levels are stripped to get rid of noise. In some 12-bit cameras lossy compression via LUT is used, and raw data contains less then 700 levels. In some the highest level is 3700 instead of 4095. In some it is only about 2000.

In its simplest form white balancing is multiplication of linear raw data. Typically this can be up to 4 times on individual channel. Exposure compensation during conversion involves another multiplication, up o 8 times. Demosaicing does not add to the data length usually, unless a channel is blown out. In that case it can add 1 or 2 bits, depending on implementation. So worst case we can end up with 22..23 bits of data.

Last 4 bits are not necessary noise only, it depends on the exposure, camera hardware, and white balance.

Best regards,

Iliah Borg

___________________________________________________________________________

Date: Tue, 17 Jan 2006 11:58:47 +0000

From: Francis Corvin

Subject: RE: Directions to look for 16 bit samples

That's why I asked earlier whether the debate on the amount of useful bits has been closed: for instance, the interpolation of the Bayer patterns causes 2/3 of the image to be an artificially generated gradient of some sort, in one channel or another. Therefore, would it pass the test of acceptability?

And that's before we start talking about moire filters at the front-end and noise reduction at the back-end. ..

Regards,

Francis

___________________________________________________________________________

Date: Tue, 17 Jan 2006 09:28:18 EST

From: Dan Margulis

Subject: Re: Re: Call for 16-bit example

Lori writes,

Just curious, does the same thing hold true for hi-res digital scanning

backs (like Betterlight for a 4x5 camera), which although usually used

for reproduction of artworks, can and have been also used for creating

digital photographs as well? Certainly there is some noise, different

types depending on what iso and scan-line-time you set up and I suppose

whether it is a newer more sensitive sensor model. I suppose the

useful-bitness would be similar to a regular digital camera?

I can speak to the issue of skies because I have been working with a lot of them this week, from a variety of different cameras. When dealing with what we might call "a clear blue sky," the performance in the red channel, which is the critical one, is uniformly atrocious across all models I've tested. It's not bad enough to show under most output conditions provided little manipulation is done to the picture, but it's plenty bad enough to require remedial action if you want to use it in, say, a blend.

I'm not going to name models because AFAIK the problem is everywhere. I will be showing a page of magnified sections of skies from two different (unnamed) current-model digicams. One is one of the most commonly named professional cameras on this list; the other is targeted at high-end consumers. The better camera's file is opened in Camera Raw and the lesser camera's file is a JPEG.

In all similar skies I've looked at closely, the green channel is reasonable. I do not believe, however, that it is accurate to 8 bits although it seems to be at least to 7. In the red channel of these skies, however, even the *fifth* bit is of questionable validity and the sixth even more dubious. The seventh and eighth bits are random numbers.

These comments apply to relatively flat areas of blue sky only.

Dan Margulis

___________________________________________________________________________

Date: Tue, 17 Jan 2006 10:42:58 -0500

From: "Iliah Borg”

Subject: Re: Re: Call for 16-bit example

Dear Dan,

In the red channel of these skies,

however, even the *fifth* bit is of questionable validity and the sixth

even more dubious. The seventh and eighth bits are random numbers.

But of course! Should we discuss why is it so?

Best regards,

Iliah Borg

___________________________________________________________________________

Date: Tue, 17 Jan 2006 09:19:46 EST

From: Dan Margulis

Subject: Re: Directions to look for 16 bit samples

Francis writes,

That's why I asked earlier whether the debate on the amount of useful

bits has been closed: for instance, the interpolation of the Bayer

patterns causes 2/3 of the image to be an artificially generated

gradient of some sort, in one channel or another. Therefore, would it

pass the test of acceptability?

Yes, it would. If that's the way the photograph is customarily captured and presented to the Photoshop operator, then it's a real-world image. The question is whether it can ever be advantageous to edit a real-world color photograph in 16-bit rather than 8-bit. In principle, how the digital file is acquired is not relevant. However, I would not accept as real-world an image that has been purposely sabotaged on acquisition by, for example, grossly darkening an image that is already too dark.

Dan Margulis

___________________________________________________________________________

Date: Tue, 17 Jan 2006 11:33:16 EST

From: Dan Margulis

Subject: Re: Call for 16-bit example

Vladimir writes,

Dan,

does that also include LAB?

LAB is not excluded by these rules, and yes, I believe a sufficiently skilled person like yourself can probably find an example where a legitimate (but incompetent) effort in LAB might provoke enough of a difference for someone to like the 16-bit version better than the 8-bit, as well as finding others where they'd like the 8-bit better than the 16-bit. Fortunately, the good folks on the other side are phobic about working in LAB, so they're unlikely to find the 16-bit example without your help.

Dan Margulis

___________________________________________________________________________

Date: Tue, 17 Jan 2006 09:22:17 -0800

From: David Cardinal

Subject: RE: Call for 16-bit example

At the risk of deforming the question in some way, the really nitty-gritty practical version of the question is for me (and many others):

"I spend a lot of time processing, sending off to editors, and printing Raw & JPEG images from my cameras. Life in 8-bits is quicker and takes less disk space. But if/when 16-bits will materially improve the quality of my product then I'm happy to use it. When & where do I need to use 16-bit in my workflow?"

In particular, images (and an accompanying workflow) which show when 16-bit edits make an output difference would be very helpful, especially if it was clear _why_ 16-bit made a difference in each case. Then photographers would have an idea when it was important and when it wasn't.

In my case the normal "decision point" is usually in ACR or Capture (or Bibble) when I decide whether to open the image into Adobe RGB (normaly I use 8-bit in that case) or Pro RGB (normally I use 16-bit for that). I realize that isn't the same as Dan's request, but in my personal case it happens to be where I make the decision currently. I make the decision mostly based on the colors in the image & the color histogram shape for each colorspace.

--David Cardinal

___________________________________________________________________________

Date: Tue, 17 Jan 2006 12:04:26 EST

From: Dan Margulis

Subject: Re: Re: Call for 16-bit example

Steve Fuller writes,

Your "real-world images" seems to be defined as a capricious, arbitrary and

time variant SUBSET of REAL WORLD IMAGES. Do not real world images include

gallery exhibition images?

The exact quotation is:

"The image(s) must be real-world color photograph(s). This means any photograph that could conceivably be used in any professional context. If it is a cropped piece of a larger photograph, the piece must be large enough that it could conceivably be used on its own."

I am sorry that it is so unclear. I meant the word "photograph" to mean something produced by a camera, which is a device that records an image by focusing light through a lens into a lightproof enclosure containing media capable of recording information. By using the word "photograph", I intended to exclude anything that is not produced by a camera, such as, for example, computer-generated gradients or paintings.

Similarly, I am sorry that you seem to find "any photograph that could conceivably be used in any professional context" to be so limiting. It seems pretty liberal to me.

It does not seem "unscientific" to use simple

math to disprove an hypothesis or to be the basis for a demonstration of the

fact that math works in the real world.

Hypotheses are neither proven nor disproven by math. Math can be used to formulate them or to suggest means of attacking them. The experimental results are what count. The entire history of science is filled with examples of theories where the propounder's math suggested one result but the reality was different. Whereupon, real scientists either revise their hypothesis or come up with new experimental data to support it.

Almost exactly five hundred years ago, the scientific community faced the same problem. People were beginning to measure and predict the positioning of the sun, but at certain times the sun inconveniently was not where the math predicted it to be. As these results were duplicated by more and more observers, real scientists began to wonder whether their math was incorrect, or perhaps was based on incorrect assumptions.

Eventually, they figured out what was wrong with the math, no thanks to the type of science that you seem to favor. If 16-bit advocates had been in charge at the time, they would have said, the math is perfect. As everyone knows the earth does not move in the heavens, a fact too obvious to either require proof or be susceptible to disproof, the experimental observations are irrelevant. The math demonstrates where the sun is even if the telescopes find it somewhere else. Eppur si muove.

Exactly! Thank you! I think we all eagerly await your proof of your

hypothesis.

Here we go again, with an attempt to shift the burden away from those who advocate the inconvenient workflow. It's not up to them to prove themselves right, but up to the rest of the world to prove them wrong!

Nobody can ever *disprove* that 16-bit is useful, any more than we can disprove the theory of intelligent design, or disprove a statement that carrying a lucky rabbit's foot cancels out the benefits of 16-bit editing. All we can say is that no evidence has yet been presented that 16-bit editing of color photographs does any good under any circumstances. I do not advocate that

anyone who is comfortable using 16-bit stop doing so.

Here, the assertion is that 16-bit editing of color photographs improves quality in comparison to the way things have been done for the last 25 years. Some people make modest claims of increased quality, but others use terms like "night and day difference", "totally obvious to anyone who looks" or, in referring to those who do not edit in 16-bit, "recreational, rather than professional users." As someone who writes about how to improve the quality of images, I have to field a lot of inquiries from baffled users as to why I am not writing about this method that produces the night-and-day, amateur vs. professional user difference.

All I can respond is that the people who are saying this refuse to back it up with images, and that I and others have tried very hard to produce the effects that they say are so pronounced, using exactly the type of images and methodologies they are talking about, and we get nothing of the kind even when we make corrections far more extreme than would ever be done in real life. And that the people who advocate this workflow offer no real backup, only theories using math that they don't understand, and when challenged they resort to lame excuses and ad hominem attacks to try to cover up the fact that they have no images to show.

My original post was simply due diligence. After six years of this silly debate, I think it's unlikely that any real-world color photograph will ever be produced that clearly shows a benefit for 16-bit rather than 8-bit editing. But I ask the question, and make the offer to print it, just in case somebody can pull such an example out of their hat. I am not expecting anyone to have such an image, and certainly you don't.

Do not the great preponderance of commercial photographic images in the

"real-world" depend almost exclusively on gradients of light and color?

In a manner of speaking, yes, and from that you are going to take the colossal and mathematically preposterous leap into saying that therefore operations on a *computer-generated* gradient will have the same effect as on a photograph. This is the same logic as saying that castor oil is a liquid, and since Château Lafite Rothschild is also a liquid and tastes good, it follows that castor oil must taste good as well. If you don't believe it, print out one of your gradients, take a photograph of it, and see how much good 16-bit does in editing it.

The claim of enormous 16-bit superiority is a claim aimed at real-world photographers and retouchers. It is not too much to ask that any demonstrations be done with real-world photography and not things that are claimed to be analogous.

I will be off-line for the next week, but in view of the fact that you have no images to offer, this exchange has ended AFAIC.

Dan Margulis

___________________________________________________________________________

Date: Tue, 17 Jan 2006 14:44:46 EST

From: Dan Margulis

Subject: Re: Re: Call for 16-bit example

Iliah writes,

Dear Dan,

In the red channel of these skies,

however, even the

*fifth* bit is of questionable validity and the sixth

even more dubious. The

seventh and eighth bits are random numbers.

But of course! Should we discuss why is it so?

By all means, but please remember, most list members aren't mathematicians, so try to keep the explanation simple.

However, it doesn't take much technical knowledge to understand the implications. Skies are the area most commonly cited (along with deep shadows) as being vulnerable to banding in 8-bit. The 16-bit proponents say this is because of the superior data in their files. However, as I pointed out, and Iliah, who is an expert, agrees, the data in the critical red channel of skies is very bad. The extra bits in this area of the 16-bit file are nothing but garbage--random numbers, pure noise.

It's conceivable that this noise may have a beneficial effect under certain extreme conditions, because noise is the enemy of banding. However, even if such an image exists, you wouldn't need a 16-bit file to get the benefit. There are lots of ways of adding fine noise--in extremis, you could convert an 8-bit file to 16-bit and get a lot of random noise in the extra bits pretty easily.

Dan Margulis

___________________________________________________________________________

Date: Tue, 17 Jan 2006 17:12:08 EST

From: Dan Margulis

Subject: Re: Directions to look for 16 bit samples

Marty Gray writes,

I too think the idea that 16 bits buys any significant advantage is way

overstated. However, I think people are looking in the wrong places for

examples. It's not the low luminance areas. The most likely scenes to exhibit

real differences between 16 bit and 8 bit images are ones showing high

luminance with lots of smooth gradients.

I agree that this is where any realistic difference is likely to show up. I was not able to produce any during my 2002 testing. However, I'll be revisiting this in the next few months as I have a long section (parts of three chapters) on highlight recovery and enhancement planned. I suspect that it will show that somewhat better highlight results can be gotten out of a carefully handled Camera Raw file than out of a JPEG, and I have the files to find out for sure. I will be doing these tests with 16-bit Camera Raw files, and if it turns out they do better than the JPEGs, then I'll rerun them in 8-bit Camera Raw and see how they compare.

Dan Margulis

___________________________________________________________________________

Date: Tue, 17 Jan 2006 17:33:50 EST

From: Dan Margulis

Subject: Re: Call for 16-bit example

David Cardinal writes,

In my case the normal "decision point" is usually in ACR or Capture (or

Bibble) when I decide whether to open the image into Adobe RGB (normaly I

use 8-bit in that case) or Pro RGB (normally I use 16-bit for that). I

realize that isn't the same as Dan's request, but in my personal case it

happens to be where I make the decision currently. I make the decision

mostly based on the colors in the image & the color histogram shape for each

colorspace.

Just to clarify a previous recommendation. As list members know, certain third-party capture modules (at least two of them) do not generate satisfactory 8-bit files. In at least one case, they convert their own 16-bit data to 8-bit by the idiotic expedient of chopping off the last 8 bits, which means that a value of 19.99 rounds to 19 rather than to 20, which can cause trouble down the line.

In view of these problems, I had previously suggested that, to be on the safe side, Raw users might wish to export in 16-bit and then convert to 8-bit at their leisure although I did not know for a fact that there was anything wrong with the way Raw makes its 8-bit files. Having done much more testing, I haven't been able to find any problem with exporting from Raw in 8-bit as David is doing.

Dan Margulis

___________________________________________________________________________

Date: Tue, 17 Jan 2006 21:54:40 -0400

From: Lee Clawson

Subject: Re: Call for 16-bit example

on 1/17/06 1:22 PM, David Cardinal wrote:

When & where do I need to use 16-bit in my workflow?"

David,

For me where and when comes after I'm satisfied that the test images have been printed and inspected (maybe even density measurements of any perceived differences) in a (book) printing plant using materials and techniques commonly available to anyone and under conditions that are repeatable.

In other words I want to see the results and differences, if any, and know that on my 4 color runs I'll get similar results. I'm more hesitant than you; for me the efficiency of workflow can wait.

Lee

___________________________________________________________________________

Date: Tue, 17 Jan 2006 20:40:38 -0600

From: "Steve Fuller"

Subject: RE: Call for 16-bit example

Dan Margulis wrote:

Just to clarify a previous recommendation. As list members know, certain

third-party capture modules (at least two of them) do not generate

satisfactory 8-bit files. In at least one case, they convert their own 16-bit data to 8-bit

by the idiotic expedient of chopping off the last 8 bits, which means that a

value of 19.99 rounds to 19 rather than to 20, which can cause trouble down

the line.

Just to avoid trouble down the line, there is no such thing in either the 16 bit or 8 bit image file systems as 19.99. The values actually used are integers, not floating point numbers (i.e. with decimal points). If you had a value of either 19 or 20 in a 16 bit file and changed the file to 8 bit the value would be 0 with three bits to spare since the number 20 uses only 5 of the lowest 8 bits. In the "real-world" there is no problem in changing such a low 16 bit value to 8 bit. It is simply black.

Regards,

Steve Fuller

___________________________________________________________________________

Date: Tue, 17 Jan 2006 23:00:27 -0500

From: "Iliah Borg"

Subject: noise in sky

I have a well-exposed RAW image taken with 1DsMkII opened on my computer.

It is a daylight scene, with accurate white balance, scene with sky, bed-sheets on a rope, closed shadows, taken at ISO 100.

For this kind of scene based on camera specifications one would expect the values in raw file to be 0..4095.

In fact, they run from 123 to 1999. Is it a 12-bit data? Not exactly. We have slightly less then 11 bits of data.

But are they actually data? I'm looking into deep shadows (door opened to the barn) where I can't extract any details whatever I try. Data variation in that area is from 0 to 17, so noise occupies about 4 bits. Histogram of that area is nothing but combs.

We end with 8 useful bits of data at most, or maybe only 7.

Let's have a look at channel data. Red varies from 123 to 1094, green - 123 to 1999, blue - 123 to 1572.

So, red contains about 6 bits of real data, given values of noise it has.

Next I need to apply white balance to that raw data.

Camera recorded white balance coefficients for the scene are 2.15, 0.93, 1.17. This is the weak red channel raw data will be multiplied 2 times, while green and blue will essentially stay. So underexposed and noisy red channel will be moved forward, making noise more visible, especially in smooth blue/green highlight areas, like sky.

Best regards,

Iliah Borg

___________________________________________________________________________

Date: Tue, 17 Jan 2006 23:08:15 EST

From: Dan Margulis

Subject: Re: Call for 16-bit example

Steve Fuller writes,

Just to avoid trouble down the line, there is no such thing in either the 16

bit or 8 bit image file systems as 19.99.

Reading this, I now know why Atlas shrugged.

The values actually used are

integers, not floating point numbers (i.e. with decimal points). If you had

a value of either 19 or 20 in a 16 bit file and changed the file to 8 bit

the value would be 0 with three bits to spare since the number 20 uses only

5 of the lowest 8 bits.

I beg to amend my previous statement as follows:

"In at least one case, they convert their own 16-bit data to 8-bit by the idiotic expedient of chopping off the last 8 bits, which means that a value known to Steve Fuller and five other people in the world as 0001001111111110, and to Michael Stokes and eight other people in the world as 13FE, and to the remaining population of the planet as 19.99, rounds to 00010011, or 13H, or 19 rather than to 00010100, or 14H, or 20, which can cause trouble down the line."

Dan Margulis

___________________________________________________________________________

Date: Wed, 18 Jan 2006 07:29:22 -0600

From: "Steve Fuller"

Subject: RE: Call for 16-bit example

Dan Margulis wrote:

I beg to amend my previous statement as follows:

"In at least one case, they convert their own 16-bit data to 8-bit by the

idiotic expedient of chopping off the last 8 bits, which means that a value

known to Steve Fuller and five other people in the world as 0001001111111110, and

to Michael Stokes and eight other people in the world as 13FE, and to the

remaining population of the planet as 19.99, rounds to 00010011, or 13H, or

19 rather than to 00010100, or 14H, or 20, which can cause trouble down the

line."

Please copy the binary number above (0001001111111110) and paste it into the

Microsoft Windows Calculator window and press the decimal conversion button

and you will read the number "5118", not 19.99.

Regards,

Steve Fuller

___________________________________________________________________________

Date: Wed, 18 Jan 2006 09:07:58 -0500

From: "Iliah Borg"

Subject: Re: Call for 16-bit example

Dear Steve,

Please copy the binary number above (0001001111111110)

and paste it into the

Microsoft Windows Calculator window and press the decimal

conversion button

and you will read the number "5118", not 19.99.

and if you divide by 256, it will be close to 19.99

Best regards,

Iliah Borg

___________________________________________________________________________

Date: Wed, 18 Jan 2006 10:38:27 -0800

From: "Paul D. DeRocco"

Subject: RE: Call for 16-bit example

From: Steve Fuller

Just to avoid trouble down the line, there is no such thing in either the 16

bit or 8 bit image file systems as 19.99. The values actually used are

integers, not floating point numbers (i.e. with decimal points). If you had

a value of either 19 or 20 in a 16 bit file and changed the file to 8 bit

the value would be 0 with three bits to spare since the number 20

uses only 5 of the lowest 8 bits. In the "real-world" there is no problem

in changing such a low 16 bit value to 8 bit. It is simply black.

He was conceptually treating the 16 bits as 8 integer and 8 fraction, so 19.99 would map to something like 0x13FD.

Ciao, Paul D. DeRocco

___________________________________________________________________________

Date: Wed, 18 Jan 2006 13:41:33 -0600

From: "Steve Fuller"

Subject: RE: Call for 16-bit example

Iliah Borg wrote:

and if you divide by 256, it will be close to 19.99

Indeed what you say is correct but that is not what Dan said. He said nothing about dividing by 256 but said that bit pattern was 19.99. That is why I have had trouble following his pronouncements. If we look at what happens or can happen in the conversion we will see that the fastest way to convert 16 bit to 8 bit is to do a logical shift. Cheap and easy. It is quite expensive to do division. I dare say that, when compared to division, that dither and a logical shift would be faster and cheaper. In neither case do we have division. In neither case do we have a number with a decimal place. In the latter we have a result to be desired. I think we would all agree that rounding per se is a poor substitute for dither. If we round we still have an expected quantization error of plus or minus one half count and if we truncate we have an expected error of plus or minus one half count. It takes dither to reduce that expected error below plus or minus a half count.

Regards,

Steve Fuller

___________________________________________________________________________

Date: Mon, 31 Oct 2005 14:07:03 -0000

From: Dan Margulis

Subject: 16- and 8-bit: Summing Up (Part 1 of 4)

Last month, it appeared that some the basics were finally being agreed upon as to some of the advantages or lack thereof in color-correcting 16-bit files vs. 8-bit files. This topic that has wasted far more time than it could possibly merit over the last half-decade. Because there was a lot of posturing that masked the essential agreement, I suggested that we stop the thread, and I promised that at a later time I would post a fuller response.

I'd like to start from scratch and explain what the basic principles are, why the debate went on so long, and what it teaches us for the future. I do not believe this is a topic significant enough for a magazine article, but this post is article-length, and is therefore divided into three parts plus an appendix. I intend this to be my last word on the subject until the next edition of Professional Photoshop, unless there are some new developments from images I am now studying.

DEFINITION.

A bit is the smallest addressable part of a computer's memory. It can be seen as either 0 or 1, either on or off, either yes or no. Each bit therefore has two possible states. Two bits taken as a pair have four possible states. Three bits have eight, four bits 16, and so on, with the number of possibilities doubling every time a bit is added.

Ever since the advent of digital color correction in the early 1980s, it has been standard to devote 8 bits of computer information to describe a single pixel in a single channel. This gives a total of 256 possibilities. In three-channel colorspaces like RGB, 24 bits (8x3) are required to fully define the pixel's color, meaning that there can be 16,777,216 (256x256x256) possible colors for a given pixel.

Nobody can see that many colors. Even the most optimistic estimates--and that's the side you find me on--say that humans can only perceive a little more than a million colors, and most experts put the figure considerably lower than that.

Nevertheless, some believe that it makes sense to try to define more colors. Some digital cameras try to record 10-bit (1,024 possible values per channel, a billion possible colors). Modern drum scanners try for 12-bit (4,096 values, 69 billion possible colors). Whether these devices are accurate to that level of precision is very doubtful.

In the mid-1990s, Photoshop introduced limited support for 16-bit files--65,536 values per channel, 281 trillion possible colors. There was no intermediate level. If you had a 10-bit file and wanted to get it into Photoshop, you had to decide whether to bloat it by making it 16-bit or compress it by making it 8-bit. Also, few important commands other than curves would work on a 16-bit file. We could not even make a layered file in 16-bit. As time went on more support was added, and today almost anything we can do in 8-bit we can do in 16-bit.

THE ISSUE.

The question before us is not whether to capture in 16-bit, store in 16-bit, or output in 16-bit. The only issue is, first, is there any advantage in *editing* files in 16-bit rather than 8-bit, and if there is, it is so enormous as to constitute a "night and day difference" or to justify the statement that anyone who does not edit in 16-bit is a "recreational, rather than professional" user of Photoshop.

16-bit files are twice as large as 8-bit files. They take longer to store and to back up and require more disk space. Also, if the file size is large, it may take Photoshop much longer to perform edits. Plus, most output devices and many layout programs won't accept 16-bit files, so we have to go to the trouble of converting them to 8-bit eventually anyway.

For some, this isn't an issue. They process a limited number of images in studio and, taking advantage of today's low prices, they have an infinite amount of storage space. For others, like newspaper photographers on deadline, doubling the file size would be so onerous as to be out of the question even if there was a undeniable quality gain associated with it. For everyone else, the doubled file size is an inconvenience to some degree. The question must be whether we gain any benefit, and if so, what, because it's possible we might want to use 16-bit some of the time and not others.

When someone advocates doing something inconvenient, whether converting to LAB, or using Camera Raw, or doubling one's file size, or putting 15 layers on a file, it's up to that person to make a compelling case for it. It isn't up to you, me, or anybody else to show that it's *wrong* to do it. The reason that the subject has refused to die is that the advocates of 16-bit editing claim exemption from this rule: they take the position that whatever they recommend, whether it's 16-bit editing or wearing garlic around the neck while writing curves, must be taken as gospel and that they have no responsibility to back up what they say.

AREAS WHERE EVERYONE AGREES.

Nobody AFAIK has ever doubted the following.

Extra bits are valuable in editing computer-generated graphics, especially those that include gradients, or with image areas that are so heavily retouched that they are essentially computer-generated as opposed to photographic.

Scanners, digital cameras, and Camera Raw all operate natively with more than eight bits. As there's no way to make them operate any other way, the question of whether they *could* operate effectively with fewer bits is irrelevant.

Certain scanners and certain camera software do not generate 8-bit files correctly. Therefore, where possible, these files should be brought into Photoshop in 16-bit, and converted to 8-bit at a later time.

Most people who handle lots of images have from time to time been burned because they failed to save a copy of the original, untouched image. People crop the image or rez it down only to discover that the extra information comes in handy a year later. The chances of a bug in Photoshop or the OS inadvertently damaging a file when it is resaved are extremely small, but they are not zero. That alone is a good reason to save a copy of the original 16-bit file.

16-bit does no real-world harm other than the extra space and computing time it requires.

THE INITIAL WILD CLAIMS.

While nobody has ever argued that people who are comfortable using 16-bit for correction should stop doing it, the same is emphatically not true of 8-bit users. Starting in 1999, a slew of self-appointed experts, largely but not exclusively Andrew Rodney and his business partners, began to attack anyone who didn't use 16-bit for *all* editing. The rhetoric they used was apocalyptic. Editing in 8-bit was "amateurish". It was "highly critical" to edit in 16-bit all the time. Those ignorant enough to edit in 8-bit proved themselves to be "recreational, rather than professional" users of Photoshop.

Early on, a number of users questioned this, stating that they had compared the two approaches found little difference in the results. Instead of accepting the possibility that they might be mistaken, the 16-bit advocates dug in their heels. I quoted the following from a single 2001 thread, where a squadron of "experts" were berating their challengers. This is not a single speaker, but a group of them, separated by ellipses.

"16 bit capability is critical during all aspects of tone compression…The difference CAN be seen in the final output very easily. Most definitely on the printed page, especially when using high-quality halftoning and even more so to a film recorder…It's very easy to see that substantial color & tone editing will eventually result in data loss and banding…If it means the difference between taking a 16-bit image capture and editing that to the final image and taking that same image in only 8-bit and editing that to the final image then there is a difference like between the day and the night…Yes, if a histogram full of holes has no impact on final output, then throw away the graphs and just get on with the print run. However, all of us have Real World Output showing the superiority of superior data acquisition…My advice? Take the information you've read here to the bank. Stop doubting and start applying what you've learned here…If you really start out with a RAW image in high-bit form and a raw image downsampled to 8 bits, the difference really is night and day. …it's totally obvious to anyone who looks that it's very advantageous to do the big moves on high-bit data."

Nobody offered a single real-world image to show this enormous difference. It was all histograms and gradients, gradients and histograms.

THE "CHALLENGE".

The type of color correction I teach does not depend on bit depth. The methods work equally well whether you choose to use 8-bit or 16-bit. I have never written an article or a column about bit depth. I don't even mention the topic in my classes.

There are around ten pages of Professional Photoshop that discuss bit depth and around five pages of Photoshop LAB Color. They are there is not because they are necessary to my message in any way, but because the advocates of 16-bit editing were so forceful in their denunciations of anyone not using their methods that I kept getting hit with the question, both on this list and elsewhere. At http: //www.ledet.com/margulis/ACT_postings/ColorCorrection/ColorCorrection.htm there are several archived threads on this topic dating from 1999. The only thing that I could answer was that I have nothing against others using 16-bit, and use it myself in dealing with computer-generated graphics and in very specialized cases with color photographs. However, AFAIK there are no real-world circumstances under which a non-expert would find it beneficial for editing color photographs.

Before putting anything in my own books, I try to verify that there isn't something unusual about my own files that causes me to draw an incorrect conclusion. I therefore posted a request for people who thought that they could demonstrate an editing superiority for 16-bit to arrange to send me files for testing. As my own testing (see Part II, "Where 16-Bit Can Be Better") had already established that a grayscale file could conceivably show an advantage either for 16-bit or (more commonly) for 8-bit editing, I specified color photographs only, in one of the four standard Photoshop RGB definitions.

Around a dozen people have responded between 2001 and now. They put together packages containing proofs and often several different versions of corrections. Over a period of a full week in 2002, I analyzed image after image trying to find any circumstances under which 16-bit editing would give superior results.

Finding none, in Professional Photoshop Fourth Edition, I published almost ten pages of comparisons, because to illustrate the points, pictures have to be fairly large. Six full pages were devoted to showing images at various magnifications. Because the 16-bit advocates had retreated to a position of claiming that the difference was only critical when the corrections were large ones, the examples I showed ranged from large to inconceivably huge, in one case taking a picture that was so flat that it was unrecognizable for subject and correcting it into something that could be mistaken for professional work. I printed each image at high magnification, including some individual channels. They were printed without identification and readers were invited to guess which was which. I particularly chose images that would be the most prone to the sort of banding that the 16-bit advocates claimed would happen.

Every person who has ever submitted files to me has agreed with my assessments of image quality. Certain people have had procedural mistakes that I pointed out, and they have always agreed that my objections were correct. In the cases where I am stating that there was a qualitative difference when done in a certain way but not in another. I have shown the results to the person submitting the files and they have always agreed with my findings.

Similar independent testing was subsequently performed by Jim Rich. The main difference between his testing and mine was that Jim's testing involved real-world corrections of images, in that his corrections, although severe, might actually be seen on an everyday basis. Mine, OTOH, were intentionally set up to be far more demanding than any real-world scenario would ever entail. Anybody having to deal with the type of challenges that I published has many more serious workflow problems than bit depth.

Jim's testing, which was also independently reviewed by experts, got the same results. Since that time, around a dozen people have performed similar tests, trying to find any real-world scenario in which 16-bit editing of color photographs might produce an advantage, however trivial, over doing the same thing in 8-bit. Everyone has come up empty.

In my LAB book, I had one further example, in trying to dispose of a similar myth. In the mid-1990s, one of the same people who now fiercely defends 16-bit editing was even more fiercely opposed to the use of LAB. He asserted that the very conversion from RGB to LAB to do the editing caused "catastrophic damage" to the image. This opinion was, of course, based on analysis of histograms and gradients. In response, in a 1997 book, I showed side-by-side images, one of which had been converted back and forth between LAB and RGB 75 times. No difference, of course. Nevertheless, the myth persisted, and I would several times a year get questions about the supposed damage. So, in the LAB book, I did another such example, 25 times back and forth. I compared it mathematically to other conversions and demonstrated that the variation between the RGB>LAB>RGB and the original RGB version was less than that between many RGB to RGB conversions.

Shortly after announcing the "catastrophic damage" theory and finding that there was no damage at all even after multiple conversions, the theorists changed their theory. The catastrophe, they opined, only occurred the *first* time that a file was converted; subsequent conversions of the same file would be harmless. But, if at some other point in the correction, there would be for some reason another conversion to LAB, *that* would be a catastrophe. This was similar to one of the changes in their 16-bit theory. Originally, it was "highly critical" to do all edits in 16-bit. Then, it was changed to "big changes". When it became clear that this theory didn't hold up either, it was changed to "big changes done over a series of smaller changes."

Therefore, in total disgust, I spent five pages of the LAB book showing large-size, magnified comparisons not of two variants, but of four, of each of two different images. The images were specifically chosen because they had the type of smooth areas that supposedly cause disaster in 8-bit editing and in conversions to and from LAB. One was a 16-bit digicam capture, the other 16-bit scanned film. They were compressed into a small 16-bit range, which is far more challenging for the subsequent edit than starting with an original limited-range capture.

To these images, I applied not one or two big corrections but, in accord, with the theory, seven of them. These were done in RGB. I did the test once in 16-bit, and once in 8-bit. But then I repeated the tests with a twist--after each of the seven moves, I converted unnecessarily to LAB and back again. Therefore, between the most politically correct of the four variants (16-bit all the way, no conversions) and the least (8-bit all the way plus a conversion to LAB after each move) there were seven night-and-day, totally-obvious-to-anyone-who-looks corrections *plus* seven catastrophic-damage conversions.

Nobody could tell which was which even at high magnifications.

Dan Margulis

----------------------------

In Part II, I discuss the situations where 16-bit editing can actually be better, and review the retreat of the 16-bit advocates from the night-and-day difference position.

___________________________________________________________________________

Date: Mon, 31 Oct 2005 13:33:13 -0000

From:Dan Margulis

Subject: 16- and 8-bit: Summing Up (Part 2 of 4)

WHERE 16-BIT CAN BE BETTER.

A 16-bit file can have very minute differences between pixels--1/256th of the minimum difference in an 8-bit file. Anything that small will have no impact on the final reproduction--no possible sequence of editing events could ever create a variation that anybody could see. The maximum initial difference between a pixel of an 8-bit and a 16-bit file would be slightly less than half a level. That is, in a 16-bit file there might be a value of 128.49, which would be treated as a value of 128.00 in 8-bit. That half-level difference won't do anything, either, *unless* some unlikely sequence of commands drives it much, much further away from where it would be if it were an 8-bit file.

For technical reasons that will be discussed later (see What the Extra Bits Actually Do, Part III), if you look hard enough and at a high enough magnification, the 16-bit edit always looks marginally smoother and the 8-bit more active. To date, I know of four types of natural photographs that, if edited to an extreme, show differences large enough for people to prefer one or the other. (There are also some times in retouching and image conversions where working in 16-bit helps, but they are so esoteric that I have rarely written about them.)

1) If we apply massive edits to a grayscale file, the difference between an 8-bit and a 16-bit correction may become noticeable. The 16-bit version would be preferred if the image featured areas where smoothness is desirable, like skies; the 8-bit when the subject is full of detail. In my testing, even with very big grayscale edits, well over half of the images showed no difference. Of the others, the result of 8-bit editing was preferred roughly twice as often as 16-bit edits. But definitely 16-bit editing got better results in certain images. The reason that this does not carry over into color images is that when three channels are superimposed on one another any variation in one is less visible. Similar massive edits to the RGB files that were the ancestors of the grayscale files showed no difference of any consequence.

2) Early in my testing, one list member provided a demonstration based on applying the same edits to one 16-bit and one 8-bit file, both generated by a scanner from a single scan. I verified that when the edits were applied the 8-bit file looked distinctly worse. However, when the tests were repeated on a copy of the 16-bit file that had been converted into 8-bit not by the scanner but in Photoshop, there was no difference in quality. I communicated this finding to the list in 2001 and recommended that people take 16-bit files from scanners where possible.

3) A second user provided a similar exercise where edits were applied to 16-bit and 8-bit files generated in Canon acquire software from the same digital capture. (The original had deliberately been acquired incorrectly in order to make the differences more apparent, which disqualifies it as a real-world example, but in view of the interesting nature of the problem I followed through with the testing.) Again, I verified that there was a quality loss by editing the user's 8-bit file, again I retested by converting his 16-bit file to 8-bit in Photoshop, and editing that. As with Example #2 there was now no longer a quality difference, so I recommended to the list that we avoid taking 8-bit files directly from a camera package when a 16-bit file is available. I do not know whether the same problem exists in Camera Raw but I will be testing it in coming months.

4) In 2005, a third user provided a Camera Raw file of a scene of a city at night. He sabotaged the image by moving the exposure slider within Camera Raw all the way to the left in spite of the fact that the image was already too dark. Then, he acquired the image in ProPhoto RGB, an ultra-wide gamut RGB definition that is rarely used in professional work. The image contained a large area of sky. Applying the drastic curves that were needed to lighten the image to the 16-bit file resulted in a perceptibly smoother and more attractive sky than the one done by converting the file to 8-bit in Photoshop and applying the same curves there. When the same image was captured with the same sabotage in Camera Raw into either of the RGB definitions that most of us use--the narrow-gamut sRGB or the wide-gamut Adobe RGB--there was no significant difference between correcting in 8-bit or 16-bit.

THE RETREAT.

Ever since the initial assertions that 16-bit editing would create an enormous difference, its proponents have been in full retreat as users have asked them again and again for any example to support the notion. They have provided a blizzard of gradients and histograms, but never a real image. One author's idea of illustrating the concept was to compare an *original* image to one that had been edited in 8-bit and then showing the histogram. In a second book, he compared reasonable editing in Camera Raw (which is 16-bit) with idiotic editing in 8-bit Photoshop, in each case claiming that it showed the superiority of 16-bit editing.

In fairness, the demand for images placed the advocates in a difficult position. There is no reason to doubt that they actually believed their original wild claims were true; as has been made abundantly clear since, they never bothered to run tests before making them. By the time they learned that there was serious doubt that there was any 16-bit benefit at all, let alone a night and day difference, they had already begun to promote seminars about the benefits of the 16-bit workflow. Furthermore, Adobe, largely at their suggestion, had begun to add 16-bit capabilities to Photoshop which were being heavily hyped. As many of these advocates take money or other support from Adobe, it would have been exceedingly awkward if they had abandoned the you-are-not-a-professional-if-you-don't-use-16-bit line.

Since they could not abandon their position but could not produce anything to back it up, they resorted to smokescreens. The usual method was personal attacks on me. They repeatedly referred to some mysterious "agenda" of mine. They called me lots of names, but never could get around to showing what the people were asking for. They asserted that I said 16-bit was worthless under all circumstances and presented gradient after histogram to prove that it wasn't. They spent scores of hours telling users that they were "too busy" to prepare demonstration images that could have been made very quickly if the difference was even a tenth as critical as what they were touting. They constantly tried to evade responsibility by saying that the burden was on me to prove that 16-bit doesn't have advantages, as if *I* were the one who was saying that anyone who didn't work my way was unprofessional and *they* were the ones who were tolerating either way.

One of the more prominent advocates, Bruce Lindbloom, was so frustrated by his inability to produce a persuasive image that he posted a web page that accused me of sabotaging my 16-bit images before testing them. Also, he asserted that I kept my results private and that nobody else could verify them. Both statements are categorically false, and Lindbloom knew that they were false when he posted them. 16-bit advocates Andrew Rodney and, to a lesser extent, Bruce Fraser, both of whom are well aware that the Lindbloom page is a crock from the word go, nevertheless repeatedly post links to it, hoping that if they post the falsehood enough times, it will magically become true.

The gyrations that these advocates went through to explain why they could not produce even a single real image that would support the notion that 16-bit editing was "highly critical", would produce a "night and day difference", and so forth are so remarkable that they are excerpted at length in Part IV.

This list did get a glimpse of the rationale from Jeff Schewe in 2002, in a thread that is posted in our archives. He defended his assertion that those using 8-bit are "recreational, rather than professional" users of Photoshop as follows (note: Jeff frequently uses ellipses [. . .] in his messages; in the one case where I have deleted an extraneous section of the message, I use ***):

"Nope. . .Dan and the rest of you are welcome to continue scanning in 8 bits and doing whatever you want to do to your images. . .but if you want absolute total control over tone and color without the risk of breaking the image somewhere down the road. . .you better learn to edit in 16 bits.***And yes, I'll stand by the line 'recreational' if you squander and waste your data bits just getting an image tone/color corrected in 8 bit. . .cause if you do that, you're working with considerably less than 8 bits/channel and deserve the banding you are likely to incur."

I replied, "Rather than continuing to post the same defensive bluster to every group credulous enough to listen, it must be a better use of your time to produce even one image that demonstrates the point. After all, this is supposed to be critical, night and day, the difference between professional and recreational imaging. If an image exists that shows such a dramatic difference, why not show it, rather than just make claims?"

The evidence Jeff offered in response was, "Pretty much all of my work the last 5 years was scanned in 16 bit for initial tone & color correction. You are welcome to look at my work and see for yourself, no banding. . .even after hours of editing and extreme manipulations. I'll let my work speak for itself."

Within a year, however, others had backed off the original claims. The new emphasis was on "flexibility for the future." The night and day differences were no longer found in really big edits, but only in ones with multiple big edits. We were cautioned that, even if 8-bit is sufficient now, new types of output devices might arise that would require more bits. The ad hominem attacks on me and my purported motivations continued whenever users asked on-line for specific images.

By 2004 the embarrassment was such that the protagonists began to deny ever having made any of the apocalyptic statements. In November, Andrew Rodney posted the following astonishing statement to this list: "And no I've not seen any text that says '16-bit is absolutely critical, creates a night and day difference, that anyone who doesn't do it is an amateur, etc., etc'. It's simply a reflection of math and physics." When Ric Cohn pointed out that Andrew's own business partners had frequently used precisely those words, the following day Andrew denied having denied it. Thereupon I produced Andrew's original denial--and he denied ever denying he had denied it. And throughout the rest of the thread he resumed the position that nobody had ever said such things. And held to it, even after the quotes were posted.

Earlier this year, on the ColorSync list, of which I am a member but don't normally participate, Bruce Fraser once again took shots at my motivations when the list turned to the bit depth topic. He wrote, "What Dan's tedious and fundamentally specious arguments deliberately miss is that the need for greater bit depth has absolutely nothing to do with reproduction and everything to do with editability."

At that point I entered the thread to point out that I did not miss that point and that on the contrary, the files that I had been testing were edited beyond all recognition, beyond any possible claim of real-world practice. And I pointed out how many other people had performed similar tests with the same results, and again asked why he could not produce any images to back up his claims of a "night and day difference" that was "totally obvious to anyone who looks".

Bruce denied having ever said these things, whereupon I produced the original files where he did say them. After further exchanges in which he waffled somewhat on these phrases, I asked pointblank whether he had ever personally run tests of 8-bit editing vs. 16-bit editing, before or after having laid down these ukases about how the difference would be night and day. He refused to answer. After being further pressed, he stated that it would be a waste of time because it was obvious that the 16-bit would look much better (if you don't believe he said this, don't take my word for it, go to Part IV). And, having refused to accept the possibility that something he hadn't tested might not be true, he ended with a typical slur: "My personal opinion is that this is a manufactured controversy--I decline to speculate on the motivation of those who have manufactured it--and I'm utterly disinclined to waste my time arguing the point when I have better things to do with it."

In many of these threads, other users have chimed in claiming that they are positive from first-hand knowledge that 16-bit editing avoids problems of banding. I'm aware of around thirty such posts, including a couple to this list. In about a dozen cases, I've gone off-line to ask these people how they are so sure. Without exception, they have never performed any testing--it's all a hunch. They, like Jeff and Bruce, merely are supremely confident that their work would show banding or other artifacting if they did it in 8-bit. But they've never tried to do the same things to 8-bit files that they do to their 16-bit files, so they can't know for sure, and they refuse to accept the word of others who *have* performed such tests.

The people who have doubted that there is a night-and-day difference between 16-bit and 8-bit correction, or that correcting in 8-bit is amateurish, have generally said they are willing to be persuaded otherwise by examples, as I am. Some members of the other side take a different tack. It is so obvious to them that their view is right that not only do they require no proof of it, but they state outright that they refuse to accept any proof that it is not. It has been remarked by others that such a position is a religious rather than a rational one, and I agree. The closest analogy I can think of would be to the person who says that it is so obvious that the world is flat that it needs no proof, and that any demonstrations that it is round will be ignored because they can't possibly be right, since it is well known that the world is flat.

It actually gets better. Since that time, Bruce Fraser has, incredibly, announced that direct comparison of 8-bit to 16-bit editing is invalid, and conceded that side-by-side tests will show no advantage for 16-bit. He writes, "I've demonstrated many times things that work better in 16-bit than in 8 bit, but Dan has rejected these because they don't fit his narrow criterion of doing exactly the same things to a 16-bit and an 8-bit file, then comparing the results." Separately, he clarifies, "The major problem with the methodology...is that by making identical edits to the 8-bit and the 16-bit, you're throwing out any benefit the extra bits may bring. They aren't useful unless you DO SOMETHING with them!"

The extra bits may indeed be useful if you do something, but there's no way of knowing for sure without trying to do the something without them, and seeing if there's a significant difference. A lot of people have done this. The answer they have unanimously come up with is that there is not.

Dan Margulis

----------------------------

In Part III, a 16-bit advocate finally comes up with a "real-world" example that turns out not to be so real-world, and a consensus develops about bit-depth and choice of colorspace.

___________________________________________________________________________

Date: Mon, 31 Oct 2005 14:34:31 -0000

From: Dan Margulis

Subject: 16- and 8-bit: Summing Up (Part 3 of 4)

THE CONSENSUS.

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. Andrew has known for at least five years that I consider testing in such RGBs irrelevant--see "The Attempts to Obfuscate" below.

Even if we were allow Andrew to sneak this image in, it wouldn't show a 16-bit superiority, for two reasons. First, he deliberately chose a zero-threshold sharpening setting for his image to emphasize the differences between his 16-bit and 8-bit versions, when an equivalent setting that required no additional steps was available. To back up the premise that you have found a real-world difference, it's fair to say "I would like to do the following or something equivalent, and I find that there is no way to do so without getting an effect that displeases me." That would have been the case with any of the four examples cited in Part II, "Where 16-Bit Can Be Better". It is, however, fatuous to say, as Andrew does, "Of many possible equivalent settings, I have intentionally chosen the one that displeases me, and now the test fails because I am displeased."

Second, the standard is "totally obvious to anyone who looks," a "night and day difference." Anybody who looked at the four examples cited above would, in my opinion, prefer the 16-bit versions. The only person known to have been shown printed versions of Andrew's samples preferred the 8-bit version. Some areas of Andrew's 16-bit version are better than the 8-bit but larger areas are worse. I think that a jury would rate the two versions as qualitatively equal, but if they did not, I expect they would choose the 8-bit version as better overall.

Andrew's edits were not particularly severe. Conceivably more massive edits would have created a pair of images with differences strong enough for people to have a clear preference for one as opposed to the other. In view of my testing with B/W images, I think it's likely that when there is an actual preference, people would tend to prefer the version corrected in 8-bit. However, there would also be cases where the smoothing effect of 16-bit editing would be preferable. But again, the situation is not real-world. Anyone knowledgeable enough to take advantage of the extra bits would be unlikely to be editing in such an RGB in the first place. And nobody, not even Andrew and his partners, advocates making big edits in an ultra-wide RGB in Photoshop proper. Any move big enough to provoke a visible difference because of bit depth, they would urge making in Camera Raw.

Lee, Andrew, and I all agreed that when the file was put into Adobe RGB rather than ProPhoto RGB, and the same edits, including the zero-threshold sharpening, were applied, there was no significant difference between the 16-bit and 8-bit version. Whereupon Andrew stated,

"I will admit: If you work with a small(er)gamut space, the need for high bit editing is reduced and possibly a non issue."

I think that this face-saving admission is acceptable--that for Adobe RGB and sRGB, the two spaces that we almost all use--editing in 16-bit is no longer highly critical, no longer the distinction between a professional and a recreational user, no longer a matter of night-and-day difference, but rather "possibly a non-issue."

In return for Andrew's concession, I cheerfully respond as follows: "I categorically recommend against making major edits to photographs in ultra-wide RGB spaces such as Wide Gamut RGB and ProPhoto RGB when any reasonable alternative exists. If you nevertheless insist upon doing so, you should take into account that under such conditions the bit depth of the file may affect quality, so you should be aware of the circumstances in which 8-bit editing may be superior as well as those in which 16-bit may be."

THE ATTEMPTS TO OBFUSCATE.

Throughout these five years, the 16-bit advocates have been trying to deflect attention from the basics, which are that they bullied and berated users, calling them ignorant and unprofessional, all because these users did not use an inconvenient workflow that has never been shown to be of any use whatsoever.

The challenge is a simple one: to take any color photograph that might conceivably be used in a professional setting, operate on it in any way that a person, even an incompetent one, might try, and demonstrate a clear superiority for 16-bit editing of that particular image. I do not say that no such image could possibly exist. I do say that we have not seen one yet, and a lot of people, including me, have tried hard to find one.

The terms of the challenge are extraordinarily permissive, and the 16-bit advocates have resorted to extraordinary whitewashing to cover up the fact that they can't meet them. They keep trying to sneak in obviously inapplicable stuff; when everyone laughs at it they accuse me of "changing the rules" and click their tongues and say, "see? No matter how hard we try, our stuff is always rejected on a technicality! Clearly there's no image in the world that Dan would ever accept!"

We saw this on the list last year. A member posted as an example a Photoshop file consisting of no more than small blue area with noise. He asserted that this was a picture of a "sky." There was no way of verifying this as there were no clouds or other detail that might identify it as a sky; no way of knowing that it wasn't computer-generated, for that matter. I said that it is somewhat difficult to accept as a "real-world photograph" something that an independent viewer can't identify as a photograph at all, let alone what it's a photograph *of*. Andrew Rodney immediately went ballistic, again accusing me of changing the rules and stating that this proved that I would never accept any image as being real-world.

Similarly, the "real-world" corrections consisted of seven pairs of drastic actions, each designed to reverse the other. Again, based on my assertion that there was not the slightest chance that anyone would ever be stoned enough to *dream* of doing something as crazy as that in the real world, Andrew again asserted that there was a change in the rules.

In the 2005 ColorSync thread, I was again accused of changing the rules because I should have made clear that "photograph" and "computer-generated gradient" are two different items and that I would not accept a gradient for testing. Also, it was alleged that I changed the rules because my use of the words "color photograph" did not make it sufficiently clear that grayscale images were excluded.

Andrew's recent image saw more of the same obfuscation. When I said that the behavior of exotic RGB definitions is irrelevant, Andrew very piously said what he usually does when caught cheating on such occasions: "I didn't expect this scene or any additional scenes I can capture with this sub-$1000 camera to 'fit' your criteria since once again, that seems to be a moving target. So I've 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."

I've never accepted such files for testing. Andrew Rodney knows this, because he complained about this condition in 2000, in a thread that's archived on our site. He correctly pointed out, and I agreed, that ultra-wide RGBs are more likely to show a difference. I replied (remember, this is 2000): "To me, it's like asking how many angels can dance on the head of a pin. Nobody to speak of is using wide gamut RGB. There are a lot better uses of our time than to investigate the question of whether it needs 16 bits. I *have* looked at the issue in Adobe RGB and don't see that the extra bits are useful there. As I mentioned earlier I would be anxious to see images from anyone that might contradict this."

Further, in the 2005 ColorSync thread, I specifically suggested that the ProPhoto space might sometimes show a difference between 16-bit and 8-bit editing if the edits were extreme enough. Seizing that suggestion, Andrew created his example--and then feigned shock that I wouldn't accept it, even though he had known for five years that I wouldn't.

This type of behavior is only what we have come to expect. As has already been pointed out, both Andrew and Bruce have tried to deny that they said the wild things they did five years ago. And, particularly, the intentional falsehoods on the Lindbloom site have been called to Andrew's attention again and again on this list and elsewhere. Yet he continues to pepper cyberspace with references to it. Every time he does so, he shames himself.

WHAT THE EXTRA BITS REALLY DO.

Understanding statistical concepts is not easy even for those with extensive training in the field. Casinos have lost hundreds of millions of dollars to mathematically astute players because the professors the casinos hired to advise them on probabilities failed to comprehend certain statistical interactions. The New York Times polled academics about a statistical-interpretation puzzle called the Monty Hall Dilemma, and the majority of professors of mathematics gave the wrong answer. Both of these examples are absolutely child's play in comparison to trying to interpret what makes a picture look good.

Progress in our field has been hampered considerably by "experts" who are so terrorized by histograms that they don't understand that they feel they will sound more authoritative if they try to terrorize their readers with them as well.

The calibrationism of the 1990s, the fear of applying easy curves to images for fear of "irretrievable data loss", the phobia of LAB, the insistence on applying profiles to things that obviously can't be profiled, are all symptoms of the same disease. The confusion between gradients and digital photography is one of the best examples yet.

A computer-generated gradient is a perfect file. Each pixel gets its optimal value. Working in 16-bit gives extra precision, and it's unconditionally better for gradients than 8-bit is. It's possible that the two methods might give equivalent results. It's possible that the 16-bit might be better. But it's not possible that it would be worse. Also, it's easy to come up with a demonstration that shows damage by editing such files in 8-bit as opposed to 16-bit.

Now, contrast that to a digital capture. It is shot through a lens that is not perfectly clean; through air that contains particulates; it is captured by sensors whose performance varies with age and which may not be clean themselves. The data is demosaiced by an algorithm that we know nothing about. The vendors apply blurring to certain areas, and generally apply contrast-

enhancing curves in certain others. Finally, the data is written using an unseen method to a format that may contain its own irregularities.

For all these reasons, the idea that even 128 levels per channel, let alone 256, are being captured with any degree of accuracy is very dubious. Yet if you open a digital file, up comes what looks like a nice, smooth histogram. That is enough for the 16-bit advocates to put their minds into neutral, prostrate themselves in front of it, and start salaaming. They assume that because the histogram looks like that of a gradient, the image will handle just like a gradient does. That's like saying that because champagne tastes good, motor oil must, or that because a helicopter can fly, it follows that a submarine can.

In real life, parts of what the camera captures are much more reliable than others. The better the shooting conditions, the more reliable the information. An underexposed image has less than 8 bits of accurate information anywhere. A shot in studio conditions has *more* than 8 bits of accurate information in the midrange of its green channel, less throughout its blue channel and in the shadows of each channel, and the rest is debatable.

CCD and CMOS devices, such as digital cameras, are notoriously poor at extracting shadow detail. Every manufacturer tries to fight noise by using some kind of blurring routine. Similarly, all digicams have difficulties with noise in blue areas, such as skies, and result to all kinds of demosaicing shenanigans to reduce it.

In these areas, the values that the camera spits out are approximations only. In the darkest eighth of any channel, an 8-bit file has 32 available tones. There is no digicam that I've ever seen that is even remotely close to capturing these 32 tones reliably. An 8-bit file allows for more precision than the camera has in shadow areas. In these shadows, the 8-bit file therefore already consists of somewhat random numbers. Making it a 16-bit file adds *totally* random numbers in these areas. The histogram-worshipers are fond of using the term "quantization error", but this merely shows their statistical naivete. In contrast to a gradient, where the 16-bit file is mathematically more reliable, the 8-bit file is mathematically purer than the 16-bit in the shadows of a digital photograph. Since, in shadows, the extra bits are random numbers, working with a 16-bit file simply adds soft noise in transition areas. Skies behave similarly.

My apologies for lapsing into techspeak. A reminder that this effect is so tiny as to be undetectable under real-world circumstances. However, if the file is stressed sufficiently (as Andrew was doing with his exotic RGB definition and his sharpening sabotage) then we may be able to perceive it--and what we will perceive is that editing in 16-bit amounts to applying a blur to these areas--a highly sophisticated blur that is hard to emulate by other means.

AFAIK, all of the claims about the images in which 16-bit supposedly is better involve either skies or shadows. Makes sense--we often blur these areas separately no matter how many bits are involved. The camera's algorithm blurs them already, but sometimes it isn't enough.

Unfortunately, if you do enough to the 16-bit file that its inherent blurring has an impact in shadows and in skies, it's likely that it also may have an impact in areas where you *don't* want blurring. That accounts for the preference one viewer had for the 8-bit version of Andrew's file. In the shadow areas it was worse, but in the foreground areas that were full of detail, it was better.

An even more striking example showed up in the last two months, where another 16-bit advocate posted a demonstration at http: //www.visual-

vacations.com/Photography/16_vs_8.htm

The image is one of a barn constructed of dark wood, taken in normal daylight. The complaint is identical to Andrew's, namely that correcting in 8-bit created undue noise in the shadows. The procedure in this image is similar to Andrew's as well, but there are some variations--especially in the result.

1) Both are definitely real-world images. This demonstration is in sRGB, which is fine. Andrew's is in ProPhoto, which disqualifies it right off the bat.

2) This image is intentionally sabotaged by acquiring it in such a way that it enters Photoshop grossly dark, and is therefore immediately disqualified, because in the real world, we do not sabotage images on acquisition. Andrew's image, by contrast, was acquired fairly.

3) Both images now take Levels changes and, in Andrew's case, Hue/

Saturation. Fine.

4) Now, the attempt to slip in the sabotage. Andrew sharpens using a zero Threshold, which is clearly intended to bring out noise and thus disqualifies it as a real-world move, since in the real world one could achieve the same sharpening affect with a Threshold of 2 or even 1. The other demonstration does this not just one better, but five better: it tortures the image with four consecutive zero-threshold sharpens, plus two applications of Shadow/Highlight, which is a form of sharpening. Again, not real-world: in the real world, when we have two alternatives, we choose the one that looks better, not worse. The purpose of sharpening is to make the picture look more natural, not more noisy.

5) And the startling bottom line: while both exercises show more undesirable noise in the shadows in the 8-bit versions, images don't consist entirely of shadows. They need to be evaluated as a whole. I'm familiar with how juries vote when given unidentified samples to choose from. We have one report that with Andrew's image the 8-bit version was chosen as better. I don't think that a jury would agree--I suspect the verdict would be a tie. With the other, however, I have no doubt. The shadows are worse, for sure, but a jury would pick the 8-bit version as better overall, because the same blurring effect in 16-bit that helped the shadows also blurred the main interest object of the image, the wood of the barn.

If editing in 16-bit were truly "better", there wouldn't be examples where editing in 8-bit appears to give superior results--it couldn't, any more than editing an 8-bit gradient can possibly produce a superior result to doing it in 16-bit. Also, it is very telling that the examples being used always are either skies or shadows, and never the third major category of image that we frequently have to blur: fleshtones. I would suggest that the reason is that camera captures of fleshtones are very much more reliable than either of skies or of shadows. There is therefore less need to blur due to inadequacies of the original capture. Even though the extra bit depth in fleshtones is probably real information and not noise, it doesn't serve a useful purpose.

OTHER VIEWS.

I would like to close by quoting at some length two other experts who have conducted their own tests.In the 2005 ColorSync thread, Jeff Schewe emerged after I had left, and, unbothered by the overwhelming evidence that there is no quality difference at all, reiterated the same old silliness:

"I would argue that it [is] critical that ALL MAJOR tone and color moves be done in 16 bit."

Jim Rich replied,

"As working in 16 bits to avoid all of these Urban Legend pitfalls such as:

Ê The color being day and night different from 8 and 16 bit images.

That 8 bit files are fragile in terms of color reproduction.

Or that you will get artifacts like banding in gradients after a lot of image editing.

That 10% percent of images require 16 bits so they don't break.

Or that you need to work in 16 bit because of device responses.

Let me say again on those points, I am more than skeptical that you require 16 bits. My experiences with RGB photos, CMYK print and Inkjet printing do not indicate that one should jump to those conclusion. And we know that mileage will vary.

And until I see a test or some other type of hard evidence that all of these problems really exist and are as wide spread, as reported I can't buy into the notion that there is an advantage to going to a full 16 bit workflow for a few renegade images.

It would be interesting if some one would please show me a suite of images where the benefits of 16 bit images jumps off the sheet and it is clear what is an 8 bits and what is 16 bit file. Then I can really buy into the 16 bit way of life. "

It's hard to know what more could be asked. Jim admits that it is impossible to prove that there will *never* be a case where 16-bit is beneficial, any more than one can prove that it would never be beneficial for a righthanded person to work with the mouse on the left-hand as opposed to the right-hand side. As indicated above, several 16-bit advocates have said explicitly that demonstrations don't matter: it is so obvious that 16-bit is the better way that it requires no proof.

Tim Grey, one of the rising stars in the Photoshop field, wrote this in his September newsletter:

"In a general sense, I do indeed agree with Dan. The way I explain this issue is that 16-bit editing provides more 'headroom' for editing, ensuring you won't create posterization in the final result. However, I've also tried to make it clear that the vast majority of the time, you will never see any benefit at all from optimizing your images in 16-bit. The simple fact is, even if you strip out a significant number of tonal values in your image, you'll still have an adequate range to produce what appears, to our eyes, to be perfectly smooth gradations. I often do a demonstration in my workshops as I posterize an image and ask students to tell me when they see posterization. In general, I get down to about 32 levels per channel before anything is visible, when there are 256 available in 8-bit per channel images. So why do you need 16-bit? The short answer is, if your computer resources can handle it, you might as well keep your images in 16-bit to preserve as much detail as possible, especially considering that output devices continue to improve, and at some point we may have output that tests the limits of our 8-bit files, where you'd actually see a difference.

The only time 16-bit would make a difference, for all practical purposes, is if you need to make extreme adjustments to the image. If that's the case, you probably would throw the image away, right? So 16-bit isn't a significant advantage to most of us. Still something I recommend as a 'just in case', but not likely to provide any practical benefit."

This is a sensible summary. Personally, I doubt that there's a realistic possibility of benefit, but certainly you never know, and if you care to speculate on it and have the disk space and computing time to spare, nobody is criticizing. I believe it's more likely that some weirdness in an output device will create a benefit than anything at the high-end. Naturally, I also think that the most likely image to show an advantage would be one consisting of a sky and little else, or an image with almost no detail outside of deep shadows.

LESSONS FOR THE FUTURE.

From the perspective of people who purport to be Photoshop authorities there is a lesson to be learned about giving non-experts a hard time in public. You never know when it's going to turn out that your views are mistaken, and then you look ridiculous.

Second, admitting that one has been wrong is not a disgrace. Rather, I think it gives one more credibility. Image processing is an infinitely complicated field. In every new edition of Professional Photoshop I've pointed out areas where I was previously incorrect. In the LAB book I talk about how I misunderstood some of the sharpening issues. In at least two sections I pointed out images that I had corrected badly.

Third, we have to grant that the difference in results between 8-bit and 16-bit editing is not trivial to comprehend, even by people with a lot of color knowledge, even after a lot of testing. OTOH, anybody who claims that converting to LAB causes "catastrophic damage", that working on several adjustment layers creates better data than applying the same corrections consecutively, or that there is a "night and day difference, totally obvious to anyone who looks" between 8-bit and 16-bit editing, is either too lazy or too incompetent, or both, to do the ten minutes of testing that it would require to cast serious doubts on these assertions.

Fourth, some sense of priorities has to be invoked. Some of the people who have been most strongly in favor of 16-bit editing don't know how to set highlights and shadows. Some actually edit not just in Levels but using the master setting rather than channel-by-channel. Under these circumstances the gain (if any) from 16-bit editing is about #4,807 on the list of things that might help the image look better. Remember: even if some exceptional image does show up that indicates an advantage for 16-bit editing, in all probability the edge will be so minor that it can easily be compensated for. But to this point, we haven't even gotten that far.

Users aren't blameless either. The entire imaging field is pervaded by purported experts peddling solutions, myself included. Users tend to be properly skeptical of claims made by unknown vendors, but a surprising number of people are buffaloed by histograms and claims of mathematical precision. Before buying into anybody's pet theories, readers should insist upon images, not a bunch of pseudoscientific gobbledygook. If the speaker can't phrase the concept in a manner you can understand, perhaps he can't understand it either.

Users would be well advised to steer clear of anyone trying to justify conversion or color correction theories with gradients, using terms like "quantization error", or trying to convince us that a good-looking histogram is more important than a good-looking image. Above all, when people come up with new nostrums, ask to see images, not theories.

Finally, it should be remembered (as always) that color knowledge is always evolving and that today's conventional wisdom is likely to be considered wrong in ten years. I hope that the history of the correction method that started out as "extremely critical", a "night and day difference," the difference between a professional and a recreational user," and became "possibly a non-issue" will be an instructive one.

Dan Margulis

___________________________________________________________________________

Date: Mon, 31 Oct 2005 13:36:07 -0000

From: Dan Margulis

Subject: 16- and 8-bit: Summing Up (Part 4 of 4)

This is an appendix to my three posts on the 8-bit vs.16-bit editing issue. Much of my post is critical of those who insist that 16-bit editing is of paramount importance yet decline to show any real-world images where there is any indication that editing in 16-bit is better. I am posting here extensive excerpts of what they say in their own defense as to why they do not.

Before turning it over to them, I have only one remark. These individuals have argued that editing in 16-bit is "extremely critical", that it is "the difference between professional and recreational users of Photoshop", that doing so results in "a night and day difference" that is "totally obvious to anyone who looks".

If anything even remotely close to that were true, a demonstration could be made of it almost instantaneously. For example, if I had to argue for why gradients should be created and edited in 16-bit and not 8-bit, I could create a convincing example showing why in less than ten minutes. Both of the invididuals quoted here spend a great deal of time in on-line groups. They have each, conservatively, spent tens of hours, possibly more than a hundred apiece, explaining why they are too busy to take these ten minutes.

Dan Margulis

********************

Note: Jeff Schewe, one of the posters here, often uses ellipses (. . .) in his messages. Where these appear, they are in Jeff's original and do not represent deletions. Some extraneous paragraphs have been deleted from the beginnings and ends of messages, but there is no editing of the text.

Jeff Schewe - 10:32pm Aug 5, 2001 Pacific

I have no interest in "Educating Dan". That's his job. Dan is right about a lot and wrong about a lot. It's very easy to see that substantial color & tone editing will eventually result in data loss and banding. A lot of people have banding problems, very few people know when and where that banding occurs, but it's due to the fact that editing 8 bit files causes the banding.

If you start with an 8 bit file and do tone and color adjustments, you lose levels. . .maybe only a few. But, combined with data loss due to rounding errors running filters, rounding errors due to layer blending, errors due to rebrushing all accumulate to eventually produce enough loss of data from the orriginal that eventually you get banding.

But. . .I have no interest in debating Dan's position on the value of 16 bit editing. . .I prove him wrong every day. If he wants to pay me to come teach him the value of 16 bit editing, I'll be happy to. . .but I'm certainly not going to do his job for him for free <BG>.

He asked me to prove it to him. . .I declined. If he wants to take one of my classes, he's welcome to. . .I'll give him a discount. . .

User 1 - 11:53am Aug 9, 2001 Pacific

Jeff, I will address you here, but my point really goes out to all. Please don't take it personally.

Regarding Margulis' challenge Jeff writes: "He asked me to prove it to him. . .I declined. If he wants to take one of my classes, he's welcome to. . .I'll give him a discount. . . "

While I appreciate your humor here, I am mystified as to why you (and others who feel as confident as you in the matter) decline his challenge... Taking Dan's challenge would be to our benefit, not Dan's

Here is a sampling of Dan's challenge to you:

"…. I have for several years asked here and elsewhere for those who advocate these methods if they might not be able to provide me, say, two or three sample original high-bit images, with a record of what moves were applied to them, so that I could verify that there is a quality gain, however slight, in applying them to a 16-bit image as opposed to an 8-bit one.

Since I have been making this request, what I have received is a large number of histograms purporting to prove that 16-bit is better, a large number of assurances that '16-bit has worked better for me', and a large number of excuses for why the images in which it has worked better are either unavailable or under NDA. As time has gone on I have grown to suspect that perhaps the reason no one can supply such images is that there are no such images to supply.

Can you help me out? If you or anyone else can supply such example images and they really demonstrate the merit of working in 16-bit, I'll be glad to let this list know and if the differences are significant I'll print them in my column at a size large enough for people to see. If you or anyone else has such images, just let me know and I'll give you shipping instructions."

To my mind Dan is being very fair in the matter, while those who decline his challenge prove his accusations right, even if his assumptions about bit depth may be wrong. He is certainly in the minority opinion on the subject, yet he is the only one to my knowledge who is willing to back up his assertions with examples. Why not back up your declarations to the degree that Dan is willing to back up his?

Jeff Schewe - 08:16pm Aug 9, 2001 Pacific

I know Dan pretty well. . .I have ZERO interest in being a subject of an upcoming article (I feel one coming from Dan) where he can takes what Bruce or I may say about 16 bit and twist it around. Suffice it to say that remaining under Dan's radar is far more comfortable <BG>

In the old days (before learning the value of editing in 16 bit) I suffered from slight to severe banding on transparency and CMYK output. since switching to the 16 bit appraoch, I no longer get banding. . .that's all the proof I need. I have no need to "prove it to Dan". Sorry. . .I say what I say. . .I'm willing to spend time teaching how to work in 16 bit (and do things the engineers never dreamed of), but I have zero interest in proving anything to ol' Danny boy. . .

I doubt Dan has ever seriously manipulated an image or done a 6 element assembly. I seriously doubt that Dan is after the most suprime high end quality. . .even if it's only marginally better. . .but working in 16 bit is seriously a better habit leading to better quality in the end. . .which is all I care about.

P.S. ask Dan about copyrights some time. . .he's got his head firmly lodged up an oriface about that as well <BG>.

User 1 - 09:53pm Aug 9, 2001 Pacific

Jeff,

Well, I hear ya, but…….

I was just hoping that someone would prove the point in the material world, rather than theoretically, or anecdotally. Somehow this has become about Dan Margulis the man, rather than the point he makes. It's ironic that although it's him against the world on this, he's the only one (seemingly) willing to post evidence to support his claims. Shouldn't the benefits of a 16-bit workflow be demonstrated anyway, regardless of the fact that Dan has issued a challenge? Why, with all that is published about PS in print and on the web, is such a presentation not already extant? That's just weird.

User 2 - 08:00am Aug 10, 2001 Pacific (#37 of 52) [Another 16-bit advocate] wrote: "What do you want someone to do? Prepare a costly print run or film recorder output using both good image preparation and bad image preparation so that you can be satisfied that we know what we're talking about?"

Certainly not, that would be unreasonable. That's why I asked if the difference could be seen on a monitor, and you said at 100% magnification or higher it could.

Even so, I'm not asking that you supply images for monitor viewing. Your time is valuable, and you have been very generous with it on this forum.

OTOH, it seems that someone who advocates a 16 bit work flow could supply a set of files for comparison. Lots and lots and lots of time has been spent discussing this issue, here and elsewhere, which is still unresolved in the minds of many people, and it could so easily be put to bed by just showing us the comparisons. Otherwise, as Rich said, it becomes tiring.

Jeff Schewe - 09:40am Aug 10, 2001 Pacific

Your points are taken. . .but proving anything is not my job. When I do notes for classes or lectures, it takes on average about 8-12 hours to prepare them. I do have notes on editing in 16 bit on my web site (I'm going to be changing the url this weekend for an upcomming class but they will be in the site map), but those are just techniques for working in 16 bit. To go through and offer scientific "proof" is something that would require even more time-which I don't have.

------------------------------------------------------------------------

Jeff Schewe - 05:30pm Aug 12, 2001 Pacific

All this debate is pretty typical of good old Dan. You notice he recently said that he has not taken the position that editing 16 bit is NOT better. . .only that he's never had anybody PROVE it to him.

I'm almost getting pissed off enough by Dan's "positioning" that I might decide to "prove it". But I don't have a great deal of time in the next week or so, so it would have to wait a bit.

Date: Wed, 15 May 2002 22:37:56 -0500

From: Jeff Schewe

Subject: Re: 8- and 16-bit correction

I watched, with amusement, when Dan challenged anybody to come up with a 16

bit image that could prove the benefits of editing in 16 bit over 8 bit. I

now understand there's a bounty out there of $100 if somebody can prove that

edits in 16 bit vs edits in 8 bit is superior. . .

That's a waste of time (and believe me, $100 is no incentive to me).

Fact is there is no image that can prove that one to several edits in 16 bit

vs 8 bits is better. I've never advocated editing in 16 bit merely as a

method of improving a few tone/color corrections. That's silly. The edits

done in the beginning of a tone/color correction does not cause banding. It

does indeed "spend bits" and I advocate spending your bits wisely. Where the

_REAL_ difference between 16 & 8 bit editing comes is well down the road.

Well after your original edits.

Photoshop is pure math. . .everything is numbers. Everything done in

Photoshop is the result of an algorithm. And believe me, Photoshop's

precision is not infinite. Where the benefits of original 16 bit editing

shows is down the road after doing corrections and applying a filter or two

(or dozen). Add a dozen layers with various opacities and blending modes and

maybe a layer effect or 2. Do a gradated adjustment layer. Do any series of

extended retouching or manipulations that many image artists do every day.

Then you'll find out that at some point in the process, you've rounded

enough data and spent enough bits that the gradation between point "A" and

"B" no longer has enough bits to produce a smooth gradation of tone or

color. Guess what, you've got banding. And, guess what else, you've just

proved that _STARTING_ with your initial tone/color edits in 16 bits and

conserving your data bits to spend later in the editing process allows you

to avoid the dreaded banding.

If you scan a chrome and do a slight to moderate curve correction and

transform from RGB > CMYK, should you scan in 16 bits? Nope. If you do

slight to moderate to even substantial tone/color edits and then plan on

assembling 1/2 dozen composited images with filters, layer blending and

effects and maybe 20 hours in image manipulations, will you benefit a _LOT_

from doing your original edits in 16 bits? You bet your ass you will.

I started scanning in 16 bits because I ran into constant problems of ending

up spending hours working on an image only to find that at some point, a

tone gradation in an image banded. Once banded, there's nothing you can do

to recover the lost spent data.

My point is that if you need maximum flexibility and edit ability and you

don't want to worry about banding, start your creative retouching in a

"perfect 8 bits/channel". That only comes after doing initial tone/color

corrections in 16 bit.

Sure, you can use the scanner software to do tone/color corrections in the

scanner's high bit depth and thus benefit from 10, 12, 14 or 16 bits of

data. The big problem I have with that workflow is this. . .there ain't a

scanner on earth who's software allows you to do "local" corrections of

tone/color. Scanners don't come with the ability to put a lasso around an

area to adjust just that area. The other weak point of scanner (or camera

software for that matter) is that a scanner preview just purely isn't as

accurate as Photoshop to show exactly what the pixels look like. Scanners

give "previews" but you don't see the full resolution till _AFTER_ you've

applied the tone/color corrections during the scan. At that point if you

touch it again you won't have a full 8 bit file. . .you're spending the bits

on a wasted edit. I also think, and perhaps I'm biased, that Photoshop is

the best "pixel viewing" application on the planet. I know of no other app

that is as accurate in showing on screen, exactly how a set of pixels will

look when you output. . .either photo or halftone reproduction. So, if I

want the most accurate on screen representation of just exactly how those

pixels will look reproduced, I'm just not interested in using a scanner

software or camera capture software's interpretation of those pixels.

Nope. . .Dan and the rest of you are welcome to continue scanning in 8 bits

and doing whatever you want to do to your images. . .but if you want

absolute total control over tone and color without the risk of breaking the

image somewhere down the road. . .you better learn to edit in 16 bits.

Yes, the tools are more limited and yes the files are 2x the size. . .so?

Ram is cheap and so are hard drives these days. I've learned to edit in 16

bit to the point where even the Photoshop engineers couldn't believe how far

one can go if you're determined. You can paint (using history), you can

copy/paste (using clone between 2 16 bit documents), you can use adjustment

layers (in an 8 bit duplicate and save out as a setting), you can use color

range in 8 bit and transfer the 8 bit selection into 16 bits for

application. You can clone and heal and run enough filters to do just about

anything you need to do to start off your imaging in the "perfect 8 bits".

And yes, I'll stand by the line "recreational" if you squander and waste

your data bits just getting an image tone/color corrected in 8 bit. . .cause

if you do that, you're working with considerably less than 8 bits/channel

and deserve the banding you are likely to incur.

Dan and others who claim 16 bit editing isn't better than 8 bit editing for

routine scanning and corrections are correct. But, I'm a photographer and

image manipulator. I choose to spend my data bits wisely because because

what I do to images isn't routine. I manipulate the heck out of images. I

choose to do all initial tone/color correction in 16 bit to avoid banding

down the road. And, personally I feel no compulsion to prove anything to

anybody except my clients that pay me a lot of money.

Regards,

Jeff Schewe

16 bit advocate and proud of it. . .

-----------------------------

Date: Fri, 15 Apr 2005 14:36:12 -0700

From: bruce fraser

The major problem with the methodology (leaving aside the minor ones) is that by making identical edits to the 8-bit and the 16-bit, you're throwing out any benefit the extra bits may bring. They aren't useful unless you DO SOMETHING with them!

-----------------------------

Date: Sun, 17 Apr 2005 15:00:55 -0700

From: bruce fraser

Subject: Re: 16 bits == 15 bits in Photoshop?

At 12:39 PM -0400 4/17/05, Dan Margulis wrote:

>So, I ask if the following is a fair summary of your position:

>1) Bruce states that the argument has never been that identical edits applied

>to 8-bit and 16-bit files would produce better results in the 16-bit version,

>but he argues that it is possible that they might.

>2) Bruce has not offered up any images that would demonstrate such a

>superiority for 16-bit correction (as opposed to identical edits

>applied to 8-bit),

>but he suggests that such images might exist.

>3) Bruce's comments on "night and day difference" and "totally obvious to

>anyone who looks" are based on his experience and perceptions; however,

he has

>never personally tested a series of corrections done to a 16-bit

>file on a live

>image versus identical corrections done to an 8-bit one.

No, that's a when-did-you-stop-beating-your-wife characterization.

My position is very straightforward.

I proved to my own satisfaction many (>10) years ago that many of the problems I encountered with 8-bit files-posterizaton, striped skies, exaggerated saturation accompanying contrast moves, and unwanted hue shifts-largely disappeared when I edited (and converted to output space, which is a big edit) in 16-bit instead.

I seem to be far from alone in having noticed this phenomenon.

I quite sensibly decline to do all my work twice with the goal of making half of it fail, and with the exception of beta-testing procedures that need examples for bug reports, I don't make a habit of saving the failures.

If someone wants to pay me my day rate to do so, I'm quite certain that I can come up with real-world examples, but I decline to donate my time to a foolish quest with whose premiss I'm in disagreement.

Anyone who sees no benefit to working in 16-bit space simply shouldn't bother doing so. But they shouldn't come crying to me when their images fall apart on output.

My personal opinion is that this is a manufactured controversy-I decline to speculate on the motivation of those who have manufactured it-and I'm utterly disinclined to waste my time arguing the point when I have better things to do with it.

Date: Fri, 22 Apr 2005 01:29:17 -0500

From: Jeff Schewe

Subject: Re: 16 bits == 15 bits in Photoshop?

To: <colorsync-users@lists.apple.com

Jim Rich said:

It makes sense to capture everything as high bit images.Everyone seems to

agree on this.

Save the high bit parent file in your archive.

ÊCreate derivative 8 bit files from the parent file for production.

Use Adjustment layers.

If the 8 bit file breaks ( as they can in rare cases), then go back to

the parent 16 bit file and use the previous Adjustment Layers.

I agree with the capture in high bit.

But I would argue that it critical than ALL MAJOR tone and color moves be

done in 16 bit. Ideally with Adjustment Layers for the simple reason that

setting black & white points (unless you do it accurately in say Camera Raw)

are the tip of the spear so to speak. Major gamma adjustments are second,

such as when you stretch one area and compress another area of the image's

histogram.

I would also argue that depending on the color space you may be in while in

16 bit, it would be a good idea, if at all possible, to do any major color

transforms while in 16 bit.

Bruce Fraser - 11:41pm Sep 16, 05 PST

If you want to work in 8 bit/channel mode, go ahead. But don't come crying to me if your file breaks. That's really all I have to say on the subject.

OK. A little more.

Dan's "tests" are based on applying exactly the same traditional levels-and-curves-based edits to 8-bit and 16-bit files, then looking for differences. Those will likely be fairly hard to find. For the type of work Dan does, 8 bits/channel is undoubtedly adequate, otherwise, being a rational person, he wouldn't do it. Others may have different needs.

Bruce Fraser - 1:07pm Sep 19, 05 PST

I'd also suggest that you need to weigh the consequences of working in 8-bit and finding you need 16 versus working in 16-bit and finding you only need 8. My lack of clairvoyance is one of the factors that leads me to work in 16-bit....

I've demonstrated many times things that work better in 16-bit than in 8 bit, but Dan has rejected these because they don't fit his narrow criterion of doing exactly the same things to a 16-bit and an 8-bit file, then comparing the results.

___________________________________________________________________________

Date: Mon, 31 Oct 2005 07:50:51 -0700

From: Andrew Rodney

Subject: 16- and 8-bit: Summing Up (Part 2 of 4)

On 10/31/05 6:33 AM, "dmargulisnj" wrote:

1) If we apply massive edits to a grayscale file, the difference between an

8-bit and a 16-bit correction may become noticeable.

Not even wanting to debate what 3massive2 implies nor 3noticeable2. Its clear there are two camps here that will never agree. Like those who believe in evolution versus intelligent design, it1s getting foolish to try move one group from one side to the other. If you want to work in 8-bit, great. You are my friend. If you want to work in high bit, again, you are welcome to do so. Drink whatever Kool-Aid pleases you palette.

Dan seems somewhat hurt by what some have said with respect to this debate. I will publicly apologize for anyone I happen to have known, associated with, ate or drank wine with or even those who are 3business partners2 who may have said things that were hurtful in the discussion of 8-bit versus 16-bit benefits. We should agree to disagree since this debate is getting to the point where each side has what amounts to religious beliefs.

We are getting to the point here that I1m actually missing the old 3Mac is better than PC2 or 3Canon is better than Nikon2. Such posts flood the net and like this set of debates seems impossible to come to any conclusion.

Andrew Rodney

___________________________________________________________________________

Date: Mon, 31 Oct 2005 10:35:59 -0500

From: "Mark Segal"

Subject: Re: 16- and 8-bit: Summing Up (Part 2 of 4)

Andrew,

If the two sides can't agree, it probably means that Dan is right, because if the differences were so obvious that no one in good faith could dismiss them, there would be no debate - and I don't think it reasonable to accuse any one of operating in bad faith.

Regards,

Mark

___________________________________________________________________________

Date: Mon, 31 Oct 2005 10:29:50 -0500

From: "Mark Segal"

Subject: Re: 16- and 8-bit: Summing Up (Part 1 of 4)

Dan,

I have a few quibbles with your summing-up.

Some digital cameras try to record 10-bit (1,024 possible values per channel,

a billion possible colors). Modern drum scanners try for 12-bit (4,096 values,

69 billion possible colors). Whether these devices are accurate to that level of

precision is very doubtful.

This point is not universally correct. For example, the Canon 1Ds and the 1Ds Mark II produce 12 bit files. As for scanners, my Minolta Dimage Scan Elite 5400 produces 16 bit files from scans, according to its sepc sheet. You would need to prove Minolta's published specs wrong before dimissing this spec as implausible.

"The question before us is not whether to capture in 16-bit, store in 16-bit, or

output in 16-bit. The only issue is, first, is there any advantage in *editing* files

in 16-bit rather than 8-bit, and if there is, it is so enormous as to constitute a

"night and day difference" or to justify the statement that anyone who does not

edit in 16-bit is a "recreational, rather than professional" user of Photoshop."

This statement of the question is a bit exaggerated relative to the merits of the choice. A difference does not need to be "night and day" for justifying one option versus the other. As long as there is a visible quality improvement, depending on one's standards of excellence it could make sense to opt for the 16 bit choice. The whole business about "recreational" versus "professional" is vitriol - it has no operational signifigance - the only thing that matters is whether the quality difference is visible in a print, whatever it is.

"........they recommend, whether it's 16-bit editing or wearing garlic around the neck

while writing curves, must be taken as gospel and that they have no

responsibility to back up what they say.

"Nobody offered a single real-world image to show this enormous difference. It was all histograms and gradients, gradients and histograms."

In his latest material published on the web forums, Andrew Rodney has presented files for downloading which he claims shows the difference in actual printed results. I have not downloaded them, so I can't confirm based on my own observation - but the fact is that at least this one person has taken the trouble to offer real evidence in support of a claim.

Remainder of the article: very thought-provoking. Anyone with any doubts needs to do these tests for ourselves and see whether our own minds' eyes agree with your findings!

Regards,

Mark

___________________________________________________________________________

Date: Mon, 31 Oct 2005 11:06:54 -0700

From: Andrew Rodney

Subject: Re: 16- and 8-bit: Summing Up (Part 2 of 4)

On 10/31/05 8:35 AM, "Mark Segal" wrote:

If the two sides can't agree, it probably means that Dan is right, because if

the differences were so obvious that no one in good faith could dismiss them,

there would be no debate - and I don't think it reasonable to accuse any one

of operating in bad faith.

Not at all. With the files I uploaded and worked on, it1s totally clear to ME that there1s an advantage. But then someone (no names please) will say this doesn1t count because the encoding is in a wide gamut space and no pro1s use this. Strawman arguments and simply not true. As Dan posted, I fully admit that the effects are far less an issue with a smaller working space. But I WANT to use ProPhoto RGB to fully contain the colors I1ve captured. At this point, the discussion went OT about the dangers (and there are some) of wide gamut spaces. There are advantages too. But if you want to poo-poo this space or that edit, you can easily mold an argument that attempts to illustrate that the other guys methods are silly and as such there1s no advantages to his use of high bit data.

This is why I1m at the point that I feel, the discussion is not worth continuing. At some point, no matter what justification you have (on either side), someone else can mold the argument in such a way as to derail the other guy.

Originally the debate was, no real world image shows high bit advantage. Now it1s no real world image in this or that gamut working space exhibits an advantage. Or, if you apply this or that edit, your test is invalid. When you make up the rules as you go, it1s easy to validate your side of the argument. Personally I find Bruce Lindblooms analysis fair. Some others do not. In the end, it1s up to someone1s opinion (and you know the old saying about opinions).

If everyone who ever subscribed to Dan's list believed either his points or my points about high bit editing, it really wouldn1t matter much in the big picture. It1s not going solve global warming or the bird flu. I1d hope each person would test the waters for themselves but if they1d rather read what an 3expert2 has to say and go that route, fine.

Dan says he1s never seen the benefits of high bit editing on output (and I assume it1s to that fine halftone process he1s using in his books). Jeff Schewe says he has. To each his own.

No one is operating in bad faith (although both sides have supplied some bogus statements and measured the process with rubber rulers). It1s now a religious belief system at play.

Andrew Rodney

___________________________________________________________________________

Date: Mon, 31 Oct 2005 18:25:21 -0400

From: Paco Marquez

Subject: Re: 16- and 8-bit: Summing Up (Part 4 of 4)

Hi Mr. Margulis,

I hope you take this request with the utmost respect with which it is intended.

I would like your permission to forward these emails to the Live Picture group. May I?

We are a small group of photographers who still make use of this program and we are all over the world. As you may imagine, we are all tech freaks and hungry for as much information as we can find and learn from. This post of yours is so great that I am sure all would be thrilled to be able to study it.

Of course, I will also phrase my request in a different manner if I may. I would like the LP group to receive your posts because your words are the lance that the emaciated caballero would use to defeat those gigantic, not windmills of error, but giants of confusion.

I know that you took a great deal of time putting it all down on "paper" and that you have your own list so if you deny my request I will understand and respect your wishes.

Respectfully,

Paco Márquez

661 McKinley St.

MIramar

San Juan, PR 00907

787-721-8554

787-587-7384 Cel.

http://www.pacomarquez.com

___________________________________________________________________________

Date: Tue, 1 Nov 2005 08:55:54 EST

From: Dan Margulis

Subject: Re: Permission to reuse

Paco writes,

I would like your permission to forward these emails to the Live

Picture group. May I?

Yes, certainly. Since this is the first day of the month, when we post list rules, I think it would be well to reemphasize the point that this question refers to.

On-line discussion groups exist for the rapid interchange of information that is useful to their members. I believe it is widely accepted (and our rules state it explicitly) that those who participate are throwing their ideas out to the public, and that their comments can be freely re-used.

*Supplements* to the text posts--such as images that are posted here or on other web-sites--are not covered by this. Anyone wishing to re-use somebody's image, article, PDF, etc., should be going to that person for permission first.

Dan Margulis

___________________________________________________________________________

Date: Tue, 1 Nov 2005 10:34:28 EST

From: Dan Margulis

Subject: Re: Matters of Opinion and Fact (was 16-bit)

Andrew Rodney writes,

Personally I find Bruce Lindblooms analysis fair. Some others do

not. In the end, it1s up to someone1s opinion (and you know the old saying

about opinions).

No, Andrew does not find Lindbloom's analysis fair--he is well aware that it is bogus. Yes, many parts of this discussion have been matters of opinion. But Lindbloom's page is based not on matters of opinion, but of fact. Namely,

1) He asserts that I sabotage my test files by converting them from 16-bit to 8-bit and back again to 16-bit before I test them, which "makes it into a non-test."

2) He asserts "There is no accountability--Dan's word is final. There has never been even a single case where the experiment could be performed independently by anyone else to see if the same result was obtained."

These two are *not* matters of opinion--they are either true, or they are false. And they are the linchpins of Lindbloom's page. The rest of what he says simply collapses without them.

Both of the above statements are categorically false. They have been exposed on this list, and brought to Andrew's attention, many times. Lindbloom knew that they were false when he posted them. Andrew Rodney has posted many, many links to this page with full knowledge of its falsity.

Dan Margulis

___________________________________________________________________________

Date: Tue, 1 Nov 2005 08:41:20 -0800

From: David Cardinal

Subject: RE: 16- and 8-bit: Summing Up (Part 1 of 4)

FWIW, when we have bench tested various current D-SLRs (including the 1D, D1X and the D2X) the noise (combination of internal & light scatter (aka lens flare)) is sufficiently large that the last 2-bits of precision are not typically meaningful.

The 10th bit is more controversial. Nikon reduces Raw files to 9.5 bits (although they do gamma encoding at the same time) when they do what they call "visually lossless" compression, but there are many photographers who rely on detail in the highlights that the Nikon compression flattens out (because of the gamma encoding) and find that the compression scheme ruins their images and refuse to use it.

I don't think anyone has tried to see whether a 10-bit linear encoding would actually be more useful than the 9.5 bit gamma encoded version Nikon uses, but it'd be a good exercise for a grad student someplace!

Modern zooms that we tested are also limited to about 10-stops (1000:1) total dynamic range in properly exposed scenes (due to lens flare), which actually lines up pretty well with the sensors' capabilities.

This is all getting trickier to measure since the very newest cameras are doing more analog "pre-conditioning" of the data before converting to digital so at some point the experiments are measuring the circuitry, not the sensor or lens.--David Cardinal

http://www.cardinalphoto.com

http://www.nikondigital.org

___________________________________________________________________________

Date: Tue, 01 Nov 2005 12:19:05 -0500

From: "Iliah Borg"

Subject: Re: 16- and 8-bit: Summing Up (Part 1 of 4)

That's true. I was not able to get anything more then 10 meaningful bits from any camera I tried. And I'm looking at raw data directly.

Best regards,

___________________________________________________________________________

Date: Tue, 01 Nov 2005 12:33:27 -0500

From: Tom Judd

Subject: Re: Enough Already! (was 16-bit)

Dan Margulis wrote:

No, Andrew does not find Lindbloom's analysis fair--

etc, etc, ad infinitum.

Dan, you obviously don't like these guys and the feeling seems to be mutual. So please take your personal pissing match offline and get this list back to something useful and informative.

ENOUGH ALREADY!!

___________________________________________________________________________

Date: Tue, 01 Nov 2005 12:03:24 -0600

From: Jeff Schewe

Subject: Re: 16- and 8-bit: Summing Up (Part 1 of 4)

On 11/1/05 Dan wrote:

In the mid-1990s, Photoshop introduced limited support for 16-bit files--

65,536 values per channel, 281 trillion possible colors. There was no

intermediate level.

Well, you might as well get the math right Dan...Photoshop has 15+1 bits accuracy, not 16 bits...so the total value of bits in a "16 bit" channel is 0-32,768 for a total of 32,769 discrete levels, not "65,536 values per channel" as you stated.

As for the rest of the lengthy quotes of Andrew, Bruce and myself-the "partnership" as you call it, well, I was worried for a while that you may have caught me in a moment of weakness, stating something that I would regret stating...I'm glad what you quoted me as saying was accurate and I still stand by what I have said. Use your bits wisely, waste them at your own risk.

So, refresh my memory...taking a nice well exposed shot of a landscape-is it within your rules to run a gradient darkening of the corners of the sky?

Cause it's pretty easy to break an 8 bit/channel image where a 16 bit/channel image will not band. Ya see, using layer masks to locally adjust tone and color is something that many if not most users of Photoshop must do. And, high bit masks are much better than 8 bit masks...of course, that may start yet another debate :~)

The thing some people forget is that when working in 16 bit (or high bit depth if you will-to remove the confusion about the total levels being 15 bit + 1) is that when in high bit depth, not only are your image pixels in high bit, but your layer masks and selection channels are as well. So, the argument might be made that when in high bit depth, not only are you conserving you image bits but receiving the benefit of the higher bit depth of your masks-and even Dan seems to now admit that higher bit depth of grayscale documents can provide an advantage...and yes, to be accurat, "Selections" in the current Photoshop are still 8 bit, but masks and channels in high bit depth images are high bit.

As for the rest of Dan's 4 part post...I'm still reading it...already got coffee up my nose from some of it (thanks for the laughs Dan, other life events recently have not been so, humorous).

Regards,

Jeff Schewe

High Bit Depth Advocate (used to be 16 bit advocate)

___________________________________________________________________________

Date: Tue, 1 Nov 2005 13:03:28 -0600

From: Howard Smith

Subject: Re: Enough Already! (was 16-bit)

Tom, I think you may be confusing technical disagreements with personal dislike. My own impression from reading these posts for the past couple of years is that the professionals on here do in fact have great respect for one another and undoubtedly go out together in a friendly group when they attend national seminars etc. Still, one can expect creative people to have strong differences of opinion and to express them in sometimes heated arguments. As I once commented on a bulletin board (one of those ancient communication forums before the Internet), if you find my messages disagreeable, just skip them. If you post any information here yourself, you may find others who will rip into it without mercy. It's a learning experience. When they're right, you've learned something. When they're dead wrong, just laugh and go on to the next post. I've have seen instances of completely uncalled for frontal assaults complete with name calling, but not from professionals.

I might add that these guys don't need me defending them, but I couldn't resist commenting on your post. Relax, Tom. Post something controversial yourself if you like fireworks :)

Howard Smith

___________________________________________________________________________

Date: Tue, 01 Nov 2005 15:10:55 -0500

From: Denton Taylo

Subject: Re: Enough Already! (was 16-bit)

With all due respect, Dan owns the list (pls see his monthly email prior). But if you don't like what Dan has to say, the delete key is handy.

___________________________________________________________________________

Date: Tue, 01 Nov 2005 15:13:49 -0500

From: Denton Taylor

Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of 4)

Hi Jeff:

I would like to take Dan's pov here, which is that if there are obvious differences, let's see them. Can you post an image with a gradient as you say, broken and unbroken?

At 01:03 PM 11/1/2005, Jeff Schewe wrote:

So, refresh my memory...taking a nice well exposed shot of a landscape-is it

within your rules to run a gradient darkening of the corners of the sky?

Cause it's pretty easy to break an 8 bit/channel image where a 16

bit/channel image will not band.

Regards,

Denton Taylor

photogallery at

www.dentontaylor.com

___________________________________________________________________________

Date: Tue, 1 Nov 2005 16:41:42 EST

From: Dan Margulis

Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of 4)

Jeff writes,

So, refresh my memory...taking a nice well exposed shot of a landscape-is it

within your rules to run a gradient darkening of the corners of the sky?

No. Computer-generated gradients have never been permitted, as everyone agrees that they can benefit from the extra bits if they are edited. "Recreational users" sometimes take their 8-bit photographs into 16-bit if they need to introduce a gradient.

But, if you ever do get the time to show us an example that doesn't have a computer-generated gradient, doesn't depend on an exotic definition of RGB, and doesn't involve intentional efforts to degrade the image, I'm sure a lot of people would be interested.<g>

(thanks for the laughs Dan, other life events recently have not been so,

humorous).

I am sorry to read the second half of this sentence. There seems to be a great deal of that going around this year, which suggests that there are many more appropriate things for us to get upset over than the number of bits in an image.

Dan Margulis

___________________________________________________________________________

Date: Tue, 1 Nov 2005 15:15:23 -0800 (GMT-08:00)

From: Kevin Connery

Subject: Camera bit depths (Was: Re:16- and 8-bit: Summing Up)

It seems to be very much camera-dependent. I've used a number of Canon's "12-bit" dSLRs, and the amount of detail in the darkest octave varies enormously. I photograph a lot of low key portraits, with critical information in the darker areas / shadows, and the 1D Mark II is much more effective than the 1D, 10D, or D60. How much that's due to pre-processing in their DIGIC units I can't tell, but there's functional detail that doesn't appear to be all noise. Those are almost exclusively printed on RA-4 photo paper via Chromira or Lightjet, not to CMYK.

I've also done a little bit of retouching on product photography (glassware) files from PhaseOne's P25 digital back, which uses a supposedly 16-bit/channel chip. The handling of real-world light gradients (photography was done on a shooting table, with colored [gelled] back- and under-lighting) was much easier in 16-bit than 8-bit--it didn't take much tone or color shifts to create visible banding in the glow with 8-bit files. Adding noise eliminated it, but it also removed the purity/sterility of the image as well. In LightJet transparencies, this was very noticable; in the printed brochures, it was not--demonstrating again that the output medium used also has an impact. Since these images were to be printed on backlit film for use at tradeshows as well as printed CMYK brochures, it was no longer a theoretical issue for this job--I had to redo the work for the transparencies starting back from the originals and stay in 16-bit. (Thank goodness for adjustment layers!)

Does anyone have measurements from the digital camera backs from PhaseOne, Imacon/Hasselblad/Leaf? Are they functionally making 14- or 16-bit captures in real life as opposed to "technical specifications"

Kevin Connery

___________________________________________________________________________

Date: Tue, 01 Nov 2005 17:52:32 -0500

From: Ric Cohn

Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of 4)

On Nov 1, 2005, at 1:03 PM, Jeff Schewe wrote:

I was worried for a while that you may

have caught me in a moment of weakness, stating something that I would

regret stating...I'm glad what you quoted me as saying was accurate and I

still stand by what I have said. Use your bits wisely, waste them at your

own risk.

Well, well we are getting to an agreement of sorts.

So, the argument might be made that when in high bit depth, not only are you

conserving you image bits but receiving the benefit of the higher bit depth

of your masks-and even Dan seems to now admit that higher bit depth of

grayscale documents can provide an advantage...and yes, to be accurat,

"Selections" in the current Photoshop are still 8 bit, but masks and

channels in high bit depth images are high bit.

Yes, this is a new slant to the High Bit debate that I've been hearing of late. Is this just a new way to cloud the issues and justify the argument after the fact (think Iraq and Bush) or is it a valid concern? It's always possible that people have seen real benefits when working in 16 bit but misinterpreted the reason why!

I have seen instances where banding in masks can cause problems and I've been aware that this is probably due to them being in 8 bits (although I've not done the tests to be sure the problem goes away in 16 bits). I have wondered whether there is any benefit to going to 16 bits when making/using masks. OTOH I'm not sure whether just adding a small amount of noise doesn't do as good a job. Dan did say that the kind of "smoothness" (ramdomness, noise??) introduced by working in 16 bits is hard to duplicate.

Is it true that switching to 16 bits allows smoothness in masks alpha channels that can't be compensated for in 8 bits? If this is true then it would possibly be a reason to switch to 16 bit mode if doing any kinds of masks- since you never know when these will band and whether the banding will cause problems that are hard to see until it's too late to get the supposed benefits of 16 bit. I could imagine a workflow where you convert 8 bit images to 16 bit before creating masks.

Ric Cohn

I've looked and never seen a High Bit advantage (but I keep looking)

___________________________________________________________________________

Date: Tue, 1 Nov 2005 21:15:19 -0200

From: Enio Leite

Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of 4)

Denton:

Let´s see if I got this straight:

Even a 16 bit INTEGER image only has 16 tones to describe the darkest stop in a 12 stop image, while for the brightest stop, 32,768 tones are available. This is the opposite of human vision which is more sensitive to shadow detail than to highlight detail. A 32 bit INTEGER image provides more tones but has the same limitation of having a disproportionate amount of tones for the highlights. 32 bit FLOATING POINT images address this issue by making more efficient use of the 32 bits. Instead of using 32 bits to describe 4,294,967,296 integer numbers, 23 bits are allocated to a fraction, 8 bits to an exponent, and 1 bit to a sign, as follows:

V = (-1)^S * 1.F * 2 ^ (E-127), whereby:

S = Sign, uses 1 bit and can have 2 possible values

F = Fraction, uses 23 bits and can have 8,388,608 possible values

E = Exponent, uses 8 bits and can have 256 possible values

Practically speaking, this allows for an almost infinite number of tones between level "0" and "1", more than 8 million tones between level "1" and "2" and 128 tones between level "65,534" and "65,535", much more in line with our human vision than a 32 bit integer image. Because of the infinitesimally small numbers that can be stored, the 32 bit floating point format allows to store a virtually unlimited dynamic range. In other words, 32 bit floating point images can store a virtually unlimited dynamic range in a relatively compact way with more detail in the shadows than in the highlights and take up only twice the size of 16 bits per channel images, saving memory and processing power. A higher accuracy format allows for smoother dynamic and tonal range compression. This format is important in the computer graphics industry (gaming and animation) and supported by Adobe Photoshop CS2, right?

Best regards!

Enio Leite

www.escolafocus.net

___________________________________________________________________________

Date: Tue, 1 Nov 2005 16:15:13 -0800

From: David Cardinal

Subject: RE: Re: 16- and 8-bit: Summing Up (Part 1 of 4)

Enio--There is one important missing variable, which is the gamma of the encoding. Gamma = 1 (linear) means that the lower stops have many less values than the upper stops (as you've pointed out in your post).

Higher gammas change this relationship. A high enough gamma evens things out so each stop has a similar number of possible values. That is one argument for gammas > 1 which do a better job of reflecting the point you make--that the eye is sensitive to changes in value, not as much to absolute values.

For example, by the time a (Raw) image is converted to Adobe RGB or sRGB the numbers of levels has been evened out quite a bit by the conversion.

The extra-confusing part is that almost all current digicams have native linear sensors, but most working spaces & photo-editing applications wind up in gamma-encoded spaces. So the "bits" get re-allocated along the way. Raw processing is often done in the linear gamma space and then photo editing in a working space with a higher gamma.--David Cardinal

___________________________________________________________________________

Date: Tue, 01 Nov 2005 19:25:55 -0500

From: Denton Taylor

Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of 4)

It all sounds wonderful in theory. All I'm saying, like Dan, is let's see the photos where it makes a difference (and Dan has already admitted that a sky gradient might be one of those instances).

At 06:15 PM 11/1/2005, you wrote:

A higher accuracy format allows for smoother dynamic

and tonal range compression. This format is important in the computer

graphics industry (gaming and animation) and supported by Adobe

Photoshop CS2, right?

Regards,

Denton Taylor

photogallery at

www.dentontaylor.com

___________________________________________________________________________

Date: Wed, 2 Nov 2005 01:57:09 +0100

From: Ben Richardson

Subject: Re: 16- and 8-bit: Summing Up

With thanks to Dan for his fine summation, to Andrew for his swift replies, and to the creator of the example hosted on visual-vacations (http://www.visual-vacations.com/Photography/16_vs_8.htm), I have at last been able to confirm my personal opinion on this matter.

I suggest 16 bit colour correction should be treated in much the same way as setting up levels and colour in scanner software prior to scanning a new frame - as a means to obtaining a file of *sufficient quality* for further work which may then be done as happily in 8 bit as in 16.

I would encourage everyone to visit the visual-vacations example, and to download and try the test themselves, but TWICE. Once as described, and once with one important change. Rather than running the complete action first in 16 bit and then in 8 bit as the author did, do the following:

Split the action into two separate actions, the first with ONLY the initial, huge levels adjustment, and the second containing the rest of the adjustments. Now run the levels part of the action on the original 16 bit file, THEN duplicate the file, convert one copy to 8 bit and run the rest of the action on both copies.

Now we see it exactly. There are clearly visible differences between the two versions, but whether one is better or worse, or would produce a better or worse print, has become a matter of opinion similar to Dan's examples. The shadowed wood at left is definitely smoother in the 16 bit, but somewhat more defined in the 8 bit, but doing the initial levels in 16 bit has clearly given us sufficient quality to work in either. (I do have to agree with Dan that the example is not exactly "real-world", but I don't think the multiple zero-tolerance sharpening is really the issue.)

If the actual 1Ds RAW file was available, you would never in a million years process it as dark as the Tiff the author supplies - you'd open up the shadows intelligently in Camera Raw or some other RAW converter. BUT if that Tiff were all you had (a real-world possibility, at least), clearly the big levels move only makes sense in 16 bit.

The original shadow area shows values between 0 and 1, thus with such a huge move to recover detail, Photoshop's math can only come up with the awful posterization seen in the original 8 bit example. However, in 16 bit, those same 0-1 values represent a few dozen levels at least, if my understanding of bit distribution is correct, more than enough to give us some real shadow detail to work with later. Obviously, there would be no advantage to simply crunching the numbers in 16 bit if the original dark Tiff had been an 8 bit file: those tones would be gone for good already, as we see in the author's version.

It is an extreme example, and somewhat unlikely in professional work, but it leads me to this:

To Dan's advice about taking 16 bit scanner or camera files if possible, and going to 8 bits in Photoshop, I would add: at least get the image in the ballpark while you're still in 16. I believe this was exactly Jeff Schewe's point when he wrote: "start your creative retouching in a "perfect 8 bits/channel". That only comes after doing initial tone/color corrections in 16 bit." This has actually been my workflow for some time, but it's nice to have it validated.

Summary: 8 bits IS as good as 16, just as long as it's a good 8 bits!

Many thanks again to all the contributors to this remarkable resource,

Ben Richardson

___________________________________________________________________________

Date: Tue, 01 Nov 2005 20:22:26 -0500

From: "Iliah Borg"

Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of 4)

11Mb file:

http://www.pochtar.com/kodak_224.jpg

demosaicing done in floating.

Best regards,

___________________________________________________________________________

Date: Tue, 1 Nov 2005 18:03:39 -0800

From: "Paul D. DeRocco"

Subject: RE: Re: 16- and 8-bit: Summing Up (Part 1 of 4)

What matters is the relationship between the size of the steps and the magnitude of the noise. The noise out of any camera or scanner will be many counts in amplitude in 16-bit mode, so having more in-between counts buys you exactly nothing. Furthermore, the noise is basically constant on a linear scale, so you get the same number of counts of noise amplitude at the dark end as you do at the light end.

Linear fixedpoint therefore matches the resolution to the noise level best. However, a gamma space of two-point-something is a better match to the eye, and therefore more convenient for editing in. The application of a gamma curve doesn't create much of a mismatch between the resolution and the noise level at the two ends of the scale, whereas the huge amount of low-end resolution you get from floating point is, well, pointless.

Ciao, Paul D. DeRocco

___________________________________________________________________________

Date: Tue, 1 Nov 2005 18:10:51 -0800

From: Paul D. DeRocco

Subject: RE: Re: 16- and 8-bit: Summing Up (Part 1 of 4)

From: Iliah Borg

11Mb file:

http://www.pochtar.com/kodak_224.jpg

demosaicing done in floating.

The point is what, exactly?

I don't know what camera that was taken with, but I've seen other hi-res Kodak images that, like this one, are extremely sharp because they don't use an antialiasing filter (or enough of one). And in this image, I can see faint moire in the screen, and some slight color artifacts on the left edge of the yellowish patch, which is about the only significant color in the whole picture. I doubt that that has anything to do with the interpolation being done in floating point, though.

Ciao, Paul D. DeRocco

___________________________________________________________________________

Date: Tue, 1 Nov 2005 18:44:07 -0800

From: Peter Figen

Subject: Re: Re: 16- and 8-bit: Summing Up

On Nov 1, 2005, at 4:57 PM, Ben Richardson wrote:

I would encourage everyone to visit the visual-vacations example, and

to download and try the test themselves, but TWICE. Once as

described, and once with one important change. Rather than running

the complete action first in 16 bit and then in 8 bit as the author

did, do the following:

There are a couple of problems with the example given here. The first is that I don't know anyone who would process a severely underexposed image using a linear gamma setting, a grossly overexposed one, but not under. Second, these images were processed in what is arguably one of the worst raw converters available. While this certainly shows 16 bpc to be better when the person processing the original raw file screwed up, there are enough questions about how the images were arrived at to merit further testing. For instance, what would a normally processed gamma corrected image look like, or images processed in alternative raw converters. CaptureOne from PhaseOne, in my experience always produces better shadow detail and lower noise than either Canon's own software or Adobe Camera Raw. I would love to see the original raw file for comparison.

For the record, virtually anytime I've seen posterization, it was there on the 16 bit file too. Canon files, the ones I'm most familiar with, seem to be extraordinarily sensitive to banding in the bright yellow-green range and processing in 16 bpc does nothing to help that. It seems to be an inherent limitation of the file structure that causes it to break much sooner than an equivalent scanned image. This is not an argument either way, just a not so casual observation that sometimes things are not as simple as they first appear.

___________________________________________________________________________

Date: Tue, 1 Nov 2005 18:56:37 -0800

From: Lee Varis

Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of 4)

On Nov 1, 2005, at 10:03 AM, Jeff Schewe wrote:

So, the

argument might be made that when in high bit depth, not only are you

conserving you image bits but receiving the benefit of the higher bit depth

of your masks-and even Dan seems to now admit that higher bit depth of

grayscale documents can provide an advantage...and yes, to be accurat,

"Selections" in the current Photoshop are still 8 bit, but masks and

channels in high bit depth images are high bit.

Real high bit masks and alphas have a noticeable advantage, unfortunately the high bit masks in Photoshop are only calculated at 8 bit precision which is like having all the weight but none of the benefit. I have done countless tests to try and validate the advantage to high bit layer masks in photoshop and I have been unable to see any visible benefit that wasn't duplicated by adding the .5% noise generated in the conversion out of 16 bit. I really long for a 16 bit "extract" mask but this is currently not possible.

Anyone with any experience working with Live Picture will attest to the significantly smoother blends possible with real high bit masks (all masks and "stencils" in Live Picture are calculated at 12 bits) Very obvious on screen and in all kinds of outputs. However, as we all know Live Picture is Dead Picture and so there is no viable alternative to Photoshop for image compositing and retouching (many who continue to use Live Picture will, of course, disagree)

Fortunately a modest amount of noise applied (then fade using Overlay) to any 8 bit layer mask or alpha channel can solve even somewhat severe cross fade banding in Layer masks. In all of my tests this addition of noise is always more effective at reducing banding than doing the layering/masking in 16 bits, flattening and converting to 8 bits. The banding introduced by image adjustments over 16 bit masked areas IS different than what you see in the 8 bit masks - mostly though the "bands" are still here just in slightly different locations and this can sometimes be seen as a benefit after a layered image has been flattened depending on the "colors and tones" under (or through) the banded mask. I'm not sure if some slight noise is added during the flattening process but once the file is converted to 8 bits most of the 16 bit mask banding is obscured by the .5% noise added in the conversion.

Frankly... there might be some slight advantage that isn't directly attributable to the noise introduced in the conversion to 8 bit but as I tend to use masks and alphas with huge multi-layered files I tend to shy away from working any bigger than absolutely necessary. Believe me large 16 bit layered files are extremely painful even with a dual G5 with RAID scratch disks.

Of course that is just my opinion - I could be wrong!

regards,

Lee Varis

http://www.varis.com

888-964-0024

___________________________________________________________________________

Date: Tue, 01 Nov 2005 21:59:21 -0500

From: Denton Taylor

Subject: Re: Re: 16- and 8-bit: Summing Up

A perfect example of 'why bother'?

Was that photo so hard that it couldn't be captured appropriately the first time around?

Frankly, both of the 'corrected' images suck.

At 07:57 PM 11/1/2005, you wrote:

With thanks to Dan for his fine summation, to Andrew for his swift

replies, and to the creator of the example hosted on visual-vacations

(http: //www.visual-vacations.com/Photography/16_vs_8.htm), I have at

last been able to confirm my personal opinion on this matter.

Regards,

Denton Taylor

photogallery at

www.dentontaylor.com

___________________________________________________________________________

Date: Tue, 01 Nov 2005 21:25:42 -0500

From: "Iliah Borg"

Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of 4)

The point is what, exactly?

The point is floating, and as such - is not exact :)

Floating point interpolation is doable, and on all the files I tried it produces less moire and artifacts then with methods (even using same interpolation routines).

Apple seems to share this opinion, as I heard Aperture (at least, partially) is also implemented in floating point.

Camera is SLR/c.

Best regards,

___________________________________________________________________________

Date: Tue, 1 Nov 2005 21:02:32 -0700

From: Ron Kelly

Subject: Re: 16- and 8-bit: Summing Up (Part 1 of 4)

David Cardinal wrote:

the very newest cameras are

doing more analog "pre-conditioning" of the data before converting to

digital

David:

What do you mean "pre-conditioning"?

Ron Kelly

___________________________________________________________________________

Date: Tue, 01 Nov 2005 22:29:22 -0600

From: Jeff Schewe

Subject: Re: 16- and 8-bit: Summing Up

Ben Richardson wrote:

Summary: 8 bits IS as good as 16, just as long as it's a good 8 bits!

In a nut shell, yes...that is the essence of what I have been advocating since I discovered the benefits of doing all major tone/color corrections in 16, er, high bit depth...including not just global (think scanner or Camera Raw) but also local through a mask or selection.

Regards,

Jeff Schewe

___________________________________________________________________________

Date: Tue, 1 Nov 2005 21:29:49 -0700

From: Ron Kelly

Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of 4)

Ric:

What circumstances cause banding in masks? I use masks as much as the next guy (I assume) but I'm not aware of any banding issues. I must be missing something here.

For what it's worth I have only had one image that I can think of that had a banding problem. Yes, that's one image EVER. It was a scan of a very high contrast image with a very light to medium dark sky, from a scanner. It had banding in it when I opened the file, before I did any editing to it. I rescanned it to no avail and finally had to select the sky and mess with it directly by painting and adding noise.

For the last three years or so I have been shooting digitally and I've not had ANY banding problems at all. My regular work is preparing files for off-set and ink-jet.

I feel that I probably do some pretty severe curving for things like enhancing shadow contrast, for example, where I'm pulling on the curves till their near vertical at times. While I do have many challenges in this discipline, banding or unwanted posterization has not been even a small problem.

The discussion of avoiding banding by editing in 16 bit is puzzling to me because it's a solution to a problem that I don't have.

Maybe I'm just lucky going around in my bubble of ignorance. Are others experiencing a lot of banding problems? How common is this?

I can't recall seeing this topic in too many posts on this forum but I'm sure there's a way to find out.

Ron Kelly

___________________________________________________________________________

Date: Tue, 1 Nov 2005 21:49:44 -0800

From: David Cardinal

Subject: RE: 16- and 8-bit: Summing Up (Part 1 of 4)

David:

What do you mean "pre-conditioning"?

Ron Kelly

That is what Nikon at least is using to describe the analog processing they do in their newest models like the D2X before the D/A conversion. They are not real open about exactly what they are doing during that phase, but it includes some type of color processing (in particular per channel amplifiers to help with white balance while not hurting color). Canon does some pre-processing as well, although I don't know if they use the term pre-conditioning for it.--David Cardinal

___________________________________________________________________________

Date: Wed, 2 Nov 2005 04:15:46 -0500

From: "Mark Segal"

Subject: Fw: 16- and 8-bit: Summing Up (Part 2 of 4)

If my memory serves me correctly, the argument about 8 vs 16 bit image editing developed before there was an issue about the merits of working in - say - ProPhoto versus Adobe RGB98. These are separate issues in time and in principle, eventhough the latter may impact the former. Hence it is not appropriate to cite this as an example of shifting ground or changing the rules. Dan is on record that based on his experience there are substantial risks and little perceptible merits to working in ProPhoto. He, therefore, is at least being consistent in pairing his technical preference for 8 bit editing with his technical preference for RGB98-type colour gamuts. If the argument has now "progressed" or been focused on the merits of 8 versus 16 bit editing in wide-gamut colour spaces, perhaps there is still more to say from a technical and objective perspective - not a matter of religion.

Mark Segal

___________________________________________________________________________

Date: Wed, 2 Nov 2005 08:20:42 EST

From: Dan Margulis

Subject: Re: rationale for monitor calibration

Ray Van Dusen writes,

On one of our dedicated printer station LCD monitors, I visually compared the

"eyeballed" created profile (with its lower brightness slider

setting) to the Optix/X-Rite created profile (with its higher

brightness slider setting) and they appeared surprisingly close at

least by eye (there was a slight color cast to the eyeballed

profile). They produced "similar" in-the-ballpark prints.

Before getting all tied up with concepts like "accuracy", you need to remember what the purpose of calibrating a monitor is. You are trying to get a good idea of what the final output will look like. Assuming that the final output isn't defective in some way, the goal is that when you see it, you shouldn't feel that you would have done the job differently if you hadn't trusted what you saw on the screen. If you have that annoying feeling from time to time, then you probably need to invest some time in calibrating. But if you *never* have that feeling, then you have already achieved 100% of the goal. "Improving" the monitor's "accuracy" does you no further good.

Are software/hardware produced profiles merely only slightly more accurate

(in terms of WYSIWYG) than eyeball produced ones?

It depends on whose eyeball is involved. The Apple routines are quite powerful. Somebody with a lot of experience should be able to generate a *more* accurate profile than hardware can. But not that many people have such experience.

If you're dealing with students, teaching them how to calibrate a monitor by eye would be a highly useful exercise because it serves as a surrogate for many other types of color problems that they'll face in the future. Get yourself a suite of half a dozen images for which you have reliable output. Don't let anybody touch the monitor's hardware settings, but have each student sit down for 10-15 minutes and try to make as nice a profile as he can. When he's done, save it out, reset the monitor to its original profile, and let the next student have at it. When enough people have tried it, get them all together, load their profiles one after another, evaluate the test images, and decide who did the best job, and why.

Dan Margulis

___________________________________________________________________________

Date: Wed, 02 Nov 2005 06:13:07 -0700

From: Andrew Rodney

Subject: 16- and 8-bit: Summing Up

On 11/2/05 2:15 AM, "Mark Segal" wrote:

If my memory serves me correctly, the argument about 8 vs 16 bit image editing

developed before there was an issue about the merits of working in - say -

ProPhoto versus Adobe RGB98.

Well both have been around and available for users of Photoshop the same time. The first incarnation of Adobe RGB (1998) was SMPTE-240M in Photoshop 5 and later named Adobe RGB (1998). ProPhoto was introduced around the same time (1998/1999) and perhaps earlier as ROMM RGB. Wide Gamut RGB was installed the same date and time as Adobe RGB (1998). It 3suffers2 if you have to use that term (which isn1t technically correct) the same issues in 8 versus high bit as ProPhoto RGB. Lastly, LAB has a heck of a lot of colors outside either ProPhoto RGB or Wide gamut RGB and yet, it doesn1t suffer the criticism although I see the same noise issues with my digital images uploaded using LAB as I do with ProPhoto RGB. So no, I don1t agree there has been a shift, only a means to ignore the man behind the curtain.

These are separate issues in time and in principle, eventhough the latter may

impact the former.

In principle, maybe but not in time. LAB predates ProPhoto and Adobe RGB (1998) by a long shot.

Hence it is not appropriate to cite this as an example of shifting ground or

changing the rules. Dan is on record that based on his experience there are

substantial risks and little perceptible merits to working in ProPhoto.

A record not agreed upon by many.

He, therefore, is at least being consistent in pairing his technical

preference for 8 bit editing with his technical preference for RGB98-type

colour gamuts.

Nope.

If the argument has now "progressed" or been focused on the merits of 8

versus 16 bit editing in wide-gamut colour spaces, perhaps there is still more

to say from a technical and objective perspective - not a matter of religion.

Well I agree that the obvious benefits of editing in high bit with the examples I posted have a technical objective. The religious aspect is how this has been ignored.

Andrew Rodney

___________________________________________________________________________

Date: Wed, 2 Nov 2005 08:20:04 EST

From: Dan Margulis

Subject: Re: Re: 16- and 8-bit: Summing Up

Ben Richardson writes,

I suggest 16 bit colour correction should be treated in much the same way

as setting up levels and colour in scanner software prior to scanning a new frame - as a means to obtaining a file of *sufficient quality*

for further work which may then be done as happily in 8 bit as in 16.

Remembering that there is to date no evidence that 16-bit correction is useful even on files of insufficient quality, to some extent this is the Tim Grey position. Anyone who is working on files that require such massive editing that they would provoke a visible difference between 8-bit and 16-bit editing has many, many more serious problems to worry about than bit depth.

In any event, anybody knowledgeable enough to get a benefit (if any) from editing in 16-bit is not going to be making a big levels move to try to correct a grossly bad image. If there was a major color cast it would be attacked by blending good channels into bad ones, and if there was an exposure issue it would be treated by assigning a false profile. Either way, the image would no longer be bad by the time the curves came out.

(I do have to agree with Dan that the example is not exactly "real-world",

but I don't think the multiple zero-tolerance sharpening is really the

issue.) If the actual 1Ds RAW file was available, you would never in a million

years process it as dark as the Tiff the author supplies - you'd open up the

shadows intelligently in Camera Raw or some other RAW converter. BUT if that Tiff

were all you had (a real-world possibility, at least), clearly the big

levels move only makes sense in 16 bit.

No. The original as processed does look a lot like a seriously underexposed image, such as one might encounter in real life. But assuming that how this sabotaged original reacts to editing would predict how a real-world image would is just like assuming that what happens with a computer gradient is going to happen with a real image. In both cases you're dealing with data that's far, far more accurate than what you would get in real life.

This example is an excellent photograph that was sabotaged by smashing it into a very small range. What's found in that limited range is more pristine even than a normally shot, normally exposed image--let alone a badly exposed original.

If the image were that dark because of incompetent photography as opposed to sabotage during acquisition, it would be so full of noise that any difference between 16-bit and 8-bit editing would be like a drop of water in a river. When digicams are starved for light you get a higher percentage of garbage even than if the scene were shot on film.

Even accepting for the sake of argument that editing this particular image in 16-bit gets a better result, which I don't accept, all it proves is that images that someone has intentionally sabotaged should perhaps be edited in 16-bit.

In the real world, we need to know how to correct underexposed images. We need to know how to help out images where somebody else has made a good faith effort to correct but has done a poor job. But we do not need to know how to correct images that somebody has deliberately tried to degrade. That just doesn't happen in the real world.

Dan Margulis

___________________________________________________________________________

Date: Wed, 2 Nov 2005 08:20:54 EST

From: Dan Margulis

Subject: Re: Camera bit depths (Was: Re:16- and 8-bit: Summing Up)

Kevin Connery writes,

I've also done a little bit of retouching on product photography

(glassware) files from PhaseOne's P25 digital back, which uses a supposedly

16-bit/channel chip. The handling of real-world light gradients (photography was done on

a shooting table, with colored [gelled] back- and under-lighting) was much

easier in 16-bit than 8-bit--it didn't take much tone or color shifts to create

visible banding in the glow with 8-bit files.

Then it sounds like you might be the guy who can come up with the elusive demonstration of the real-world file where real-world corrections work better in 16-bit than in 8-bit. Are these files, with a record of the steps that were done to them, available? Can they be released for publication?

Dan Margulis

___________________________________________________________________________

Date: Wed, 2 Nov 2005 08:46:02 -0500 (EST)

From: MARK SEGAL

Subject: Re: 16- and 8-bit: Summing Up

Andrew,

Let us not misunderstand precisely what I said: I did not say the wide-gamut colour spaces post-dated the 8 versus 16 bit argument. I said the arguments about the colour spaces post-dated the arguments about bit depth.

OK, Dan's views about the risks of using wide-gamut colour spaces may not be shared by many, but from my experience they cannot be dismissed either. I (and it turns out, others) have encountered situations where ProPhoto was playing havoc with colour and detail rendition (specifically in what I have referred to elsewhere as "Chinatown red". By moving these particular images back from ProPhoto to RGB98 I was able to rescue detail and better simulate the red tones in the prints. In these cases I was using 16-bit files. Bottom line: I too prefer to use a wide-gamut editing space because there are colours the Epson 4000/4800 printers "see" which ARGB98 does not, but I do have emprical evidence that one needs to be pragmatic about this choice.

Now, if you seem to be successfully demonstrating with "normal RGB colour images" that "normal kind of edits" in wide gamut colour spaces systematically produce visibly superior quality prints in 16 bit mode compared with 8 bit mode, this is evidence I think Dan should examine and comment on.

Mark Segal

___________________________________________________________________________

Date: Wed, 2 Nov 2005 08:45:32 -0800

From: Peter Figen

Subject: Re: banding in masks

On Nov 1, 2005, at 8:29 PM, Ron Kelly wrote:

What circumstances cause banding in masks? I use masks as much as the

next guy (I assume) but I'm not aware of any banding issues. I must

be missing something here.

I have often had banding in very subtle layer mask gradations that were painted in at opacities under 10 percent in near white areas of the image. It was obvious that there were too few levels spread across too great a distance. These instances were before layer masks were available in 16 bpc files, and I haven't had a similar type of masking recently, so I don't know if working in 16 bpc would make a difference.

___________________________________________________________________________

Date: Wed, 2 Nov 2005 08:49:17 -0800

From: David Cardinal

Subject: RE: Re: 16- and 8-bit: Summing Up

If the image were that dark because of incompetent

photography as opposed to sabotage during acquisition, it

would be so full of noise that any difference between 16-bit

and 8-bit editing would be like a drop of water in a river.

When digicams are starved for light you get a higher

percentage of garbage even than if the scene were shot on film.

Amen to that. Over the years I have had a handful of "once in a lifetime" images that were badly under-exposed--normally due to unavoidable issues & lack of prep time (endangered critter pops up suddenly when you're getting set up to shoot something completely different, etc.) and in each case noise has been the limiting factor in correction. The new noise processors are pretty good but there is a limit to what they can do after the fact. In those cases 8-bit has been the least of my worries!--David Cardinal

___________________________________________________________________________

Date: Wed, 2 Nov 2005 15:16:22 -0800 (PST)

From: John Opitz

Subject: Re: 16- and 8-bit: Summing Up (Part 2 of 4)

In fairness, the demand for images placed the

advocates in a difficult position.

There is no reason to doubt that they actually

believed their original wild claims were true

By the time they learned that there

was serious doubt that there was any 16-bit benefit at

all, let alone a night and day difference, they had already begun to promote

seminars about the benefits of the 16-bit workflow. Furthermore, Adobe,

largely at their suggestion, had begun to add 16-bit capabilities to

Photoshop which were being heavily hyped. As many of these advocates take

money or other support from Adobe, it would have been exceedingly

awkward if they had abandoned the

you-are-not-a-professional-if-you-don't-use-16-bit line.

I’ll tell ya’. You have hoots-fa. You have spunk. And those that do push products, ideas, most never state that they are a paid endorser, whether it’s for God and his almighty dollar (or other currency exchange) or a car, yacht or whatever is brought to the table, beside the main course. As well as capitalizing on what you’re mentioning. How is one to know that his/her endorsing is not being biased based on these benevolent (sorry this is the only word I can come up because if I use “paid”,”pay” this can be interrupted as a kick-back) offerings by said company involved? It would be hard for the endorser to say the product is not what it is hyped to be. Officially or unofficially. They should have been looking at testing, instead of looking at… chasing rainbows for that pot of gold. If this was to happen? Coming forward about it, that is. A thing would happen, what I call: “Truth or Consequences”. His/her credibility is at stake and a lot more at that. I would think that people all over the world would believe this is a common practice, though. But, you know how all that works. Unlike you, you write, speak with no deceit about things. You say, do; write about things that others would never dream of doing.

You brought up a very good point… I never lost the faith…. Just like a father to his own son, you’ve been there through the worse and best of times. When dark, stormy clouds would hover over an image-editing program (version 5/5.5, 7) we know so well. Like a concerned parent, you warned of the downfalls. Even if the advice fell on deaf ears. You’ve been there to lift one up like a savior out from the drowning flood that came upon it. While non-believers belittled some, for not seeing that the clouds would just pass. Sadly, their fate was not as fortunate. You gave strength and showed how to battle fears of utilizing other color spaces for editing images that would be better than editing in a single color space. You showed that conversions were not as frightening, as a child would have phobias about falling asleep in the night and having nightmares. To the Father of the False Profile. Your guidance on how color management can be used for color correcting by assigning, convert>assign a simple profile. You showed how discipline, speed, agility like a martial arts master to his students who uses his own inner physical strength to do things some would think is impossible without the use of man-made weapons (plug-ins), The Mysticism of Channel Blending. Your philosophies on working by the numbers approach, eliminating impossible colors, using common sense. To the way you lit the guided path for one. I will not thank you. For I would rather go to one knee and bow, to honor you. For the one that has snatched the pebble from your hand, telling you it is time for one to leave. May your wisdom and teachings, writings be the guiding light to a new dimension in color correction. These things will never be forgotten. Don’t ever sell out. You’re the last and the few of a rare breed. A toast to you. From my very good friend, Jack Daniels’ and myself.

John Opitz

___________________________________________________________________________

Date: Wed, 02 Nov 2005 19:09:26 -0500

From: Ric Cohn

Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of 4)

On Nov 1, 2005, at 11:29 PM, Ron Kelly wrote:

The discussion of avoiding banding by editing in 16 bit is puzzling

to me because it's a solution to a problem that I don't have.

Ron- If I create a mask from a layer or a gradient and then apply curves to it, I will frequently see banding if I look at the alpha channel. This isn't surprising as I've essentially been making edits to a computer generated 8 bit B&W image. Whether this banding is a problem is very image/adjustment specific. The banding in the resulting layer mask has to be severe enough and the layer it's applied to has to be sensitive enough to show it. I work on a wide variety of images and for most this does not create a problem.

I also believe that as (non-drum) scanners and digital captures improve this becomes less of a problem- not because the masks are any less banded, but because the images have better channels which are less subject to damage from adjustments. I've been saying for years that what matters is whether you have good bits to begin with! I wonder if the benefits the 16 bit advocates "see" isn't really the coincidence that captures greatly improved at the same time that 16 bit editing become feasible? It's true that I've had much less trouble with banding, etc. than I did in the past. I've attributed it to better working methods and better adjustments, but maybe I'm just as wrong about the reasons for my better work <g>.

Ric Cohn

___________________________________________________________________________

Date: Wed, 2 Nov 2005 21:24:17 -0800

From: J Walton

Subject: Re: Re: 16- and 8-bit: Summing Up (Part 2 of 4)

John,

Ummm....

I don't think Jack Daniels has been a very good friend to you. Where are you coming from with this post?

___________________________________________________________________________

Date: Wed, 2 Nov 2005 23:11:25 -0700

From: Ron Kelly

Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of 4)

On 2-Nov-05, at 5:09 PM, Ric Cohn wrote:

If I create a mask from a layer or a gradient and then apply

curves to it, I will frequently see banding if I look at the alpha

channel.

Ahh . . . now I'm getting somewhere. Why would I want to curve the mask? Is the mask on a layer curved along with the image data on said layer?

If not, do you copy the mask to a grayscale document and curve is there prior to pasting it back into the original layer?

Ron Kelly

___________________________________________________________________________

Date: Thu, 03 Nov 2005 10:16:04 -0600

From: Jeff Schewe

Subject: Re: 16- and 8-bit: Summing Up (Part 2 of 4)

John O wrote:

And those that do push products, ideas, most never state that they are a paid

endorser, whether it1s for God and his almighty dollar (or other currency

exchange) or a car, yacht or whatever is brought to the table, beside the main

course.

Mr. Margulis certainly _SHOULD_ know better than imply a level of unhealthy impropriety between the relationships of certain Photoshop testers and Adobe.

I have been an unpaid volunteer alpha tester for Photoshop since version 4.0. I can't count the hundreds1 or perhaps thousands of hours I've personally spent trying to work towards improving Photoshop for the simple motive of getting a better tool for my own work.

For Mr. Margulis or any of the other denizens of this domain to think that my opinions and philosophies are somehow effected by the fact I get to work, for free, improving Photoshop is pretty silly. The net sum I've received is a copy of each Photoshop version I've tested...so let's examine that. Several hundred hours of testing vs a single version of Photoshop? I would be lucky to be "making" a fraction of minimum wage...

I will admit that I have been paid by Adobe to write articles to be posted on Adobe's web site. But I see nothing about getting paid to write in the least bit unsavory. I have also occasionally been sponsored to speak and teach about Photoshop by Adobe. But if you think the relatively paltry amounts would do anything to alter my opinions, then you simply have never met me.

Mr. Margulis has met me. I'm pretty sure he knows the truth, even if his rather slimy attempt to discredit my/our reputations give insinuations to the contrary...

The statement: "As many of these advocates take money or other support from Adobe, it would have been exceedingly awkward if they had abandoned the you-are-not-a-professional-if-you-don't-use-16-bit line." is pure Dan Margulis bullshit, and he knows it...don't you Dan?

Perhaps Mr. Margulis should revise and amend his statements...if nothing else, be _VERY_ clear exactly _WHO_ he is talking about.

As for getting paid to endorse Photoshop, sorry, that's never happened.

Regards,

Jeff Schewe

___________________________________________________________________________

Date: Thu, 3 Nov 2005 07:24:59 -0800 (PST)

From: John Opitz

Subject: Re: 16- and 8-bit: Summing Up (Part 2 of 4)

Good Morning, Mr. Walton,

<< I don't think Jack Daniels has been a very good

friend to you.

Yes, true. But that was Saturday, October 28(pool party). When he turned into the “Blood of Satan”. When the Jagermeister and Goldschlager dropped in and corrupted him. When these guys get together you have to make sure you have the Roman Rituals handy. Preferably, book marked. You know what its like to go through the Roman Rituals? Unless you’re a priest, you can down a six-pack before you find what you’re looking for. And don’t forget the holy water. You don’t want to get into a situation like I did. I had to start blessing my pool to use water from that. My intention was to have “The Three Wiseman” just drop in., Jack Daniels, Jameson and Jose Cuervo.

Where are you coming from with this post?

Gods’ Country, Texas.

On a serious note. Because of the negative waves in the past from this topic. I felt it was due, positive waves. To appreciate his time donated to this list. What he has done for the P.S.community. As well as others on this list that contribute heavily to it. And I don’t have to list their names. You see them all the time. Hey…I thought I was on a roll with the poetic way I typed. I was serious about it. What can I tell you, I won’t give up my day job? But, you have to cut me some slack. I’m not an author…. Or a writer either. I got my spelling right! I have to stop now because, I owe! I owe!, off to work I go!

John Opitz

___________________________________________________________________________

Date: Thu, 3 Nov 2005 08:49:48 -0800

From: David Cardinal

Subject: RE: Re: 16- and 8-bit: Summing Up (Part 2 of 4)

I have been an unpaid volunteer alpha tester for Photoshop

since version 4.0. I can't count the hundreds1 or perhaps

thousands of hours I've personally spent trying to work

towards improving Photoshop for the simple motive of getting

a better tool for my own work.

FWIW, knowing Jeff, Bruce & Dan, nothing is capable of stopping any of them from saying what they think, normally about the same time they think it :-)

In terms of 8-bit vs. 16-bit, the one area I'm personally most curious about is skies. I don't fully understand all the interactions between initial bit depth, some of the processing I might do (like with PixelGenius burn effect), printer profiles, and driver/RIP, but I do know that for my photography (mostly nature & wildlife) skies can be much more challenging than I initially expected.

I'd be delighted to hear others results in this area.

In my case I've found skies (when reproduced in large prints in particular) to be a valuable yardstick for evaluating printer profiles and profiling solutions. None of the scanner based profile creation systems did that great a job (this is with an Epson 4000 and various papers), while both ProfileMaker and the profiles available with ImagePrint have done much better. I'm getting a copy of PrintFix Pro to evaluate next, as I'd love to be able to recommend a solution to my readers that was less expensive than ProfileMaker + Eye-One.

--David Cardinal

Note: The above post provoked a valuable thread on characteristics of skies. That thread is posted under "Skies" in the Color Correction section.

___________________________________________________________________________

Date: Thu, 03 Nov 2005 19:09:40 -0000

From: "colorman042000"

Subject: Re: 16- and 8-bit: Summing Up (Part 2 of 4)

--- In colortheory@yahoogroups.com, John O wrote:

On a serious note. Because of the negative waves in

the past from this topic. I felt it was due, positive

waves. To appreciate his time donated to this list.

What he has done for the P.S.community. As well as

others on this list that contribute heavily to it. And

I don't have to list their names. You see them all the

time. (cut)

Well said Jon! I would like to add that Dan is a man of convictions, has a clear vision of "what ought to be", he is not wishy-washy, he has strength and *flavor*, a bit abrasive on the edges, those are the attributes(like it or not)of a good teacher and leader in his field.

Andre Dumas

___________________________________________________________________________

Date: Thu, 03 Nov 2005 15:13:56 -0500

From: Ric Cohn

Subject: Re: Re: 16- and 8-bit: Summing Up

On Nov 3, 2005, at 11:16 AM, Jeff Schewe wrote:

As for getting paid to endorse Photoshop, sorry, that's never happened.

Jeff,

While I'm sure this is true I have always assumed that the national exposure, paid speaking engagements, endorsements and other benefits would bring an economic kick to your bottom line. If not, you're not working it enough!

I know other writers and speakers that because they are in the "photo" consumer's eye get access to printers, cameras, lighting gear, etc. in exchange for testing and/or giving presentations on using these products. Do these people really like these products: for the most part I assume so- there is a lot of great equipment out there. Does the fact that they get the newest stuff for free only as long as they are super positive about it affect how they express their opinions- yes, I assume it would have to. Certainly, just the fact that you can judge something without considering it's dollar cost to you personally has to make a difference.

This is a long winded way of explaining how I personally read Dan's comments. I can't speak for anyone else.

Regards,

Ric Cohn

___________________________________________________________________________

Date: Fri, 04 Nov 2005 14:47:34 +1300

From: Kevin Crosado

Subject: Re: banding in masks

The banding in the resulting layer

mask has to be severe enough and the layer it's applied to has to be

sensitive enough to show it. I work on a wide variety of images and for

most this does not create a problem.

The finished product also comes into it - you can see all manner of evils on a computer monitor at 100% that disappear in a print. Sort of like in the days before CTP, when the banding in Quark gradients used to give me kittens when checking the film, but it never appeared in the finished jobs, even single colour ones.

Regards

Kevin Crosado

De Selby Research

___________________________________________________________________________

Date: Fri, 04 Nov 2005 09:37:13 -0500

From: Ric Cohn

Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of 4)

Ron- I frequently use a channel as the beginning of a mask. I then apply it either as a selection when making an adjustment or as a mask for an Adjustment or regular Layer. Even applying a blur can introduce banding if there are too few tones to begin with. If I make changes that create banding in a mask there is the possibility that the banding will "show through" to my image layer. Does that clear it up?

Ric Cohn

___________________________________________________________________________

Date: Fri, 4 Nov 2005 12:26:16 EST

From: Dan Margulis

Subject: Re: Re: 16- and 8-bit: Summing Up (Part 2 of 4)

Jeff Schewe writes,

I have been an unpaid volunteer alpha tester for Photoshop since version

4.0. I can't count the hundreds1 or perhaps thousands of hours I've

personally spent trying to work towards improving Photoshop for the simple

motive of getting a better tool for my own work.

Wow. No wonder you haven't had time to find a single image that suggests that 16-bit color editing is better than 8-bit. Adobe must be very grateful to you for spending all this time, and I daresay you must have made some really close friends in the company.

I will admit that I have been paid by Adobe to write articles to be posted

on Adobe's web site. But I see nothing about getting paid to write in the

least bit unsavory. I have also occasionally been sponsored to speak and

teach about Photoshop by Adobe.

Indeed, and some very posh worldwide destinations they pick, too. Not to mention the endorsements of your products from Adobe personnel, the favorable placements of your products on their website, and their generous support of you as editor-in-chief of their public relations site.

Mr. Margulis has met me. I'm pretty sure he knows the truth, even if his

rather slimy attempt to discredit my/our reputations give insinuations to

the contrary..

There is nothing illegal, unethical, or slimy about software companies giving money to those they think they can help them, and there is nothing illegal, unethical, or slimy about people taking it from them. We have at least two full-time Adobe employees on this list, and there's nothing slimy about the money they take, either.

Their contributions are valuable. They usually stress the positive aspects of Adobe products, and correct misconceptions about them if they can. If Adobe happens to do something that they personally don't approve of, they'll just keep quiet. If they, like me, strongly believe that Adobe management is damaging quality by forcing unreasonable turnaround times on its programming teams, or that Adobe shouldn't permit you and Chris Cox to bash users in the disgraceful way that you both do, readers understand that employees sometimes just have to bite their tongues. And so we respect what they write--because they explicitly identify themselves as working for Adobe.

The difficulty is not with those who admit their affiliations, but with shills--"independent experts" who don't reveal that they're deeply in hock to the company that creates the software they make their "independent" comments about. The phenomenon is not limited to Photoshop, and it's not limited to Adobe. It's a logical response to the growing importance of online commentary. Back in the old days, the vendors had similar cushy relationships with trade magazines, who always seemed to have favorable things to say in their "independent" comments about the products of their largest advertisers.

At least with the magazines, though, you could see that they were taking money from the vendors. A lot of today's shills, you can't. This is not the fault of the vendors, who may have perfectly valid other reasons for paying the person. Nobody has to be a shill--a person makes *himself* a shill by a conscious decision to hide the fact that he can't afford to say bad things about the vendor. All that a person has to do is disclose the relationship, and then readers can use their own judgment as to how much weight to give to his comments, and nobody can accuse him of any impropriety.

This has always been my POV, for all products, not just Photoshop. This list has always had the following rule:

"CONFLICTS OF INTEREST

Members are entitled to know if posters have commercial affiliations that might affect their views as to the products and topics they post about. If you have such an affiliation, you are expected to disclose it. This doesn't mean in every post, but often enough so that the readers will be in no doubt as to what your biases might be. For the purpose of this list, if you're writing about a certain product, and you've accepted money from that company within the last five years, that's something that should be disclosed."

The statement: "As many of these advocates take money or other support from

Adobe, it would have been exceedingly awkward if they had abandoned the

you-are-not-a-professional-if-you-don't-use-16-bit line." is pure Dan

Margulis bullshit, and he knows it...don't you Dan?

I know that you have just admitted that you take money and other support from Adobe. As to the other statements that came in the two sentences before the one quoted above, one asserted that Adobe was at that time hyping, as a major reason to buy Photoshop 7, the inclusion of more 16-bit capability. The other claimed that at the time, certain 16-bit advocates were marketing seminars where one of the main benefits being advertised was learning the 16-bit workflow. If you are disputing either of these assertions, then there's probably room for a little historical research and discussion. But if we accept that 1) Adobe was hyping 16-bit workflows; 2) a person was selling seminars hyping 16-bit workflows; and 3) the same person was also taking money from Adobe--then it seems as a matter of logic that it might have been awkward for that person to suddenly discover that there was no benefit to color correction in 16-bit.

As for getting paid to endorse Photoshop, sorry, that's never happened.

A couple of weeks ago I had a great dinner at Elizabeth on 37th, a Savannah restaurant that I am happy to recommend. In addition to a highly commendable presentation of tasso, shrimp, and grits, they serve a great coffee. When I finished mine, they gave me a second cup for free, and then a third.

I actually anticipated that they might offer it, and in fact I secretly thought that I had already paid for the free coffee by buying that nice dinner. Nevertheless, I thanked the servers for their kindness.

The problem with taking money from the companies one writes about is that, like restaurant patrons, it's sometimes hard to know what they think their money entitles them to get for free.

Dan Margulis

___________________________________________________________________________

Date: Sat, 05 Nov 2005 21:08:37 -0600

From: Jeff Schewe

Subject: Re: Re: 16- and 8-bit: Summing Up (Part 2 of 4)

Dan Margulis writes:

Wow. No wonder you haven't had time to find a single image that suggests that

16-bit color editing is better than 8-bit. Adobe must be very grateful to you

for spending all this time, and I daresay you must have made some really close

friends in the company.

I have plenty of images whose benefits of editing in 16 bit is easy to see. Problem is that most if not all have a variety of adjustment layers with soft-edged selections or gradients, which fail Mr. Margulis 's stink test for no "synthetic gradations".

As for my having friends in the company, not so much-I have a lot of friends on the engineering staff of Photoshop-and yes, they do appreciate the time & effort I spend trying to make Photoshop better. Contrast that with certain grumpy old men who seem to go out of their way to insult, attack and generally approach the engineers in a mean-spirited way. I've found that my method, over time, works a heck of a lot better-if you want functions and features added to Photoshop.

Indeed, and some very posh worldwide destinations they pick, too. Not to

mention the endorsements of your products from Adobe personnel, the favorable

placements of your products on their website, and their generous support of

you as editor-in-chief of their public relations site.

Ding, ding, ding...sorry, wrong, thank you for playing our game :~)

Not sure what posh worldwide destinations Mr. Margulis is referring to, in fact I have no idea WHAT he's referring to. However, the rest of this paragraph is typical crap. I have no idea if _ANY_ Adobe personnel have EVER made any " endorsements ". If they have, I would love to see/read them. As a rule, Adobe employees are precluded from making any public endorsements or testimonials. Privately, yes, they have expressed a degree of "support" to me.

As for "favorable placements of your products on their website", perhaps Mr. Margulis might want to read the terms of the membership benefits of the Adobe Solutions Network (ASN). PixelGenius is a member of the ASN. Part of the membership is a listing as a developer. As far as I know, that's the _ONLY_ place our products are listed-and no, the "favorable placements" are something we pay for as a member of ASN. We don't get anything like that for free.

As for PhotoshopNews.com, if Mr. Margulis took the time to actually read the "About PhotoshopNews", he would find the following statement:

"PhotoshopNews is not affiliated with Adobe Systems Incorporated. Adobe and Photoshop are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries."

See: <http: //photoshopnews.com/about-photoshopnews/>

PixelGenius is the sole owner of PSN. And since we take neither sponsorship nor advertising, my role as editor-in-chief is completely without Any compensation. So, I'm unclear just exactly what "support" he thinks Adobe gives me on "their site" (which is our site). If he is referring to the fact that I seem to have a lot of access, yes. I do. See above...I get along with the engineers real well.

But, as to relations with the rest of Adobe, in point of fact, we had a rather bloody fight with Adobe legal just to get permission to use the "Adobe ®Photoshop®" anywhere on the web site.

As to the other statements that came in the two sentences before the one

quoted above, one asserted that Adobe was at that time hyping, as a major

reason to buy Photoshop 7, the inclusion of more 16-bit capability. The other

claimed that at the time, certain 16-bit advocates were marketing seminars

where one of the main benefits being advertised was learning the 16-bit

workflow. If you are disputing either of these assertions, then there's

probably room for a little historical research and discussion.

Perhaps Mr. Margulis' memory is indeed failing him. If he is referring to a series of seminars called "Digital Imaging For Photographers" (DIFP), that Bruce Fraser, Andrew Rodney and I spoke at, the seminar series was done for the Advertising Photographers of America (APA) with the proceeds of the events going to APA. So the characterization that I was "selling" anything is completely untrue. The thing I was doing for APA was to GIVE them the proceeds (mid-5 figures) and promote high quality digital imaging workflows-including working in 16 bit.

So, what exactly was I "selling" Mr. Margulis?

If he was referring to a series of seminars I gave for Apple called "The Art of High Resolution", those were done for Apple, and they were free to attendees. Again I wasn't selling anything...but did advocate 16 bit...at least I'm consistent :~).

Ironically, Mr. Margulis regularly speaks at Photoshop World. The single largest sponsor of Photoshop World is Adobe...go figure...

But if we accept that 1) Adobe was hyping 16-bit workflows; 2) a person was

selling seminars hyping 16-bit workflows; and 3) the same person was also

taking money from Adobe--then it seems as a matter of logic that it might have

been awkward for that person to suddenly discover that there was no benefit to

color correction in 16-bit.

1) Adobe _WAS_ promoting 16-bit workflows...

2) I was _NOT_ selling seminars-I was speaking at some...

3) The amount of money I've received from Adobe post dates considerably, any of the time frame Mr. Margulis is referring to. Photoshop 7 shipped in April of 2002. The only Adobe-paid speaking I've done was at PhotoPlus Expo in 2003, and again in 2004 relating to Photoshop CS. The paid writing was done in 2004, again relating to Photoshop CS-which already had 16 bit. So, his allegation that I would find it "awkward" to do anything regarding Photoshop 7 because Adobe paid me money doesn't compute. Either his memory is failing him, he didn't check his facts or his motives and agenda is showing...

Contrary to Mr. Margulis's assertions, I _STILL_ strongly believe in a 16 bit workflow for all major tone and color corrections, both globally and locally. And, not only am I a strong advocate of 16 bit, I'm also pushing hard to get more 32bit HDR into Photoshop, cause for me, even 16 bit isn't enough.

Mr. Margulis has so alienated the Photoshop engineers that I doubt he will EVER have any future opportunity to have any input to the development of Photoshop. Which is really a shame since he certainly could have a lot of useful contributions. He has considerable knowledge to share...is an excellent teacher and a personable fellow in person. But for some reason, when he writes his diatribes, his mean-hearted side takes over and he looses any sense of decorum, and he also loses the the ability to actually contribute in any sort of meaning manner.

Personally, I couldn't care less what Mr. Margulis thinks of me...but he does a serious disservice to the industry when he distorts the way this industry runs...he knows better, or should.

I'm not going burden the list with any further discussion regarding my integrity...I don't need to do so and those people who know me, know where I am coming from... I'll let you, the readers decide...

Regards,

Jeff Schewe

16-bit is for wimps...give me 32-BIT!!!

___________________________________________________________________________

Date: Sun, 6 Nov 2005 07:24:47 -0400

From: Paco Marquez

Subject: Re: Re: Re: 16- and 8-bit: Summing Up (Part 2 of 4)

Gentlemen, I am a photographer who is trying his best, day in and out, to learn as much as possible from as many experts as possible. And so I came to subscribe to this list.

I am nothing special and as such you might diss me for what I am about to say but please understand that I say it with the utmost respect and gratitude to all you big honchos involved in this back and forth.

This thread is getting a bit personal for my taste and I wish you gentlemen would take it "outside" please. Mr Margulis, I know this is your group and I am just a guest here so I don't say this lightly.

If you are going to keep this tirade going for much longer it is just going to get nastier and more personal than it now is. I am saddened and a bit ashamed by this. The worst part is I can see no end to it unless you all duel each other and then win your argument by being the sole survivor.

I enjoy and learn immensely from your disagreements and historically, disagreements have led the arts and the sciences to great achievement not to mention something as small in the scheme of the universe as 8 or 16 bits. But your responses to each other are getting too personal for myself who comes here to learn from "all" of you. It is up to me to try out your techniques and theories, and then adopt and adapt what you have taught.

Please make us see you disagree in a spirit of goodwill and respect for one another.

To you all my most sincere wishes for Peace, Health, Love, Gold and Time!

Paco Márquez

661 McKinley St.

MIramar

San Juan, PR 00907

787-721-8554

787-587-7384 Cel.

http://www.pacomarquez.com

___________________________________________________________________________

Date: Sun, 06 Nov 2005 11:43:56 -0800

From: Marco Ugolini

Subject: Re: Re: Re: 16- and 8-bit: Summing Up (Part 2 of 4)

For what it's worth, I share Mr. Marquez's very sensible remarks, and subscribe 100% to the spirit of his message.

Best regards.

--------------

Marco Ugolini

Mill Valley, CA

___________________________________________________________________________

Date: Mon, 07 Nov 2005 11:10:30 -0400

From: Lee Clawson

Subject: Re: Re: Re: 16- and 8-bit: Summing Up (Part 2 of 4)

Paco and Marco,

Include me too !

Dan I, unlike you who had to spend an enormous amount of time thinking, writing, and responding don't find the on-going posts, as you describe, to have "wasted far more time than it could possibly merit over the last half-decade". What Andrew (re)started in early September and continued to date has made me rethink how I work. What you, Lee Varis and others had to say made me rethink how it is or could be applied.

My colleagues have written to me saying that reading through this stuff makes their hair hurt. Sometimes I feel this way too, sometimes like I'm reading court transcripts. But a waste of time has never come to mind.

Lee Clawson

___________________________________________________________________________

Date: Mon, 7 Nov 2005 11:44:28 -0500

From: Henry

Subject: Re: Re: Re: 16- and 8-bit: Summing Up (Part 2 of 4)

On Nov 5, 2005, at 10:08 PM, Jeff Schewe wrote:

Mr. Margulis has so alienated the Photoshop engineers that I doubt he will

EVER have any future opportunity to have any input to the development of

Photoshop. Which is really a shame since he certainly could have a lot of

useful contributions. He has considerable knowledge to share...is an

excellent teacher and a personable fellow in person.

This doesn't seem, on the surface, to speak very well of the Photoshop engineers. Such a statement might also be taken by some as a validation for the suspicion that has been sensed about the Adobe attitude by a growing number of product users.

My hope is that they take note when Mr. Margulis makes recommendations. The same goes for your input, Jeff. It is troubling when you find a corporation shutting off input from all but the insiders.

Just an observation.

Henry Davis

___________________________________________________________________________

Date: Mon, 7 Nov 2005 12:51:14 -0800

From: "Mike Russell"

Subject: Re: Re: Re: 16- and 8-bit: Summing Up (Part 2 of 4)

From: "Lee Clawson"

...

My colleagues have written to me saying that reading through this stuff

makes their hair hurt. Sometimes I feel this way too, sometimes like I'm

reading court transcripts. But a waste of time has never come to mind.

Hair always hurts when the conventional wisdom is controverted. This is an indication that careful thought and a return to basic principles are needed.

While I applaud cordiality, and believe that Dan has been exemplary here, in human affairs the conflict of important ideas has always been accompanied by a parallel conflict of personalities.

Mike Russell

www.curvemeister.com

___________________________________________________________________________

Date: Mon, 07 Nov 2005 14:51:46 -0500

From: Steve Hirsch

Subject: Re: Re: Re: 16- and 8-bit: Summing Up (Part 2 of 4)

I wholeheartedly agree with Paco. As someone who mostly lurks on this board I would add that I might choose to get more involved in this board1s discussion threads if I didn1t feel that I would be stepping into a mudslinging firestorm by doing so.

Just my 2c

Steve

Steve Hirsch, Systems Manager

Hachette Filipacchi Media, U.S.

1633 Broadway

New York, NY 10019

212-767-6536

___________________________________________________________________________

From: Dan Margulis

Date: FriÊNovÊ11,Ê2005Ê 1:30 pm

Subject: Re: [colortheory] Re: Re: 16- and 8-bit: Summing Up (Part 2 of 4)

Henry Davis writes,

This doesn't seem, on the surface, to speak very well of the Photoshop

engineers. Such a statement might also be taken by some as a validation for the

suspicion that has been sensed about the Adobe attitude by a growing number of

product users. My hope is that they take note when Mr. Margulis makes

recommendations.

The underlying point is well taken, but it gives me too much credit. The historical problem is that, while there are some people at Adobe who take criticism well, there's at least one member of the Photoshop team who's so arrogantsthat he can't even consider the possibility that he's ever wrong, and at least one other who's so shy that he can't cope with disagreement. The unfortunate result is that the Photoshop team listens almost exclusively to bootlickers and sycophants who are guaranteed to greet anything they do with wild applause.

Historically, the stability and reliability of the Photoshop software has been outstanding in comparison to that of other Adobe products and those of other vendors, or at least it has been up until the release of Bridge, which is not sreally a product of the Photoshop team. OTOH, since 1998 there have been four major corrective upgrades necessitated not by bugs but by mistakes in concept--Photoshops 5.0.2 and 7.0.1, which corrected badly thought-out color behavior, and Bridge 1.0.1 and 1.0.2, which were necessitated by the irresponsible decision to take File Browser out of Photoshop before it was clear that the replacement for it actually was stable enough to ship to customers.

This is an excessive number of "concept" corrective updates, one that users shouldn't have had to put up with. Every one of them could have been avoidedhad my advice been taken. In every case, I gave that advice long before the actual release. In every case, between the release but before the correctiveupdate, Adobe employees and shills publicly called me unseemly names forsuggesting that there was something wrong, but never apologized after the problems were corrected.

The corrective updates, obviously, weren't needed because *I* found the original releases unsatisfactory, but rather because thousands of other users did as well. So the question must be not why Adobe didn't listen to *me*, but whythey couldn't find any of these other users to listen to.

It is troubling when you find a corporation shutting off input from all but

theinsiders.

It is, but there's always room for hope--or for Adobe to do its own internal corrective update.

Dan Margulis

Receive Schedule and Pricing updates.

Receive Schedule
and Pricing updates.