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: Stephen Lawrence <email@hidden>
- Date: Sun, 25 Jun 2006 02:07:20 +0100
On 24 Jun 2006, at 20:52, Robert L Krawitz wrote:
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).
Hi Robert, yes we are in agreement on that. You want more than 8-bits
internally in your linearisation and halftoning for many print system
combinations. My point was agreeing with Graham that 8-bit *input*
into linearisation can produce output without quality compromises.
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.
Why is it so large? Does Gutenprint have its own weave algorithm?
Interlacing, to substitute a generic term for Epson's own Microweave,
generally requires only a band of limited height and therefore size.
Assuming Gutenprint has its own algorithm you ought to be able to
reduce that footprint drastically.
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.
Yes if the halftoning is implemented using a threshold array then
expanding to 16-bits will not massively expand the size of an already
small halftone. The example that sprang to mind as I wrote my reply
was an implementation using a bitmask. In that case a 256x256 bitmask
jumps from 2MB in size for 8-bit to 512MB for 16-bit uncompressed!
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.
Personally I think the "sweet spot" in a *printer driver or RIP*
currently still lies with harnessing calculation in greater than 8-
bits where necessary to the performance of an 8-bit pipeline
elsewhere. As I can't see what customer issue a completely 16-bit
pipeline would address at the moment. That said that will most likely
change down the line as workflows and printers evolve. 16-bit input
becoming the norm and print gamuts large enough to stretch 8-bit
would be an obvious tipping point. But if the architects of
Gutenprint have decided to go 16-bit throughout now then all power to
your elbow. What does Gutenprint do with 8-bit input?
Regards,
Steve
_______________________________________________
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