Re: Color Conversions and Dither
Re: Color Conversions and Dither
- Subject: Re: Color Conversions and Dither
- From: "Roy Harrington" <email@hidden>
- Date: Sun, 18 May 2008 22:59:08 -0700
On Sun, May 18, 2008 at 5:56 PM, Graeme Gill <email@hidden> wrote:
> Roy Harrington wrote:
>
>> evidence of this is difficult if not impossible. My gut feeling was
>> that since the printers
>> themselves (Epsons) were essentially just 2-bit at the dot level an
>> intermediate stage of
>> 16-bit --> 8-bit --> 2-bit would not hurt versus 16-bit --> 2-bit
>> directly. So rather than
>
> That's a bit misleading. The screening does convert to very low
> bit, but it doesn't necessarily loose 6 bits of information, the
> information is just transformed from intensity levels to spatial
> information. The loss of information (if any) in the screening
> depends on the screening algorithm. In classical line algorithm
> it depends on the line spacing. In something like a stochastic
> screening, it depends on the cell size. For instance, stochastic
> screening to 2 bit is capable of representing 2^16 levels using
> a 128 x 128 cell.
Sure, there are a lot of considerations. My comments are very
specifically targeted for the data that must pass through the OS
on the way to the print driver which is often restricted to 8-bits/channel.
As noted, the transformation of intensity levels to spacial info makes
a major contribution.
Roy
>
> The important aspect is actually what color space we're in.
> In a well behaved (that is visually linear, where any 1 bit difference
> in color value is a proximately visually uniform) space, 8 bits
> per component is usually quite adequate. In something like
> an uncalibrated printers device space, particularly if it's
> an ink jet with a high dot overlap factor, then 8 bits is
> going to be completely inadequate.
>
> So a high quality print path will actually be prepared to
> boost the bit depth in the process of transforming from
> one colorspace to another (ie. through a calibration curve),
> if it is attempting to maintain adequately low quantization
> levels in each colorspace. Not all printer drivers pay attention
> to such detail though.
>
> Note that if you're driving the printer via the vendors
> "RGB" printer interface, you're essentially driving
> it in an "sRGB" like space, in which their driver is
> doing a lot of work to linearize the device, and make
> the color space behave reasonably.
>
> Of course, doing all your work in 16 bit gives much greater margin
> for error, dynamic range, and freedom from worry about exactly which
> colorspace things are in.
>
> Graeme Gill.
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden