Clear 16 bit superiority | Dan Margulis | Photoshop

Ledet training home -> Adobe training -> Photoshop training -> Professional Photoshop training with Dan Margulis

Dan Margulis Applied Color Theory

A Case of Clear 16-bit Superiority?

A case of clear 16 bit superiority

Posted by: "Ric Cohn"

Thu Oct 5, 2006 10:53 pm (PST)

This has been covered before, but I just encountered such a clear case I thought I'd share it and see what other's feel this shows. The clear superiority of 16 bit has to do with creating a mask from an Lab channel.

I shot some glasses with gold rims and wanted to created a mask based on the gold color. I took an 8 bit ColorMatch RGB file from a PhaseOne H25 back and converted it directly to Lab. I made a very small curves adjustment to ensure that only the gold bands would be positive in the b channel. When I looked at the channel I was amazed by the massive blotches of tone! It was not suitable for pulling a clean mask.

I went back and converted the same RGB file from 8 Bit to 16 Bit before converting to Lab, applied the identical curve and compared the results. The 16 Bit file was vastly superior. Curious, I went back and reprocessed the Raw file as a 16 Bit ColorMatch file and then did the same conversion to Lab and applied the identical curve again. Comparing the two 16 Bit files the difference was slight, but the file that was processed as 16 bit and kept as 16 bit all the way was clearly smoother.

Comments?

Ric Cohn

___________________________________________________________________________

Re: A case of clear 16 bit superiority

Posted by: "MARK SEGAL"

Fri Oct 6, 2006 7:08 am (PST)

At the risk of re-opening what to some may be an unwelcome debate - because this group has been through it so many times and it has been unfortunately personalized - your experience is supported in principle. 16-bit files just have an exponentially larger number of much smaller discrete levels to fill the colour space and protect against the kind of blotching/banding/posterization you observed. While the theoretical advantage this provides may not necessarily show in practice for a majority of images, it would seem to be the case that there are those real-world situations where the extra data may protect the tonal transitions. A case at hand apparently is yours, where logic suggests that making curve edits altering the colour balance (exchanging blue for yellow) within what (from your slight description of the image)seems to be a narrow "b" band in a large colour space such as Lab - requires many small discrete levels of tonal gradation to prevent visible decomposition as you skew the tonal range along that axis toward more yellow. What seem to feel like small nudges of "a" and "b" curves produce surprisingly large changes in colour balance.

Mark Segal

___________________________________________________________________________

Re: A case of clear 16 bit superiority

Posted by: "Howard Smith"

Fri Oct 6, 2006 7:10 am (PST)

Ric, my own cynical suggestion is that you either post your starting-point images or find a really deep cave somewhere really deep in the woods. Surely you know what kind of response.but you're just joking..right?

Howard Smith

___________________________________________________________________________

Re: A case of clear 16 bit superiority

Posted by: "Stephen Marsh"

Fri Oct 6, 2006 7:10 am (PST)

Ric Cohn wrote:

This has been covered before, but I just encountered such a clear

case I thought I'd share it and see what other's feel this shows. The

clear superiority of 16 bit has to do with creating a mask from an

Lab channel.

Ric, I believe that you are sincere - so I will give you a sincere reply.

To be clear Ric, the debate in the past has been over full colour RGB scans or digicam shots in non wide gamut working spaces for press output - that is/was the subject of the high bit workflow challenge/debate that Dan raised. He was very open in stating where he thought it did help. The whole issue was that users were being advised to use this workflow when it may not have helped them, only hindered them (say outputcentric prepress instead of inputcentric photographers).

Dan has indicated why single channel files and CG images are better handled in high bit or higher resolution and why they are excluded from the challenge. The debate that Dan raised was in a specific context. This case that you bring up is interesting, but not applicable to that debate.

It is applicable in a wider sense of applied theory, I am not dismissing what you consider to be important results - just putting them in the correct context considering the history of the topic on this list.

I shot some glasses with gold rims and wanted to created a mask based

on the gold color. I took an 8 bit ColorMatch RGB file from a

PhaseOne H25 back and converted it directly to Lab. I made a very

small curves adjustment to ensure that only the gold bands would be

positive in the b channel. When I looked at the channel I was amazed

by the massive blotches of tone! It was not suitable for pulling a

clean mask.

The AB channels often contain much junk and can often accept aggressive local or lesser global noise reduction (beware desaturation of smaller bright objects, but not an issue in this case).

I am not sure if you would get better real world results using chroma noise reduction in the camera raw package, or using a colour blend blurred layer in RGB before going to LAB or just fixing the noise/artifacts in the single AB channels when in LAB. All of these options would probably be better than just accepting the raw LAB chroma channel as is as a base for masking (the threshold command is a great equalizer, brutal but effective in some cases!).

I went back and converted the same RGB file from 8 Bit to 16 Bit

before converting to Lab, applied the identical curve and compared

the results. The 16 Bit file was vastly superior.

This is all a bit beyond my knowledge (colour quantization and all that stuff & not being a colour scientist), even though Photoshop uses high bits behind the scenes in profile conversions, that is not the same as putting the file into high bit for a colour mode conversion. One can help reduce invisible artifacts in LAB conversions by using high bit before going to LAB. It surpises me that a minor curve that enhances contrast in the A or B channel would result in such a clear difference between the regular bit LAB conversion and the high bit LAB conversion. (see below *)

One way to inspect this invisible detail is with difference mode blending of a LAB dupe over the original RGB image, perhaps flattened and then equalized to enhance the differences for visual inspection (black indicates no difference between the two images). Another way would be with the B-Xray feature of Binuscan PhotoRetouch Pro/Digicam.

Curious, I went

back and reprocessed the Raw file as a 16 Bit ColorMatch file and

then did the same conversion to Lab and applied the identical curve

again. Comparing the two 16 Bit files the difference was slight, but

the file that was processed as 16 bit and kept as 16 bit all the way

was clearly smoother.

Comments?

I am not surprised that in working with a single channel that a high bit image may in some cases show a result that may be considered superior for the task at hand - even more so as this is a LAB colour channel.

I am surprised that with only a minor edit, there is such a difference, but this is a LAB chroma channel (not L). The H and S of HSB also look crappy too! As would the LC of LCH or the LS or LSB.

This is very different from editing a single RGB or CMYK channel, or the L of LAB.

* Another point would be what are the results of a *Photoshop* dithered conversion from high bit to regular bit, as opposed to the (non Adobe?) camera raw generated regular bit file. Also a non dithered conversion in Photoshop to compare against the camera raw 8 bit conversion would be useful.

But in closing, this does not disprove anything - it simply backs up what is known and has been stated in the past by many parties.

Of course, a suitable crop of this area of the image, in high resolution in both 16 bpc raw converter render and 8bpc raw converter render would be helpful for members on the list to see for themselves what you describe (and the .acv curve file too).

Regards,

Stephen Marsh.

___________________________________________________________________________

Posted by: "Bartlomiej Walczak"

Sat Oct 7, 2006 8:08 am (PST)

Re:A case of clear 16 bit superiority

Mark,

From what I know 16-bit conversion does not invent any new colours in between. Otherwise it would have to do it randomly, thus introducing noise. It is a simple number conversion.

When you upconvert to 16-bit before going to Lab, then Lab has more "room" to fit all your RGB values to a* and b* without the need to posterize the colours. This is the only benefit I see of upconverting before going to Lab. And in this case there is no "bogus" data, because you essentially prevent posterization that happens when you go from 8-bit RGB to 8-bit Lab. It's only a matter of getting bigger range.

As somebody mentioned, fit for specific purposes.

All the best

Bart Walczak

___________________________________________________________________________

Posted by: "MARK SEGAL"

Sat Oct 7, 2006 9:46 am (PST)

Re: A case of clear 16 bit superiority

Thanks. I don't know what "a simple numbers conversion" means or indeed whether it is that simple. Also I don't think up-converting creates more "room". It creates more data. The issue is what kind of data it creates.

Mark Segal

___________________________________________________________________________

Posted by: "Matthew Rigdon"

Sat Oct 7, 2006 8:48 am (PST)

Re: A case of clear 16-bit superiority

On Oct 6, 2006, at 4:57 PM, Mark Segal wrote:

Dan, no question that when one starts a file's life in 8-bit the 16

bit data simply isn't there; hence when converting such a file to

16 bit information must be invented. But what if his "b" channel

were not noisy? Why are all the extra 8 bits of data being

generated necessarily garbage? Is it factually correct that this is

what a bit depth conversion does - fills the empty bins with

garbage? Is there no mathematics in Photoshop that invents the

missing data on a "nearest neighbour" basis such as what happens

when up-rezzing a file, so that if the "b" channel contains real

information that information gets cloned to fill the empty bins?

I think what he's pointing out is that the noise from the blue channel is ruining 2 bits of data, so even the nearest neighbor is going to be ruined because it's trying to make part of its determination from garbage. So instead of just saying that one neighbor is red, one is green, I should be yellow, there are cases in a noisy image where one neighbor is red, one neighbor is Chevolet, and I should be chartreuse ;)

Even if you shot the image in RAW, you'd still only end up with 12- bits of potentially valid data (noise will eat away at that), so 16- bit is filling in the holes. But the holes are being filled with fake data (it's smart fake), but fake either way. In this case, the 8-bit data is noisy, but it's coming from a sensor with 12-bit accuracy (or higher, I don't have a medium format back), so there's so much noise in this particular image that even the 16-bit would pick it up (if you can't get clean 8-bit from 12-bit, going to 16-bit isn't going to improve it). The problem was in the mask, though, and masks can certainly benefit from 16-bit as a single 16-bit channel comes much closer to offering the number of values as three 8-bit channels together.

Matthew Rigdon

___________________________________________________________________________

Posted by: "MARK SEGAL"

Sat Oct 7, 2006 9:45 am (PST)

Re: A case of clear 16-bit superiority

I guess I'm still stuck on the factual question about whether or not there was much noise in the blue channel of this particular image to begin with.

Mark Segal

___________________________________________________________________________

Posted by: "Dan Margulis"

Sat Oct 7, 2006 9:47 am (PST)

Re: A case of clear 16-bit superiority

Mark Segal writes,

Dan, no question that when one starts a file's life in 8-bit the 16 bit

data simply isn't there; hence when converting such a file to 16 bit information

must be invented..

On the contrary. The 16-bit data *is* there--provided that the data in the 8-bit RGB is good enough. If you convert good 8-bit RGB to 16-bit LAB, the L channel is usually good for at least 9 bits, maybe 10. But that's because it's heavily affected by the luminosity component of the green channel, which is usually captured quite reliably by the camera, further verified by the reasonably reliable luminosity of the red channel (the blue basically does not contribute).

But what if his "b" channel were not noisy?

Then he would be working with a category of camera that has not yet been invented. The B channel is constructed from *color*, not luminosity, information extracted primarily from the blue channel, secondarily from the red. That information has nothing to do with darkness--solely with the camera's ability to differentiate blues. Every camera in the world has grave difficulties with this.

Why are all the extra 8 bits of data being generated necessarily garbage?

Because you can see that much of the *first* eight bits of data is garbage. Recomputing it from the same data to more decimal places just generates further garbage. In Ric's application, it happens to be beneficial to generate this garbage because it randomizes (blurs) what happens next, and thus attacks the noise.

Is it factually correct that this is what a bit depth conversion does -

fills the empty bins with garbage?

A bit-depth conversion within a colorspace just adds zeros plus a dither. A bit-depth conversion *across* colorspaces, which is what we're talking about, adds useful information if the useful information is there to be found in the mix of channels provided by the source file. If it can find nothing but garbage there, then it has no choice but to fill the extra bits with garbage.

Dan Margulis

___________________________________________________________________________

Posted by: "Richard Wagner"

Sat Oct 7, 2006 9:49 am (PST)

Re: a case of clear 16-bit superiority

Sorry, Matthew, I've reviewed your post several times and I still can't follow your arguments. Could you try to re-state it for me, without the embedded analogies, or give a more concrete example? I don't follow this "fake data" argument at all, mathematically. (Converting an 8-bit integer to 16-bit gives the exact same number.) Also, your quote, "so there's so much noise in this particular image that..." Have you seen this image, or is this speculation?

Thanks,

--RIch Wagner

___________________________________________________________________________

Posted by: "Ric Cohn"

Sat Oct 7, 2006 3:18 pm (PST)

Re: A case of clear 16-bit superiority

On Oct 6, 2006, at 1:58 PM, Dan Margulis wrote:

AFAIK, there would be no benefit in your example to *acquiring* the

file in 16-bit--the advantage took place because you decided to

*convert* a copy of an existing 8-bit file to 16-bit.

This is the one point where I respectfully disagree. As I stated, I reprocessed the Raw file into 16 bit mode so I could compare the 8 bit to 16 bit conversion with a true 16 bit file. In this particular case I found the "16 bit all the way" file superior. I also mentioned in my last post to Steven that I compared a different file today and didn't see any advantage. However, going back and comparing to see if it's better is a PITA. If there is sometimes an advantage to starting with a file processed into 16 bit, it does make me reconsider how frequently I start out in 16 bit for safety's sake. Up until now my answer has been almost zero, from now on-- who knows? I need more knowledge.

What is happening mathematically is: the B channel is strongly related to the

original blue channel, which is commonly rather noisy. That noise indicates

that even the first 8 bits of data are not reliable--probably it's more like

the first 6 bits. So, you are generating 8 extra bits of information that is

absolute garbage, of no statistical validity at all, completely random digits.

Can we be sure there is no more data in the 16 bit processed file? The PhaseOne H25 is a few years old, but it is still one of the best single shot digital backs out there ($20,000 when new). There are, of course, innumerable variables that I have no ability/desire to test for. For example, the capture was 1 second with tungsten lights at EI 50. This might lead to more noise in the blue channel than for shorter exposures or daylight or strobe. Under normal editing conditions none of these differences would be visible.

There will be more along these lines (although pertaining to RGB maneuvers,

not the B channel) in the forthcoming book.

Delighted to hear it. I definitely have more to learn.

Ric Cohn

___________________________________________________________________________

Posted by: "Ric Cohn"

Sat Oct 7, 2006 3:21 pm (PST)

Re: A case of clear 16-bit superiority

On Oct 7, 2006, at 12:00 PM, Dan Margulis wrote:

Then he would be working with a category of camera that has not yet

been invented. The B channel is constructed from *color*, not luminosity, information

extracted primarily from the blue channel, secondarily from the red. That

