My comments were made solely based on the dynamic range of a paper print maxing
out at about 5 stops. I don't expect that to change.
Chuck Norcutt
> -------Original Message-------
> From: Moose <olymoose@xxxxxxxxx>
> Subject: [OM] Re: 16 bit tiff
> Sent: Oct 06 '08 05:35
>
> 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
> ==============================================
>
==============================================
List usage info: http://www.zuikoholic.com
List nannies: olympusadmin@xxxxxxxxxx
==============================================
|