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: Robert L Krawitz <email@hidden>
- Date: Mon, 19 Jun 2006 07:26:18 -0400
Date: Mon, 19 Jun 2006 14:14:20 +1000
From: Graeme Gill <email@hidden>
Robert L Krawitz wrote:
> That's fine, as long as your application supports it (most Linux/UNIX
> apps don't), and as long as the data path is 16 bits/channel. If the
> path is 8 bits/channel, and you're doing color management in the
> application, you're losing a lot of information. Color management
> basically performs a mapping; if the output space is 8 bits/channel,
> and the mapping isn't 1-1 (which normally it won't be), you might wind
> up with stair stepping.
For much work, 8 bits per component is entirely adequate, if it is
in a well behaved color space. If the printer driver doesn't have
appropriate linearisation curves to 12 or 16 bits internally, and
the profile is exposed to most of the extreme dot gain that high
resolution inkjet printers natively have, then yes, you've then got
to push back 12 or 16 bit precision into the profile (and the
profile quality is generally compromised if it has to cope with
extreme channel non-linearity). So if you are saying that
Gutenprint needs 16 bits/component input to get good results, then
I see that as a Gutenprint problem. It needs some decent
calibration curves for each printer.
I believe that 8 bits/component is enough in many cases also. I would
expect it would break down somewhat in nonlinear regimes such as when
the ink load is high, in dark desaturated regions and colors other
than pure C, M, or Y. I've seen non-monotonic behavior in such cases
(the output actually appears to get lighter with increasing ink) if
the ink quantity isn't right. If you're trying to do cross-channel
ink limiting in 8-bit space you're going to lose precision.
I also don't believe that Gutenprint (or any other driver, for that
matter) will ever have perfect linearization curves for each and every
printer model, paper type, and ink set (for people using third party
inks). Also, printers are mechanical devices and are subject to wear
over time, which may change the amount of ink deposited.
16 bits/channel really isn't that expensive these days. I'm not
talking about images themselves being 16 bits, although that's
desirable for other reasons (such as image editing). If you're
willing to trade off speed vs. quality -- a perfectly legitimate
tradeoff as a matter of individual choice -- then go ahead and use 8
bits. If you want top quality printing things like blue skies --
where smooth gradients are most likely to show up stair stepping --
then you may prefer a different tradeoff. Personally I think it's
poor practice to use 8 bits for intermediate representations; the
cumulative precision loss after a few steps will add up very quickly.
--
Robert Krawitz <email@hidden>
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail email@hidden
Project lead for Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
_______________________________________________
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