Heresy...HERESY I say! I will not give up 16Bit

Mitch

Before I begin. How many of you, like me, process your images in 16 bit waiting until the last moment to convert to 8 bit for printing? Always saving that 16 bit file? I would bet quite a few of you.

I am somewhat behind in my reading. I just finished Chapter 6 of "Photoshop Lab Color". I am sorry to say I have not been following along with the thread, but I did go and read the review of this chapter before writting this. gefillmore did a very good job of summarizing this chapter even mentioning the point of this post:

>The technical half.

• the author goes into detail about how converting to LAB and back will not hurt the image
• he also discusses using an 8 bit vs. 16 bit file

>

"he also discusses using an 8 bit vs. 16 bit file"

Except for the rare exception the author says that there is no advantage, let me say that again "NO ADVANTAGE", to working in 16 Bit. He goes on to suggest that the file should be opened in Photoshop as a 16 bit, when converting from raw I am guessing, then converted to 8 bit for all PSing.

I am paraphrasing, " working in 16 bit is like wearing a belt and suspenders".

I will say I am enjoying this book very much and am learning a lot, but I am not ready to give up my 16 bit files. I'm happy with my belt and suspenders THANK YOU!


Mitch

rutt

Dan's 8 vs 16 bit argument has been around a long long time and generated a lot of heat on other boards and on his mailing list -- http://groups.yahoo.com/group/colortheory/

Dan has an outstanding challenge -- Show a real image gand a real workflow where processing in 16 bits results in a visibly superior end product. This has been around a long time and nobody has satisfied Dan.

Dan also has a fairly subtle mathematical argument as to why this is. You need a little statistics background to follow. Read the relevant part of chapter 6 carefully if you care.

Personally, I do exactly what you do. My computer is fast enough that processing in 16 bits doesn't really bother things. It won't produce worse images. So I'm lazy and only convert when saving at the end. On my laptop, which is very slow by comparison, I do sometimes convert to 8 bits early.

Here's where you are in this discussion: you are playing chess with an international grandmaster famous for the the strength and subtlety of his opening game. He has opened with move you, a occasional recreational player, have never seen before.

How do you want to approach this situation? You can't win this game without a lot of work, maybe a whole lifetime's worth. Do you care enough? If so, you better start reading your opening books and playing tournaments and going to the best clubs. The Photo Finish forum of dgrin isn't one of those best clubs, actually the game isn't played here at all. Start by really reading chapter 6 in detail and then join Dan's mailing list and dig tough his archives.

No way can or should this discussion be reproduced on dgrin. Just take my word for that.

Shay Stephens

My biggest reason for working in 16 bit is for gradients. I run into posterization problems in 8bit, and less when working in 16bit. So for consistancy sake, no matter the image, I always work in 16 bit mode.

Mitch wrote:

Before I begin. How many of you, like me, process your images in 16 bit waiting until the last moment to convert to 8 bit for printing?

rutt

Shay Stephens wrote:

My biggest reason for working in 16 bit is for gradients. I run into posterization problems in 8bit, and less when working in 16bit. So for consistancy sake, no matter the image, I always work in 16 bit mode.

Shay, here's your big chance to be world famous (among a small circle of friends) reproduce the workflow and show the results and post to Dan.

Dan is known for being stubborn and cantankerous, but I have a lot of personal experience with him. He's very empirical and fair. If you really are right, he'll admit it and eat a lot of crow in public. But be prepared for some very careful peer review of your results.

Shay Stephens

Crow not on the menu
Well, here's the rub. I don't care what Dan thinks one way or another about my work flow. Not a smack against him or anything. I just don't feel the need to validate my workflow with any outside entity, especially one with a workflow that is in LAB. I deal with RGB from beginning to end with the occasional CMYK conversions.

rutt wrote:

Dan is known for being stubborn and cantankerous, but I have a lot of personal experience with him. He's very empirical and fair. If you really are right, he'll admit it and eat a lot of crow in public. But be prepared for some very careful peer review of your results.

rutt

Shay Stephens wrote:

Well, here's the rub. I don't care what Dan thinks one way or another about my work flow. Not a smack against him or anything. I just don't feel the need to validate my workflow with any outside entity, especially one with a workflow that is in LAB. I deal with RGB from beginning to end with the occasional CMYK conversions.

