Are 16 bit scans = 8 bit scans converted to 16 bit in CS2?

The point in question here seems to be primarily concerning the difference between 8 bit edits and 8-bit to 16-bit edits. No one is talking about the difference between native 8-bit vs 16-bit edits (other than Dan Margulis, I suppose). There is no need to concern oneself with "dithering" going from 16-bits to 8-bits, as that is not what Frans et al is talking about. We only need start with an 8 bit file and do two comparative edits - one in 8 bit and one upconverted to 16-bits. Like Frans, I have done this test before and got similar results to his shown above. It is beyond question that converting an 8-bit image to 16-bits first and then editing will result in less image degradation than staying in 8-bits all the way.<p>

 

So the moral of this story is... If you are stuck with 8 bit output (which the OP is at present), then it is best to convert to 16-bits before doing any major edits, the reason being that you LOSE NOTHING, but stand to GAIN (comparatively) something.

<blockquote>

<p>1) Since I don't have a later version than CS version 8.0 and you have CS4, why don't you do the tests?</p>

 

</blockquote>

<p>I did, and it proves that dither does affect the conversions plus, the post of Bruce's above is from Feb 2002, so it seems pretty clear to me that whatever version was out 7 years ago behaved the same way. </p>

<blockquote>

<p>Frans I after reading this long discussion I was looking for some examples of you work. Is this your photography <a rel="nofollow" href="http://picasaweb.google.com/frans2001" target="_blank">http://picasaweb.google.com/frans2001</a></p>

</blockquote>

<p>Yes it is, Carl.</p>

<blockquote>

<p>I don't believe that upconverting to 16 bit solves the most common reason for posterization - when you try to add contrast to an image.</p>

</blockquote>

<p>Applying Levels 120/1/140 is adding contrast to the max and as I have shown with my examples there is a huge difference between the 8 and 8 to 16 bit image.</p>

<blockquote>

<p>I did, and it proves that dither does affect the conversions</p>

</blockquote>

<p>Care to share examples with and without dither with us and explain how it matters since all the indications from Adobe are that dither doesn't come into play when you convert a file from 8 to 16 bits or vica versa?</p>

<blockquote>

<p>the post of Bruce's above is from Feb 2002, so it seems pretty clear to me that whatever version was out 7 years ago behaved the same way.</p>

</blockquote>

<p>My CS version is from even later than that, 2003 and the accompanying help information is pretty clear in stating that dither only comes into play when upconverting an 8 bit file to a different work space, as I already have mentioned. Besides the only places in the CS menus where you can check or uncheck dither are when you want to convert to a different work space, not when you up- or down-convert between 8 and 16 bits.</p>

<blockquote>

<p>Care to share examples with and without dither with us and explain how it matters since all the indications from Adobe are that dither doesn't come into play when you convert a file from 8 to 16 bits or vica versa?</p>

</blockquote>

<p>The method is described above using Apply Image on both conversions. The net result is NOT a single level, but rather several on either side which proves there's a difference, the results of noise being applied in the conversion. It matters because dither IS added in the conversion and I think Bruce above explains why one would wish to test without this affecting the data. </p>

<blockquote>

<p>The method is described above using Apply Image on both conversions. The net result is NOT a single level, but rather several on either side which proves there's a difference, the results of noise being applied in the conversion.</p>

</blockquote>

<p>Did I mention I don't have CS4? I thought I did! Why not post the resulting images, similar to what I did so we can all learn from your wisdom?</p>

<blockquote>

<p>It matters because dither IS added in the conversion and I think Bruce above explains why one would wish to test without this affecting the data.</p>

</blockquote>

<p>So show me with examples.</p>

<p>It's also interesting to note that a discussion on how editing an 8 bit version versus the upconverted 16 bits version of the same image may get you different results, is now overshadowed by the issue of dither or not while it is unclear if dither even comes into play.</p>

<blockquote>

<p>Did I mention I don't have CS4? I thought I did! Why not post the resulting images, similar to what I did so we can all learn from your wisdom?</p>

 

