Ad
Ad
Ad
Pages: « 1 [2]   Bottom of Page
Print
Author Topic: Is 8-bit enough for OUTPUT quality?  (Read 7933 times)
Schewe
Sr. Member
****
Offline Offline

Posts: 5255


WWW
« Reply #20 on: September 01, 2009, 05:49:29 PM »
ReplyReply

Quote from: madmanchan
My opinion is that the original question needs to be posed more carefully. Guillermo wants to know whether 8 bits is enough for output, not editing. But what, exactly, does the term "output" mean? To me, the term "output" really means the final space after which no additional color transformations are applied by devices (hardware or software) prior to viewing.


Output should mean at the print head _AFTER_ all manner of color transforms have occurred or at the display, same spec. At the moment, only 3rd party rips and certain drivers (the Epson Mac drivers or the Canon plug-ins) can even handle more than 8 bits/channel because for Windows, there is no wider bit pipeline (talk to MSFT about that if it bothers you).

When it comes down to the display, the question is what is the computer feeding the system's display pipeline with and what is the vid card and/or display doing with the data?

In terms of 8 bit at the print head, yes, I do think that 256 actual levels per channel is enough for pretty much anything other than perhaps synthetic gradient blends that have no photo grain or noise built in. But the real question is what constitutes the actual output? Is it _AFTER_ any and all color space and gamma adjustments have been made? If so, prolly yes for photos...possibly not for Illustrator type gradations and tints...
Logged
madmanchan
Sr. Member
****
Offline Offline

Posts: 2100


« Reply #21 on: September 02, 2009, 03:03:52 PM »
ReplyReply

Hi Mark, yes, you understood correctly. I think banding can certainly be introduced at both of those steps: i.e., the color transformation via the printer profile, as well as the color math inside the driver. I cannot really comment on the latter, knowing very little about how the internals of modern print drivers work -- though I would guess it is rather unlikely to be problematic.

It is usually quite easy to avoid the former problem. For example, if you take a raw file in LR and hit the Print button, LR will render the raw file to a 16-bit in-memory image (you can think of this as a 16-bit ProPhoto TIFF that is never written to disk as a file) and does the printer profile color math on it, using the 16-bit data in the ICC profile (assuming your printer profile is 16 bits -- many are). I have not seen a case where visible banding in the print was due to this part of the processing pipeline.

Cheers,
Eric
Logged

Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6767


WWW
« Reply #22 on: September 02, 2009, 06:30:19 PM »
ReplyReply

Quote from: madmanchan
It is usually quite easy to avoid the former problem. For example, if you take a raw file in LR and hit the Print button, LR will render the raw file to a 16-bit in-memory image (you can think of this as a 16-bit ProPhoto TIFF that is never written to disk as a file) and does the printer profile color math on it, using the 16-bit data in the ICC profile (assuming your printer profile is 16 bits -- many are). I have not seen a case where visible banding in the print was due to this part of the processing pipeline.

Cheers,
Eric

Thanks Eric, that is most interesting about the LR pipeline - it seems kind of like a RIP?  I wonder whether Epson's own profiles or the ones I roll with my Pulse Elite and accompanying X-Rite software are indeed 16-bit and whether there is a way to know for sure. Also I'm wondering whether the process you describe for LR is also valid for PS. E.G. I'm printing from CS4 because I still need to make the final tweaks under softproof   I must say, though, I very seldom have a case of banding on paper, even with sky gradients I make from time to time and which can begin to show slight evidence of banding on the display while in 16-bit PS ProPhoto working space.
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
madmanchan
Sr. Member
****
Offline Offline

Posts: 2100


« Reply #23 on: September 02, 2009, 11:20:19 PM »
ReplyReply

Hi Mark, yes, subtle sky gradients to tend to show banding on displays. This is a good example of how 8 bits isn't enough for an intermediate representation (the intermediate representation being the data sent to the video card; the image data then typically undergoes further encodings ...)

Epson's provided profiles are 16-bit. I'm pretty sure all of the stock profiles provided by the popular printer makers are 16-bit, though I haven't personally checked them all.
Logged

papa v2.0
Full Member
***
Offline Offline

Posts: 186


« Reply #24 on: September 03, 2009, 08:00:28 AM »
ReplyReply

Hi
Interesting thread.

can I ask what is the image history, ie from capture to the example posted.

8 bit should be sufficient for most applications. 3*8 bit give 16777 million colours and it is suggested that we see only 10 million (Judd and Wyszecki,1975; Pointer and Altridge,1998; Pointer, 1998). Although having said that the reproduction of a continuous tone greyscale has its problems, partly due to the eyes unequal response to different parts of the greyscale compared with equal luminance luminance quantization for example.

So I wonder where the problem is lying.

Logged
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6767