Dan doesn't care whether your workflow is in RGB or LAB. Any example would work. He doesn't want to validate your workflow. He just wants any example using any sane workflow (yours would surely qualify, he just wants to exclude artificial examples, especially fabricated just win his challenge.)

But don't get me wrong. I agree with you. This battle is very much NOT worth fighting with Dan. In fact I do just what you do, work in 16 bits most of the time. It's at least as good as chicken soup and vitamin C for a cold; it can't hurt. In the old days when computers were way slow, it very much could hurt, but I barely notice the difference in terms of speed.

I do want to set the record straight about Dan though. LAB isn't his only thing at all, just his newest thing. In fact he is writing a book now with no LAB work at all. My favorite quotation of Dan's: "Every image has 10 channels." A lot of us have been very excited by Dan's LAB work. It really is revolutionary and very very clever. But LAB centric workflow isn't Dan's first innovation, by far, and I sure it won't be his last.

rutt

Dan's actual Call for 16 Bit Example
Dan gave me permission to cross post the most recent version of his challenge. If you actually care enough to read it closely, you'll see that he really isn't very doctrinaire about it, just very careful. (See his admission that 16 bit processing can make a difference in B&W.) It will also give you an idea of what a hornet's nest this topic is.

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

zigzag

Uh, I had a real problem show up once trying a shadow/highlight maneuver in 8-bit on a badly underexposed shot. Going to 16-bit resolution definitely made a difference, though in the end the shot still sucked.

Wonder if I could find that shot again in raw. Workflow went something like: look at shot, curse, convert from raw, curse again, shadow/highlight, curse a lot. Then realize I'm in 8-bit, and redo the above workflow. Finally, curse a bunch more and throw out the shot.

rutt

zigzag wrote:

Uh, I had a real problem show up once trying a shadow/highlight maneuver in 8-bit on a badly underexposed shot. Going to 16-bit resolution definitely made a difference, though in the end the shot still sucked.

Wonder if I could find that shot again in raw. Workflow went something like: look at shot, curse, convert from raw, curse again, shadow/highlight, curse a lot. Then realize I'm in 8-bit, and redo the above workflow. Finally, curse a bunch more and throw out the shot.

Sounds like you have exactly what Dan is calling for. Email him right away!

zigzag

Meh, still at work (even brought my camera today thinking I'd get out early enough to catch something to shoot while there was still light). And when I get out I have too many things to do to go find that shot's raw file (on my home comp).

Maybe tomorrow I'll look for it.

rutt

I guess you missed the invisible smiley there, eh?

Shay Stephens

********** The following types of images are not of interest.

2) Computer-generated artwork such as gradients, or any photograph that has been modified to such an extent that it is effectively computer-generated.

rutt

Shay, I don't follow you. Does that mean that you figured something out?

Shay Stephens wrote:

********** The following types of images are not of interest.

2) Computer-generated artwork such as gradients, or any photograph that has been modified to such an extent that it is effectively computer-generated.

jfriend

Not sure why Dan argues the 8-bit point so hard

rutt wrote:

Dan's 8 vs 16 bit argument has been around a long long time and generated a lot of heat on other boards and on his mailing list -- http://groups.yahoo.com/group/colortheory/

Dan has an outstanding challenge -- Show a real image gand a real workflow where processing in 16 bits results in a visibly superior end product. This has been around a long time and nobody has satisfied Dan.

Dan also has a fairly subtle mathematical argument as to why this is. You need a little statistics background to follow. Read the relevant part of chapter 6 carefully if you care.

I was promoting/describing some things I had learned in Dan's LAB book over on dpreview. One poster took issue with Dan (and by reference everything in his book) because of the controversy around his 8-bit opinion. Dan may be right (I don't really know and don't really need to know), but it does appear that fervently arguing the point is not helping him sell more books if that's his goal as it stirs up controversy and credibility about the rest of his work too. I wonder why he argues so hard about it?

I personally do the same thing you do Rutt. I keep the image in 16-bits for as long as it's not inconvenient because "it can't hurt" and "it might help". I usually don't save it in 16-bits if I'm done with the editing and, like you, sometimes my laptop has a hard time handling the huge 16-bit edition so I convert to 8-bits there. Now that I have 3GB in my desktop, it rarely has problems with large 16-bit images anymore.

wxwax

rutt wrote:

Shay, I don't follow you. Does that mean that you figured something out?

Shay says he keeps his shots in 16-bit because they make better gradients.

Margulis forbids gradients from being used in his challenge.

rutt

wxwax wrote:

Shay says he keeps his shots in 16-bit because they make better gradients.

Margulis forbids gradients from being used in his challenge.

Thanks, Sid. I get it now. I think Dan is referring to artificially generated gradients, not to natural ones.

Really, though, to me, this is Dan's least interesting issue. (See next post.) Shay is better off making beautiful pictures than thinking about this.

rutt

jfriend wrote:

I wonder why he argues so hard about it..

What can I say, John. I agree with you. The argument started in an earlier era when the difference between 8 and 16 bit processing was a really big deal in terms of practicality. Even now, the difference can be important for batch processing or less powerful machines. I

've been personally present when Dan talked about this. He is invested in this issue. He's thought very hard about it. He bends over backwards to make sure he understands the examples and arguments which are presented to him. AND IT DRIVES HIM CRAZY that other people can't follow his logic and SEE THE PLAIN TRUTH THAT HE IS RIGHT. What can I say? Sometimes it's hard being a genius.

rutt

Hey, Shay, I'm sorry for being a little dense. My day started very early and included a 500 mile drive (including some blindfold PS tutelage of a certain house pro via cell phone.)

Yeah, I can see why your work might like computer generated gradients and it's easy to understand why these favor 16 bit color. And as you see, Dan knows about it.

The whole thing is angles the head of a pin by now. But Dan has thought very deeply about it and it galls him when others disagree without equally deep understanding.

Anyway, as I said at first, there are better places for this particular discussion than this forum and probably better things to do with all of our lives.

Pindy

I will not let this dead horse lie
Sorry to resurrect this, but I just saw an interesting photoblog HERE which was very nice, but I was looking in the "About" page and she makes this claim that caught my eye:

"Post-Processing
I shoot in RAW+JPEG format and post-process my digital images with Photoshop CS2 just as I develop film in a darkroom: by increasing/decreasing contrast and saturation and adjusting tonal values. The vibrancy of colour and contrast in my digital images is due to working with 16-bit versus 8-bit digital files. "

This instantly registered as a potential bit of BS, but I was intrigued.

She links to THIS PAGE, which I read and it theoretically made sense.

Immediately, I opened Margulis' Professional Photoshop (rev 6) book to see what he said on the matter and was surprised to find the same thing the O.P. found—that there's no real benefit. Except in gradients and some B&W.

Despite this claim—or better, the lack of proof to the contrary for Mr Margulis—a few questions arose.

I notice that Bob Johnson mentions a gradient as his main example. Given Dan's rules of submission, I think this kind of answers most of my questions, but if I may be indulged:

1. Bob Johnson speaks of truncation in such an 8-bit system once the image is processed. In digital audio, all DSP causes the signal's bit depth to grow (it becomes a "longword") and to eliminate quantization error caused by truncation to reduce the longword to the capture depth, you apply a dither to gracefully bring it back. Does Margulis claim that the truncation error (and therefore loss of processing resolution) essentially is imperceptable at 8-bits?

2. Why, if our RAW files are 12 or 14-bits-per-channel, would we edit them in an 8-bit space? Isn't this contrary to logic? Even if there is no benefit to processing in 16-bits, why don't we autimatically use it as a basis for editing if we shoot RAW? What happens to the 4-6 least significant bits?

3. Despite the setting of 8-bit or 16-bit spaces in PS, in what bit resolution does PS perform it's processing? That of the host processor? I imagine this would be at least 48/56-bit processing or greater these days.

4. Assuming that this positive view on 16-bit files is pure golden-eyed pontification, is there anyone of national clout who DOES espouse this methodology for ordinary photos? I don't mean to belittle Bob's contributions as he seems to have dedicated a lot of time to his site and to education and I'm not claiming he's wrong or right.

Not having done any testing yet myself, I'm not in any way passing judgment. I realise this is an old saw and appreciate any knowledge to be passed on.

David_S85

The whole argument will soon be rendered academic. As RAW files are now in the 14-bit range (probably the full 16 in a few years), and all the most used tools in PS being converted to 16-bit, 8 bit editing will someday seem like bear skins and stone knives. If 16-bit is possible, I say use it as far as you have it.

Richard

David_S85 wrote:

The whole argument will soon be rendered academic. As RAW files are now in the 14-bit range (probably the full 16 in a few years), and all the most used tools in PS being converted to 16-bit, 8 bit editing will someday seem like bear skins and stone knives. If 16-bit is possible, I say use it as far as you have it.

I don't follow. Aren't the main issues 1) our perceptual inability to discriminate tiny differences and 2) output devices are almost always 8 bit. So even if we had 64 bit capture and processing, it wouldn't do us much good till output devices have finer color resolution and--perhaps more important--greater dynamic range.

jfriend

rsinmadrid wrote:

I don't follow. Aren't the main issues 1) our perceptual inability to discriminate tiny differences and 2) output devices are almost always 8 bit. So even if we had 64 bit capture and processing, it wouldn't do us much good till output devices have finer color resolution and--perhaps more important--greater dynamic range.

No, it's actually not primarily those two issues. The issue is that because the digital image pixels are stored as integers, many editing operations causing rounding errors. Multiple consecutive edits of certain types can theoretically cause mutiple consecutive rounding errors that can compound in a way that can cause a given color or tonal value to be off by multiple steps in a way that could become visible.

This is seen most clearly when you have a computer generated perfect gradient with no noise. Certain types of 8-bit edits will have compounded rounding errors and cause banding (tonal or color steps in a gradient that is supposed to be smooth) that can be visible. Fortunately, these types of gradients don't exist in nature as they almost always have non-linear variations and enough noise that banding isn't seen as easily. But, the theory is that other types of subject matter could be affected in a noticable way too.

The argument is whether nature produces naturally occuring subject matter that is susceptible to this and whether a set of editing operations in Photoshop is likely to produce this compounding of rounding errors enough to make it visible.

Here's a contrived example to show you the effect. I started with a simple gradient from blue at the bottom to black at the top. I then applied a simple levels change to this image 10 consecutive times (to pick an editing operation that suffers from integer round-off error). Each time, I changed the middle value in the levels dialog to 1.1 and the right value to 240. I did this test on a 16-bit version of the original and on an 8-bit version of the original. At the end, I converted the 16-bit result to 8-bits and saved all as JPEGs. In the version that was edited in 8-bits you can see banding in the tone. If the version that was editing in 16-bits, you cannot see banding. If you see banding in all versions even the unedited gradient, then it's probably due to your monitor.

Here's the original gradient:


Here's the one edited in 16-bits:


And here's the one edited in 8-bits (where I see banding):


Now, this particular test does not meet Dan's challenge because it's a totally contrived image and edit, but I thought it would be useful to illustrate the theoretical benefits of 16-bit editing.

Richard

John,

Thanks for posting the clear example. I understand compounded rounding error and the theoretical advantage of 16 bit, but in my own work I have never been able to see the slightest difference in results. I rarely use gradients other than an occasional use as a layer mask. I don't believe there is much risk of introducing banding from a mask.

I was taking issue with David's statement that "...8 bit editing will someday seem like bear skins and stone knives." He may be right, not because RAW files have greater bit depth or because Adobe fully implements 16 bit tools in PS, but because output devices also improve to accommodate 16 bit signals. We'll see. Until then, for the overwhelming majority of cases, working in 16 bits is like the Spinal Tap guitarist setting his amplifier to 11.

Regards,

jfriend

rsinmadrid wrote:

John,

Thanks for posting the clear example. I understand compounded rounding error and the theoretical advantage of 16 bit, but in my own work I have never been able to see the slightest difference in results. I rarely use gradients other than an occasional use as a layer mask. I don't believe there is much risk of introducing banding from a mask.

I was taking issue with David's statement that "...8 bit editing will someday seem like bear skins and stone knives." He may be right, not because RAW files have greater bit depth or because Adobe fully implements 16 bit tools in PS, but because output devices also improve to accommodate 16 bit signals. We'll see. Until then, for the overwhelming majority of cases, working in 16 bits is like the Spinal Tap guitarist setting his amplifier to 11.