information has nothing to do with darkness--solely with the camera's ability to

differentiate blues. Every camera in the world has grave difficulties with this.

I'm finding this is all very interesting and educational. I don't think it's worth getting too caught up on one particular image. There are too many variables that might have nothing to do with whether it's truly an 8 bit vs. 16 bit difference. However, this does raise some questions which I do not know the answers to.

For what it's worth, I went back and looked at the RGB channels of both the 8 bit and the 16 bit file. There is some noise in all the channels visible at 100%. I'm not sure that the B is any more noisy than the others. In a flat dark gray area of the file the Red and Green channels are both worse than the blue. Perhaps the Raw processor is designed to move some the garbage out of the Blue to make it appear better? These are the kinds of variables that make it impossible to generalize from one image and one Raw Processor, Scanner, etc. The 16 bit processed file is smoother (as expected??). Shouldn't the unedited files look identical? Converting the RGB file from 8 bit to 16 bit did nothing (of course). I again converted both files to Lab (no dither) and the 8 bit file has much more garbage in all 3 channels. Note that all of this is on files where no adjustments have been made after processing.

I have never doubted the quality of CaptureOne (the only Raw processor choice for PhaseOne backs), however, it occurs to me that the difference in appearance between the unedited files might be showing a weakness in the programs internal 16 bit to 8 bit conversion. Any thoughts?

I don't know that it would appear in print in a moderately adjusted image, but even at 100% I can see differences in the on screen composite images that might become significant-- especially if I do major edits. All the Lab channels, especially the L channel has much more blotchy noise in the 8 bit RGB to 16 bit Lab image.

I hope this is clear.

Ric Cohn

___________________________________________________________________________

Posted by: "Richard Wagner"

Sat Oct 7, 2006 3:21 pm (PST)

Re: A clear case of 16 bit superiority

On Oct 7, 2006, at 9:32 AM, MARK SEGAL wrote:

I guess I'm still stuck on the factual question about whether or

not there was much noise in the blue channel of this particular

image to begin with.

As do I. Ric is starting out with an image shot on an H 25, one of the lowest noise digital camera backs in production today, with a sensor that produces 16-bit output (not 12), at low ISO (I would assume he shot at 50 or 100), under studio conditions. Why should this image have more noise than others? And in particular, why should there be enough "noise" to degrade his 8-bit images? There is clearly more "real" data (not "fake" data) in the 16-bit images that gets truncated when going to 8-bit, and Ric did the experiment to demonstrate that. As Ric originally stated,

"Curious, I went

back and reprocessed the Raw file as a 16 Bit ColorMatch file and

then did the same conversion to Lab and applied the identical curve

again. Comparing the two 16 Bit files the difference was slight, but

the file that was processed as 16 bit and kept as 16 bit all the way

was clearly smoother."

He is working from the same RAW file. If there was not more "real data" (or significant bits) in the 16-bit original, why should it give smoother tones than the 8-bit image converted to 16-bit and processed identically? For that matter, why should PhaseOne bother making a 22 MP back with 16-bit output? Marketing hype?

--Rich Wagner

___________________________________________________________________________

Posted by: "Ric Cohn"

Sat Oct 7, 2006 3:22 pm (PST)

Re:A clear case of 16 bit superiority

On Oct 6, 2006, at 8:41 AM, Stephen Marsh wrote:

Dan has indicated why single channel files and CG images are better

handled in high bit or higher resolution and why they are excluded

from the challenge. The debate that Dan raised was in a specific

context. This case that you bring up is interesting, but not

applicable to that debate

Yes, I tried to make it clear to those that are familiar with the issues that I wasn't claiming I'd proven "THE" 16 bit advantage. I was one of those who gave 16 bit images to Dan for the last edition and had been unable to find any advantage either. My point is that here was an image destined for a printing press where knowing when to go to 16 bit is critical. It also raises the question in my mind (and for my particular kinds of work) whether I should greatly increase the situations where I process into 16 bit files for safety's sake. I do think this is of interest to others on this list as it is to me.

Dan has mentioned that when to use 16 bit (whether as 16 bit processed or just as 8 bit to 16 bit conversions I'm not sure) is being included in his new book. I'm very glad to hear this, as I don't believe there is much good information out there at this time... Lot's of "use 16 bit all the time" and lot's of "for photographs I've never seen a benefit".

It surpises me that a minor curve that

enhances contrast in the A or B channel would result in such a clear

difference between the regular bit LAB conversion and the high bit LAB

conversion.

To clarify, I don't believe the small curves adjustment had anything to do with the banding. I was just trying to show that I hadn't done anything crazy to hose the data and that I did my best to treat them identically. Since I was basically working on one B&W channel and applying a massive contrast increase to create a mask there are simply not enough levels in 8 bit to separate closely spaced tones. I don't understand the math either, but it would appear that when converting from 8 to 16 bit Photoshop (thankfully for this purpose) will average the bits into the available levels.

Note that I had Dither turned off for the conversions.

As I said, for this image, going back and reprocessing the file as 16 bits and staying in 16 bits appeared superior to me. Today I did another image that required separating an almost neutral blue pattern from an almost white plate. Using the same trick I converted from my 8 bit file to 16 bits and it worked much better. In this case, I also reprocessed the file as 16 bits for comparison. In this case, after applying a massive curve, I saw slight differences between the two 16 bit files, but no clear advantage to the file which had stayed in 16 bit all the way.

Of course, a suitable crop of this area of the image, in high

resolution in both 16 bpc raw converter render and 8bpc raw

converter render would be helpful for members on the list to see

for themselves what you describe (and the .acv curve file too).

If people are interested perhaps I could post some closely cropped files. Can these be placed as .tifs on the Yahoo site?

Ric Cohn

___________________________________________________________________________

Posted by: "Matthew Rigdon"

Sat Oct 7, 2006 3:22 pm (PST)

Re: A clear case of 16 bit superiority

Just going off Dan's observation (that I have found to be true) that most digital cameras exhibit noise in the blue channel (more so than in others). The original poster was making a mask from the B channel and chances are that channel will be noisier than the A channel (which relies more on red and green channels).

And since a lot of this goes into arguments about unique colors or not losing data, etc, in the majority of digital cameras the values aren't there. Most digital cameras use Bayer algorithms to make up the colors in the image to begin with (the Foveon being the only exception I know of), plus it's based on sampling green two times more than blue or red, so it adds another dimension to the argument about whether or not we should be worried about how many thousands or millions of colors are in a data file.

Everyone keeps saying that 8-bit to 16-bit doesn't change anything, but we're not talking about an 8-bit value in a register, we're talking about RGB values that are set within a color space. Does every 8-bit value in sRGB have an absolute correspondence to a 16-bit value in ProPhoto? Or does Photoshop run some sort of background conversion that sometimes moves an 8-bit value up one or down one? In the case of the camera, you have to ask whether the 12-bit to 8-bit conversion is more accurate than the 12-bit to 16-bit conversion. The problem is that we often don't know what the programmers are doing and what happens in a CMM or graphics program is very different than just moving a value from an 8-bit register to a 16-bit register.

Since a lot of people want to talk about the science, I think part of this an argument about whether 16-bit is more accurate than 8-bit. 16- bit is always more precise, but is the 16-bit image necessarily more accurate? And I don't think anyone's proven that 16-bit images are more accurate than 8-bit images. Part of the problem is figuring out what accurate means. Visual accuracy? Accurate compared to the original data file? But all these various conversions, combined with the effects of anti-aliasing filters (in the Canon sensors) and the Bayer conversion throws all sorts of monkey-wrenches into the argument when you're dealing with real-world images (you don't have pure, untouched, absolutely accurate data to begin with).

The original poster may be able to follow up more, although his example doesn't prove that 16-bit images are better, it just reinforces that masks are sometimes better edited in 16-bit (32K levels as opposed to just 256), but this doesn't prove that the image in its entirety will be improved by working in 16-bit.

Matthew Rigdon

___________________________________________________________________________

Posted by: "MARK SEGAL"

Sat Oct 7, 2006 3:23 pm (PST)

Re: A clear case of 16 bit superiority

Thanks for the extended explanation Dan, but I am still a bit uncertain about this. Firstly, I find it hard to understand how the 16 bit data is there when the finest of DSLRs now on the market only capture in 12 bit. The expansion from 12 to 16 I believe happens depending on the settings one chooses in Camera Raw, or whatever image file converter. You are of course correct that the Blue channel is usually the most prominent culprit for noise, but the s/n relationship is HIGHLY variable from one image to another depending on the conditions of capture (lighting, ISO setting, exposure, etc.) When I process a raw file and open it in PSCS2, one of the first things I usually do is test the image for noise to see whether it needs a pass of noise reduction. I use either Noise Ninja or Noiseware. NN is nice because it gives you a numerical readout of the noise level (colour and luminosity). the noise readings on my images typically vary between about 4 and 24. Hardly ever anything below 4 or above 24, though the program can measure much more. Unless the noise level is beyond say 12 or so, for inkjet printing up to A3 it can just as well be ignored. And that applies to MANY of the images I make. So again, I'm not saying the garbage theory is garbage, but I'm wondering whether in the case at hand the garbage really is garbage to begin with. I think the owner of the image needs to provide more information so we can put some additional facts behind the explanation.

Mark Segal

___________________________________________________________________________

Posted by: "Dan Margulis"

Sat Oct 7, 2006 9:34 pm (PST)

Re: A clear case of 16 bit superiority

Ric writes,

This is the one point where I respectfully disagree. As I stated, I

reprocessed the Raw file into 16 bit mode so I could compare the 8

bit to 16 bit conversion with a true 16 bit file. In this particular

case I found the "16 bit all the way" file superior.

OK, I have re-read your initial post, and unfortunately I missed that point on first reading. My apologies.

I have never doubted the quality of CaptureOne (the only Raw

processor choice for PhaseOne backs), however, it occurs to me that

the difference in appearance between the unedited files might be

showing a weakness in the programs internal 16 bit to 8 bit

conversion. Any thoughts?

