Untitled Document

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

___________________________________________________________________________

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

___________________________________________________________________________

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

___________________________________________________________________________

Ric Cohn wrote:

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.

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

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.

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.

___________________________________________________________________________

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

___________________________________________________________________________

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

___________________________________________________________________________

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

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

___________________________________________________________________________

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

___________________________________________________________________________

Mark Segal writes,

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

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.

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.

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

___________________________________________________________________________

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

___________________________________________________________________________

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

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.

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.

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

Ric Cohn

___________________________________________________________________________

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

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

___________________________________________________________________________

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

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,

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

___________________________________________________________________________

On Oct 6, 2006, at 8:41 AM, Stephen Marsh 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. 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".

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.

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

Ric Cohn

___________________________________________________________________________

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

___________________________________________________________________________

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

___________________________________________________________________________

Ric writes,

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

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

___________________________________________________________________________

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

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

___________________________________________________________________________

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

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.

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.

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

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?

NOT OBVIOUSLY REVELANT TO THE ISSUE.

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

___________________________________________________________________________

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.

___________________________________________________________________________

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

___________________________________________________________________________

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

___________________________________________________________________________

Dear Richard,

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

___________________________________________________________________________

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

___________________________________________________________________________

--- In , Ric Cohn wrote:

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

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.

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.

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.

___________________________________________________________________________

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

___________________________________________________________________________

Ric Cohn writes,

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

___________________________________________________________________________

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

___________________________________________________________________________

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

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

___________________________________________________________________________

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

___________________________________________________________________________

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

___________________________________________________________________________

Hi,

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

___________________________________________________________________________

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

___________________________________________________________________________

Ron,

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

bob Frost.

___________________________________________________________________________

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

___________________________________________________________________________

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

___________________________________________________________________________

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

___________________________________________________________________________

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

___________________________________________________________________________

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.

___________________________________________________________________________

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

___________________________________________________________________________

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

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

___________________________________________________________________________

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

___________________________________________________________________________

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

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