Regards,

Got it. I follow the same logic as Rutt. I'm not sure if 16-bits makes a difference or not. So, since I start out with 16-bit RAWs (OK, maybe they're 12-bits) I just leave it in 16-bits for all editing operations until I go to save. Then, when I save, it almost always goes to an 8-bit JPEG. It doesn't cost me anything more and, in the off chance that it does make a difference in some images, I'm safer. If it never makes a difference, then I haven't lost anything either.

I agree that if we start to get 16-bit output devices, then the whole equation would really change.

arodney

Dan's wrong, period. His so call challenge is bogus. For one, he's always changing the goal posts in mid game. I suspect he's doing this more for attention and controversy than anything else. I myself submitted proof of this at least two years ago on his list, then Dan moved the goal posts by saying my test was unfair because I used ProPhoto RGB then started yet another straw man controversy about wide gamut spaces (note, if you'd like a file and a demo of why only this space is useful, one I of course submitted to Dan, lets start another thread). I used an image from a Canon DSLR of a real life image, illustrated visible damage to an image in 8-bit that was not visible on screen or print from the high bit file (12 bit, Photoshop calls everything more than 8-bit a 16-bit file for simplicity and its doing its work in 15-bit).

The math is undeniable.

A true color scientist and imaging expert who began to discuss this with Dan, then gave up due to the totally unscientific methods of Dan's has a very useful page on his site that pretty much sums up Dan's cheating in respect to this challenge:

http://www.brucelindbloom.com/index.html?DanMargulis.html

Read it. It sums up the issues here. It summarizes non scientific, religious thinking on Dan's part.

The bottom line is, you have high bit capture from virtually every scanner and digital camera that hands you the Raw. I wonder why? All the input manufacturers must be wrong.

The output device plays a huge role too. Dan only see's the world in the form of a CMYK halftone dot. I've asked him if he's got a DSLR, a half decent ink jet but of course, that's not up for discussion. An 8-bit file that will show no sign of banding on a halftone process may very well show banding on a nice Epson 3800. Let alone a really fine contone printer like a Lightjet, film recorder etc.

The other issue is, we never know what kind of output device we may send these documents to in the future, why throw away data in such cases? We never know what conversion to a color space we may make in the future that might break an 8-bit file. Same with an edit. Why paint yourself into a corner? At the very least, keep a high bit, wide gamut archive. IF you want to now work in 8-bit, fine. If something breaks, and it may, you've got the data. Besides, storage is cheap, your images and their quality is, at least for some, priceless.

In the days when I started working with Photoshop (1990, V.1.0.7), it would take 20 minutes to rotate a 15mb file a few degrees. We have huge image processing capabilities now, the issue of working with a bigger file, considering the insurance is, for most, a non issue.

I also guess the world's leading software engineers at Adobe are wrong and Dan is right considering all the tools they have provided us in 16-bit over the years. Today, nearly every global color and tone control necessary operates in high bit within Photoshop. But what do Thomas Knoll and Mark Hamburg know? Then we have the high bit processing pipeline in Camera Raw and Lightroom.

There ARE printers that will accept and use more than 8-bits per color! Canon has some, Epson is on the way (you can send high bit data to an Epson through some RIPs today and have been able to for years).

Look, Dan has some great techniques and idea's. But he really makes himself seem silly and less capable when he builds straw man arguments like he does, totally alters the testing on the fly, dismisses what is simple math and implies (or straight out says) people like Knoll, Hamburg, Cox, Lindbloom and all the other's building imaging products are wrong, he's right. Its a lot of flat earth, non scientific thinking.

arodney

rutt wrote:

Sounds like you have exactly what Dan is calling for. Email him right away!

Yes please do, I can't wait to see what's wrong with that example and how he'll change the goal posts.

I'd also LOVE to see a copy if you're willing to provide one and the steps used.

Mark Segal