This may well be the problem. In previous testing it became clear that certain capture modules did a poor job of generating 8-bit. For this reason, I have previously recommended to the list that they export into Photoshop in 16-bit and then convert to 8-bit at their convenience. I have verified that Camera Raw does not have this problem, but without checking my files, I seem to recall that CaptureOne does. So, I think you need to try it again by starting with 16-bit in Photoshop, and converting immediately to 8-bit (for the mask, of course, you'll need to go back to 16-bit for LAB).

That is, of course, just for curiosity--if you've opened in 16-bit RGB, and you can see that you may be making a mask out of the B channel, it wouldn't make much sense to go to 8-bit at all. But it would be nice to know.

I am a little vague on what procedure is involved here and where the mask fits in. For sure, I expect that the mask will be better if you make it in 16-bit, but AFAIK it shouldn't make a difference whether you *start* in 16-bit RGB or just convert into 16-bit LAB for the mask file.

My suggestion: if you are basing your comments on a Capture One-generated 8-bit file, redo the test by converting 16>8 in Photoshop. If you still think that 16-bit all the way is significantly better, then for sure I want to see it, but I think it would be easiest if you just e-mail me a 1 mb reproduction offline together with a step-by-step of what you were doing to the file. It could be that we're talking past one another.

The moderators are working on ideas to get us more posting space (and the offers of help last week from Adriano and from Mike Russell are noted and appreciated) but for the time being there is not enough space in yahoogroups to host images. I do note that Andrew Webb has kindly agreed to host the image. Before doing that, I think it might be wise to shoot me off the step-by-step, because I may have tested something similar and have another image to illustrate it with.

Because of this issue with lousy 8-bit coming out of camera modules, I'm including in the appendix to the forthcoming edition a relatively simple test, requiring comparison of an 8-bit file generated by the module to a 16-bit file converted to 8-bit in Photoshop. If anybody wants, I'll post the test here.

Dan Margulis

___________________________________________________________________________

Posted by: "Richard Wagner"

Sun Oct 8, 2006 7:31 am (PST)

Re: A clear case of 16 bit superiority

On Oct 7, 2006, at 10:19 AM, MARK SEGAL wrote:

Thanks for the extended explanation Dan, but I am still a bit

uncertain about this. Firstly, I find it hard to understand how the

16 bit data is there when the finest of DSLRs now on the market

only capture in 12 bit. The expansion from 12 to 16 I believe

happens depending on the settings one chooses in Camera Raw, or

whatever image file converter.

Actually, the H 25 Phase One digital back that Ric used to capture the image under discussion uses 16-bit output from the sensor. () But I agree with the rest of your discussion - the noise in the image will be very, very low.

--Rich Wagner

___________________________________________________________________________

Posted by: "markds0"

Sun Oct 8, 2006 7:35 am (PST)

Re: A clear case of 16 bit superiority

Matthew I don't see where you are coming from in most of your last post, so I put my questions after your statements where they belong, and to make my stuff clearly distinct from your stuff I put mine in CAPS. [This is not shouting with the keyboard - only done for easy distinction of who is saying what :-).]

The original poster was making a mask from the B channel and chances are that channel will be noisier than the A channel

(which relies more on red and green channels).

WHAT ARE THE "CHANCES" - IT IS MORE IMPORTANT TO HAVE THE FACTS OF THIS CASE, AND FROM WHAT HAS BEEN SAID SO FAR IT WOULD SEEM THERE IS MOST LIKELY LITTLE NOISE IN THE BLUE.

Most digital cameras use Bayer algorithms to make up

the colors in the image to begin with (the Foveon being the only

exception I know of), plus it's based on sampling green two times

more than blue or red, so it adds another dimension to the argument

about whether or not we should be worried about how many thousands

or millions of colors are in a data file.

WHAT "DIMENSION" IS ADDED BY THE EXISTENCE OF TWO GREEN CHANNELS FOR EACH RED OR BLUE? AND HOW IS THE ARGUMENT ABOUT UNIQUE COLORS RELEVANT TO THIS DISCUSSION. WE'RE TALKING ABOUT WHETHER A CONVERSION FROM 8 TO 16 BITS ADDS GARBAGE OF LEVELS WITH USEFUL DATA - NOT NECESSARILY "UNIQUE" COLORS.

Everyone keeps saying that 8-bit to 16-bit doesn't change anything

WHO ARE THESE EVERYONE? THE WHOLE PURPOSE IS TO CHANGE CERTAIN THINGS (FOR THE BETTER).

In the case of the camera, you have to ask whether the 12-bit to 8-

bit conversion is more accurate than the 12-bit to 16-bit conversion.

THESE CONVERSIONS DON'T HAPPEN IN A CAMERA, THEY HAPPEN IN THE RAW CONVERTER, AND WHY DO YOU HAVE TO ASK THAT? WHAT IS THE RELEVANCE OF THIS QUESTION TO THE MATTER AT HAND?

Since a lot of people want to talk about the science, I think part

of this an argument about whether 16-bit is more accurate than 8-

bit.

NOT OBVIOUSLY REVELANT TO THE ISSUE.

The original poster may be able to follow up more, although his

example doesn't prove that 16-bit images are better, it just

reinforces that masks are sometimes better edited in 16-bit (32K

levels as opposed to just 256), but this doesn't prove that the

image in its entirety will be improved by working in 16-bit.

THIS IS A PARAPHRASE OF WHAT DAN SAID, BUT NOTHING IN THE MATERIAL ABOVE SUPPORTS IT. AND THE ISSUE WASN'T ABOUT WHETHER OR NOT 16 BIT DEPTH IS NECESSARILY BETTER THAN 8 IN ALL CIRCUMSTANCES. THE QUESTION WAS ABOUT WHY IT SEEMS BETTER IN THE PARTICULAR EXAMPLE AT HAND. IT'S GOOD IN A DISCUSSION LIKE THIS TO KEEP THE ANSWERS FIRMLY RELEVANT TO THE QUESTION, WHICH NOW INCLUDES WHAT DAN PROPOSED AS A DIRECT ANSWER TO IT.

Mark Segal

___________________________________________________________________________

Posted by: "Bartlomiej Walczak"

Sat Oct 7, 2006 3:26 pm (PST)

Re: A clear case of 16 bit superiority

Hi Mark,

OK, let me explain it then.

The conversion from 8-bit to 16-bit is done in the following way:

A=128,5*B

Where A - pixel value in 16-bit, B - pixel value in 8-bit.

Because all numbers must be integer, then some rounding will take place, for example for value 153 you will get 19661 in 16-bit. But divided you get 128,503(...) so this is not much of a difference (3/100).

There is no interpolation, dither, no other data manipulation that takes place which you can test for yourself. If your histogram was "spiky" in the first place, then upconverting to 16-bit will not create artificial detail from something that it was not there. There is no magic in conversion to 16-bit. It's a very linear operation. There is no harm in doing this.

As for more room when converting 16-bit sRGB image to Lab as opposed to 8-bit sRGB to Lab, here is how different 16-bit values I got for two pixels that had -2 in channel a in 8-bit: one was -219, another was -305 in 16-bit. If I just converted to 8-bit Lab, this difference (yes, it *is* a subtle difference) would be lost.

I think the topic of posterization has been talked to death here, but this is precisely the result. The number of unique colors that you can get by converting to 8-bit Lab and back to sRGB is dramatically reduced. This does not happen when you convert to 16-bit Lab and then convert back to sRGB, precisely because different values are not treated as the same ones (two times -2 vs -219 and -305).

So there is absolutely no harm done in upconverting to 16-bit and going to Lab.

If you want to make a test of a difference, do it this way:

- take any real-world sRGB picture

- duplicate it

- convert one version straight to Lab

- convert another version to 16-bit (image->mode->16-bit per channel)

- convert the second one to Lab

- convert both back to RGB

- convert the second one to 8-bit

- put one image on top of the other in a difference mode

- make a threshold adjustment layer to see how many pixels differ

The differences are not big - maximum 3-4 levels. But there are many pixels that differ by 1-2 levels especially in the lighter and darker parts of the image. Does data loss happen? Yes. Is it noticeable? I don't think so.

My conclusion is that if you want, you can take an extra step and upconvert to 16-bit before conversion to Lab, just to be sure that you're not loosing too much data. But I bet not very many people will notice if you don't. Especially if they hadn't seen the image before the correction.

So... does this answer your question?

All the best

Bart

PS: Dan, thanks for the great book on Lab.

___________________________________________________________________________

Posted by: "MARK SEGAL"

Sun Oct 8, 2006 7:29 am (PST)

Re: A clear case of 16 bit superiority

Bart, no it doesn't answer my question, but thanks for trying.

I'm not a color science mathematician so I find this totally confusing. I don't understand the first equation you have there - never seen a formulation like that - I don't know how it gave you a value of 19661 in 16 bit from a value of 153 in 8 bit. (In any case Photoshop works in 15 bit, so 1 bit-worth gets filled with zeros on conversion anyhow.)

I also think for clarity it would be useful to discuss separately the implications of conversion related to size of the colour space and those related to bit-depth. While they are separate, I believe the the former has implications for the appropriate choice of the latter.

Mark Segal

___________________________________________________________________________

Posted by: "Matthew Rigdon"

Sun Oct 8, 2006 3:10 pm (PST)

Re: A case of clear 16 bit superiority

A lot of people on this list gets photos from people who shoot everything in high quality JPEG, which means the 8-bit conversion is done in camera. This would happen in all cases that a photographer uses jpeg, as jpegs are always 8-bit.

As to the specific case, the camera produces 16-bit images (I didn't know that, I just have a Canon) but the number of cameras out there that can do this is very small (and very expensive). While going all 16-bit throughout the process might be better if you start 16-bit, this often gets spun off into the conclusion that everyone should work 16-bit because it worked in this one case. The original poster went on to explain that 16-bit conversions with his Capture One software were better than the 8-bit conversions, but Dan pointed out that Capture One doesn't handle 8-bit well.

There are many variables to the whole situation, however in this case the original poster is using software that just doesn't do a very good job converting to 8-bit. He should use 16-bit for his workflow, but it's not because 16-bit is inherently superior. It's because the software tool he's using doesn't do good 8-bit conversions.

He also mentioned pulling a mask and masks are much easier to work with in 16-bit, so in many cases you may want to take a 16-bit version of the image, pull your mask, then drop it into the 8-bit version of the image for other work. While 16-bit improves the mask, it doesn't necessarily improve the other work you do on the image (curves, sharpening, etc).

But if the question is just whether 16-bit is better in this particular case, the answer is yes. If you're shooting with a medium format back and you use Capture One, you should use 16-bit because the software does a bad job converting to 8-bit.

Matthew Rigdon

___________________________________________________________________________

Posted by: "Iliah Borg"

Sun Oct 8, 2006 8:42 pm (PST)

Re: A case of clear 16 bit superiority

Dear Richard,

The quantization and rounding errors associated with an 8-bit vs. 16-

bit workflow involving conversions between sRGB (or other RGB color

spaces like ColorMatch) and Lab are easy to demonstrate.

Ink smearing and dot gain are even easier to demonstrate. Usually any subtle imperfections in histograms are well masked with those effects.

Have you tried to compare the histogram of the image in computer to the histogram obtained from a print?

Now this reminds me of one of the most asked questions: "How should the perfect histogram look like?" :)

Best regards,

Iliah Borg

___________________________________________________________________________

Posted by: "Ric Cohn"

Mon Oct 9, 2006 10:44 am (PST)

Re: A clear case of 16-bit superioiryt

Andrew Webb has been kind enough to let me upload the files in question to his server and has provided this link: <http: //www.webbwork.com/clients/colortheory/>

The Raw processor did indeed do a poor job of outputting to 8 bits. It might have been the difficult nature of this shot that made it so apparent, but from now on I'll process at 16 bits and downsample to 8 bits if I don't think 16 bit will help.

That leaves a comparison of the original 16 bit output and a duplicate file downsampled to 8 bit then upsampled or not back to 16 bit in Pshop. Here the differences are much more subtle. The question now is whether the differences are significant and whether there are other changes in my working methods that would eliminate the differences (for all practical purposes).

One thing that is very clear from this test is the superiority of converting from 8 to 16 bit before creating masks. I guess the next question is how radical do the adjustments to an Alpha channel need to be to see a difference? I hate to say it, but it may be that working in 16 bit makes sense for more of my work than I used to think, even if the file comes to me in 8 bit. Thoughts?

I know I have a lot more to learn!

Ric Cohn

___________________________________________________________________________

Posted by: "Stephen Marsh"

Mon Oct 9, 2006 10:50 am (PST)

Re: A clear case of 16-bit superioiryt

--- In , Ric Cohn wrote:

Yes, I tried to make it clear to those that are familiar with the

issues that I wasn't claiming I'd proven "THE" 16 bit advantage. I

was one of those who gave 16 bit images to Dan for the last edition

and had been unable to find any advantage either.

Just trying to do my bit to keep the topic in focus from the start Ric, but that was perhaps always wishful thinking.

My point is that

here was an image destined for a printing press where knowing when to

go to 16 bit is critical.

The mask, not the image - is that not so? What you comment on is known and easily observed, although I have not found it to be as significant a problem in my work (but I don't always use raw AB channels as sources for masks so it is no surprise that I may not have seen this). What you were not commenting on (the benefits of a 16bpc workflow for RGB/CMYK image editing for press output) is not easily observed in real world results.

It also raises the question in my mind (and

for my particular kinds of work) whether I should greatly increase

the situations where I process into 16 bit files for safety's sake. I

do think this is of interest to others on this list as it is to me.

Food for thought is always good, but a food fight is not - which is where this topic usually goes.

Parts of my reply were more aimed at the posts that were likely to come, rather than being aimed at you Ric. Sorry for any confusion, just trying to keep things on topic before the topic goes off the rails.

It is well worth keeping in mind that this is LAB mode a single AB channel of LAB and not working three RGB channels, so thus the results of high bit mode conversions are different to RGB and CMYK.

If people are interested perhaps I could post some closely cropped

files. Can these be placed as .tifs on the Yahoo site?

I personally would place any files into a .zip archive and then upload the archive to the www.yousendit.com server, simply use your own email as the recipient and then post the http link that will be emailed to you to the list (it is then freely available for 7 days).

Regards,

Stephen Marsh.

___________________________________________________________________________

Posted by: "Mark Segal"

Mon Oct 9, 2006 9:14 pm (PST)

Re: A clear case of 16-bit superiority

RIc,

You shouldn't hate to say it. The overwhelming majority of published Photoshop experts advise that working routinely in 16 bit mode mitigates the risk of posterization/banding in certain situations - they do not say that one will necessarily always see better image quality from 16 bit files - they present the case for using it as an insurance policy. It does come at the cost of much larger file sizes, but with today's computers and low cost disc storage this is not the big deal it used to be.

Mark Segal

___________________________________________________________________________

Posted by: "Dan Margulis"

Tue Oct 10, 2006 5:12 am (PST)

Re: A clear case of 16-bit superioiryt

Ric Cohn writes,

That leaves a comparison of the original 16 bit output and a

duplicate file downsampled to 8 bit then upsampled or not back to 16

bit in Pshop. Here the differences are much more subtle. The question

now is whether the differences are significant and whether there are

other changes in my working methods that would eliminate the

differences (for all practical purposes).

There are a number of missing pieces here. The only things I'm getting from the link are the original 16-bit RGB image, plus a B curve that is evidently being used to create a mask. I don't have a sense of how everything fits together because, unless I missed it, there's no explanation of what we are trying to achieve and no step-by-step as to how it is done.

Here's what I'm perceiving so far.

1) You say that the 8-bit file being generated by the CaptureOne module is no good. You suggest starting with a 16-bit file, and then, at some future point, converting it to 8-bit in Photoshop. This accords with my own experience.

2) We are taking a copy of this file into LAB and applying a curve to the B channel, which is then going to become a mask for reasons that are as yet unclear. I have done this four ways: converting the 16-bit to LAB, converting the 16-bit to 8-bit in RGB and then converting to LAB one time with dither and one time without, and converting 16>8>16 in RGB and then to LAB. In each case I apply the supplied drastic curve to the B channel and save it as an 8-bit grayscale file. I understand you to be saying that at this point, the 16-bit all the way version is the best, the 16>8>16 version is slightly worse, and the undithered version done in 8-bit all the way is much worse. If so, that's the way I see it, too. I see the dithered 8-bit version as being approximately equivalent to the 16>8>16 version.

But what is this mask being used for? Are we working the file itself in LAB, or did we just take a copy of it into LAB for the purpose of generating the mask? The following are my questions about the process.

1) I'm confused by the initial post, which seemed to say that there was an advantage in 16-bit in this image above and beyond the mask itself. IOW, assuming that a good-quality mask falls out of the sky into our lap, does it matter whether what happens next happens in 16-bit or 8-bit? Or was this claim somehow related to the 8-bit file generated by CaptureOne as opposed to the file that went 16>8 in Photoshop?

3) What happens next, once we load the mask? Is the next step so small that the difference between the four masks is inconsequential?

3) Why are we making a mask out of the B at all? Certainly there are some images that require us to use the B, but in this one, it looks like we'd be better off starting with the red of RGB.

4) In every use that I can think of for this mask, we should be blurring it before loading it. If we do this, there won't be any difference between the 16-bit mask and the 16>8>16 one. There may not even be a difference between the 16-bit all the way and 8-bit all the way versions. Is there some reason that we're avoiding the normal step of blurring the mask?

These questions are all academic IMHO in relation to your workflow now that you have decided to acquire the image in 16-bit. Whatever the reason is that requires this mask, you should be aware from the moment that you open the picture that you probably need one and that applying a drastic curve to the B channel is one possibility for where to get one. If so, who cares whether it would work better in 16-bit or not? It certainly wouldn't work worse, and you only have to keep the file in 16-bit for a little bit longer. Once you've gotten the mask you can drop the file to 8-bit if you like.

Dan Margulis

___________________________________________________________________________

Posted by: "Rich Wagner"

Mon Oct 9, 2006 10:50 am (PST)

Re: A clear case of 16-bit superioiryt

Olivier,

Thanks for your interesting post of a "thought experiment." It will take me some time to carefully think about it. Like you, I also hope for more courtesy on this Listserve, as the environment often borders on toxic.

I would like to also point out that all of the "problems" that (may or may not) occur with 8-bit Lab can be completely avoided by working in 16-bit Lab. This does not mean that one would have to adopt a 16-bit workflow. 8-bit images can be converted to 16-bit, the "work" can be done in 16-bit Lab, and the image can be converted back to RGB or CMYK and then converted to 8-Bit and saved. Unless you store intermediate images, this does not require additional storage space, and the speed of current computers makes the additional processing time insignificant. There is really no significant downside that I am aware of in working within 16-bit Lab, and there may be a significant advantage - even with "real" images, as Ric recently reported. It is very common in signal processing to use higher precision math for intermediate calculations. I don't understand why it should be such a big deal in this case, or why the mention of 16-bit causes such dramatic increases in blood pressure and pulse to many on this List.

Thanks again for contributing to this discussion.

--Rich Wagner

___________________________________________________________________________

Posted by: "Ron Kelly"

Mon Oct 9, 2006 9:16 pm (PST)

Re: A clear case of 16-bit superioiryt

On 9-Oct-06, at 6:40 AM, Rich Wagner wrote:

I don't understand why it

should be such a big deal in this case, or why the mention of 16-bit

causes such dramatic increases in blood pressure and pulse to many

on this List.

Richard:

I would have to disagree with you and several others who have said that doubling the size of the file is insignificant with respect to "the proliferation of storage speed/cost reduction and increase in computer power" (sic).

I don't want to use a 100 mb file if 50 will do the *same* job; I don't mind if the file I'm working on is 5mb instead of 10, etc. It's about a ratio, not an absolute value; 1/2 the size is 1/2 the cost and twice the speed.

No matter what the speed of future computers, we only need so many bits for our files. What is that threshold? Time will shortly tell whether we need more than 8 as this issue will be understood by a critical majority and then we'll move on to other things.

Time will also tell whether we, the consumers of mainstream software and hardware, will be served in a reasonable way or forced to go to the grocery store in a semi-trailer. It isn't always the case that what predominates in the marketplace is the best for the end user.

Now that we have DVD discs which are much larger than CDs, I must say that I don't really feel the need to replace my music library with files that are sampled at twice the rate of CDs. As far as I know, no one is advocating for that, thank goodness.

Ron Kelly

___________________________________________________________________________

Posted by: "Mark Segal"

Mon Oct 9, 2006 9:16 pm (PST)

Subject: Re: [colortheory] Re: 'Quantization' and Rounding 'Error'

I don't understand why it should be such a big deal in this case, or why the mention of 16-bit causes such dramatic increases in blood pressure and pulse to many on this

List.

Rich,

Neither do I. it should be completely uncontroversial, because it is no big deal. People should work in whatever bit mode suits their purposes. The same goes for working colour spaces. I think the continuation of either of these issues is completely pointless.

Mark Segal

___________________________________________________________________________

Posted by: "Rich Wagner"

Tue Oct 10, 2006 5:28 am (PST)

Re: A clear case of 16-bit superioiryt

On Mon, October 9, 2006 1:10 pm, Ron Kelly wrote:

Ron,

I would respectfully like to submit that you've missed my point. You can take an 8-bit source file, convert to 16-bit in PS and then convert to Lab, do your work in Lab and convert back to 8-bit RGB, then save the file with zero increase in file size, and the benefit of higher precision while working in Lab. There is a zero hit on archive storage space.

--Rich Wagner

___________________________________________________________________________

Posted by: "Bartlomiej Walczak"

Mon Oct 9, 2006 9:16 pm (PST)

Re: A clear case of 16-bit superioiryt

Hi,

MS> I'm not a color science mathematician so I find this

MS> totally confusing. I don't understand the first equation you have

MS> there - never seen a formulation like that - I don't know how it

MS> gave you a value of 19661 in 16 bit from a value of 153 in 8 bit.

MS> (In any case Photoshop works in 15 bit, so 1 bit-worth gets filled

MS> with zeros on conversion anyhow.)

Technically it's 16-bit signed, where the 1st digit tells if it is positive or negative value. 16-bit range is 0-65535, signed it's -32287 to 32288. Because RGB uses only positive values, you get only 15-bit worth of data. A different case with Lab, where a and b can be negative.

As for the equation, I got it from Photoshop itself. In order to check how it behaves, I used info pallette, one in RGB 8-bit, another in RGB 16-bit. You can then see what value of an 8-bit pixel will be when converted to 16-bit.

I wanted to make sure that the values I was getting were the correct ones, so I created a b/w gradient in 8-bit RGB and converted it to 16-bit RGB. The values were exactly as Photoshop had displayed them before.

You can do it by yourself and check it. You will see that the numbers in 16-bit are the same as in 8-bit times 128,5 or 128,503. This 0,5 did surprise me, I expected rather 128 (2^7). But this is how it works.

No data loss, dithering or anything like that in converting to 16-bit.

As for LAB, I'm leaving the subject. Richard has already expressed my own opinion better than I can.

All the best

Bart

___________________________________________________________________________

Posted by: "Ron Kelly"

Tue Oct 10, 2006 2:17 pm (PST)

Re: A case of clear 16-bit superiority

Rich:

Perhaps you are a much more confident Photoshopper than I am.

I often save a file in several states; I don't just archive the final state. What if I want to

return to "fix" something?

If I'm working in 16 bit at some point, I'm going to be archiving some 16 bit files, even if

I output at 8 bit. That's going to up the ante, and if I got something for that cost then

I would consider doing so.

Ron Kelly

___________________________________________________________________________

Posted by: "Bob Frost"

Tue Oct 10, 2006 2:21 pm (PST)

Re: A case of clear 16-bit superiority

Ron,

Now that we have DVD discs which are much larger than CDs, I must say that I don't

really feel the need to replace my music library with files that are sampled at twice

the rate of CDs. As far as I know, no one is advocating for that, thank goodness.

Those hifi experts who can hear the difference would disagree with you!!

bob Frost.

___________________________________________________________________________

Posted by: "Matthew Rigdon"

Tue Oct 10, 2006 5:01 pm (PST)

Re: A case of clear 16-bit superiority

There is a DVD-Audio spec, it's just nobody will buy the discs (they're out there, somewhere).

It's interesting because while everyone in the image processing world is obsessing about higher and higher quality, over in the audio and video worlds quality is dropping. DVDs were a jump ahead of VHS, but downloaded movies are a step below DVD (in the case of video files for the iPod, the quality is barely above VHS). Every field varies, but there is a point of diminishing returns when it comes to output quality from input source. You often have to make decision based on things other than theory or laboratory results. A DVD-Audio disc is superior to a CD, but do I actually want to pay for it?

Matthew Rigdon

___________________________________________________________________________

Posted by: "Richard Wagner"

Tue Oct 10, 2006 5:01 pm (PST)

Re: A case of clear 16-bit superiority

You're right, Ron. Every one of those intermediate files would be twice as big. You'd probably generate terabytes worth of intermediate files and then you'd need to invest in an expensive RAID drive to store all of them. I'd stick to 8-bit all the time, start-to-finish, and not worry about any differences in the images. I'm sure the quality of your work is more than good enough right now, and further improvement would be a waste of CPU cycles as well, so there's no point in upping the ante by using greater accuracy in your workflow. Let the levels fall where they will! And check E-bay often, there have been some great deals on 8-track tapes. They still sound terrific, even on the latest Bose sound systems, especially if you use a filter to dampen the noise. (Just think of it as a Gaussian blur on the b channel.)

Seriously, would you save that many files as 16-bit Lab intermediates that it is going to "up the ante?" Hundreds a day? Thousands? Do the math! This sure seems like another specious argument triggered by the dreaded enemy known as "16-bit," rather than a legitimate workflow concern. But, hey, if it's not right for you, don't do it!

16-bit is dangerous territory, anyway. If you try it just once, you'll probably start playing around with wide-gamut color spaces and experimenting with other dangerous stuff, and before you know it, you'll have turned into a color management junkie and you'll start hanging out with the addicts on the "other" listserve. Resist the temptation!!! Stay in 8-bit!

--Rich Wagner

___________________________________________________________________________

Posted by: "Ron Kelly"

Tue Oct 10, 2006 5:02 pm (PST)

Re: A case of clear 16-bit superiority

Bob:

I don't want to go too far with this music analogy. I suspect that sound recording has it's own tempests-in-a-teapot and no, it's not my area of expertise.

However, the analogy is apt this far: if the "experts" contend that something sounds better, I would agree with them if:

-it's proven using with (in this case) *sound* as opposed to charts or statistical analysis;

-independent, double-blind juries agree (you don't need vision to hear, nyuk!);

-my own ears agree also.

I would not agree with the "experts" if they prove the superiority of one sound file over another by using a graphical display of a statistic, such as a histogram type graphic.

I wouldn't ultimately evaluate sounds by anything else than my ears just as I ultimately wouldn't evaluate images with anything else but my eyes.

Cheers,

Ron Kelly

___________________________________________________________________________

Posted by: "Matthew Rigdon"

Tue Oct 10, 2006 5:02 pm (PST)

Re: A case of clear 16-bit superiority

But all of your 8-bit values are being shifted up half a level, correct? I don't believe that a 16-bit value in Photoshop can contain a fraction.

If all the 8-bit values are being rounded up, then every pixel in your 8-bit image is being changed when you convert to 16-bit. If preserving these original unique values is our goal, then converting to 16-bit would be doing harm to our entire image, wouldn't it?

Matthew Rigdon

___________________________________________________________________________

Posted by: "Bob Frost"

Wed Oct 11, 2006 2:14 pm (PST)

Re: A case of clear 16-bit superiority

Ron,

If I am not careful, I shall start pointing out how one's hearing ability diminishes with age, just as our vision does! And replacement innards for our ears haven't quite got there yet, unlike lens replacements that refresh our vision.

Bob Frost.

___________________________________________________________________________

Posted by: "Hoffner, Randall N"

Wed Oct 11, 2006 2:20 pm (PST)

Re: A case of clear 16-bit superiority

This is a bad comparison. DVD audio is compressed, using MPEG or Dolby AC-3 compression. (Not to say it can't sound good.) It starts life with a sample rate of 48 kHz and a bit depth somewhere up to 24 bits per sample. 5.1 channel sound can be recorded on DVDs in this manner.

Compact discs record uncompressed 2-channel stereo audio at 16 bits per sample, with a sample rate of 44.1 kHz. Here you could start the bit depth argument, but the philosophy is that if you acquire and edit at 24 bits, and maybe sampling at 96 kHz, you do less audible damage to the music, but 16 bits is fine for the end product.

There is a standard for Super Audio CD that has a 96 kHz sample rate, but it didn't really fly in the marketplace, and Nyquist tells us it is not necessary to sample at this high a rate.

Bottom line, CDs deliver higher audio quality than DVDs.

Randy Hoffner

___________________________________________________________________________

Posted by: "Richard Wagner"

Wed Oct 11, 2006 2:23 pm (PST)

Re: A case of clear 16-bit superiority

On Oct 10, 2006, at 2:50 PM, Matthew Rigdon wrote:

It's interesting because while everyone in the image processing world

is obsessing about higher and higher quality, over in the audio and

video worlds quality is dropping.

Really??? You must mean, like, HDTV? ( 2006/10/05/technology/05pinnacle.html) Or HD-DVD? (36 megabits a second) Or was it Blu-ray? (com/reuters/ technology/tech-media-gamestop.html) Video quality is dropping? No interest in high-res video? Not from what I'm seeing. Cell phone signal quality? Can you hear me now? Nope, no improvement there...

--Rich Wagner

___________________________________________________________________________

Posted by: "MARK SEGAL"

Wed Oct 11, 2006 2:24 pm (PST)

Re: A case of clear 16-bit superiority

A 16-bit workflow can't damage your images, so if you really need excuses not to use it, you can always point to issues about processing and storage, but it is best to put a fine point on these issues so we really know what we're dealing with. The latest price for a 500 gigabyte external HD is 235 dollars - that's 47 cents per gigbyte. On average my 16-bit processed Canon 1Ds files are roughly 150 MB each. Tthat's about 7 images per GB, or 6.7 cents storage each. Had I preserved that work in 8 bit, the saving would be about 3.4 cents per image, so after 10,000 images say 340 dollars. I stopped burning files to DVD after I was reliably informed that they can be expected to degrade after a few years, unless they are DVD-RAM. This technology is anyhow slow and and at today's storage costs expensive compared with external HDs operating on USB2 or Firewire. My 4 year old computer handles 16 bit processing efficiently and the new one I am about to buy will be blazing faster, so there's no concern about that either. If everything else about digital photography were as cheap as storage we'd be in nervana.

Mark Segal

___________________________________________________________________________

Posted by: "Terry Wyse"

Wed Oct 11, 2006 2:27 pm (PST)

Re: A case of clear 16-bit superiority

On Oct 10, 2006, at 7:41 PM, Ron Kelly wrote:

I don't want to go too far with this music analogy.

No, lets! It's like this....

16-bit doesn't always show its advantages, especially with offset printing, because we're only able to play the image on the equivalent of low-end boom box speakers today but SOMEDAY we'll able to play them on a nice set of B&W/Klipsch/Infinity Reference/high-end-imaging- device-of-choice. I'll bet then we wish we'd have recorded that priceless image in higher bits. Or not.

The bit of carping about 16-bit images taking up only twice as much storage makes me giggle. I wonder how many terabytes are wasted as a result of folks convinced that all that extra RESOLUTION in their images really makes a difference? I'll bet all those wasted bytes pail in comparison to what would be "wasted" as a result of using 16- bit some, but not all, of the time.

As for me and my house, we'll keep most of our working files in 16-bit and convert to 8-bit for final output.

Regards,

Terry Wyse

___________________________________________________________________________

Posted by: "Ron Kelly"

Wed Oct 11, 2006 2:39 pm (PST)

Re: A case of clear 16-bit superiority

On 10-Oct-06, at 5:17 PM, Richard Wagner wrote:

You're right, Ron. Every one of those intermediate files would be

twice as big.

Richard:

Yes, I am right about that. That's one thing that we know for certain.

Ron Kelly

___________________________________________________________________________

Posted by: "Bartlomiej Walczak"

Wed Oct 11, 2006 2:18 pm (PST)

Re: A case of clear 16-bit superiority

Well... it's not that simple with video if you consider the coming of HDV and HDTV. It goes towards the higher quality too (I do editing so I know what I'm talking about here). The question of downloading is rather the availability issue, and how much quality people can sacrifice only to have their video delivered them via Internet.

Interestingly, the issue of DVD (Standard Definition) vs HDV (High Definition) seems to be strangely similar to 8-bit vs 16-bit debate. HDV offers clearly better resolution when viewed close to the screen, but from more than 1 meter you will not see much difference.

And DVD Audio the same. There are people who will notice the difference, but most probably will not.

All the best

Bart

___________________________________________________________________________

Posted by: "Bartlomiej Walczak"

Wed Oct 11, 2006 2:19 pm (PST)

Re: A case of clear 16-bit superiority

Hi,

MR> But all of your 8-bit values are being shifted up half a level,

MR> correct? I don't believe that a 16-bit value in Photoshop can contain

MR> a fraction.

You're right, it can't. Mind you, half a level in 16-bit is roughly 0,03 levels in 8-bit. So the difference is not anything anyone can notice except in numbers.

Not all values are shifted. Even ones are not, because they give the integer result.

MR> If all the 8-bit values are being rounded up, then every pixel in

MR> your 8-bit image is being changed when you convert to 16-bit. If

MR> preserving these original unique values is our goal, then converting

MR> to 16-bit would be doing harm to our entire image, wouldn't it?

See above, plus when you convert back to 8-bit you return exactly to the number you started from. So your 8-bit values are preserved. Go and check for yourself.

All the best

Bart

___________________________________________________________________________

Posted by: "Dan Margulis"

Wed Oct 11, 2006 2:21 pm (PST)

Subject:Moderator Notice: Stay on Topic

Folks,

When Ric Cohn posted concerning his image in which there was a question about 16- and 8-bit, Stephen Marsh wisely cautioned the list that none of us have any more tolerance for useless political banter on this topic. We have been going through it for six years on this list, and anyone who wants to bore themselves with it will find plenty of reading material in the edited threads posted at www.ledet.com/margulis.

Stephen's warning has unfortunately proven correct. I am about to leave for the airport for another two-week trip. Before going, I am approving a backlog of (currently) eight posts, not one of which has anything to do with the primary purposes of the list.

If Ric comes back with more details about the image he is referring to, we certainly want to continue the discussion of it. Already he has emphasized a couple of points that are useful to us in our daily lives--that third-party capture modules sometimes give us bad 8-bit files, and that when making masks involving extreme changes to the AB channels of LAB it can be useful to convert from 8-bit to 16-bit. And there may be more lessons from the image as well, we don't know yet.

Mark Segal is quite correct when he says that working in 16-bit is not harmful to the file, at least not unless you are making extreme changes in B/W or in an ultra-wide or ultra-low gamma RGB, which nobody does AFAIK. Ron Kelly is quite correct when he objects to doubling file size without having the slightest expectation of any benefit, and at this point the evidence is overwhelming

that there isn't--if Ric's image shows an overall 16-bit advantage, it will be the first one that we know of. Nobody should be sniping at Mark if he chooses to use 16-bit. If they do, I'm rejecting the post and I hope that other moderators would do so as well. Ron is a photographer. He works with photographs. Nobody should be sneering at Ron for not using 16-bit UNLESS they can show him how it benefits a photograph--not a histogram, not a gradient, not a reference to how things work in the audio or video worlds. Anyone who does otherwise is on notice that I will reject the post and that I urge other moderators to do the same.

Specific comments on Ric's image and what it demonstrates are of course welcome, as are any other example images.

For a good part of the last year I have been working with new images that offer a lot of interesting lessons. I have not been able to share them with the list because of time constraints associated with the new edition, but I hope we'll be able to discuss them constructively in the future.

I would also comment that it is correct that the way to evaluate whether an image has been improved is by a jury that doesn't know which version is which. As readers will know, I often put such juries together and would be glad to do so again if circumstances warrant.

Also, next month I will be teaching two advanced courses where I am being joined by people who are roughly as good at color correction as I am. If useful images surface before then, we can certainly bring them to that group's attention. For example, Vladimir Yelisseev provided a very useful image on the question of whether to acquire images into ProPhoto RGB. It arrived too late to include in the book (although I have put it on the book's CD with a brief discussion of what it shows in the text), and I hope we will be able to discuss it here by the end of next month.

