 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| PhotoKB HomeDiscussion Groups Digital Photography Digital PhotoDSLR CamerasZLR CamerasPoint & Shoot CamerasFilm Photography 35 mmLarge FormatMedium formatDarkroomFilm and LabsOther EquipmentPhoto Technique Nature PhotographyPeople PhotographyTechnique GeneralGeneral Photo Topics General TopicsAustralian PhotographyUK PhotographyDirectoryPhoto Clubs |
Photo Forum / Digital Photography / DSLR Cameras / February 200616bit vs 8 bit for prints
A photographer friend of mine processes everything in Photoshop in 16 bit RAW. When he wants to have a print made he changes the image to an 8 bit tif. He says that the reason for dropping to 8 bit is that most photo labs have 8 bit printers. It seems to me if you are going to switch to 8 bit for the print, you might as well have never started in 16 bit in the first place. Don't you lose the extra dynamic range, etc. as soon as you make the change? It doesn't makes sense to me. What would happen if you sent a 16 bit file to be printed? How much larger would the file size be - twice the size of the 8 bit?  SignatureTerry Remove the rodent from my email address to reply directly. > It seems to me if you are going to switch to 8 bit for the print, you might > as well have never started in 16 bit in the first place. Don't you lose the > extra dynamic range, etc. as soon as you make the change? It doesn't makes > sense to me. There is no extra dynamic range, just extra precision, which is of no benefit in printing. It is of benefit in processing, when you're moving levels around and stuff. You'd see no difference in the printed output. > What would happen if you sent a 16 bit file to be printed? If the lab isn't sent up to handle them, they would either reduce to 8 bit or reject the file. Depends how their system is set up. > How much larger would the file size be - twice the size of the 8 bit? Pretty much. SignatureJeremy | jeremy@exit109.com >There is no extra dynamic range, just extra precision Thats certainly true if you converted from 8-bit to 16-bit, but 16-bit could hold a lot more dynamic range than 8-bit, if the source was of sufficient quality and precision. Signature<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<> John P Sheehy <JPS@no.komm> ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>>< > >There is no extra dynamic range, just extra precision > > Thats certainly true if you converted from 8-bit to 16-bit, but 16-bit > could hold a lot more dynamic range than 8-bit, if the source was of > sufficient quality and precision. It *could*, but it *doesn't*. The dynamic range is set by the capabilities of the sensor in the camera, not by the bit depth chosen. The amount of dynamic range provided by the sensor is then divided up into some number of steps -- 8 bits, or a larger number (the storage for high-bit images is 16-bit, but the actual data from the sensor is much more commonly 12-bit or 14-bit, it's just stored in a 16-bit field). There isn't spare dynamic range in the sensor that's being thrown away in 8-bit mode. SignatureDavid Dyer-Bennet, <mailto:dd-b@dd-b.net>, <http://www.dd-b.net/dd-b/> RKBA: <http://noguns-nomoney.com/> <http://www.dd-b.net/carry/> Pics: <http://dd-b.lighthunters.net/> <http://www.dd-b.net/dd-b/SnapshotAlbum/> Dragaera/Steven Brust: <http://dragaera.info/> >> >There is no extra dynamic range, just extra precision >> [quoted text clipped - 10 lines] >a 16-bit field). There isn't spare dynamic range in the sensor that's >being thrown away in 8-bit mode. What part of that is not implied in "if the source was of sufficent quality and precision"? Much of the dynamic range of the sensor never makes it to the RAW data; only the low ISO uses the top range of the sensor, and it loses much to the 12-bit digitization. The higher ISOs only use a fraction of the sensor's absolute range. So, in a sense, the sensor's dynamic range doesn't "set" anything, per se; it is merely a "superlimit" of DR, with other sublimiters coming into play. Signature<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<> John P Sheehy <JPS@no.komm> ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>>< > >> >There is no extra dynamic range, just extra precision > >> [quoted text clipped - 13 lines] > What part of that is not implied in "if the source was of sufficent > quality and precision"? The part where we're talking about actual cameras, rather than theory. SignatureDavid Dyer-Bennet, <mailto:dd-b@dd-b.net>, <http://www.dd-b.net/dd-b/> RKBA: <http://noguns-nomoney.com/> <http://www.dd-b.net/carry/> Pics: <http://dd-b.lighthunters.net/> <http://www.dd-b.net/dd-b/SnapshotAlbum/> Dragaera/Steven Brust: <http://dragaera.info/> >> What part of that is not implied in "if the source was of sufficent >> quality and precision"? >The part where we're talking about actual cameras, rather than theory. I was talking about data formats, not cameras, and I was replying to statements about data formats, not cameras. Things were written in this thread that either implied or reinforced the common misconception that "dynamic range has nothing to do with bit depth", and so I made it clear that bit depth (and the mapping used) determine the limits of dynamic range. I will continue to make that point until such a time that people stop saying or implying that dynamic range has nothing to do with bit depth. Signature<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<> John P Sheehy <JPS@no.komm> ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>>< > >> What part of that is not implied in "if the source was of sufficent > >> quality and precision"? [quoted text clipped - 10 lines] > point until such a time that people stop saying or implying that dynamic > range has nothing to do with bit depth. It's not *true* in any useful sense. I am not aware of any situation in which selecting a bit depth changes the dynamic range of photographic equipment. Are you? That bit about the mapping used that you slipped in up there is the key point. SignatureDavid Dyer-Bennet, <mailto:dd-b@dd-b.net>, <http://www.dd-b.net/dd-b/> RKBA: <http://noguns-nomoney.com/> <http://www.dd-b.net/carry/> Pics: <http://dd-b.lighthunters.net/> <http://www.dd-b.net/dd-b/SnapshotAlbum/> Dragaera/Steven Brust: <http://dragaera.info/> >>>>What part of that is not implied in "if the source was of sufficent >>>>quality and precision"? [quoted text clipped - 15 lines] > photographic equipment. Are you? That bit about the mapping used > that you slipped in up there is the key point. OK I did a test: <http://www.edgehill.net/1/?SC=go.php&DIR=Misc/photography/gamut-bits> -big difference! >OK I did a test: ><http://www.edgehill.net/1/?SC=go.php&DIR=Misc/photography/gamut-bits> >-big difference! The only difference I see is that the sRGB 8-bit one is rendered with brighter tones, and is clipped more. They are almost identical, otherwise. Signature<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<> John P Sheehy <JPS@no.komm> ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>>< >> OK I did a test: >> <http://www.edgehill.net/1/?SC=go.php&DIR=Misc/photography/gamut-bits> [quoted text clipped - 3 lines] > brighter tones, and is clipped more. They are almost identical, > otherwise. There's a lot more detail in the grey "thing" behind the lady's head in the ProPhoto image. That said, converting to 8-bit at the START of the workflow is going to induce posterization. You don't want that. Converting to 8-bit at the END of the workflow, when you'll be doing no further modifications, really won't affect the image. For printing purposes, it shouldn't make a difference in what you can actually see. > >> OK I did a test: > >> <http://www.edgehill.net/1/?SC=go.php&DIR=Misc/photography/gamut-bits> [quoted text clipped - 6 lines] > There's a lot more detail in the grey "thing" behind the lady's head in > the ProPhoto image. Definitely. But I don't understand the workflow on the two samples. The ProPhoto is now an 8-bit sRGB JPEG now, too, isn't it? So what was the workflow for the 16-bit ProPhoto and for the 8-bit JPG? Greg >There's a lot more detail in the grey "thing" behind the lady's head in >the ProPhoto image. But the image on the right is too bright, and is blown out. We can't tell why from the image. Signature<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<> John P Sheehy <JPS@no.komm> ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>>< >>There's a lot more detail in the grey "thing" behind the lady's head in >>the ProPhoto image. > > But the image on the right is too bright, and is blown out. We can't > tell why from the image. ProPhotoRGB seems to have pushed the histogram to the left so there was more info being boosted by the curve I applied. The curve was just a straight drag of the top-right point 2/3 over to the left increasing the brightness/contrast of the shadows. Input=50 output=255. I don't understand why but it wasn't a bit depth issue, maybe a gamut issue, probably a strange difference in applying those specific adjustments to that particular range in those particular gamuts. I fiddled a bit with a straight black/white gradient to see if there was more posterizing and couldn't find anything meaningful. >>>There's a lot more detail in the grey "thing" behind the lady's head in >>>the ProPhoto image. >> >> But the image on the right is too bright, and is blown out. We can't >> tell why from the image. > ProPhotoRGB seems to have pushed the histogram to the left so there was > more info being boosted by the curve I applied. The curve was just a > straight drag of the top-right point 2/3 over to the left increasing the > brightness/contrast of the shadows. Input=50 output=255. I don't > understand why but it wasn't a bit depth issue, maybe a gamut issue, It's nothing to do with the gamuts. ProPhoto uses gamma 1.8 whereas Adobe and sRGB use gamma 2.2. As a consequence of this, adjusting curves works differently. To determine just the effect of using a different colour space, you'd want something with the primaries of ProPhoto and the gamma of Adobe RGB. > probably a strange difference in applying those specific adjustments to > that particular range in those particular gamuts. > I fiddled a bit with a straight black/white gradient to see if there was > more posterizing and couldn't find anything meaningful. Andrew. > ProPhotoRGB seems to have pushed the histogram to the left so there was > more info being boosted by the curve I applied. The curve was just a [quoted text clipped - 3 lines] > probably a strange difference in applying those specific adjustments to > that particular range in those particular gamuts. ProPhoto uses a gamma of 1.8, which results in less of the response curve being used for the shadow areas than in the 2.2 gamma of sRGB (so the shadows will posterize more easily if you're not careful), and makes "equal" curves work differently. SignatureJeremy | jeremy@exit109.com >>ProPhotoRGB seems to have pushed the histogram to the left so there was >>more info being boosted by the curve I applied. The curve was just a [quoted text clipped - 8 lines] > the shadows will posterize more easily if you're not careful), and makes > "equal" curves work differently. Yeah, that would explain it. Strange that the widest gamut would have more data jammed into the shadows. I guess that's not as bad as it sounds. AdobeRGB's gamma 2.2 histogram looks more like sRGB. http://www.luminous-landscape.com/tutorials/prophoto-rgb.shtml >> The only difference I see is that the sRGB 8-bit one is rendered with >> brighter tones, and is clipped more. They are almost identical, [quoted text clipped - 5 lines] >That said, converting to 8-bit at the START of the workflow is going to >induce posterization. Yes it can... but only by working at it. If an image requires enough levels/curves/saturation correction to cause posterization you should not be wasting time on it >...................................For printing purposes, it shouldn't >make a difference in what you can actually see. Precisely! >>OK I did a test: >><http://www.edgehill.net/1/?SC=go.php&DIR=Misc/photography/gamut-bits> [quoted text clipped - 3 lines] > brighter tones, and is clipped more. They are almost identical, > otherwise. It seems to have to do with the color space rather than bit depth. I applied an identical curve but the histograms look quite different so it worked differently. I'm not sure why the histograms look so different and the images look identical in ProPhotoRGB vs sRGB. ProPhoto was much more scrunched up to the left and taller. For some reason, the replies below this message show as *error* in my newsreader so I don't know what Bill Lloyd or G.T. said in response. >>OK I did a test: >><http://www.edgehill.net/1/?SC=go.php&DIR=Misc/photography/gamut-bits> [quoted text clipped - 3 lines] > brighter tones, and is clipped more. They are almost identical, > otherwise. > For some reason, the replies below this message show as *error* in my > newsreader so I don't know what Bill Lloyd or G.T. said in response. nevermind, they are ok now > >>>>What part of that is not implied in "if the source was of sufficent > >>>>quality and precision"? [quoted text clipped - 18 lines] > <http://www.edgehill.net/1/?SC=go.php&DIR=Misc/photography/gamut-bits> > -big difference! I can't tell what you think you've proven, or what you did in preparing this test. So far as I can tell it has nothing to do with the subject of this discussion. SignatureDavid Dyer-Bennet, <mailto:dd-b@dd-b.net>, <http://www.dd-b.net/dd-b/> RKBA: <http://noguns-nomoney.com/> <http://www.dd-b.net/carry/> Pics: <http://dd-b.lighthunters.net/> <http://www.dd-b.net/dd-b/SnapshotAlbum/> Dragaera/Steven Brust: <http://dragaera.info/> >>>It's not *true* in any useful sense. I am not aware of any situation >>>in which selecting a bit depth changes the dynamic range of [quoted text clipped - 6 lines] > > I can't tell what you think you've proven, Me either <g> > or what you did in preparing this test. That should be self evident from the text on the image. I increased contrast to show differences between two conversions from a raw file. > So far as I can tell it has nothing to do with > the subject of this discussion. Correct. It seems to be a gamut issue. The point was to see if gamut and bit depth effect ability to post process cleanly. Gamut does but I don't understand why. Bit depth does not seem to have any visible effect although I understand it should have theoretical impacts. >OK I did a test: ><http://www.edgehill.net/1/?SC=go.php&DIR=Misc/photography/gamut-bits> >-big difference! This proves you can take a crap 16 bit image file and with hard work and perseverance turn it into an even worse 8 bit web image. What has it got to do with comparing 16 and 8 bit files printed on a 8 bit printer? >>OK I did a test: >><http://www.edgehill.net/1/?SC=go.php&DIR=Misc/photography/gamut-bits> [quoted text clipped - 4 lines] > it got to do with comparing 16 and 8 bit files printed on a 8 bit > printer? That's a tiny crop heavily stretched for which I had reason to stretch heavily (although not that far). It was not offered as art or technical perfection. As it turns out, it was a useless test also because of the gamut gammas. I tried setting something up where I could see the difference between 8 & 16 bit & I was unable to see anything. >> There is no extra dynamic range, just extra precision > > Thats certainly true if you converted from 8-bit to 16-bit, but 16-bit > could hold a lot more dynamic range than 8-bit, if the source was of > sufficient quality and precision. But it doesn't, so the theory isn't very relevant. SignatureJeremy | jeremy@exit109.com SNIP >> 16-bit could hold a lot more dynamic range than 8-bit, if the >> source was of sufficient quality and precision. > > But it doesn't, so the theory isn't very relevant. It doesn't ??? Since when is 65535:1 smaller than 255:1 ??? Bart > SNIP > >> 16-bit could hold a lot more dynamic range than 8-bit, if the [quoted text clipped - 5 lines] > > Since when is 65535:1 smaller than 255:1 ??? "Dynamic range" is about the brightest and dimmest regions in the scene that are imaged, and has nothing to do with the numerical values used to represent those regions. SignatureDavid Dyer-Bennet, <mailto:dd-b@dd-b.net>, <http://www.dd-b.net/dd-b/> RKBA: <http://noguns-nomoney.com/> <http://www.dd-b.net/carry/> Pics: <http://dd-b.lighthunters.net/> <http://www.dd-b.net/dd-b/SnapshotAlbum/> Dragaera/Steven Brust: <http://dragaera.info/> > "Jeremy Nixon" <jeremy@exit109.com> wrote in message > >> But it doesn't, so the theory isn't very relevant. > > It doesn't ??? It could, but it doesn't. In 16-bit you're mapping the same range to the 16 bits of value (or 15 bits, in Photoshop) as you are to the 8 bits. There's no stone tablet coming down the mountain that says you have to do that, but there's little or no value in not doing that with the current state of the art. > Since when is 65535:1 smaller than 255:1 ??? Since that has no relation whatsoever to the actual dynamic range that can be represented in the image. SignatureJeremy | jeremy@exit109.com > A photographer friend of mine processes everything in Photoshop in 16 bit > RAW. When he wants to have a print made he changes the image to an 8 bit > tif. He says that the reason for dropping to 8 bit is that most photo labs > have 8 bit printers. Or put a slightly different way, "Can't handle 16 bit images" > It seems to me if you are going to switch to 8 bit for the print, you might > as well have never started in 16 bit in the first place. Don't you lose the > extra dynamic range, etc. as soon as you make the change? No - it's more a case of giving you "editing headroom" whilst you make adjustments, especially if you're using a large gamut colourspace like ProPhoto. There's no change the dynamic range - only the size of the steps between levels within the range. Think of 2 staircases - both go from sea level to the top of a mountain - one has 256 steps, the other 32768 - both have the same height (dynamic range), but the one with 32768 steps has less of a jump between levels. Once you've finished editing then converting the finished shot back to 8 bit gives you 256 levels of each colour - human eye can't usually tell the difference between levels at 200 (is even pressed to see 128 levels) - so it doesn't make any difference to the finished shot. > What would happen if you sent a 16 bit file to be printed? Depends on the lab - in many cases you just get rubbish. > How much larger would the file size be - twice the size of the 8 bit? Yes. >No - it's more a case of giving you "editing headroom" whilst you make >adjustments, especially if you're using a large gamut colourspace like >ProPhoto. There's no change the dynamic range - only the size of the steps >between levels within the range. Think of 2 staircases - both go from sea >level to the top of a mountain - one has 256 steps, the other 32768 - both >have the same height (dynamic range), The dynamic range is a ratio, not a height. The maximum dynamic range expressable at the pixel level is the ratio of the luminance of the highest value to the lowest. If the values are linear, then the dynamic range of 16-bit is 257 (65535/255) times as high as 8-bit; if the shadows are 2.2 gamma-adjusted, 16-bit data has a potential dynamic range 196,000x as high as 8-bit. Common standards use linear data for deep shadow ranges, I have been told, so the more probably figure is 257. 16-bit conversions have a little bit more dynamic range than 8-bit conversions for low-noise ISOs (provided they are both TIFF; if the 8-bit is JPEG, then the difference is wider). The real limitation to dynamic range is the RAW data itself (at low ISOs) and noise (at higher ISOs). 2.2-gamma 8-bit data can hold a lot of DR, and 16-bit astronomical DR. The limitation is precision in the 8-bit data. >but the one with 32768 steps has less >of a jump between levels. Signature<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<> John P Sheehy <JPS@no.komm> ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>>< >In message <ZrdIf.146283$vH5.1208765@news.xtra.co.nz>, >The real limitation to dynamic range is the RAW data itself (at low >ISOs) and noise (at higher ISOs). 2.2-gamma 8-bit data can hold a lot >of DR, and 16-bit astronomical DR. The limitation is precision in the >8-bit data. The slope-limited gamma in sRGB gives about 12 bits of dynamic range for 8-bit/ch data. DSLRs tend to have 12-bit A/D convertors so there is a good match between the cameras and sRGB. SignatureThat was it. Done. The faulty Monk was turned out into the desert where it could believe what it liked, including the idea that it had been hard done by. It was allowed to keep its horse, since horses were so cheap to make. -- Douglas Adams in Dirk Gently's Holistic Detective Agency >>In message <ZrdIf.146283$vH5.1208765@news.xtra.co.nz>, >>The real limitation to dynamic range is the RAW data itself (at low >>ISOs) and noise (at higher ISOs). 2.2-gamma 8-bit data can hold a lot >>of DR, and 16-bit astronomical DR. The limitation is precision in the >>8-bit data. >The slope-limited gamma in sRGB gives about 12 bits of dynamic range >for 8-bit/ch data. DSLRs tend to have 12-bit A/D convertors so there is >a good match between the cameras and sRGB. Perhaps I could have been clearer. What I meant was that the main problem with 8-bit data is precision, *not* DR. The placement of my last sentence was not to qualify the one before it. "The main limitation of 8-bit data is its low precision" - that should be clearer. Signature<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<> John P Sheehy <JPS@no.komm> ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>>< >In message <ebt43mro7d8bmqf0hv6h97j504@inews_id.stereo.hq.phicoh.net>, >Perhaps I could have been clearer. What I meant was that the main [quoted text clipped - 3 lines] >"The main limitation of 8-bit data is its low precision" - that should >be clearer. If 8-bit/ch would not be precise enough for final output, then CTRs would have to show al kind of artifacts as well. As far as I can tell they don't. It is true that 8-bit/ch doesn't any margin for error. So it suitable for the final output, but not for intermediate steps. SignatureThat was it. Done. The faulty Monk was turned out into the desert where it could believe what it liked, including the idea that it had been hard done by. It was allowed to keep its horse, since horses were so cheap to make. -- Douglas Adams in Dirk Gently's Holistic Detective Agency >If 8-bit/ch would not be precise enough for final output, then CTRs would >have to show al kind of artifacts as well. As far as I can tell they don't. > >It is true that 8-bit/ch doesn't any margin for error. So it suitable for >the final output, but not for intermediate steps. It's not suitable for final output, when there is no noise in the image, such as computer-generated 3D renders that don't employ dithering. For digital images, there is enough noise to avoid posterized contour banding. Signature<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<> John P Sheehy <JPS@no.komm> ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>>< > In message <ZrdIf.146283$vH5.1208765@news.xtra.co.nz>, > The dynamic range is a ratio, not a height. Thank you for once again advancing my education ;) Getting back to the original question though, changing a 16 bit image to an 8 bit one as the final workflow step isn't going to give us any visable differences - correct? >> In message <ZrdIf.146283$vH5.1208765@news.xtra.co.nz>, >> The dynamic range is a ratio, not a height. >Thank you for once again advancing my education ;) >Getting back to the original question though, changing a 16 bit image to an >8 bit one as the final workflow step isn't going to give us any visable >differences - correct? On an 8-bit display, no. If you have a 10-bit display, you can see the difference in the red and especially the green channel if there is no noise to break up posterization. 128,128,128 is very distinct from 129,129,129, to my eyes. I can read 129 text on a 128 background, if the fonts are big enough. For photographic images, there is usually noise that hides this. For what it's worth, I leave data 16-bit, to print myself from photoshop. Why take the extra step (and risk saving it in 8-bit), for nothing. Photoshop doesn't say, "Hey, that's 16-bit; I can't use it"; it just converts on the fly for the printer. Signature<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<> John P Sheehy <JPS@no.komm> ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>>< >On an 8-bit display, no. If you have a 10-bit display, you can see the >difference in the red and especially the green channel if there is no >noise to break up posterization. I meant that you can potentially see the difference between 16-bit and 8-bit with a 10-bit display (smooth gradients with low noise); not that you could see more posterization with the 10-bit display, in case that wasn't clear. Signature<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<> John P Sheehy <JPS@no.komm> ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>>< > Getting back to the original question though, changing a 16 bit image to an > 8 bit one as the final workflow step isn't going to give us any visable > differences - correct? In theory it could, but in practice, as a general rule, no. I keep everything in 16-bit, but there's no harm in going to 8-bit for output as long as you don't overwrite the original with it (or if you don't do any further processing on the image). (In practice, in fact, you can do a lot to an 8-bit image before you'd notice any *visible* degradation, but why take the loss if you don't have to? Someday, we may have better output capabilities, after all.) SignatureJeremy | jeremy@exit109.com > I keep everything in 16-bit, but there's no harm in going to 8-bit for > output as long as you don't overwrite the original with it (or if you > don't do any further processing on the image). I agree - I was just clarifying - I do all my own printing, and as such have a 100% 16 bit workflow. > (In practice, in fact, you can do a lot to an 8-bit image before you'd > notice any *visible* degradation, but why take the loss if you don't > have to? Someday, we may have better output capabilities, after all.) I'm told that that holds true for sRGB, but not on big colour space profiles like LAB. > "Jeremy Nixon" <jeremy@exit109.com> wrote in message > [quoted text clipped - 4 lines] > I'm told that that holds true for sRGB, but not on big colour space profiles > like LAB. Dan Margulis, who literally wrote the book on LAB color, argues against this pretty effectively in "Photoshop LAB Color", and backs it up by doing the conversions repeatedly, 25 times, with adjustments in between, with no visible loss. (I highly recommend the book, by the way, but be warned: it's more dense and information-rich than pretty much any other technical book I've read, and a lot of the stuff is pretty advanced and definitely not suitable for the novice or even intermediate photographer.) SignatureJeremy | jeremy@exit109.com >> "Jeremy Nixon" <jeremy@exit109.com> wrote in message >> [quoted text clipped - 18 lines] > lot of the stuff is pretty advanced and definitely not suitable for the > novice or even intermediate photographer.) Yes - I have the book, and work in LAB a lot. It's interesting that Bruce Fraser argues the other way in Real World Colour Management - and has an example photo off memory. Personally, I feel 16 bit has potential advantages, no disadvantages that affect me - so in my case it's a no-brainer to use it. >> "Jeremy Nixon" <jeremy@exit109.com> wrote in message SNIP >> I'm told that that holds true for sRGB, but not on big colour >> space profiles like LAB. [quoted text clipped - 3 lines] > backs it up by doing the conversions repeatedly, 25 times, with > adjustments in between, with no visible loss. The key word being "visible" loss, and that's further helped by the fact that our vision system is pretty poor in qualitative comparisons. This experiment might give some more perspective to the RGB to Lab conversion (Photoshop's integer number version of Lab that is): <http://www.brucelindbloom.com/index.html?RGB16Million.html> The simple conversion from sRGB to Lab potentially loses up to 87% of the colors and changes them to different/similar ones. Other interesting experiments can be done with the same file, e.g. assigning a really wide colorspace like ProPhoto RGB, and converting it to Adobe RGB leaves 6224566 colors (36% remaining) out of 16.7 million, or converting to sRGB leaves 4400295 colors (26% remaining). I used Absolute Colorimetric Rendering for those percentages. Conversions are often lossy, and it's only due to limitations of our vision (and mental remapping) that things don't look aweful :-) Bart > The key word being "visible" loss, and that's further helped by the > fact that our vision system is pretty poor in qualitative comparisons. Why in the world would I care about invisible loss? > This experiment might give some more perspective to the RGB to Lab > conversion (Photoshop's integer number version of Lab that is): > <http://www.brucelindbloom.com/index.html?RGB16Million.html> > The simple conversion from sRGB to Lab potentially loses up to 87% of > the colors and changes them to different/similar ones. It's a contrived example that has nothing to do with photographs. Try it on a real-world photographic image. SignatureJeremy | jeremy@exit109.com >> The key word being "visible" loss, and that's further helped by the >> fact that our vision system is pretty poor in qualitative comparisons. > >Why in the world would I care about invisible loss? That is precisely the point - going from 16-bits to 8-pits in the final image is just that, an invisible loss. >> This experiment might give some more perspective to the RGB to Lab >> conversion (Photoshop's integer number version of Lab that is): [quoted text clipped - 4 lines] >It's a contrived example that has nothing to do with photographs. Try it >on a real-world photographic image. Well it can't be any more obvious, since this contrived example starts with all of the possible colours and a real photo will only have a subset of those. So the loss due to the conversion can only be less with a real world photo than it is with the test image. Bart's "loses up to 87%" remains a perfectly valid statement even for a real photo. SignatureKennedy Yes, Socrates himself is particularly missed; A lovely little thinker, but a bugger when he's pissed. Python Philosophers (replace 'nospam' with 'kennedym' when replying) >> It's a contrived example that has nothing to do with photographs. Try it >> on a real-world photographic image. [quoted text clipped - 4 lines] > with a real world photo than it is with the test image. Bart's "loses > up to 87%" remains a perfectly valid statement even for a real photo. Perfectly valid, and perfectly misleading, something that statistics can often be. "Loses up to 87%" is of course correct, but when the actual effect on real-world photographs is *none at all*, statistics like that serve only to scare people into mindlessly following cargo-cult advice (which is itself a time-honored tradition in photography, unfortunately). The point is -- sure, there's a loss, but it's negligible at the final stage and shouldn't scare you from doing the conversion. SignatureJeremy | jeremy@exit109.com >>> It's a contrived example that has nothing to do with photographs. Try it >>> on a real-world photographic image. [quoted text clipped - 13 lines] >The point is -- sure, there's a loss, but it's negligible at the final >stage and shouldn't scare you from doing the conversion. We seem to be in violent agreement. Bart's post indicated that "up to 87%" could be lost in a conventional mode change without any visible loss to demonstrate how much excess information was present in the 16-bit RGB and thus how safe it was to reduce from 16 to 8 bits at the final output stage. He wasn't saying (correct me if I am misinterpreting you, Bart!) "Tsk, tsk, you mustn't convert because you will lose 87% and it will look horrible!". You seem to be interpreting his assessment in completely the opposite sense that it was intended. SignatureKennedy Yes, Socrates himself is particularly missed; A lovely little thinker, but a bugger when he's pissed. Python Philosophers (replace 'nospam' with 'kennedym' when replying) > He wasn't saying (correct me if I am misinterpreting you, Bart!) "Tsk, > tsk, you mustn't convert because you will lose 87% and it will look > horrible!". > > You seem to be interpreting his assessment in completely the opposite > sense that it was intended. Perhaps so, but the above seems to be exactly what he's saying, even after going back and re-reading his posts. SignatureJeremy | jeremy@exit109.com >> He wasn't saying (correct me if I am misinterpreting you, Bart!) >> "Tsk, [quoted text clipped - 8 lines] > after > going back and re-reading his posts. Sorry, but it is not what I implied. Only if we have an (unlikely) situation of an original with 16.7 million colors, we would have a certainty of retaining no more than 13% unique colors (most of them similar to the originals) out of the full potential. The risk is in the similarity, as it might produce posterization or banding in smooth gradients. Whether the human visual system is able to detect it is another factor, but if the HVS can, we have a problem due to the chosen workflow and need to go back to the source data. Bart SNIP >>The point is -- sure, there's a loss, but it's negligible at the >>final stage and shouldn't scare you from doing the conversion. >> > We seem to be in violent agreement. ;-) > Bart's post indicated that "up to 87%" could be lost in a > conventional mode change without any visible loss to demonstrate how > much excess information was present in the 16-bit RGB and thus how > safe it was to reduce from 16 to 8 bits at the final output stage. Yes, sort of. I intended to point-out that although the loss is potentially massive (or nil) the human visual system (HVS) may have difficulty to perceive the loss. That is what the whole controversy between the different factions boils down to, IMHO. One faction sees no downside whatsoever, another only sees doom and damnation. As usual the truth is somewhere in between. > He wasn't saying (correct me if I am misinterpreting you, Bart!) > "Tsk, tsk, you mustn't convert because you will lose 87% and it will > look horrible!". Indeed, I never said one would in every case lose 87% of all info. Info might be transformed into other info (or not), and that would lead to an increased chance(!) of artifacts occurring. The artifacts may or may not occur, and may be visible or not. However, it's a bit like the inverse of a lottery. In a lottery I'd have a potential gain versus a certain loss, in integer image data conversions there is no direct gain versus a potential loss. > You seem to be interpreting his assessment in completely the > opposite sense that it was intended. Maybe not completely opposite, because there *is* an increased chance on the losses wreaking havoc severe enough for the HVS to detect (e.g. as banding or posterization/noise). We can reduce the risks by doing all significant conversions (amongst which conversion to and from Lab) in 16-b/ch (even if we start with 8-b/ch gamma adjusted data), before falling back again to 8-b/ch for output. Bart > Perfectly valid, and perfectly misleading, something that statistics can > often be. "Loses up to 87%" is of course correct, but when the actual > effect on real-world photographs is *none at all*, statistics like that > serve only to scare people into mindlessly following cargo-cult advice Like the lab I use was bitching about. There are people who DEMAND to email them huge tiff files to make 5X7 and 8X10 prints claiming they read somewhere that a single jpeg conversion is going to lose them a bunch of image quality. I'm sure in a scientific test there is a loss but in the final print, a high quality jpeg isn't going to visibly be any different than the tiff file. SignatureStacey SNIP >>It's a contrived example that has nothing to do with photographs. >>Try it on a real-world photographic image. > > Well it can't be any more obvious, since this contrived example > starts with all of the possible colours and a real photo will only > have a subset of those. Indeed, and that subset may consist (partly or mostly) of the exact colors that are changed to similar ones, thus losing color distinction that was present in the original capture. It usually manifests itself as banding or apparent noise in smooth gradients. > So the loss due to the conversion can only be less with a real world > photo than it is with the test image. Bart's "loses up to 87%" > remains a perfectly valid statement even for a real photo. We owe it to our 'limited' visual system's accuracy (mostly due of our mental interpretation skills taking over) and relatively low printing/display accuracy that the results are visually tolerable. However, I added the slightly OT profile conversion (from wide to more limited) experiment's warning, as it *can* become visible: <http://www.xs4all.nl/~bvdwolf/main/downloads/8vs16-bpch%20processing.png> Most of the noise was produced when converting from a wide to a more narrow color space and from switching between RGB and Lab and back, in 8-b/ch. Printing also requires conversion between color spaces, and it's best done in 16-b/ch since subsequent resampling and sharpening can "enhance" the artifacts. Arguably, in print the losses may be hard to see, but that's due to limited print quality we have to live with, and lack of magnification. Magnification will make the losses "more visible". Bart >> The key word being "visible" loss, and that's further helped by the >> fact that our vision system is pretty poor in qualitative comparisons. > > Why in the world would I care about invisible loss? That's my thinking on a lot of this. If you have to blow up a portion of a print 10 times larger than you'd ever print it to see something, why should I care? SignatureStacey > A photographer friend of mine processes everything in Photoshop in 16 bit > RAW. When he wants to have a print made he changes the image to an 8 bit [quoted text clipped - 4 lines] > might > as well have never started in 16 bit in the first place. 16bit is good when using a large color space doing edits which are adjusting color etc. If you want to see an amplified results of using too few bits for a color space, drop down to lower than 8 and do some color edits! :-) SignatureStacey >16bit is good when using a large color space doing edits which are adjusting >color etc. If you want to see an amplified results of using too few bits >for a color space, drop down to lower than 8 and do some color edits! :-) How? Most image programs don't do real color manipulations at anything less than 8 bits per channel. 8 bits is sufficiently low enough to demonstrate catastrophic loss. Take a full-range image, make one copy 16-bit and one 8-bit. Then, do a Levels with the output set to 0 to 2, then do it again with the input at 0 to 2. One looks like it hasn't changed, the other is totally trashed. Signature<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<> John P Sheehy <JPS@no.komm> ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>>< >>16bit is good when using a large color space doing edits which are >>adjusting color etc. If you want to see an amplified results of using too [quoted text clipped - 3 lines] > How? Most image programs don't do real color manipulations at anything > less than 8 bits per channel. Old ones do.. It's where I first noticed this was atempting edits on low color bit images years ago.. SignatureStacey >>>16bit is good when using a large color space doing edits which are >>>adjusting color etc. If you want to see an amplified results of using too [quoted text clipped - 6 lines] >Old ones do.. It's where I first noticed this was atempting edits on low >color bit images years ago.. OK, you must be talking about 15/16 bit (total for all channels) "high color" modes. I was thinking about the palette-based modes. Did the programs actually use 15/16 bit data internally, though, or were they just displaying 24-bit (8 per channel) internal data on the screen? Signature<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<> John P Sheehy <JPS@no.komm> ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>>< |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.