chucknorcutt@xxxxxxxxxxxxxxxx wrote:
> One first needs to differentiate based on an 8 bit file of what type? A TIFF
> or a JPEG? The reason is that there are two things in question here. One is
> resolution and the other is color detail (meaning subtle differences in
> shade).
>
> An 8 bit TIFF file, whether uncompressed or compressed contains 8 bits of
> color info for every pixel that was represented in the original raw file.
> And 8 bits of color info for each RGB pixel is more color detail than can be
> printed by any existing print process on any existing paper. So, the short
> answer for a TIFF file is that there is no difference at all between an 8 bit
> and 16 bit file used to make a print. That assumes, however, that any
> editing of pixel brightness was done in 16 bit form before conversion to 8
> bit. But, for editing at the pixel brightness level, there is a definite
> difference between 8 and 16 bit. Keep your intermediate editing files in 16
> bit form and your final output files in 8 bit form.
>
I am not entirely convinced of this. I have no empirical data
whatsoever. My processed files are saved as 16 bit PSDs and that's what
I print from. Doing my own comparisons tests sounds like way more time,
cost and effort than just adding disk space. With terabyte disks rapidly
approaching $100, I just can't see the point in tossing valid image data
based on storage constraints.
As a matter of theory, there are reasons why 16 bit input to the
printing process could yield more accurate color in the print. A lot
happens between the input file and the finished print, and there is room
for significant differences between 8 and 16 bit processes in that path.
First, the printer is a CYMK device and the input image for us is
usually RGB. If you get into soft proofing in PS or other printing
apps., you will see that the conversion may have a significant effect on
color tonality. The RGB image should have a color profile and a color
gamut and the printer/ink/paper combo likewise should have a profile
(often hidden in the driver and not named as such) and will have a quite
different color gamut.
So one thing that must be done as part of the process is remapping the
image to the new gamut via profiles. As this involves the same sort of
modifications of tonal values as many editing functions, the same
problems can occur as noted in your last post on the subject, holes and
piles, lack of subtlety in some tonal transitions, etc. If the app that
does this conversion operates in 16 bit, the result will be at least
theoretically better with a full 16 bit input. PS does it in 16 bit, as
I'm sure the high end RIPS do. Whether other printing apps, like Qimage,
and which manufacturer drivers for which models do or don't, I don't know.
Second, do we really know that contemporary high end consumer- low end
pro printers are actually 8 bit down inside? Most of them now have 6-8
ink colors and some have variable droplet sizes and drop pitches. So
lets assume for fun a printer with eight inks, two droplet sizes and
fixed pitch. Whatever the input, the actual data streams that drive the
heads are 256 x 8 x 2 = 4096 combinations.
I'm not a theoretical mathematician, and don't know any way to relate
this to input file bit depth. I can calculate that it's the same number
of different values as contained in a 12 bit image file.
Third, many printing apps, at least RIPs and Qimage, do sharpening and
sometimes tricky things like detail enhancement based on individual
printer characteristics. Once again, this involves changing individual
pixel values, again with the interpolation and integer rounding
problems. I recall at least one app, perhaps Qimage (?), that says it
does all intermediate calculation steps in floating point, only
converting to integer values as the last step before sending the image
to the printer itself, so that multiple processing steps won't compound
the problem.
In any case, I am convinced that saving final files for print in 8 bit
RGB versions for long term storage and dumping any higher depth is not
adequate to promise the best possible current print output, let alone
future printed output.
Moose
==============================================
List usage info: http://www.zuikoholic.com
List nannies: olympusadmin@xxxxxxxxxx
==============================================
|