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: Sat, 24 Jun 2006 15:52:13 -0400
From: Stephen Lawrence <email@hidden>
Date: Sat, 24 Jun 2006 18:44:14 +0100
Graham Gill wrote:
> 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.
Yes, that was my experience engineering inkjet printer driver
colour systems for my previous employer. Sure you want greater than
8 bit internally for a few key areas. I found that typically
somewhere around 10 to 12-bits were required in the dot gain
correction and halftoning for the reasons you explain. But for
input to the driver and generally internally 8-bit produces great
output assuming the input image is good. Its a case of using the
appropriate bit depth where needed. For example, going too 16-bit
internally can be very painful in some circumstances. The large
memory foot print that would be required for a halftoning mask
would be one example that springs to mind.
I don't see how a true 8-bit linear scale *internally* is going to
work very well -- even 1/256 of maximum ink density produces a
surprisingly dark tone (of course, you could still use an 8-bit dither
matrix). 12 bits may be enough, but if you're going to do that, you
might as well go to 16 for programming convenience anyway. The acid
test for this is highlight detail in gradients, particularly with a
printer with tiny droplets and/or light inks. If you can see any
stair-stepping at all, either the linearization is wrong or you need
more precision. I've seen too much inkjet output where the first few
steps above zero (or below white, if you prefer) are perceptible.
That shouldn't be the case -- the steps should be completely
imperceptible, or you need more precision. That said, I have no
objection to offering low and high quality modes, so the user can
select a tradeoff. However, if you're going to be printing at
1440x2880 DPI to get a print that looks lifelike, it should *really*
look lifelike.
In my view, the memory footprint issue is overblown, at least for high
quality output. With Epson consumer/prosumer printers, at least, the
real memory consumption is the weave buffer. In very high quality
modes on large pages I've seen that reach 1 GB. In contrast, the
dither matrices we use for ordered dither are about 65000 elements
(tiled, of course). That's negligible these days, when most people
have at least 128 MB in even older computers.
Obviously, there are performance implications involved in going to 16
or 32 bits -- memory bandwidth requirements go up, it's less
cache-friendly, and if you're using vector instructions you may need
to execute more of them. In a lot of cases the right thing to do is
accept a small decrease in quality for more speed, but that depends
upon what you're trying to do. Printers are only going to keep
getting better (larger gamut, smaller drops), and quantization
artifacts will become more visible as people's expectations get
higher.
--
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