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 21:48:09 -0400
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.
That's probably true in most cases. There's a problem if there's a
profile between the input and the linearization. If the profile is
monotonic and not the identity, it will result in some distinct input
colors being mapped to the same output color. That's not good.
> 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.
Microweave (at least as I see it used -- in the programming reference
manuals) refers to the printer performing the interlacing internally.
The weave/interlace algorithm does require a band of limited height.
The problem is that at high resolution, on a printer with a very wide
head and with wide output, that still totals quite a lot. For
example, consider printing at 5760x2880 DPI on 13" wide paper (more or
less worst case) on an Epson R1800. In order to hold a single band,
we need
5760 (hres) *
2880 (vres) *
13 (width) *
2 (bits/dot) *
7 (inks) /
8 (bits/byte)
This works out to 377 MB. If we are printing near the top or bottom
of the page, we need twice that because the weave pattern is different
near the top and bottom and we need extra space to hold these special
passes. I feel like I've missed something here because the numbers
I've gotten from my weave calculations are a bit more than that, but
maybe not.
> 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!
Can you explain that -- I'm not familiar with that way of doing it.
> 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?
I committed full 16-bit support to the core in 1999, although it
wasn't until a couple of years ago that everything in the package
could handle it. I figured that eventually we'd (or really I -- it
was just my personal hack back then because I wanted to print photos
under Linux on a Stylus Photo EX) really need it, and I wanted to be
ahead of the curve.
1999-10-17 <email@hidden>
Files: print-escp2.c (1.6) (+27 -40)
print-pcl.c (1.5) (+28 -25)
print-ps.c (1.4) (+29 -21)
print-util.c (1.8) (+814 -4)
print.h (1.5) (+65 -35)
16-bit everything (untested)
Gutenprint upsamples 8-bit input to 16 bits (multiplying by 257).
When the input is 8 bits, the per-channel lookup tables are 256 16-bit
entries.
However, the real reason I advocate a 16-bit pipeline *right now* is
to protect against loss of precision in intermediate results. A few
roundoffs in the chain and you might lose a bit or two of accuracy.
If the working precision is 16 bits we might be down to 14 bits or so
of accuracy, which is not a big problem. If the pipeline is 8 bits,
and each stage of the pipeline rounds back to 8 bits, we might be down
to 6 bits or thereabouts of accuracy. THAT'S a big deal. If you want
8 bit inputs and outputs, the intermediate stages need to have more
than that.
In other words, what's happening here is that you're passing an 8-bit
file through color management, which is chopping its output back to 8
bits. There goes some accuracy, when there really isn't any to
spare.
--
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