Re: HP DeskJet 890C: poor performance on Linux vs. Windows
On 31-Jul-98 Martin Weinberg wrote:
> I used GIMP to view the original images and convert to postscript.
> They were both jpeg and gif originally. Similar results were
> obtained by converting with XV.
>
> Hm. Is there a better way to do the conversion?
That is similar to how how I would do it too, except that I use ImageMagic.
However, now you have a double conversion going on: jpeg|gif -> PS ->
HPwhatever. There is scope for degradation at each stage.
The great merit of using a custom driver is that it has been written with the
express purpose of doing a good job for each specific graphic file type and
the specific hardware it was written for (e.g. jpeg->HPDJ890C, gif->HPDJ890C).
Therefore a lot of the hard work of discovering exactly what compensations are
required has already been done by the manufacturer. There is nothing magic
about Windows in this context: it is merely a channel by which the printer code
generated by the driver reaches the printer. The real tuning required for the
printer is built in to the driver.
To return to the Linux problem. Though I use a native PS printer for production
B&W work I also have an Epson Stylus Color 600 for colour (mostly for digital
photography: the cat looks great). For jpeg.etc->PS I use "convert" which
actually is a part of ImageMagic but by using it standalone you have direct
access to its options. I have also tried the GIMP and I think I marginally
prefer using convert. For the moment we'll suppose we have a good PS version of
the image; but we'll have to come back to this supposition.
For PS->Epson I use ghostscript 5.10 which has a lot of different drivers for
the Epson Stylus Color series. I haven't used an HP colour printer so can't
comment directly on that. However, under ..../ghostscript/5.10/doc/hpdj you
will find files README.hpdj and gs-hpdj.txt, which suggest that only HPDJ
explicitly supported by the hpdj drivers go up to 855C, not 890C though it
claims that no PCL3 printer has failed to work.
What does seem to be missing with the the HPDJ drivers is the facility which is
provided with the Stylus Color drivers: you can edit the colour transformation
maps yourself in the .upp files and (less so) in the older DEVICE=stcolor
drivers -- AND you may like to note that the new .upp drivers are designed to
be "universal" though in a development stage at present. Read the WHOLE of
..../ghostscript/5.10/doc/drivers.txt to see what is going on -- it's a bit
confusing. A relevant extract (re .upp files) is the following:
QUOTE
uniprint -- ESC/P, ESC/P2 and PCL/RTL-Driver by Gunther Hess gunther@elmos.de
=============================================================================
This driver is intended to _become_ a unified printer driver. If you
consider it ugly, please send me your suggestions for improvements. The
driver will be updated with them. Thus the full explanation of the drivers
name is:
Ugly- -> Updated- -> Unified-Printer-Driver
But probably you want to know, something about the functionality:
At the time of this writing uniprint drives:
NEC Pinwriter P2X (24Pin B/W Impact printer, ESC/P-Style)
Several Epson Stylus Color Models (ESC/P2-Style)
HP-Deskjet 550c (Basic HP-RTL)
Canon BJC 610
It can be configured for various other printers _without_ recompilation
and offers uncompressed (== ugly) SUN-Rasterfiles as another format, but
this format is intended for testing purposes rather than real use.
=============================================================================
UNQUOTE
You might like to try this option.
Now, here comes some theory (very incomplete since it's really only a summary of
experience).
First of all, the jpeg.etc->PS conversion may be more or less good. You have
some control over this according to which converter you choose and what options
you use for it. More later.
Secondly, the PS->HPwhatever (probably PCL) may involve a transformation from
RGB (Red-Green-Blue) colour coordinates to CMYK (Cyan-Magenta-Yellow-Black);
PS->EpsonSTC certainly does. This is where a lot of grief comes in, because the
jpeg.etc->PS translation is RGB, and the relation between RGB and CMYK is not
mathematically precise.
The fundamental difference is that RGB is for "emitting" colours, i.e. "R"
shines Red (as on your monitor) and you see Red. CMYK is for "absorbing"
colours. In theory CMY are complementary to RGB so that an ink which absorbs C
will reflect R. In theory. So CMYK are for printing on paper and viewing by
reflected light as opposed to RGB which are for viewing by emitted light.
In practice the complementary relationship is both physiologically inexact and
dependent on both the quality of the inks and on the quality, absorbency and
"runnability" (i.e. how far does the ink diffuse into it) of the paper.
Therefore your control of the results by mere calculation is loose, and you
need to experiment.
There is a further complication: again in theory a saturated combination of
C+M+Y absorbs everything and should look black. In practice it doesn't, so it
looks instead like rather rich s**t. This is why K (true blacK) is introduced
as a 4th component: where true black is called for, the printer prints in black
ink.
Now have a look at one of the .upp files, say stc600c.upp. You will see four
lines like
-dupBlackTransfer="{ 0.0000 0.0329 0.0706 0.1160 0.2392 0.7955 }"
-dupCyanTransfer="{ 0.0000 0.0452 0.0836 0.1215 0.1493 0.1749 }"
-dupMagentaTransfer="{ 0.0000 0.0602 0.1133 0.1961 0.2945 0.3885 }"
-dupYellowTransfer="{ 0.0000 0.0350 0.0914 0.1567 0.2430 0.2934 }"
These define a non-linear relationship between the intensities of K,C,M,Y
requested and the densities of the respective inks printed (i.e. they control
the colour requests sent to the printer). By varying these (not a trivial task)
you can aim for better results and, with luck, you will even get very good
ones. Note that (see documentation) there is a family of drivers for each
printer, one driver for each paper quality, which are supposed to give good
results for the corresponding paper types (though I have found this not to be
always so).
In fact, for plain ordinary paper (the cheap sort you put in a laser printer or
photocopier, on which I do my routine printing) I have found that the older
driver invoked by -sDEVICE=stcolor in gs gives better results than the .upp
drivers; you can also to some extent tune the colour densities on these (see
documentation). On the other hand, I find that the .upp drivers, suitably
tuned, work best for the special papers you can buy for the colour printers.
In fact, on my Epson Stylus Color 600 I use plain paper for "rough draft",
Xerox Ultra White Inkjet Paper (relatively cheap) for "good draft" or for any
production where really good finish is not required, Epson Photo Quality Ink
Jet Paper (quite expensive, about $0.10 per sheet) for good finish, and Epson
Photo Quality Glossy Paper (very expensive, about $1 per sheet) for the very
best (excellent for photos). (In passing, don't forget that "White" means "no
mark on the paper": it's actually the only theoretically possible way to get
white with CMYK, as opposed to RGB where white is 100%R + 100%G + 100%B.
Therefore "White" is what the paper says it is, and if you compare ordinary
printer paper with one of the high-quality papers above you will see that
ordinary white paper is far from being really white. The glossy papers also
enhance brilliance because they reflect non-absorbed light back through the
ink and give it a luminous quality).
For each of these I have experimentally tuned a corresponding driver according
to the above principles. Results are usually pretty good, but various factors
(see below) mean that this is not always so.
The above discussion implicitly supposes that there is one image in PS which
you are trying to print nicely on your Color Printer. If you could be sure of
getting a correct RBG rendering in PS such that the conversion to CMYK gave
good results on the colour printer,then you would be home and dry every time.
You certainly do not want to re-tune your RGB(PS)->CMYK for each and every
print.
Now we go back to square 1 (you were warned, above!). You start off with, say a
jpeg file (say image.jpg). You could convert this straight into PS using xv,
GIMP or Imagemagic without playing around, and carry on from there with gs.
But don't forget that you can also use these tools to adjust image.jpg (work on
a copy rater than the original) so as to change the relative colour values, the
brightness, the contrast, the dithering and the smoothing etc. THIS IN FACT IS
THE REALLY CRUCIAL PHASE, prior to feeding through to the gs conversion and the
pre-tuned printer driver.
So I'm supposing that you already have printer drivers tuned to reasonably good
general performance for different paper types (do this using non-demanding
images, i.e. try to strike the best performance you can get for "average
middle-of-the-road" images). Don't rush this; it will take some time, but doing
it right in the first place is the key to being able to flexibly tune the
source image itself in order to get really good results.
Next, remember that when you are using any of the image manipulation tools to
alter the characteristics of an image you will be viewing the results on
screen. This is a luminous ("emitting") RGB medium. What you see on screen is
NOT what you will get on your reflective ("absorbing") CMYK paper. So you will
have to learn by experiment and experience how what you see on your screen
relates to what will get printed on the paper. You may be able to alleviate the
mismatch somewhat if you can adjust the "gamma" on your monitor ("gamma" is a
parameter intended precisely for this purpose: in theory, in fact, every
monitor in a graphics workshop should be capable of being adjusted so that the
same graphics file will display indistinguishably on every screen).
To sum up: You have to deal with the following stages in printing from a
graphics file to paper (the ** line is where you expect to do the major part of
any tweaking needed by the particular image):
original jpeg | gif | etc
-> modified jpeg | gif | etc (image manipulation software, viewed on screen)**
-> PS file (image software, options allow some variation)
-> printer command file
using gs plus printer driver for printer+paper, tuned for good results
with "typical" image. Try test prints on fair-quality paper, move to good
quality paper when you think you're nearly there, and to high-quality paper
when it looks almost right and maybe 1 more adjustment might be needed.
As I said at the beginning, there is a lot of hassle, some once-and-for all and
some potentially every time, in the above which has been by-and-large worked
out for you by the manufacturer and embodied in the supplied printer driver,
which essentially goes straight from the first (or maybe second) line to the
last for each graphics file type and each paper type, with usually "image type"
(i.e. portrait, outdoor scene, pastel shades, large blocks of solid colour,
...) selectable when you start the driver up.
When you fall back on the Linux resources, which have not been explored with
such thoroughness, you have to do a lot of the work yourself. The above account
summarises my own experience in trying to divide the hassle between the
once-and-for-all and the per-image. It works very well fairly often, well enough
most of the time, and leads to trouble and many test prints sometimes. I'm sure
I could do better ... !!
You may find that the most difficult images to get right are those in which one
primary color (R/G/B) dominates, if your once-and-for-all tuning has been done
for images which tend to combine a wide spectrum with no large blocks of solid
colour; you may prefer trying (or you may additionally try) to optimise this
tuning for images with large blocks of primary colours -- this is an
alternative route which I have not explored. Another snag you may encounter
with the newer .upp drivers in gs is that the dithering produces little
polygonal blocks of uniform colour where the original colour shading varies
slowly and smoothly (as in drapes of clothing under certain lighting). This
arises from the discretisation used in the dithering algorithm, and I suspect
that putting it right may involve fiddling with the gs source code and
recompiling ... When this is a problem I fall back on the older drivers, which
don't seem to suffer from it.
Good luck.
Ted.
PS to all on debian-user: With regret, I do NOT wish to get involved in
person-to-person discussions about the details of getting this right on each
individual's printer etc. It is potentially an involved and drawn-out process
and I do not have the time to get drawn into it. Apologies in advance, but I do
hope that the above is helpful to some of you.
--------------------------------------------------------------------
E-Mail: (Ted Harding) <Ted.Harding@nessie.mcc.ac.uk>
Date: 01-Aug-98 Time: 00:47:23
--------------------------------------------------------------------
--
Unsubscribe? mail -s unsubscribe debian-user-request@lists.debian.org < /dev/null
Reply to: