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: Mon, 26 Jun 2006 22:23:17 +0100
On 25 Jun 2006, at 02:48, Robert L Krawitz wrote:
Microweave (at least as I see it used -- in the programming reference
manuals) refers to the printer performing the interlacing internally.
It might be worth taking a look at the print files.
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.
Hand on heart it's been a few years since I was anywhere near an
interlacing algorithm and of course the stats will depend on the
algorithm used but the height of your band seems way taller than I
recall being needed. At most I thought you would only need a little
over head height and with peizo there are not many nozzles to make
that large. My advice, for whatever it is worth, on the top and
bottom of the page would be to think about how the three phases
transition. If you architect around that you ought not need to double
the band.
Can you explain that -- I'm not familiar with that way of doing it.
I had a real quick look on the web for a reference but couldn't find
you a good one. If I come across anything I'll pass it on. It may
well be in Ulichney's reference but my access to that book is
something I left behind with the old job unfortunately.
In a bitmask you have a unique mask or tile for each intensity level.
So for a 8-bit 256x256 bitmask halftone you have 256 256x256 masks.
Bitmasks have two useful attributes compared to a threshold array.
Firstly, the uniqueness of each mask means you can use the most
optimal dot placement for the intensity level the mask represents.
Secondly, you can avoid some of the IP issues around threshold
arrays. Their principal disadvantage is that for high intensity
ranges such as 16-bit they are not space efficient uncompressed
compared to threshold arrays.
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.
I can see where you are coming from, but the only effective round
down is in output from colour matching and try as I might I was never
able to see the difference on the page when I made comparisons. As
soon as you hit linearisation in a well designed system you are
higher than 8-bit from there on anyway. Although of course conversely
in halftoning you are actually doing data reduction <L>.
Well I think we are pretty well off topic now so should probably not
take this any further. On the list anyway.
Best Wishes,
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