This is a VERY tired issue whose technical relevance recedes by the half-year, every year since it started, all the time. It is bound with the wide colour space issue. There are inkjet printers on the market whose gamut exceeds ARGB(98), and will only continue to get wider with every new model release. That was not the case several years ago. My Epson 4800 is a case in point. Take an image with bright colours, set-up a soft-proof say with Epson Enhanced Matte as the paper, and cycle through from sRGB to ARGB(98) to ProPhoto. You'll be surprised to see how much colour gets added from the one to the next, and therefore how much colour gets lost when you send images to an Epson professional printer in narrower colour spaces. The catch IS, to use these spaces safely (i.e. to avoid banding) it is rather important to work with 16 bit files. These files can survive serious editing in wide gamut space while preserving smooth tonal gradations (because there are many more brightness levels to fill the wider space) - whereas the probability of a train smash is much greater editing 8 bit files in wide gamut space. The gradient example is not all that bad, because nature provides us one which is not that different - large expanses of blue sky whose H,S,B characteristics change SMOOTHLY between the horizon and the upper atmosphere. Skies are particularly vulnerable to being stressed in editing. 16 bit will help and 8 bit is a risk.

Of course the 16-bit advantage depends on what you are doing with your photography, and what quality standards are therefore needed and expected.

This discussion along with Dan's rules and criteria may have provided lively debate at the time, but it is history. The contemporary discussion is all about the enabling characteristics of today's and tomorrow's technology and what demands they put on the input data.

arodney

With respect to Dan, his 16-bit challenge (or that on wide gamut spaces, Raw conversions, Compost Curves,), there are a few issues to consider. First and foremost, if you wish to simply take someone’s word for a technical issue involving digital imaging without actually testing this yourself, you may appear as one who prefers to subscribe to a religious belief system rather than the scientific approach and I do not wish to argue with anyone about religion!

Everything we do in Photoshop, Lightroom, Color Management, it boils down to math. If you set up the rules objectively and scientifically, you can test just about any argument to prove or disprove an opinion expressed by a so called imaging expert. No one, myself or Dan or you, is born with a unique knowledge of Photoshop or imaging. Someone has to teach us and we have to teach ourselves. Testing is one such way to further this goal.

Getting back to Dan’s 16-bit challenge. With the Bruce Lindbloom experience known to me, I still submitted a Raw file to the Color Theory list that illustrates some image damage due to processing in 8-bit that wasn’t produced in 16-bit. You can test this for yourself. The Raws, instructions, XMP files, Bridge Cache files are all on my public iDisk in a folder called “16bit challenge”. There is even a screen capture of the results for those who simply refuse to send a few minutes testing all this with the actual files (I know who you are...).

I could post the mountains of nonsense and long winded tripe Dan wrote on his list to dismiss the test but they all amount to moving the goal posts mid game. The same stuff Lindbloom mentioned at .http://www.brucelindbloom.com/index.html?DanMargulis.html To make matters worse, at one point he dismissed the DNG on the iDisk as ‘not being the Raw file’, obviously misunderstanding what a .DNG even is! We have a real world image, it shows damage in 8-bit, not in 16-bit. Now the rules are changed YEARS after it started because I used a wide gamut space: ProPhoto RGB. That’s a bad color space according to Dan. You can listen to the religion or just test this yourself. I’ve again provided files to do this but its easy to do on your own captures. Also on my iDisk is a folder called “ProPhotovsAdobeRGB files”. Render the Raw in both sRGB, Adobe RGB and ProPhoto RGB in Camera Raw using the same settings but only altering the encoding color spaces. Do it in 16-bit, highest rez to be fair. Now in Photoshop, simply move the Hue slider (Hue/Sat) up to +7. Not a big move or edit. Do this on an Adjustment layer and you can now drag and drop it onto the other two images. Look at the detail at 100% zoom of the yellow flowers. What do you see? I’ve seen this on lots of images with saturated imagery. Then Dan will argue there’s no need for ProPhoto RGB due to output gamut limitations and again, we can test this all the way to print and realize that the gamut of output devices has increased tremendously in a few years.

This test illustrates another misunderstanding by Dan. He now proposes we zero out Camera Raw and Lightroom and apply (in 8-bit sRGB no less), all corrections in Photoshop. A savvy reader here might have asked about the +7 Saturation tweak. Why not make it in the Raw processor and not worry about damage to smaller gamut encoding later in Photoshop. Good call! You’ve seen that applying all global and tone editing in high bit in a Raw converter produces superior data, then doing this kind of work after in Photoshop, EVEN IN 16-bit! Indeed, make the plus saturation edit in the converter, do NOT render the data such that it needs to be corrected in Photoshop. Rendering isn’t color correction (guess who doesn’t get that important distinction?).