Meanwhile, let's have an end to this thread, except as to how it relates to specific images such as the one Ric has provided.

Dan Margulis

___________________________________________________________________________

Posted by: "Matthew Rigdon"

Thu Oct 12, 2006 7:10 am (PST)

Re: A case of clear 16-bit superiority

Well, superior has a lot of different meanings. DVD-Audio does offer a higher sampling rate (which is supposed to be better) but requires extra amounts of compression (as you pointed out, CDs are uncompressed). But in other industries, you end up with all sorts of factors coming into play. DVD-Audio is superior in that it can include up to 5.1 channels of audio and has a higher sampler rate, but it's compressed so you aren't getting "perfect" quality. Of course, all of this is complicated by the fact that audio starts out as an analog signal that gets converted to digital and then back to analog for playback. There are plenty of hardcore audiofiles who note, rightly, that analog is still superior to digital for audio clarity. It's just not convenient.

Video has always been compressed in some fashion. In my eyes, HDTV is worse, at least when I go in the store and look at the sets playing DirectTV. I've dealt with video compression for years, though, so that may be why HD drives me nuts: I can see the compression artifacts. In order to make HD work, they have to use MPEG-2 or MPEG-4, which works by throwing data away. There's never been much argument in the video field, though, because it was (and still is) a matter of throwing data away or just not being able to work at all. All the reasonably priced HD video formats out there (HDV, DVCPRO) use copious amounts of compression to get things to fit. My point is that you often have to make decision to "mangle" data in order to produce a video or album, but it doesn't mean that the work is ruined or of lesser value.

I personally shoot RAW and edit in 16-bit, but I know that it doesn't make my image files any better than anyone else's. I prefer to focus on the work itself and getting the best results, not how I get there. And if I found myself in the right situation, I wouldn't hesitate for a moment to use 8-bit for all my work as results can be achieved there that are just as good as what I'm doing in 16-bit, especially in light of the current output capabilities of monitors and printers.

I think a good part of it is too much focusing on theories and numbers, as has been pointed. I can prove, beyond a shadow of a doubt, scientifically, that any Britney Spears album is superior to any Beatles album in terms of recording, mixing, and production. But more of us would probably prefer to listen to "Hey Jude" than "Hit me Baby, One More Time." :)

Matthew Rigdon

___________________________________________________________________________

Posted by: "Ric Cohn"

Mon Oct 16, 2006 4:33 pm (PST)

Re:Moderator notice: stay on topic -16 bit file

On Oct 11, 2006, at 1:48 PM, Dan Margulis wrote:

If Ric comes back with more details about the image he is referring

to, wecertainly want to continue the discussion of it.

Sorry, I haven't been able to follow through yet. Due to a heavy work load, illness and a family visit I haven't been reading the posts. I plan on catching up and looking at everything again soon. In the mean time, the Raw file and my 16 bit processed file are posted. I don't know if anyone has looked at these critically or not. At least it's a real image from a good digital back.

BTW, I was at a client's last week where they had blown up an image from this digital back for their lobby. It was a cropped file blown up to about 4' x 8' and looked pretty good even up close.

Ric Cohn

___________________________________________________________________________

Posted by: "Ric Cohn"

Wed Oct 18, 2006 9:12 pm (PST)

Re: A case of clear 16 bit superiority -- Follow Up

As promised I have taken another look at the image in question and will re-evaluate what I see and try to answer some lingering questions. I want to make clear that I'm not looking to prove or disprove any point of view. I'm just trying to figure out when and where I should modify my workflow. In fact, I think the non-typical nature of this image might show problems that many would never see. Certainly I've output thousands of 8 bit images from CaptureOne without seeing this vast a difference.

Dan wrote:

There are a number of missing pieces here. ...

But what is this mask being used for? Are we working the file itself in LAB,

or did we just take a copy of it into LAB for the purpose of generating the

mask?

I wanted a sharp mask of the gold. For color correction reasons I wanted to be able to desaturate everything except the gold and be able to adjust the gold color separately. Once the mask was finished the desaturation and color adjustment could easily be handled in Lab, however, AFAIK there was nothing to prevent it being done in RGB or CMYK either. It also may be beside the point that I went to Lab at all. The move to Lab certainly brought out problems in the file that might not have ever been seen if it had remained in 8 bit RGB.

1) I'm confused by the initial post, which seemed to say that there was an

advantage in 16-bit in this image above and beyond the mask itself. IOW,

assuming that a good-quality mask falls out of the sky into our lap, does it matter

whether what happens next happens in 16-bit or 8-bit? Or was this claim somehow

related to the 8-bit file generated by CaptureOne as opposed to the file that

went 16>8 in Photoshop?

The initial use of the file was as a mask source. I also intended to lay the gold from this image over another file taken, without the gold being lit, in lighten mode to reduce the haze caused by lighting the gold. Since the final image was going to have a white background, the noise in the shadows would have been meaningless in the final image. However, the problems I encountered led me to look at the file itself. At that point it seems not to matter what the original purpose was.

2) What happens next, once we load the mask? Is the next step so small that

the difference between the four masks is inconsequential?

3) Why are we making a mask out of the B at all? Certainly there are some

images that require us to use the B, but in this one, it looks like we'd be

better off starting with the red of RGB.

I don't see any of the RGB channels as doing a good job of selecting the gold. I suppose a command that looks at the composite channels like Color Range might have worked OK, am I missing something? I suspect that there is something clever I could have done with the Blend-If sliders or Apply Image or Calculations...

4) In every use that I can think of for this mask, we should be blurring it

before loading it. If we do this, there won't be any difference between the

16-bit mask and the 16>8>16 one. There may not even be a difference between the

16-bit all the way and 8-bit all the way versions. Is there some reason that

we're avoiding the normal step of blurring the mask?

It may be bad/sloppy technique, or maybe I did the right thing in this case? In the past when I've needed a sharp mask I've been successful by first creating the mask and then blurring it just the amount needed. This might not be good, but I've gotten away with it and was surprised when it didn't work here. I'm sure with a little blurring and painting and some selecting I could have made the 8 bit file work, but by using 16 bit I didn't have to, which is what I find important.

In reviewing some past posts I realize I've learned and then forgotten many things related to this topic. I apologize. I find that when problems come up only on rare occasions it's easy to forget how I dealt with it the last time. This (my limits) is one important reason I prefer to standardize my workflow. However, I deal with too many images to feel comfortable with an all 16 bit workflow. I just don't see any difference too much of the time. The latest 39 mega pixel digital backs give an almost 120 mb 8 bit file. Whether you need that much resolution is a separate question, but when I've used one of these backs the processing is slow even in 8 bits with my lowly G5 Dual processor with lots of Ram. You really need a quad- and that's not even talking about working on images with multiple layers.

Since I no longer care about my mask, the extreme curve to the b channel is just an easy way to see the difference in the channels and also why I happened to see the difference in the first place. In reviewing the RGB image I still think Lab was a much easier place for me to get a selection of the gold metal. I wouldn't (and didn't) try to get a mask from the one curve, but I thought the one curve would give the general idea and also magnify the problems. Again, I'm sure there are better ways that I didn't think of.

First, dealing only with the file output from CaptureOne in 16 bit that's posted on Andrew Webb's site: If I take this file and convert it directly to Lab (no dither) and also make a duplicate of the file, downsample to 8 bit and then upsample back to 16 bit then convert to Lab they are not identical. I see differences in the smooth dark background areas of the image that are greater than I had expected and that, to my eyes, look like they might be significant enough to result in an output result that most would consider better. These values average about L=8 and might not be visible on a monitor in a bright room setting. I'm not sure about SWOP type conditions, but this would definitely be visibly lighter than black (and hence not all fall to D-max) on my Canon i9900, for example. I'm looking at the image with an Artisan monitor calibrated to a 400:1 contrast ratio. Also surprising, to me, is that the difference is most noticeable in the composite view. Until I apply a curve I really can't see the difference in the a or b channels. After applying a steep curve to the a and b channels the differences there are much more visible.

Because I know it will be asked, I printed a very small piece of the 2 files placed side by side (converting to 8 bit AdobeRGB for printing). I printed at 100 dpi to exaggerate any differences. The background of the "16 bit all the way file" appears a very little bit smoother, which in this case I find more pleasing. Other's might not agree, and the image is available to anyone who wants to try this.