</blockquote>

<p>Apply Image has been in Photoshop since version 1.0.7 if memory serves me (its been 19 years since I installed that build). </p>

<blockquote>

<p>It's also interesting to note that a discussion on how editing an 8 bit version versus the upconverted 16 bits version of the same image may get you different results, is now overshadowed by the issue of dither or not while it is unclear if dither even comes into play.</p>

</blockquote>

<p>It comes into play because it introduces an apples to oranges comparison of the data handling! And its in response to your post here which is incorrect:</p>

<blockquote>

<p>Adobe says it only works on 8-bit files when you convert to a different color space. They don't say it works on 16-bit files and they don't say it works when you convert from 8 to 16 or 16 to 8 bit in, presumably, the same work space. My tests seem to confirm what Adobe says.</p>

</blockquote>

<p>Here is the same document converted with and without Dither:<br>

<img src="http://digitaldog.net/files/dither.jpg" alt="" width="542" height="782" /></p>

<p>IF the conversions where identical, there would be a single level (level 128). By moving the level sliders as I already specified above, its easy to see the noise introduced by dither INTO the conversion which DOES affect the science. </p>

<p>This is applied with all color space conversions (even trips to Lab) as well as conversions from 16-bit to 8-bit. </p>

<p>I don't know what tests you did to "prove" there's nothing dither does here so again, I suggest you test this again using the instructions above. </p>

<p>I'm no expert mediator, but i'm guessing we're not going to get you two to send each other Christmas cards!</p>

<blockquote>

<p>Applying Levels 120/1/140 is adding contrast to the max and as I have shown with my examples there is a huge difference between the 8 and 8 to 16 bit image.</p>

</blockquote>

<p>You are overlooking that you first did a massive reduction in contrast by applying output levels 120/140 before doing the 120/1/140 input levels adjustment. You didn't add contrast, you restored the original contrast that had been removed by the output levels adjustment. Nobody edits images that way in the real world, taking away contrast and then putting it back. Typically they will either want to reduce contrast or enhance it - not do one then the other.</p>

<p>What your example images show, and what the test in the link I originally posted shows, is the advantage of 16 bit when doing contrast <em>reductions</em> .</p>

<p>If you do just the contrast enhancement (input levels 120/1/140) without first reducing contrast you'll get exactly the opposite results. The 16 bit image will be better, and the 8 bit image will look worse regardless of whether it was edited in 8 bit or 16 bit. (Of course, they will all look like crap because no one would need to make that strong of an adjustment on a real world image.)</p>

<p> </p>

<blockquote>

<p>Apply Image has been in Photoshop since version 1.0.7 if memory serves me</p>

</blockquote>

<p>Could you please explain why Apply Image would be needed to convert from 8 to 16 bits. I use Image>Mode>16 Bits/Channel and, as I have mentioned already, dither doesn't seem to be an option when I use that. What is overabundantly clear from my posted examples is that whether dither was at play or not, editing an 8 bit image that has first been converted to 16 bits causes way less damage than the same editing applied to the unconverted 8 bit image. It's not that I don't want to understand if and how dither plays a role or not, but my examples are hard to reason away, don't you think?</p>

<blockquote>

<p>And its in response to your post here which is incorrect</p>

</blockquote>

<p>Well, look for yourself what Adobe says for my version of Photoshop: "The Use Dither (8-bit/channel images) option controls whether to dither colors when converting 8-bit-per-channel images between color spaces. This option is available only when the Color Settings dialog box is in Advanced Mode." If that's incorrect than you better use your connections with Adobe to set them straight.</p>

<blockquote>

<p>Could you please explain why Apply Image would be needed to convert from 8 to 16 bits.</p>

</blockquote>

<p>It absolutely is not needed. Its an analytical tool. It proves there's a difference using dither and not using dither. Read the posts above about this tool.</p>

<blockquote>

