Re: Decent results with Gutenprint - the poor man's RIP.
Re: Decent results with Gutenprint - the poor man's RIP.
- Subject: Re: Decent results with Gutenprint - the poor man's RIP.
- From: Graeme Gill <email@hidden>
- Date: Wed, 21 Jun 2006 12:51:17 +1000
edmund ronald wrote:
There was considerable advantage in using more than 8 bits
out of all this, ie. for the raw device channel value to the
screening.
WHAT DOES THIS MEAN ? I don't quite understand - can you explain or
expand a bit ?
When driven directly (ie. not by the Manufacturers drivers), an inkjet
printer is basically sent the 1's and 0's that determine whether a dot
of ink is placed on the page. (For printers with multiple dot sizes,
there might be more than a single bit per dot, but the principle remains
the same.) A driver or RIP has to produce these 1's and 0's. Generally
how this is done is to use a screening algorithm of some kind. It might
be a classical clustered dot algorithm, or it might be something more
stochastic like error diffusion or a stochastic threshold screen. The screening
algorithm turns a raster composed of continuous pixel values (0.0 .. 1.0, 0 .. 255,
0 .. 4093, 0 .. 65535 etc.) into the 1's and 0's that determine whether
a dot is printed or not. If you look at the transfer curve that you get through
the screening algorithm from raw device value to density/L* value out,
particularly at high resolution, it is highly non-linear. There is massive
amount of dot gain, and when you feed "1.0" into the channel, you get
too much ink on the page. The usable range might only be from 0.0 to 0.3
(30% of the total raw device value range), and even over that range, the
response is highly non-perceptualy linear.
So if you were to encode the raw device values using 8 bits (0 .. 255), then
you would only be using a small portion of it (0 .. 90 say), and the step
size would be very obvious, particularly near white, so this is a bad approach.
12 or 16 bits is needed to encode the raw device values.
If a linearisation LUT is used to convert the driver/RIP input values,
then this can both apply the per channel ink limiting, and linearise the response
curve. It's pretty simple to lookup an 8 bit input and translate into
a 16 bit raw device value. With a good linearisation curve, the
8 bit steps will be close to imperceptible, even near white, and
the profile has a good space to do it's stuff in.
In many printers that use light inks, there will also be a separation
applied, to produce (say) the Dark Cyan and Light Cyan raw values from
the input Cyan channel, which can be combined into the linearisation
lookup.
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