Also, if this were a "real" image and the blotchiness bothered me I would apply a little noise and move on, never aware that I could have eliminated it at the beginning, and not necessarily ending up with a better or worse photograph either (I said this image wasn't meant to prove "the" 16 bit advantage! <g>).

Finally, I looked at the Raw image again to see if I could significantly improve the original output. Outputting with less noise reduction cuts down on blotchiness, but increases noise. I wouldn't make any change in that setting. The amount of sharpening applied to this image (Normal, Amount 20, Threshhold 3) was less than the default (Normal, 25, 3), but more than my usual (Soft, 10, 3) which just makes the capture look reasonably sharp, but requires more sharpening later. My conclusion is that changing the Raw output settings (at least with this version of this software) would not change these results. The Raw file is posted if others want to try other settings and see for themselves.

My personal conclusion (with a bunch of unanswered questions): Going from 8 bit to 16 bit before a trip to Lab can make a big difference. Starting and staying in 16 bit may offer enough difference in some circumstances to make it worthwhile.

I can't say for sure that some changes in how I work with files wouldn't mitigate these differences. I'm still willing to learn more.

As I said in my initial post, this isn't an image I'd ever present as one of my best or even as interesting. However, I hope others find this discussion, at least, of some interest.

Ric Cohn

___________________________________________________________________________

Posted by: "Lee Clawson"

Thu Oct 19, 2006 9:25 am (PST)

Re: A case of clear 16 bit superiority -- Follow Up

on 10/18/06 10:17 PM, Ric Cohn wrote:

Ric,

Thanks for the follow-up. Yes, there's a few of us out here who are

interested in what you're seeing.

Thanks,

Lee Clawson

2/\V/\7 Studio

___________________________________________________________________________

Posted by: "Richard Wagner"

Thu Oct 19, 2006 9:27 am (PST)

Re: A case of clear 16 bit superiority -- Follow Up

Ric,

Thanks for taking the time to pursue the analysis of this image and the problems that it created. I think there is still a lot of important information in this "lesson" that has not been adequately mined. It's still on my back burner - not forgotten, but it is not possible for me to devote adequate time to it at the present. I do have a couple of comments on your response.

On Oct 18, 2006, at 7:17 PM, Ric Cohn wrote:

First, dealing only with the file output from CaptureOne in 16 bit

that's posted on Andrew Webb's site: If I take this file and convert

it directly to Lab (no dither) and also make a duplicate of the file,

downsample to 8 bit and then upsample back to 16 bit then convert to

Lab they are not identical. I see differences in the smooth dark

background areas of the image that are greater than I had expected

and that, to my eyes, look like they might be significant enough to

result in an output result that most would consider better.

This is conclusive evidence that the "data" in the upper byte of the 16-bit capture is significant, and that you can see the effect of having a "high-bit" capture compared with an 8-bit capture. This added tonal resolution becomes more important, and more visible, during manipulations of the image. The 8-bit image data are "rounded off," and if this is done before manipulating the file, the round-off errors will be multiplied.

This effect is different from (but will be additive with) the "quantization error" involved in converting an image to 8-bit Lab. Converting an 8-bit image to Lab will give a different image than converting *either* 16-bit file directly to (16-bit) Lab, as the quantization error with the 8-bit conversion is significant. Obviously, using the original "high-bit" image and converting directly to 16-bit lab is the best that can be done to reduce data loss. The question is then, as you correctly point out, whether or not it is worth the overhead. Higher precision, or faster speed? Depends on what the goals/requirements are.

Because I know it will be asked, I printed a very small piece of the

2 files placed side by side (converting to 8 bit AdobeRGB for

printing). I printed at 100 dpi to exaggerate any differences. The

background of the "16 bit all the way file" appears a very little bit

smoother, which in this case I find more pleasing. Other's might not

agree, and the image is available to anyone who wants to try this.

Out of curiosity, why do you convert from Colormatch to AdobeRGB prior to printing? Why not print directly from ColorMatch to your output profile?

Thanks again for the excellent example and the significant time that you have contributed to this lesson.

Best,

--Rich Wagner

___________________________________________________________________________

Posted by: Dan Margulis

Thu Oct 19, 2006 9:57 am (PST)

Re: A case of clear 16 bit superiority -- Follow Up

Ric writes,

As promised I have taken another look at the image in question and

will re-evaluate what I see and try to answer some lingering

questions. I want to make clear that I'm not looking to prove or

disprove any point of view.

I certainly will look at this, but am on the road for the next ten days, so I will not have a response until probably a week from Monday.

P.S. to Ric. You had indicated that you found that the 8-bit file your module had provided was inferior to exporting in 16-bit and then converting to 8-bit in Photoshop. Can you indicate what the problems were when the 8-bit was exported directly?

Dan Margulis

___________________________________________________________________________

Posted by: "Dan Margulis"

Sat Oct 21, 2006 9:27 am (PST)

Re: A case of clear 16 bit superiority -- Follow Up

From the road:

I'm looking over a couple of posts offering images to look at, and both seem to have more or less the same issue, so before doing anything with them I'd ask for further materials. (Reminder, I'm a couple of weeks away from doing this).

Ric Cohn writes,

I don't see any of the RGB channels as doing a good job of selecting

the gold. I suppose a command that looks at the composite channels

like Color Range might have worked OK, am I missing something? I

suspect that there is something clever I could have done with the

Blend-If sliders or Apply Image or Calculations...

I suspect it too, but I'm still not totally clear on what you were trying to do. I would ask for a step-by-step, with all the commands you used, so that we can make some kind of valid comparisons. The problem is that if I assume that you were trying to accomplish A, I can make a great demonstration of how to do it with Blend If, but if it turns out that your commands were only slightly different it might not work. So, if you could just do a summary sheet of what commands were used and in what order, and attach the settings, we could make some comparison images and see what's up.

Dan Margulis

___________________________________________________________________________

Re: A case of clear 16 bit superiority - Follow up.

Posted by: "Ric Cohn"

Tue Oct 24, 2006 3:27 pm (PST)

On Oct 19, 2006, at 12:19 PM, dmargulisnj wrote:

You had indicated that you found that the 8-bit file your module

had provided was inferior to exporting in 16-bit and then

converting to 8-bit in Photoshop. Can you indicate what the

problems were when the 8-bit was exported directly?

OK, for what it's worth, here's what I see: I took the 16 bit file exported fie, downsampled to 8 bit, and layered it onto the 8 Bit exported file. The differences are obvious in the darkest smooth shadows. These take on an unpleasant mottled look. I don't know that I'd see a difference that I consider significant if an image didn't have smooth dark tones. Others are welcome to do more tests.

I know in the past Dan has mentioned that differences could be cause by things as simple as the dither that Photoshop uses. I tried converting back and forth from 16 bit with dither turned on in my preferences, but I didn't see any improvement in the mottling of the 8 bit generated file.

The RGB channels are all noisier in the 8 bit processed file with the most noise difference in the Red, then the Green and least in the Blue. The 8 bit processed file appears to have both more distinct noise and larger and more areas of noise. The differences are more obvious if I apply a lightening curve to the shadows, however my measurements below are from the original files.

I made eyedropper measurements of several areas of the shadow. Here are the numbers, others can say if they're significantly different to them, or not. 5 x 5 eyedropper. First numbers 8 bit processed file/ Second numbers 16 bit file downsampled to 8 bit.

1. 18, 19, 18 / 19, 19, 18

2. 16, 17, 18 / 18, 18, 19

3. 17, 17, 18 / 18, 18, 19

Lighter area have less or no differences. For example here's a lighter gold color

4. 225, 206, 162 / 225, 206, 162

Unfortunately, since I can't process this PhaseOne file in ACR there is no way for me to verify that ACR doesn't do this too, but I hope it's not.

As a side note, I sent a bug report with a file to the CaptureOne developers. I haven't heard back from them, but I have been involved in Beta Testing with them and they are developing a new version. It's possible that this will eventually be fixed. I believe Dan mentioned having a simple test suggestion in his new book. With the constant changes in software this seems like an excellent idea.

Whether any of this is significant depends. In this one case the 8 bit file output by CaptureOne was a problem for me. I hope this difference gets fixed in a later software upgrade because for now I am processing all of my images as 16 bit and then running an action in Photoshop to down sample them, just in case it makes a difference which will matter once additional image editing is done. Not my idea of where I want to put my imaging efforts.

Ric Cohn

___________________________________________________________________________

Re: A case of clear 16 bit superiority - Follow up.

Posted by: "Ric Cohn"

Tue Oct 24, 2006 3:40 pm (PST)

On Oct 21, 2006, at 11:33 AM, Dan Margulis wrote:

I suspect it too, but I'm still not totally clear on what you were

trying to do. I would ask for a step-by-step, with all the commands

you used, so that we can make some kind of valid comparisons. The problem

is that if I assume that you were trying to accomplish A, I can make a

great demonstration of how to do it with Blend If, but if it turns out

that your commands were only slightly different it might not work. So,

if you could just do a summary sheet of what commands were used and in

what order, and attach the settings, we could make some comparison

images and see what's up.

Here's my step-by-step. It takes longer to explain than to shoot and adjust <g?>. I'm not going to give exact adjustment settings. After all the times I've looked at this image for these reports I can't say for sure what my original settings were. I believe the general details will be enough for someone else to see if they would do it differently. I'm sure it's more detail about a boring photograph than anyone would want. The end result was to be 2 separate files of glasses with metal rims (gold and platinum) on a white background with a drop shadow. The final image is included on the download site so people can see what the heck I'm talking about.

Several lights were used to light the glasses, some of which lit mainly the front of the glasses and others the background and surface. I knew this client doesn't like color in the crystal and wanted the gold and platinum to be particular colors. Since I was going to remove color from the crystal anyway I didn't bother to balance the different lights to give perfectly neutral color. I knew I would need a mask for the gold rims and gold reflections in the glass so I could control this color separately and produce a gold and a platinum version from the same shot (rather than setting up a second shot where the only difference was the rim color) without color in the crystal. Also, lighting up the metallic rims invariably puts more haze in the crystal than desired so I wanted to be able to layer the different elements later.

The exposure for the rim lights seemed like the best choice for pulling a mask. I knew the gold rims would be well separated in the b channel so I took this image (processed as 8 bit from CaptureOne) converted it to lab and copied the b channel. I then applied curved and did some Apply Image in overlay mode in attempt to create a mask with the gold bands and reflections white to gray and the rest of the channel black.

Once I reached this point it became clear that the adjustments I had made, combined with the noise in the channel, was making it much more difficult than I had expected to get a mask. I was looking at a lot of hand work and decided to look for another way to get my mask. As there had been a lot of discussion on the list of 16 bit and 8 bit differences I decided to look at a 16 bit image. I went back and output a 16 bit image with identical settings. This file was much better which led me to say I saw "a case of clear 16 bit superiority". As Dan rightly pointed out, because PhaseOne does a poor job of outputting 8 bit files, the differences become much much smaller if you make the 8 bit file in Photoshop. In any case, doing the same adjustments to the 16 bit file easily gave me the mask I was looking for.

Now the questions are:

1. Was the benefit of the 16 bit file only due to the poor 8 bit quality of CaptureOne? In other words is a good 8 bit file upsampled to 16 bit just as good for this purpose as an original 16 file? I believe that the 16 bit original is still smoother than the same file downsampled to 8 bit and then upsampled back to 16 bit. Someone else would have to verify if this difference is enough to lead to better results.

2. Is there a better method for getting the mask in the first place?

3. Would this better method eliminate the advantage of the 16 bit file?

4. Did the trip to Lab accentuate the problems?

5. In that no one is questioning the benefit of working on masks in 16 bit, is there any reason to extrapolate this into working on a 3 channel file?

The only question I can weigh in on is #1. I did yet one more comparison. I took my 16 bit file and layered it with a file made by downsampling and then upsampling a copy of this file to get 2 16 bit files. I then applied huge curves to all 3 channels. I can see very little difference between the L's, more difference between the a's, and a lot of difference between the b's. I do believe an original 16 bit processed file would be better for what I am doing here, which is copying the b channel and applying massive contrast increasing steps.

Other's are encouraged to try it themselves and come to their own conclusions. The original 16 bit file and the Raw file are both available on the download site. I don't think the exact settings of my Curves Adjustment layer are necessary, but if desired perhaps Andrew Webb would allow me to post more files on his site. I must admit I'm a little disappointed that no one has downloaded files and voiced their own opinions on this.

Ric Cohn

___________________________________________________________________________

Re: A case of clear 16 bit superiority - Follow up.

Posted by: Dan Margulis

Tue Oct 24, 2006 10:09 pm (PST)

Ric writes,

I made eyedropper measurements of several areas of the shadow. Here

are the numbers, others can say if they're significantly different to

them, or not. 5 x 5 eyedropper. First numbers 8 bit processed file/

Second numbers 16 bit file downsampled to 8 bit.

1. 18, 19, 18 / 19, 19, 18

2. 16, 17, 18 / 18, 18, 19

3. 17, 17, 18 / 18, 18, 19

Lighter area have less or no differences. For example here's a

lighter gold color

4. 225, 206, 162 / 225, 206, 162

OK, then it is almost certainly creating its 8-bit file by throwing away the final 8 bits of the 16-bit file, as opposed to the correct way of looking at them and rounding to the nearest 8-bit value. IOW, if it finds a value of 18.99, it rounds it to 18, whereas a sensible program would round it to 19. In effect, it's giving you a 7-bit file, not an 8-bit.

Unfortunately, since I can't process this PhaseOne file in ACR there

is no way for me to verify that ACR doesn't do this too, but I hope

it's not.

It doesn't, I've tested.

As a side note, I sent a bug report with a file to the CaptureOne

developers. I haven't heard back from them, but I have been involved

in Beta Testing with them and they are developing a new version. It's

possible that this will eventually be fixed. I believe Dan mentioned

having a simple test suggestion in his new book. With the constant

changes in software this seems like an excellent idea.

Here is the test.

Dan Margulis

The procedure to determine whether your raw capture module is converting 16-bit to 8-bit files correctly is as follows:

* Export the file from your module in both 8-bit and 16-bit. Convert the 16-bit to 8-bit in Photoshop.

* In this newly converted file, make a duplicate layer. Then make a duplicate copy of the two-layered file.

* Using the Apply Image command, apply the raw module's 8-bit version to the top layer of one file, at 100% opacity, Lighten mode. Do the same to the other file, but use Darken mode instead of Lighten.

* Change the mode of the top layer of each file to Difference. Both files will now appear solid black.

* Flatten both files, and apply Image: Adjustments>Auto Levels. This will bring out what appears to be noise, representing the difference between what used to be the two layers before they were flattened.

* Compare the two results. If each shows approximately the same amount of noise, you have no problem. If, however, one file has far more noise than the other, it probably means that your module is discarding the final eight bits when it converts from 16-bit to 8-bit, an inferior method. In that case, you should always export from the module in 16-bit, and convert to 8-bit in Photoshop when ready.

___________________________________________________________________________

Re: A case of clear 16 bit superiority - Follow up.

Posted by: "Ric Cohn"

Wed Oct 25, 2006 9:42 am (PST)

On Oct 24, 2006, at 7:53 PM, Dan Margulis wrote:

* Compare the two results. If each shows approximately the same amount

of noise, you have no problem. If, however, one file has far more noise

than the other, it probably means that your module is discarding the

final eight bits when it converts from 16-bit to 8-bit, an inferior

method.

Wow, a huge difference between the 2 files! The Darken file has much more noise than the Lighten file. The lighten file had a very faint reversed image.

Out of curiosity, I repeated the test, laying the downsampled 16 bit file onto itself. Both resulting files looked identical and very similar to the Lighten version of the "bad" file. This seems to make sense, as my tests indicated that all, or virtually all, of the difference was in the darkest bits.

Can you explain briefly how this test works? Would you always expect the Darken file to be the one to show more noise? Also, why didn't my second test (laying the file onto itself) result in a totally black file?

I did find the step-by-step instructions a little hard to follow. I've rewritten them and numbered the steps in a way I find easier. Other's can comment on whether this is better, worse or no different for them.

The procedure to determine whether your raw capture module is

converting 16-bit to 8-bit files correctly is as follows:

1. Export the file from your module in both 8-bit and 16-bit.

2. Convert the 16-bit file to 8-bit in Photoshop.

3. In this newly converted file, make a duplicate layer.

4. Then make a duplicate copy of this two-layered file.

5 Using the Apply Image command, apply the raw module's 8-bit version

to the top layer of one file, at 100% opacity, Lighten mode.

6. Do the same to the other file, but use Darken mode instead of Lighten.

7 Change the mode of the top layer of each file to Difference. Both

files will now appear solid black.

8 Flatten both files, and apply Image: Adjustments>Auto Levels. This

will bring out what appears to be noise, representing the difference

between what used to be the two layers before they were flattened.

9. Compare the two results. If each shows approximately the same amount

of noise, you have no problem. If, however, one file has far more noise

than the other, it probably means that your module is discarding the

final eight bits when it converts from 16-bit to 8-bit, an inferior

method. In that case, you should always export from the module in

16-bit, and convert to 8-bit in Photoshop when ready.

Ric Cohn

___________________________________________________________________________

Re: A case of clear 16 bit superiority - Follow up.

Posted by: "Ric Cohn"

Wed Oct 25, 2006 1:42 pm (PST)

On Oct 25, 2006, at 12:01 PM, Ric Cohn wrote:

Also, why didn't my second test (laying the file onto itself)

result in a totally black file?

Oops, I said I found the steps as originally written difficult to follow. I made a mistake (happily, not one that affects my results). I just realized that on the Lighten version of the first file and on both files of my second test using identical layers I didn't flatten before using Levels. When I did this the files for the identical 8 bit files were totally black. On the first test where I didn't flatten the lighten layer before hand, when I went back and did this the Lighten file was even darker- making the noisy Darken file look even worse.Sorry.

Ric Cohn

___________________________________________________________________________

Re: A case of clear 16 bit superiority - Follow up.

Posted by: "Ric Cohn"

Thu Oct 26, 2006 4:09 pm (PST)

On Oct 19, 2006, at 5:24 AM, Richard Wagner wrote:

Out of curiosity, why do you convert from Colormatch to AdobeRGB

prior to printing? Why not print directly from ColorMatch to your

output profile?

I actually converted out of Lab to AdobeRGB. If the file had stayed in ColorMatch I'd have stayed there. I converted to AdobeRGB because that's my normal working space and my printer profiles are created using AdobeRGB as the output space. For maximum consistency I have been told it's safer to print from AdobeRGB files. I've never actually seen a problem with any RGB or even with files in Lab or (tagged) CMYK. Photoshop and the print driver seem to handle it OK. I frequently use ColorMatch for RGB sent to clients who I think might not handle the post well-- harder for them to make adjustments that will look good on screen but will never print well. I'm finding this less necessary as retouchers (and to a lesser extent printers) becomes more RGB savvy.

Ric Cohn

___________________________________________________________________________

Re: A case of clear 16 bit superiority - Follow up.

Posted by: "Andrew Rodney"

Thu Oct 26, 2006 7:07 pm (PST)

On 10/26/06 1:13 PM, "Ric Cohn" wrote:

I converted to AdobeRGB because

that's my normal working space and my printer profiles are created

using AdobeRGB as the output space. For maximum consistency I have

been told it's safer to print from AdobeRGB files. I've never

actually seen a problem with any RGB or even with files in Lab or (tagged)

I doubt the profile was built for Adobe RGB (1998). By the time it's getting the data, it's in LAB through the PCS.

Andrew Rodney

___________________________________________________________________________

Re: A case of clear 16 bit superiority - Follow up.

Posted by: Dan Margulis

Thu Oct 26, 2006 7:13 pm (PST)

Ric writes,

Can you explain briefly how this test works?

Photoshop's conversion from 16-bit to 8-bit is known to be accurate enough, I have tested it thoroughly.

If you convert 16-bit to 8-bit in some other program, the results should be very similar. They shouldn't be pixel-for-pixel identical, because Photoshop uses its own dither that the other program won't match exactly.

The test checks how many of the foreign program's pixels wind up darker than Photoshop's vs. how many are lighter. There's no excuse for a gross disparity in the two figures, like the one you're seeing.

Would you always expect the Darken file to be the one to show more noise?

Probably, but some other program might round to the next higher number rather than the next lower number, assuming that it is too stupid to know that it should simply round to the *nearest* number.

Dan Margulis

___________________________________________________________________________

Re: Moderator notice: stay on topic

Posted by: "Richard Wagner"

Fri Oct 27, 2006 2:04 pm (PST)

I almost forgot - I3A 7466 also defines an extended dynamic range version of ROMM encoding known as ERIMM RGB. This color encoding has a logarithmic nonlinearity function and a large enough dynamic range to handle the full range of information captured on color negative film, but it requires a minimum bit-depth of 12 bits. (ROMM is defined for 8, 12, and 16-bit encoding.) The times, they are a changin'!

Besides RIMM-ROMM-EROMM, there is also e-sRGB, which is generally similar to sRGB except that it allows for extended encoding of RGB values that range from -0.53 to 1.68. This allows for the encoding of a larger or extended color gamut compared to sRGB. e-sRGB requires 10 bits per component as a minimum encoding bit depth. While both sRGB and e-sRGB are output-referred, sRGB was designed for display-based imaging systems, while e-sRGB was designed for high quality printing.

All of the great new inkjet printers coming out are handicapped without wide-gamut input, so that's where the imaging industry is putting its resources.

--Rich Wagner

___________________________________________________________________________

Re: A case of clear 16 bit superiority - Follow up.

Posted by: "Richard Wagner"

Fri Oct 27, 2006 6:16 am (PST)

On Oct 26, 2006, at 12:13 PM, Ric Cohn wrote:

I actually converted out of Lab to AdobeRGB. If the file had stayed

in ColorMatch I'd have stayed there.

Ah, fine...

I converted to AdobeRGB because

that's my normal working space

ok.

and my printer profiles are created

using AdobeRGB as the output space.

??? The printer profiles are device profiles - they *are* the RGB output space, and the profile connection space (PCS) is usually Lab. They don't have, can't have AdobeRGB in them. So when you print a ColorMatch file, the image goes ColorMatch-->Lab, Lab-->PrinterRGB by way of the ColorMatch profile and the printer profile that you select. When you build a profile, the target is printed without a profile (to get the colors printed at the "unadulterated" values - e.g., 255, 255, 255) and the measured values (e.g. Lab) from the target are then used to find the "correction factors" for the raw numbers to give the desired patch colors. There's no place for any other RGB profile in the process.

For maximum consistency I have

been told it's safer to print from AdobeRGB files.

Not true. When printing from AdobeRGB, the only role for the AdobeRGB profile is to make the conversion to Lab. The printer profile will then convert from Lab to its "own" RGB. The other half of the printer profile (printerRGB to Lab) is only used for soft proofing. It's also possible to make a "device link" profile that bypasses the PCS.

I've never

actually seen a problem with any RGB or even with files in Lab or

(tagged) CMYK. Photoshop and the print driver seem to handle it OK.

As well they should - or they wouldn't be ICC-compliant. The quality of the printer profiles does make a big difference - as I'm sure you're aware.

I frequently use ColorMatch for RGB sent to clients who I think might

not handle the post well-- harder for them to make adjustments that

will look good on screen but will never print well.

Sneaky devil!!!

I'm finding this

less necessary as retouchers (and to a lesser extent printers)

becomes more RGB savvy.

That's good to hear.

Best,

--Rich

___________________________________________________________________________

Re: A case of clear 16 bit superiority - Follow up.

Posted by: "Rick Gordon"

Fri Oct 27, 2006 6:18 am (PST)

One issue that I've noticed additionally is that Photoshop appears to use the Use Dither value that is set up in the current Color Settings preferences when converting from 16-bit to 8-bit. Whether Use Dither is enabled or not will make a difference in the result, which is particularly apparent in an area of flat color whose value requires rounding upon conversion to 8-bit.

Rick Gordon

___________________________________________________________________________

Re: A case of clear 16 bit superiority - Follow up.

Posted by: "Jim Rich"

Fri Oct 27, 2006 11:40 am (PST)

Ric,

I have been loosely following this thread, so I might have missed something, but when you say "The differences are obvious in the darkest smooth shadows." I am not sure what that means yet.

Does that mean when you printed it out on say an epson printer or on a printing press that you can distinctly see the differences?

Or are you working in Photoshop at 100% or are you zoomed in close?

Just curious.

Thanks

Jim Rich

Rich & Associates

G7 Certified Expert

___________________________________________________________________________

Re: A case of clear 16 bit superiority - Follow up.

Posted by: "murraydejager"

Fri Oct 27, 2006 1:59 pm (PST)

Hello Everyone,

Rich, I used your cropped Tiffs to do the test as you suggested. What I found is correct, the ProPhoto file is better!

But why does this effect only seem to happen with Photoshop's Hue/Saturation command? If I do any other adjustments (even radical curves) to any of the files, in any of the three color spaces the same effect doesn't show up. Is this defect limited to this Photoshop command only?

Also, I converted all the files to 8 bits in Photoshop and did the same test. I couldn't tell the difference between any of the 16 bit or 8 bit photos. The same defect to the non-ProPhoto photos existed to the same degree. I don't know why but I was expecting the effect to be worse when doing the saturation adjustment to an sRGB 8 bit file.

Any thoughts would be appreciated,

Murray DeJager

___________________________________________________________________________

Re: A case of clear 16 bit superiority - Follow up.

Posted by: "Ric Cohn"

Fri Oct 27, 2006 1:59 pm (PST)

Jim-

I'd welcome your expert eyes on the original files! Remember that this part of my test refers to the difference in CaptureOne's 16 bit and 8 bit output. This is not an 8 bit vs 16 bit superiority claim. The test that Dan posted makes the difference even more clear. I see no reason to doubt Dan's guess that the program is throwing out the last bit in rounding, giving essentially 7 bits. In any case: By "darkest smooth shadows" I'm referring to an almost flat dark background most of which is in the L= 10-25 range.

As I said in one post, I did print it out (with no adjustments added) knowing I'd be asked <g> and I so see a slight difference in smoothness in a print from my i9900. However, the difference is so much more visible on screen after applying adjustments that I didn't bother to do any more prints. What started my testing was the unsuitability of the 8 bit file for my purposes after applying corrections.

At this point, I'm more interested in the subtle differences between the 16 bit file and a file down sampled properly to 8 bit in Photoshop. The difference is there. Could it be significant under the right (wrong) conditions? Could the differences be compensated for completely, and in an easy way, if you only had the 8 bit file?

Ric Cohn

___________________________________________________________________________

Re: A case of clear 16 bit superiority - Follow up.

Posted by: Stephen Marsh

Fri Oct 27, 2006 11:08 pm (PST)

Murray, there is a 'secret' option to be used with the Hue/Sat command that not all users are familiar with - which has a profound effect on the effect and thus the useability of the command. Fading to color blend mode or using the command in an adjustment layer set to color (or saturation) blend mode.

Another alternative are AB channel moves to increase saturation.

I have not had time yet to test these files, so I would be interested in your findings if you were simply using hue/saturation in normal blend mode.

Best,

Stephen Marsh.

___________________________________________________________________________

Re: A case of clear 16 bit superiority - Follow up.

Posted by: Dan Margulis

Sun Oct 29, 2006 10:40 am (PST)

Ric writes,

Other's are encouraged to try it themselves and come to their own

conclusions. The original 16 bit file and the Raw file are both

available on the download site. I don't think the exact settings of

my Curves Adjustment layer are necessary, but if desired perhaps

Andrew Webb would allow me to post more files on his site. I must

admit I'm a little disappointed that no one has downloaded files and

voiced their own opinions on this.

I suspect that they have tried but, like me, are unable to make head or tail of what you are trying to achieve. I have read and re-read everything you have sent me offline; I have downloaded all files and re-read your instructions, and nothing makes sense. I have repeatedly asked for a step-by-step, and you have responded with a narrative that does not correspond to anything in either the original or the final image that has been shown. I have now invested well over two hours in the exercise and still have no idea what procedure is being suggested.

Specific problems:

*The instructions state that the client wants to desaturate the glasses, but the glasses in the original are already essentially totally desaturated.

*The instructions call for construction of a drop shadow, but there is no method indicated of achieving it, and no indication of a shadow in the final document.

*The instructions call for creation of a "platinum version", but there is no indication of what that is, or any final document suggesting what it might be.

*The instructions state that there is one curve applied to the document. The original picture has a dark background and the glasses are lighter. In the final document, the glasses are grossly lighter than in the original. There is no mention of this in the instructions.

*In the final picture the background has vanished completely. It is impossible IMHO to do this with curves. There is therefore at least one step missing from the explanation.

You have contributed a great deal of your own time to producing other examples, such as the lengthy series that was published in PP4E. Everybody has to appreciate the effort you have put into these things. This present example, however, can't go any further without a real step-by-step that makes it clear what is being done to the image and why.

I therefore have to give up on this image and summarize what we found as follows:

*The B channel is always the least reliable of the ten channels we might use. It is not as accurate even as the blue of RGB, which is itself very inaccurate.

*It is standard practice to apply blurs to the mask of the type you are using. This goes triple for something as choppy as a contrast-enhanced version of the B.

*Because enhanced versions of the B are so poor, I have for many years suggested converting to 16-bit prior to making them, as a means of blurring by the addition of soft noise.

*We have known for several years that certain capture modules, yours being one, do not produce accurate 8-bit files. In these cases, I advise acquiring the file in 16-bit and converting to 8-bit at a later time in Photoshop.

The following are surmises only because I do not have enough information to test the image.

*Using the B for a mask in this image is likely not as effective as using Blend If or a copy of the red or Maximum-GCR black channels.

*Without seeing what the mask is to be used for, it's impossible to see how much blurring is necessary. I would be surprised if the mask generated in 16-bit all the way was any more effective than the one made by 8-bit to 16-bit. However, it's academic: since you already are opening the file in 16-bit, and you know you want it for the mask, it would be stupid to convert to 8-bit only to convert it back.

*It's also academic whether an 8-bit all the way mask is less effective than a 8-to-16-bit mask would be in this particular image. We know of others where it definitely is, so why take the time to investigate whether this is another? It's two extra steps in the process to convert the 8-bit RGB file to 16-bit and then back again when finished.

*Given a good 16-bit mask, I seriously doubt that there would be a quality difference in applying it to a 16-bit file or dropping it to 8-bit and applying it to an 8-bit file.

Dan Margulis

___________________________________________________________________________

Re: A case of clear 16 bit superiority - Follow up.

Posted by: Ric Cohn

Sun Oct 29, 2006 6:09 pm (PST)

On Oct 29, 2006, at 10:15 AM, Dan Margulis wrote:

I suspect that they have tried but, like me, are unable to make

head or tail of what you are trying to achieve.

I sincerely apologize for any lack of clarity! I think confusion was added by my not explaining some things that I didn't think were important for the test and by my adding details that were not germane to exactly what I was looking at. However, your conclusions at the end of your post are probably enough, and I'm not sure that any more benefit is to be gained by your going further.

You helped me determine very early on that there was a problem with the CaptureOne generated 8 bit file. The test you posted is quite brilliant and is much easier than waiting for the one image where it is easy to see a difference (like this one) to discover this. Frankly, the fact that CaptureOne is both expensive and extensively tested lead me not to question it's output. A mistake I'll try not to repeat.

That means the main question remaining is whether there is any advantage to keeping the 16 bit output for a) masks and/or b) (shudder!) general adjustments. At this point my answer to a) is "probably under some conditions" and to b) is probably not, but not conclusively "no". Those are the 2 questions I'm most interested in answers to. Peripherally, I'm also interested on whether there are better ways for me to get a mask of the gold.

I believe you previously agreed that if you take this 16 bit file and downsample it and then upsample it back to 16 bit, the original 16 bit file is smoother. When I convert these files to Lab and apply the large curve to the b there is a difference that I think is significant, but am interested in your, and other's, views. I have said before that I prefer to avoid an all 16 bit workflow, as I do not believe the penalties are worth the gains. However, I do think the question of whether there are times I should stay in 16 bit and/ or switch to (by upsampling) 16 bit is both important and not clearly understood at this time. For now, I think there are benefits to always going to 16 bit when converting to Lab if a mask might need to be made.

I have repeatedly asked for a step-by-step, and you have responded

with a narrative that does not correspond to anything in either the

original or the final image that has been shown.

Again, I apologize. I mistakingly didn't think a step-by-step was necessary since the original file was supplied. At this point I agree there's no reason for you to go back and work with this file and I still think that other's, if they want to look at the files, would be as well served by doing their own adjustments to the files and coming to their own conclusions.

Specific problems:

*The instructions state that the client wants to desaturate the

glasses, but

the glasses in the original are already essentially totally

desaturated.

1. Yes, the crystal is almost, but not completely, without color. My lights, by chance, might have been totally identical in color balance. Frankly, I didn't check before starting my corrections because usually lighting fine crystal will lead to some spectral colors, which I consider good but this particular client does not. In any case, this just explains why I thought it necessary to get a good mask for the gold. Whether I was correct or not is, I think, beside the point for this test (although perhaps not unimportant in deciding whether I should have started differently in taking the picture in the first place <g>).

*The instructions call for construction of a drop shadow, but there is no

method indicated of achieving it, and no indication of a shadow in the final

document.

2. I think this is more needless detail that I added. The "final" glasses, as uploaded, do actually have a holding shadow added, but not the final shadow which was a little more apparent. In any case, the glasses, as shot, needed to be silhouetted and a drop shadow created, which is not something affected by anything I was looking at.

*The instructions call for creation of a "platinum version", but there is no

indication of what that is, or any final document suggesting what

it might be.

3. I mention the "platinum version" only to explain why I thought I needed to be able to desaturate the metal and the crystal separately. The actual appearance of the platinum metal bands is a slightly warmer neutral than say sterling silver. I needed to partially, but not completely, desaturate the gold in order to match this color. Again, I don't think whether I was right or not in thinking I needed a mask is germane to what was the best way to get the mask once I decided I needed it.

*The instructions state that there is one curve applied to the document. The

original picture has a dark background and the glasses are lighter. In the

final document, the glasses are grossly lighter than in the original. There is no

mention of this in the instructions.

4. I thought I was clear and obviously I was not. I mentioned that the lights used for the photography (there were at least 8 different lights) were captured both together and separately for the "foreground" and "background" (i.e. 3 separate captures: All lights, Front lights alone, Back lights alone). This has become such common practice with digital still-life, that I didn't realize how confusing this could be to read about! Sometimes I'll decide later that multiple captures aren't needed, but if in doubt I take the pieces. The one curve was applied to a copy of the b channel of the file I supplied.

You are right, I only showed the exposure for the front lights (that were lighting the gold rims) which is the capture I chose to use to get my mask. I looked back at the original files, and when I convert the capture that had all the lights I see this would probably have worked just as well, but not better. I think this is what you found most confusing. I suspect you were looking for a "one capture" solution for both the image and the mask (preferably with some adjustment like Blend If that wouldn't require a physical mask), and I left out my reason for not using only one capture for the shot: Lighting the metal put's a lot of haze and extra reflections into the crystal. I planned on minimizing these by using the different captures, layered with blending modes. Perhaps this could have been gotten around with some of the clever adjustments you are so good at, but I didn't supply you with the "all lights" file to try it on. Stupid in retrospect. I was so focused on finding a simple solution to what I saw as the problem it didn't even occur to me that other's wouldn't see it the same way.

However, your conclusions at the end of your post are probably enough, and I'm not sure that any more benefit is to be gained by going further.

*In the final picture the background has vanished completely. It is

impossible IMHO to do this with curves. There is therefore at least

one step missing from the explanation.

You are absolutely correct. The final shot is a composite of the different captures, plus a path to create a white background.

You have contributed a great deal of your own time to producing

other examples, such as the lengthy series that was published in

PP4E. Everybody has to appreciate the effort you have put into

these things. This present example, however, can't go any further

without a real step-by-step that makes it clear what is being done

to the image and why.

Yes, I tried to both share what I saw with the group and look for insights that would help me. In this case, in spite of my putting in a lot of time and effort, perhaps there has been more of the latter than the former.

*The B channel is always the least reliable of the ten channels we might use.

It is not as accurate even as the blue of RGB, which is itself very

inaccurate.

Good to know.

*It is standard practice to apply blurs to the mask of the type you are

using. This goes triple for something as choppy as a contrast-

enhanced version of the B.

Yes. However, as I said in a previous post, I usually find it possible with good files to increase the contrast and then apply the amount of blurring I see is needed.

*Because enhanced versions of the B are so poor, I have for many years

suggested converting to 16-bit prior to making them, as a means of

blurring by the addition of soft noise.

Despite what I consider careful reading, I guess this never sunk in. I'm sure all this has been gathered and made clear in the new book. I look forward to studying it!

*We have known for several years that certain capture modules, yours being

one, do not produce accurate 8-bit files. In these cases, I advise acquiring the

file in 16-bit and converting to 8-bit at a later time in Photoshop.

Your step-by-step test makes it very easy for users to see whether this is true for their modules. If only it were always as easy to objectively test for answers!

The following are surmises only because I do not have enough

information to test the image.

*Using the B for a mask in this image is likely not as effective as using

Blend If or a copy of the red or Maximum-GCR black channels.

Blend if might work. I still think the white highlights in the crystal make it impossible to use the Red or Max-GCR black channels. Here is one area I'd love to see someone else show what they would do.

*Without seeing what the mask is to be used for, it's impossible to see how

much blurring is necessary. I would be surprised if the mask generated i

16-bit all the way was any more effective than the one made by 8-bit to 16-bit.

However, it's academic: since you already are opening the file in

16-bit, and you know you want it for the mask, it would be stupid

to convert to 8-bit only to convert it back.

I took another look, and I do think the 8 bit to 16 bit file would work in this case. However, it's not all "academic" since although, in this case, I have the original 16 bit, I don't always know at the time I process a file if I will need a mask requiring 16 bit. If going 8 bit to 16 bit is always as good, then it's academic. If sometimes you need to start with a 16 bit original this can have major workflow considerations. For example, should I process and archive all originals in 16 bit or can I continue to only keep 8 bit originals? I already archive the original Raw files. In theory, I can always go back and reprocess if I need a 16 bit file, but this is inconvenient when you're trying to get a job finished and out the door-- especially if you have already done work on the 8 bit file!

*It's also academic whether an 8-bit all the way mask is less effective than

a 8-to-16-bit mask would be in this particular image. We know of others where

it definitely is, so why take the time to investigate whether this is another?

It's two extra steps in the process to convert the 8-bit RGB file to 16-bit

and then back again when finished.

This will certainly be what I do from now on.

*Given a good 16-bit mask, I seriously doubt that there would be a quality

difference in applying it to a 16-bit file or dropping it to 8-bit and applying

it to an 8-bit file.

I also suspect this is true. I'll leave it to someone else to look at this file or find another and try to disprove this.

In any case, I think my difficulty in communicating what I did, and why, is a good cautionary tale <g>

Regards,

Ric Cohn

___________________________________________________________________________

Re: A case of clear 16 bit superiority - Follow up.

Posted by: "Ric Cohn"

Mon Oct 30, 2006 12:51 pm (PST)

On Oct 29, 2006, at 10:15 AM, Dan Margulis wrote:

I have repeatedly asked for a step-by-step, and you have responded

with a narrative that does not correspond to anything in either the

original or the final image that has been shown.

It's a lot of work which I don't know adds anything, but after my last email I am more aware of how many vagaries there were in my previous posts. For anyone who wants to try it, here is the step by step of what I did when looking at these files. I hope this is clear enough. I'm assuming a fairly advanced knowledge of Photoshop.

1. Go to http://www.webbwork.com/clients/colortheory and download at least these 3 files: 8BitCaptureOneProcessed_Cropped.psd.zip, 16BitCaptureOneProcessed_Cropped.psd.zip, CurveApplyToLab_b.acv.zip. Optionally download the other files.

2. Turn off Dither in Photoshop: In Photoshop go to Edit>Color Settings and make sure "Use Dither (8-bit/channel images)" is unchecked.

3. Open 8BitCaptureOneProcessed_Cropped.psd. This file was output as 8 bit from CaptureOne. Upsample this image to 16 bit.

4. Open 16BitCaptureOneProcessed_Cropped.psd. This is the identical Raw file output as 16 bit from CaptureOne.

5. Duplicate 16BitCaptureOneProcessed_Cropped.psd and down sample to 8 bit and then upsample back to 16 bit. Save this file as 16BitCaptureOneTo8To16.psd

6. Compare the Composite and Individual Channels for all 3. I find a good way to compare files is: Go to full screen mode on all files, make all files 100%, select the Hand Tool and make sure that "Scroll All Windows" is checked. Then use Command-Tab to bring each image to the front. Use the hand tool to move around the images. It also helps to rename the Background layer with the file name so it's easy to double check which file you are looking at by looking at the name in the Layers Pallet.

If you look at the background behind the glasses you will see that 8BitCaptureOneProcessed_Cropped.psd is very noisy and that there is a very very slight difference between 16BitCaptureOneProcessed_Cropped.psd and 16BitCaptureOneTo8To16.psd.

7. The noise in the file 8BitCaptureOneProcessed_Cropped.psd is an indication that CaptureOne is doing a poor job of outputting this file as 8 bit. For an even more graphic comparison run Dan's test from a previous post.

(It is not impossible that settings within CaptureOne could reduce or even eliminate the difference between the 16 bit and 8 bit files output by CaptureOne. See below for more on this.)

8. Take all 3 files and convert to Lab.

9. For all 3 files make an Alpha channel of the "b". Apply the curve: CurveApplyToLab_b.acv.

10. Compare the 3 Alpha Channels at 100% and 200%. You will see that 8BitCaptureOneProcessed_Cropped.psd is so bad and so posterized that it's usefulness is questionable. Close this file so you can compare just the 2 files derived from the same 16 bit file. You will also see that 16BitCaptureOneProcessed_Cropped.psd is smoother than 16BitCaptureOneTo8To16.psd. 16BitCaptureOneTo8To16.psd has some sharp specks and slight posterization.

I did one more test to see if the Sharpening in CaptureOne contributed to the problem. I output the same set of files with sharpening turned off and repeated the above steps. I see: 1. The 8 bit file still looks worse, but the Alpha channel with the curve applied doesn't look as bad as the sharpened output file's Alpha Channel. 2. The Alpha Channel for the 16 bit file and the 16 bit to 8 bit to 16 bit file have exactly the same difference as before and look virtually the same as the Alpha Channels from the sharpened files.

From the fact that the "pure" 16 bit file is different from a "downsampled then upsampled" 16 bit file, I conclude: 1. There was probably real data in the 16 bits that was lost when downsampled, and/ or 2. Despite turning off dither, Photoshop may still add some noise when converting to and from 16 bit.

AFAIK if Photoshop is doing something on conversion that makes the 2 files different this is undocumented.

Unanswered here is whether the differences seen here makes the 8 bit file less suitable under any conceivable repro conditions.

For even more "fun" download the Raw file: RawFile.TIF.zip (and a copy of CaptureOne DB or CaptureOne Pro if you don't own a copy of CaptureOne Pro). Make your own output settings and repeat the test or create your own.

I hope this is clear enough for everyone (including Dan!). I don't intend to do any more, but I hope others will.

Ric Cohn

___________________________________________________________________________

Re: A case of clear 16 bit superiority - Follow up.

Posted by: "Richard Wagner"

Mon Oct 30, 2006 1:00 pm (PST)

On Oct 29, 2006, at 6:35 PM, Ric Cohn wrote:

I took another look, and I do think the 8 bit to 16 bit file would

work in this case. However, it's not all "academic" since although,

in this case, I have the original 16 bit, I don't always know at the

time I process a file if I will need a mask requiring 16 bit. If

going 8 bit to 16 bit is always as good, then it's academic.

It's not, as you have shown.

If sometimes you need to start with a 16 bit original this can have

major workflow considerations. For example, should I process and

archive all originals in 16 bit or can I continue to only keep 8 bit

originals? I already archive the original Raw files. In theory, I can

always go back and reprocess if I need a 16 bit file, but this is

inconvenient when you're trying to get a job finished and out the

door-- especially if you have already done work on the 8 bit file!

Ric,

I think this is the crux of the whole issue. A 16-bit original always has the potential to be better than an 8-bit file, but never worse. How often it is "better," and by how much, depends on what you shoot, what you do with the file during editing, and how picky you and your clients are. With the cost of disk storage dropping, and processor speeds increasing, many people find it more economical to keep a 16- bit workflow up until the time of delivery to the client rather than going back to re-render or re-scan an original. If you work in a wide-gamut original, the question becomes academic, as the only way to maintain color accuracy is with 16 bits.

Thanks again for all of the work that you contributed to this lesson.

--Rich Wagner

Contact request form

Receive Schedule
and Pricing updates.

If you let us know how to contact you, we will enter you into our monthly drawing for a free 2-day class (A $895 value).

Get free video training
Get free tips, tricks and shortcuts
Get special sale pricing and free seminar invitations

Logo_small

Teach for us

Sterling Ledet & Associates, Inc. 4100 Perimeter Park South Atlanta, GA 30341

work sales@ledet.com work administration@ledet.com work webmaster@ledet.com

P work 770.414.5007 P work 877.819.2665 F fax 312.896.9094

Authorized Training Provider

Receive Schedule and Pricing updates.

Receive Schedule
and Pricing updates.