<p>I use Image>Mode>16 Bits/Channel and, as I have mentioned already, dither doesn't seem to be an option when I use that.</p>

</blockquote>

<p>Dither is accessed in Color Settings. You are under the incorrect impression it plays no role in bit depth conversions and it does, Apply Image proves this. Did you read Bruce's quote?</p>

<blockquote>

<p>Well, look for yourself what Adobe says for my version of Photoshop:</p>

</blockquote>

<p>Well what they say is true. And it also affects conversions from 16-bit as Bruce and I pointed out and as I've illustrated using the Apply Image test you've yet to try. What they say in the small info type in Color Settings is not incorrect. But it is incomplete. If everything they say here and elsewhere in the app was complete, there would be little need for books on the subject.<br>

Maybe you'll also notice I asked about dither in my FIRST post because it does affect the testing!</p>

<blockquote>

 

</blockquote>

<blockquote>

<p>You are overlooking that you first did a massive reduction in contrast by applying output levels 120/140 before doing the 120/1/140 input levels adjustment.</p>

</blockquote>

<p>It doesn't matter. You overdo the editing to clearly show the difference. You could only apply some amount of Input Levels adjustment and you still would see a difference, but less dramatic. These tests are not designed to tell you to what extent the issue is going to show up in a particular image with a particular set of edting steps. They are designed to illustrate the underlying problems, what you may notice in your images if they show up and how to avoid/reduce problems in the first place by upconverting an 8 bit image to 16 bits before editing.</p>

<blockquote>

<p>It absolutely is not needed. Its an analytical tool. It proves there's a difference using dither and not using dither.</p>

</blockquote>

<p>OK, that helps a lot to clarify things. No, I did not apply this analytical tool; I visually compared the results between the edited 8 bit files, one edited with the Color Settings Use Dither on and the other off and I didn't <strong>see </strong>any difference. Using the analytical tool may very well have shown a difference but from my visual observations I can say that any impact of dither is <strong>very, very small compared to the overall results</strong>.<br>

So, it looks like first converting an 8 bit image to 16 bits before editing results in less posterization while dither may have a secondary, much smaller impact.</p>

<blockquote>

<p>It doesn't matter. You overdo the editing to clearly show the difference. You could only apply some amount of Input Levels adjustment and you still would see a difference, but less dramatic. These tests are not designed to tell you to what extent the issue is going to show up in a particular image with a particular set of edting steps. They are designed to illustrate the underlying problems, what you may notice in your images if they show up and how to avoid/reduce problems in the first place by upconverting an 8 bit image to 16 bits before editing.</p>

 

</blockquote>

<p>This comment tells me that you haven't read what I wrote above and/or haven't fully digested it. Re-read it again, then try the tests - <em>because it absolutely does matter. </em></p>

<p>The banding you see in your example does not arise from the addition of contrast. The banding happens because you took the nice smooth gradient blue sky image and compressed what were 256 discrete values (full 8 bit data) and put it into just 20 discrete values by changing the output levels to 120/140. What was black was converted to 120, what was white was converted to 140. Many of the closely related tones in the sky get converted to the same value (which can only lay on the integers between 120 -140). This<em> compression </em> of data that takes place in 8 bit mode is the destructive edit.</p>

<p>When you put the contrast back in by doing input levels 120/1/140, all you are doing is making visible the damage that you did in the first step by stretching the values back to roughly their original postion, except there are now much fewer tones to work with.</p>

<p>Don't believe me? Try this.... compress the data first in 8 bit mode by setting output levels 120/140, <em>then convert to 16 bit</em> , then undo the compression by setting input levels 120/1/140. The file will still look like crap, even though you did the addition of contrast step in 16 bit mode.</p>

<p>I'll restate it again...</p>

<p><em>Adding contrast to an 8 bit image = no practical difference between editing in 8 bit or 16 bit.</em><br>

<em>Removing contrast from an 8 bit image = big difference between editing in 8 bit or 16 bit. </em></p>

<blockquote>