Mark Segal* produced two papers to attempt to allow users to fully understand the role of composite curves, Camera Raw rendering in response to more misinformation from Dan. Dan is now trying to discredit the use of Camera Raw and Lightroom as professional tools (his words) when in fact he shows a huge misunderstanding not only how to use these tools but also the difference in handling Raw data versus gamma corrected pixels. At one point, Dan posted he had created a spreadsheet that proved his point by reveling the exact math used. Despite numerous requests from readers of his list to provide the spreadsheet, Dan refuses to do so, once again putting his claims in a seriously defective scientific light. Instead he once again religiously indoctrinated the list but did not objectively and scientifically prove his points.

I’m perfectly happy to be proven wrong too unlike Dan. That’s how we learn! If these tests are faulty, I want to know why but I want scientific reasoning behind the argument that anyone can demonstrate to themselves. Lastly, when someone makes a claim, as Dan (and I) have done, its not up to you, the reader to prove us wrong, its up to us to prove our theories and techniques are right. That isn’t how Dan operates. You have to attempt to prove him wrong and when you provide actual demonstrative results, as Bruce Lindbloom discusses, and I have witnessed, the rules change, the goal posts are moved mid-game. It is not up to Dan’s readers to prove there is or is not a 16-bit advantage. It’s up to Dan's to prove the is NO advantage which he’s never done. And yet, many of us have proven to ourselves he’s wrong based on actual testing anyone can also try so they can evaluate the results and make up their own minds. We allow outside scrutiny and balanced discussions. We don’t say we have the exact math behind a command to prove a point then refuse to provide this evidence to support our claims. We don’t dismiss what more educated people have to say when asked (I’m referring to the engineers that build these products, guys like Thomas Knoll) who have said that the so called facts Dan expressed about an Adobe product is wrong. These issues shouldn’t be about religion, they should be proven and expressed based on empirical testing. You the reader are welcome to take either approach in learning.


My public iDisk:

Thedigitaldog

Name (lower case) public
Password (lower case) public

Public folder Password is "public" (note the first letter is NOT capitalized).

To go there via a web browser, use this URL:

http://idisk.mac.com/thedigitaldog-Public

* http://www.luminous-landscape.com/essays/Curves.shtml and http://www.luminous-landscape.com/pdf/Curves2.pdf

arodney

Mitch wrote:

Before I begin. How many of you, like me, process your images in 16 bit waiting until the last moment to convert to 8 bit for printing?

Little tip. If you're printing directly from Photoshop, you don't need to convert to 8-bit. Using the Print with Preview (Print in CS3), will sample the 16-bits on the fly when printing. Keep the document in 16-bit.

Pindy

Don't get me wrong; I wasn't defending Dan's claim nor refuting it. I start to see skies banding with some simple saturation adjustments in Aperture, which is what fuelled my interest in this in the first place. Does anybody know what the processing is like under that hood?

This is all fascinating. We have not dissimilar debates that rage in audio fora that all hinge on the same type of thing, because a handful claim that they hear that something that sounds good to most people sounds "bad" to them, and this is the Get Out Of Jail Free Card of digital audio debate. It is also this kind of thinking that indoctrinates people who haven't done any double-blind testing themselves. I see why this is so frustrating for so many, but I'm kind of having deja vu. At least with this issue you can genuinely see the results (positive or negative) without having to have "faith" in some notion.

Pindy

From Bruce Lindbloom's site:

This understanding was wrong. The fifth of Dan's conditions ("Condition 5") modifies step (a) as shown here:

Original 16-bit image ? convert to 8-bits ? convert to 16-bits ? apply corrections ? convert to 8-bits.
Original 16-bit image ? convert to 8-bits ? apply corrections.
Compare (a) and (b).

Dan is suggesting that you take a 16-bit file, lop off the 8 LSBs, convert it back to 16-bits by adding 8 LSBs containing nothing but zeroes, then adjust and no wonder you won't see much difference!

There seems to be confusion between extra bits of info in the file and the the act of double-precision processing.