WWW
« Reply #25 on: September 03, 2009, 08:33:08 AM »
ReplyReply

Quote from: papa v2.0
Hi
Interesting thread.

can I ask what is the image history, ie from capture to the example posted.

8 bit should be sufficient for most applications. 3*8 bit give 16777 million colours and it is suggested that we see only 10 million (Judd and Wyszecki,1975; Pointer and Altridge,1998; Pointer, 1998). Although having said that the reproduction of a continuous tone greyscale has its problems, partly due to the eyes unequal response to different parts of the greyscale compared with equal luminance luminance quantization for example.

So I wonder where the problem is lying.

The issue isn't how many colours you can see. It is about the number of levels of tonality needed to protect against posterization or banding in the transformation process, because levels get lost with tonal transformations, so the more you start with the lower the risk
« Last Edit: September 03, 2009, 09:43:14 AM by MarkDS » Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6767


WWW
« Reply #26 on: September 03, 2009, 09:45:00 AM »
ReplyReply

Quote from: madmanchan
Hi Mark, yes, subtle sky gradients to tend to show banding on displays. This is a good example of how 8 bits isn't enough for an intermediate representation (the intermediate representation being the data sent to the video card; the image data then typically undergoes further encodings ...)

Epson's provided profiles are 16-bit. I'm pretty sure all of the stock profiles provided by the popular printer makers are 16-bit, though I haven't personally checked them all.

Thanks Eric. Sounds right. I should try to find out whether the X-Rite Pulse Elite profiles are also 16 bit - one would think so.

Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
Schewe
Sr. Member
****
Offline Offline

Posts: 5255


WWW
« Reply #27 on: September 03, 2009, 10:14:10 AM »
ReplyReply

Quote from: MarkDS
I wonder whether Epson's own profiles or the ones I roll with my Pulse Elite and accompanying X-Rite software are indeed 16-bit and whether there is a way to know for sure.


It's not the profile that determines the bit depth of the color transform, it's the CMM. ColorSynce and Windows have CMMs that are 16 bit but if you do color transforms in Photoshop or Lightroom using the Adobe ACE CMM, the transform is done in 20 bits/channel precision, not limited to 16 bits. So, if you are using Photoshop or Lightroom to handle the color profile transforms and you are starting in 16 bit, the profile transforms are done 16>16 in 20 bits then reduced to the bit depth of the print pipeline AFTER the transform. In the case of Leopard and certain printers, that's 16 bit. On Windows it's currently limited to 8 bits. But it doesn't hit 8 bits till AFTER the color transforms.
Logged
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6767


WWW
« Reply #28 on: September 03, 2009, 10:44:23 AM »
ReplyReply

Quote from: Schewe
It's not the profile that determines the bit depth of the color transform, it's the CMM. ColorSynce and Windows have CMMs that are 16 bit but if you do color transforms in Photoshop or Lightroom using the Adobe ACE CMM, the transform is done in 20 bits/channel precision, not limited to 16 bits. So, if you are using Photoshop or Lightroom to handle the color profile transforms and you are starting in 16 bit, the profile transforms are done 16>16 in 20 bits then reduced to the bit depth of the print pipeline AFTER the transform. In the case of Leopard and certain printers, that's 16 bit. On Windows it's currently limited to 8 bits. But it doesn't hit 8 bits till AFTER the color transforms.

Hi Jeff, and thanks for those clarifications. I guess from what you are saying it would be fait to conclude that because any math likely to impact on the banding issue is done before the printer driver in 16-bit, we've got that protection, then the rest depends on the printer driver, which is 8 bit on most of our Epsons anyhow; so we wouldn't worry about the Windows constraint unless we owned one of those 16 bit printers. Is that correct?

Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
JeffKohn
Sr. Member
****
Offline Offline

Posts: 1671



WWW
« Reply #29 on: September 03, 2009, 11:25:55 AM »
ReplyReply

Quote from: MarkDS
Hi Jeff, and thanks for those clarifications. I guess from what you are saying it would be fait to conclude that because any math likely to impact on the banding issue is done before the printer driver in 16-bit, we've got that protection, then the rest depends on the printer driver, which is 8 bit on most of our Epsons anyhow; so we wouldn't worry about the Windows constraint unless we owned one of those 16 bit printers. Is that correct?
Yes it's correct in theory, but it doesn't mean that the transform to the printer profile will never cause banding. Even 20-bit precision won't guarantee that you avoid banding if it's a crummy printer profile. The quality of the printer profile is definitely a factor.
Logged

Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6767


WWW
« Reply #30 on: September 03, 2009, 11:44:33 AM »
ReplyReply

Quote from: JeffKohn
The quality of the printer profile is definitely a factor.

Sure, I would expect so.

Mark
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
Pages: « 1 [2]   Top of Page
Print
Jump to:  

Ad
Ad
Ad