<p><em >Adding contrast to an 8 bit image = no practical difference between editing in 8 bit or 16 bit.</em><br /><em >Removing contrast from an 8 bit image = big difference between editing in 8 bit or 16 bit</em></p>

 

</blockquote>

<p>Indeed! As Bruce points out in his Real World Camera Raw, the two moves (compressing and expanding) play vastly different and profound effects on the data. With tonal compression, the levels are lost differently than clipping. If you lighten the midtones without moving the clipping point, the levels between the two are compressed. Pixels that were at differing values now have the same value. With tonal expansion, you don't lose the data per say, you stretch the data over a wider range which often produces banding in smooth gradients. The gaps between the values are expanded too far. </p>

<p>Andrew - that's a good point about the midtone slider!</p>

<p>I can see how almost any edit involving a change in the tone curve (without adjusting the clipping points) will result in both a localized increase in contrast in one range, and a decrease in contrast in another range. Even moving the midtone slider left or right will result in compression in the highlights and expansion in the shadows, or vise versa.</p>

<p>So, pretty much all image edits in the real world would contain both addition and reduction of contrast. There would be portions of the image that would benefit from being upconverted from 8 to16 bit, and portions where there would not be benefits. </p>

<p>The problem areas are the ones where you want to have a <em><strong>net</strong> </em> increase in contrast above the original 8 bit baseline - which can lead to posterization. The upconvert to 16 bit doesn't help there, it doesn't create more tonal steps regardless of how much you compress and uncompress the data. In addition, the loss of data that happens during compression is only visible if you stretch out the data again. In the real world of image editing, you would have to create competing image edits of reducing contrast then adding it back for the benefit of 8 bit to 16bit conversion to really show. This is is poor Photoshop technique, IMHO, if you are trying to do quality image editing, regardless of whether you're working in 8 bit or 16 bit.</p>

<p>So, now I've come full circle.... I think that the test referenced in that first link I posted is contrived and not realistic. It doesn't represent how we actually work in PS, and it is also designed to heavily emphasize the one area where upconverting 8 bit to 16 bit actually makes a difference.</p>

<p>And then there's this just in from Chris Cox:</p>

<blockquote>

<p>Andrew;<br /><br />If you have an 8 bit source and need to apply extreme adjustments – then there might be some advantage to converting to 16 bit <strong>and dithering</strong> when converting back to 8 bit.<br />In general, starting with an 8 bit image – <strong>you’ve already lost most of your detail.</strong><br /><br />Dithering only happens when converting DOWN depths. There is no point (or purpose) in dithering when converting from 8 to 16, or 16 to 32.<br /><br /></p>

</blockquote>

This has been a bizarre debate, which seems to have turned into a witch-hunt against Frans instead of answering the OP's question. The OP question concerns the difference between 8-bit upconverted to 16-bit edits vs native 16-bit edits. No one in this thread has suggested that the former could match or even be preferable to the latter. This we all agree on (accept Dan Margulis, as I noted). Frans stated (correctly, imo) that if you are stuck with 8-bit output, which the OP is at present, then there can be some advantage to upconverting to 16-bit before editing as opposed to staying in 8-bit all the way. Now why Andrew is going on about converting from 16-bit to 8-bit I've got no idea. We are talking about the situation where the OP is stuck with an 8-bit output to begin with. And Sheldon seems to be wandering around all over the place popping up on both sides of the argument depending on which way the wind is blowing. Why Sheldon are you going on about the difference between contrast addition and removal? The OP's question doesn't concern only one or the other. The discussion here is talking about editing in general. Editing in general shifts pixel values around. The point that Frans, and now myself, are making is that there are precision errors when moving data around. 16-bit depth is more precise than 8-bit. Simple as that.

 

Let's take an extreme example: 3-bit vs 16-bit. 3 bits can encode 8 levels, and 16 bits can encode 65-odd thousand levels. Let's say your editing requires reducing all pixel values to 2/3rds of their original values. Let's take the highest value from each bit depth and see what happens:

 

8*2/3=5.333; 65536*2/3=43690.666

 

So, a simple error calculation associated with the 8 bit rounding (i.e. 5.333 becomes integer 5) is 0.333/8 = 0.042; 16-bit rounding error is .666/65536=0.0000102. You can see that the error associated with rounding in the larger bit-depth is much less than the smaller bit-depth. This is what Frans is saying. Now whether that makes a visible difference in real world edits is another question. It probably doesn't usually, but I have found with skies particularly (especially when you have blown the blue channel at capture) it doesn't take much to make them band.

<blockquote>

<p>Let's take an extreme example: 3-bit vs 16-bit. 3 bits can encode 8 levels, and 16 bits can encode 65-odd thousand levels. Let's say your editing requires reducing all pixel values to 2/3rds of their original values. Let's take the highest value from each bit depth and see what happens:</p>

</blockquote>

<p>Be careful here, the math doesn't automatically produce the results. For example, with 24 bit color, the math tells us we can define 16.7 million colors. One could suggest that 24 bit color would then provide a lot more colors than fewer bits per color. But if you capture a scene of say a gray card in 24 bit color, you're far from having 16.7 million colors. The math theoretically allows the definition of said colors but that hardly suggest all 24 bit files have that many colors (clearly they don't). If you assume that a 16-bit document from an 8-bit document has this many tone values, I think you better prove it. Now the math might be using a higher precision, but that doesn't mean the math accesses that degree of tonal data. </p>

<p>You have a white or black document in 3-bit and then 16-bit. You saying one has 8 levels while the other has 65000 odd levels? </p>

No. That's why I said "...then there <b><i>can</i></b> be some advantage to upconverting to 16-bit before editing as opposed to staying in 8-bit all the way". <p>

 

The way I look at it is this. You lose nothing (as far as I know) from converting from 8-bit to 16-bit to do editing. But there is the chance of gaining something (in comparison with staying in 8 bit all the way) by doing it this way. So why not do it? Of course, as we all agree, the best option is to capture the highest bit depth to begin with, but if you're stuck with low bit depth, then it could make sense to move up to a higher bit depth for editing.

<p>With regard to the original post.... If I recall, the Oxygen software <em>does</em> have the ability to capture 16bit scans. Scitex trumpeted the idea of creating archive scans in 16bit space back in the late 90's. I would just poke around in the settings to find it.<br>

What I do remember from my Scitex was that the transparency scans were so good that a little dust clean up was all that was required.</p>

<blockquote>

<p>And Sheldon seems to be wandering around all over the place popping up on both sides of the argument depending on which way the wind is blowing.</p>

</blockquote>

<p>Well, I'll certainly concede that I've refined my understanding of this issue over the course of this thread and that I don't agree with what I wrote in my first two posts (esp my second post).</p>

<blockquote>

<p>Why Sheldon are you going on about the difference between contrast addition and removal? The OP's question doesn't concern only one or the other. The discussion here is talking about editing in general. Editing in general shifts pixel values around.</p>

</blockquote>

<p>This is the biggie. Pushing pixels around is fine, and we all agree on the obvious (8 bit good, 8 bit edited in 16 bit better, 16 bit best), but there is only one problem that everyone keeps coming back to - <em>posterization</em> . That's what this whole discussion is about, banding in smooth tonal transitions. There isn't any other issue that we're trying to fix.</p>

<p><strong>What causes posterization? </strong> <em>Not having enough tones across a gradient to create the appearance of a smooth transition. You get that from trying to stretch data that isn't there. <br /> </em></p>

<p><strong>But my 8 bit file looks fine, no banding. </strong> <em>That's right, it is fine, until you try to stretch those tones across a wider range (adding contrast ). </em></p>

<p><strong>Well, I'll just convert up to 16 bit, that will solve my problem. </strong> <em>NO, it won't!</em></p>

<p>Sorry for the digression, but I hope you get my point. The OP's question was fundamentally this - <em>Is it okay to just upconvert my 8 bit file to 16 bit and edit, or should I be more worried about the bit rate at the time of capture?</em> My answer is that the bit rate at the time of capture is MUCH, MUCH more important than what bit rate you edit in. My recent comments in this thread have all been about the <em>why</em> behind that.</p>

<p>The reason I go on about contrast addition/subtraction is this... The problem of banding/posterization results from adding contrast to an image, which is equivalent to stretching tones across a wider range. When you start in 8 bit, you gain nothing from editing in 16 bit that contributes to solving that problem (unless you are doing unusual edits that compress then uncompress tonal ranges). You only get a practical benefit from capturing in a higher bit rate.</p>

<p>So, my argument is not against upconverting to 16 bit for editing. Obviously it is better and it takes no effort. My argument is against the illusion that upconverting to 16 bit solves the fundamental problem of posterization/banding -<strong> <em>it doesn't</em> </strong> . It may be useful in other areas but it fails to fix the one thing that really matters.</p>

<p>The takeaway is this... put your effort into starting out with a higher bit rate image if you care at all about any of this.</p>

<blockquote>

<p>The point that Frans, and now myself, are making is that there are precision errors when moving data around. 16-bit depth is more precise than 8-bit. Simple as that.</p>

</blockquote>

<p>You are way off track with this line of thinking. It may be true but it is a red herring to this discussion and doesn't matter in the practical world.</p>

<p>To use your own example against you.... Convert both 8 bit data and 16 bit data to 2/3 of their original values. In the 8 bit world - 200,200,200 becomes 133,133,133. In the 16 bit world - 25700,25700,25700 becomes 17133,17133,17133. Take the 8 bit data and put it on the 16 bit scale and you have 17090,17090,17090. The difference between the two due to rounding error is 43 bits out of 65,536. Or to put it in 8 bit terms, 1/3 of one bit - which is basically not visible.</p>

<p>None of the rounding errors of the 8 bit space, though they may exist, make any significant difference when we are talking about what is the cause of banding/posterization. The fundamental question at hand is this - What happens when you compress and stretch tonal values and what benefits do you get from capturing/editing in 8 bit vs 16 bit?</p>

<p>Anyhow, sorry to go back and forth on all these posts, I hate threads that are argumentative. But I'm interested in this issue (I scan and edit a lot of 4x5 film) and the more I look into it, the more I realize that there's only one real answer.... capture in a higher bit rate.</p>

<p>

<p >

 

 

<blockquote>

<p >Dither only comes into play when you convert an 8 bit image to a different color space, so no, dither was not on since I didn't convert to a different color space.</p>

</blockquote>

<p > </p>

<p >Un no...wrong answer. If you have Use Dither selected as an option in the Advanced Color Settings, a low level noise dither will be applied on _ANY_ transform whether it's from RGB>CMYK, RGB>RGB or 8 bit to 16 bit or 16 bit to 8 bit. It does not surprise me that adding noise helps reduce banding....which is EXACTLY what the Use Dither was put in place for, to cut down banding. So if you start in 8 bit and convert to 16 bit, you had noise added by virtue of the conversion––if you have that option on (it's on by default).</p>

<p > </p>

<p >What you are seeing is expected benefit from adding a bit of noise when doing color to tone adjustments. You are _NOT_ getting the full benefit if working in 16 bit from the very beginning however. Jumping into 16 bit from 8 bit will only ever provide a tiny benefit (and most of that is from adding the noise in the conversion).</p>

<br />

 

 

</p>

</p>

<p>I have been away for only half a day a see what happens? Total chaos. Everybody voicing a different opinion and <strong>NOBODY</strong> is posting any examples as proof of what they are saying. I'm in and out of a 4 day event, but when I have the time I'll try out Andrew's analytical tool and report back. I'll show the results of Photoshop CS version 8.0 drastic edits on 16 bit, 8 bit and 8 bit converted to 16 bits images, with and without dither.</p>