gimp-print-devel

Re: [Gimp-print-devel] 3.2 or 4.0 Release criteria

[Robert L K. <rl...@al...>]

   Date: Wed, 03 May 2000 21:29:22 +0200
   From: Thomas Tonino <tt...@bi...>

   >    > 4) Documentation.
   > 
   >    For the user? In the UI mostly.
   > 
   > That's what I meant about a help system.

   I meant things like 'Highest Quality 1440x720' instead of '1440x720 -
   may not work
   on some models'

The print plugin itself protects against that particular class of
problem; the Ghostscript driver should, but it needs some
infrastructure work to make it happen.

   I have scanned my printouts again.

   They can now be found at:

   http://people.a2000.nl/ztonino/dither/files/1440EnhancedRandomFS.jpg
   The magenta smear is a scanner problem. There is a little hint of the
   shadow near the hairline. It is visible with teh bare eye as well.

   http://people.a2000.nl/ztonino/dither/files/1440HQRandomFS.jpg
   http://people.a2000.nl/ztonino/dither/files/2880x720RandomFS.jpg
   http://people.a2000.nl/ztonino/dither/files/720SoftweaveRandomFS.jpg

OK, I'm confused.  I don't see any artifacts at all when I print it
(either as an EX or as a 600; of course, the EX printout is smoother),
and I'm not sure what artifacts you're referering to.  The missing
magenta and cyan seems to have entirely gone away.  The EX printout is
a bit reddish, but that's about it.  For that matter, I'm not sure
what artifacts you're referring to on your jpegs, either.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] GS6.21 + gimp-print 3.1.4 + STC900 : floating point exception

[Robert L K. <rl...@al...>]

   Date: Wed, 03 May 2000 20:09:36 +0200
   From: Ron van Ostayen <R.A...@Wb...>

   The STC900 is a fast printer and with windows I use the 360dpi output
   often for preview.
   The windows driver requires approx 20 headmovements and 10 seconds to
   print a page, gimp-print requires approx 40 movements and 50!! seconds
   to print a page.

I haven't tuned 360 dpi thus far.  It will be done, but have
patience.  Was this color, or black and white?

   gs -sDEVICE=stp -dMODEL=13 -dQuality=0 -sOutputFile=tiger.prn tiger.ps 

   Floating point exception

   I traced the problem to gdevstp-dither.c: dither_set_ink_spread(void
   *vd, int spread).
   The division at the end of the routine performs a division by 0.

Thanks.  I've fixed it.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] Stylus photo 870

[Jean-Marc V. <ver...@if...>]

> OK, probably the inks are different.  I should put an Epson cartridge
> in my printer and see what happens.

Aha, that would explain. I'm using Epson inks.

>
>    Primarily, red looks too yellow and blue too magenta to me. Gray is
>    not quite gray either. This can probably be fixed by adjusting the
>    respective densities but I haven't tried yet.
>
> I've noticed that too.  Does your gray turn out slightly greenish?

Yup.

>
>    Wow, much better ! I can see color again :) The thresholds look excellent.
>    Looks a bit grainy (Dither=2), but that's photo quality again.
>
> Try adaptive random (dither=4).  I need to take a closer look at this
> grain issue, since the stuff as of this morning seems to have
> regressed a bit.
>

Same thing with dither=4. The rendenring is slightly different but about as
grainy.

I just printed the exact same photograph (a rather difficult one from previous
experience) with my version of gimp-print-3.1.2 (a), with stock 3.1.3 (b),
yesterday's 3.1.3 with dither=2 (c) and with dither=4 (d).
b, compared to others is lousy. That's history.
c and d don't differ significantly. They're good. A bit grainy, slightly
oversaturated, greenish grays (see above).
At this point (a) is best in my opinion. A little less saturated than c,d (but
whether this is worse or better is rather subjective and can be adjusted).
Better grays. Less grainy.

Why (a) is better, I don't know yet, but I might find out by examining the
ouput. I'll report later. I have some thoughts though:

The greenish thing should not be difficult to fix. That's color balance again
and probably involves no specific flow in the algorithms.

One issue in the grain, I've seen it while working on 3.1.2, is what I would
call "undersampling of smallest drops". Because I'm new here I don't know
whether this has been discussed before, sorry. Anyway, I think that smallest
drops in variable size (or smallest ink levels) are so tiny that they don't
fill
in. Take 50% gray. If printed with only smallest dot size black will shoot
everytime at 720 dpi and yet will be grainy because the diameter of the drop is
less than 35 microns. This particularly shows for dark inks (K,C,M). The fix is
to mix in larger volumes of lighter inks (Y, LC, LM) instead and to use some
CMY instead of K (larger volumes again) for midtone grays. The risk then is to
damp the paper. So we need to keep track of the volume of ink laid down. I can
tell for sure that this problem occurs and I can tell where exactly from the
printout, particularly for grays, because it shows despite randomization.

Of course there might be other issues as well.

Let me know if I am too verbose. I realize that the above is rather descriptive
and does not actually fix the problem. I'm still a bit overwhelmed by changes
in dithering in 3.1.3. But I realize they're for the better; dithering plays a
huge role in a good rendering.


-- 
--
Jean-Marc Verbavatz		<ver...@if...>
5, rue La Fontaine		"http://perso.cybercable.fr/verbavat"
F-75016 Paris

Re: [Gimp-print-devel] Compilation error (was: Andy or Mitch, please read the Help forum)

[Robert L K. <rl...@al...>]

   From: Frederic Vivien <vi...@lc...>
   Date: 03 May 2000 12:18:02 -0400

   Answering to rlk, I only had feed-back from him. As I have seen people
   discussing on my problem on this mailing-list, I came here to speed-up
   things, if possible. I have tried to play with the Makefile to have
   the gtk version working (what follows is from memory, as I do not
   write from the computer the experiments were made on). I removed what
   concerned the object files gimp_color_window.o and gimp_main_window.o,
   but the compilation of "print" failed during hte "link edition"
   (sorry, do not know the english expression), because of functions like
   "Image_init". The problem seems to come from the gimp libraries. The
   commands "nm libgimp.a | grep Image_init" and "nm libgimpui.a | grep
   Image_init" returned nothing. Am I doing something wrong here or is
   this the expression of another gimp version compatibility problem ?
   What is the name of the gtk version of the gimp-plugin ?  Any advice
   will be appreciated...

Image_init is from the plugin itself.  I don't know why you'd have a
problem with that -- can you send us the exact error message.  Beyond
that, I'll let the GUI folks answer that.  Supposedly there's a fix
for it in the repository.  I'll probably cut 3.1.4 pretty soon after
someone verifies that the fix works.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] Latest stuff

[Robert L K. <rl...@al...>]

   Date: Wed, 03 May 2000 11:06:57 +0200
   From: Thomas Tonino <tt...@bi...>

   > That sure looks like a registration problem of some kind, doesn't it...

   It does, but the strange thing is that the problem does not seem to have
   a direction. Maybe becuase dithering works two-directional?

It's possible.  I'm just very surprised, though, because I've never
seen anything of the sort.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] 3.2 or 4.0 Release criteria

[regis r. <re...@re...>]

On 03-May-00 Robert L Krawitz wrote:

> Things that only advanced users will ever care about:
> 
> * Printer command (we should somehow try to autodetect that)

What commands? To shown the ink levels in the cartridge? to help to change it?
...

> * Gamma 
> * Dither algorithm
> 
> * Ink type (if you're using e. g. MIS monochrome inks, you're an
>   advanced user, period).

:-)))) 
Others software use standard drivers for printing with theses inks.
They only recommand to use UCR than CGR separation table but it is not
necessary. And to change the saturation.

> Well, a lot of people on the list complain (with justification, I
> think) that the code is poorly documented.  It's a lot easier for
> people to code and submit changes if they understand what's going on.

May be a "how-to" file which explain as the driver works should be interesting
(at least for me). 


-- 
<regisr>       re...@re...     http://www.regix.com/

Re: [Gimp-print-devel] 3.2 or 4.0 Release criteria

[Thomas T. <tt...@bi...>]

Robert L Krawitz wrote:

> But do most users have a clue what it means?  We can always put
> something in the doc discussing how to fine tune the output.

I think gamma is the most needed. You could call it 'darkness' or
'lighter-darker'.

Brightness, as the density of light tints, is much less needed. How dark
the darkest will be is more a function of the paper type. But I must
admit: I have not played with the settings at all.

>    > 4) Documentation.
> 
>    For the user? In the UI mostly.
> 
> That's what I meant about a help system.

I meant things like 'Highest Quality 1440x720' instead of '1440x720 -
may not work
on some models'

I have scanned my printouts again.

They can now be found at:

http://people.a2000.nl/ztonino/dither/files/1440EnhancedRandomFS.jpg
The magenta smear is a scanner problem. There is a little hint of the
shadow near the hairline. It is visible with teh bare eye as well.

http://people.a2000.nl/ztonino/dither/files/1440HQRandomFS.jpg
http://people.a2000.nl/ztonino/dither/files/2880x720RandomFS.jpg
http://people.a2000.nl/ztonino/dither/files/720SoftweaveRandomFS.jpg

I hope the file names are self explanatory.
http://people.a2000.nl/ztonino/dither/files/me2.jpg again is the
original image. Color differences seem to be caused more by the scanner
than by anything else.

With the bare eye, 1440 High Quality Random FS looks best on the 600 -
at least with this picture.


Thomas

[Gimp-print-devel] GS6.21 + gimp-print 3.1.4 + STC900 : floating point exception

[Ron v. O. <R.A...@Wb...>]

Hi all,

I've recently started testing gs+gimp-print with my STC900.
I use this printer mainly to print reports, letters etc. produced with
latex and dvips.  

Unfortunately there are no good, free drivers available for this
printer:
GS supports a general Epson printer (slow and medium quality)
CUPS only provides a medium quality, medium speed driver for a general
Epson printer,
SWPRINT has a fine driver, but this software isn't free.

So, I decided to try gimp-print.
The 1st experiments with gs6.21 + gimp-print3.1.3 were promising:
   Fine print quality, in text, graphics and photos albeit with low
saturation.
However the driver is slow.

The STC900 is a fast printer and with windows I use the 360dpi output
often for preview.
The windows driver requires approx 20 headmovements and 10 seconds to
print a page, gimp-print requires approx 40 movements and 50!! seconds
to print a page.

It would be nice if the low resolution settings of gimp-print were
faster, perhaps with lower quality.  The high resolution settings should
provide the best quality, perhaps with lower speed.

Robert informed me that the latest CVS-version provides better
saturation so I decided to try that one:
gs6.21 + gimp-print 3.1.4

gs -sDEVICE=stp -dMODEL=13 -dQuality=0 -sOutputFile=tiger.prn tiger.ps 

Floating point exception

I traced the problem to gdevstp-dither.c: dither_set_ink_spread(void
*vd, int spread).
The division at the end of the routine performs a division by 0.

I hope someone on this list can use this information to fix the problem.
Best regards,

Ron van Ostayen
 
R.A...@Wb...
Laboratory of Tribology
Department of Mechanical Engineering
University of Technology Delft

Re: [Gimp-print-devel] Color Management for Better Prints

[Karl H. K. <kh...@kh...>]

Sven Neumann <neu...@un...> said: 

> Hi,
> 
> > I just finished my first very rough cut of a color manager plugin
> > for the Gimp. This plugin uses ICC profiles to make color adjustments
> > on images loaded into the application. At this time it can only
> > deal with RGB images, and there are several other limitations. It
> > can however be used to improve the "color correctness" of images
> > printed with the Print Plugin. I have not yet tested it with the
> > latest release of the dither code, but what I've seen with the
> > earlier versions looked pretty good.
> 
> could you explain the purpose of your plug-in in more detail? Usually
> you wouldn't want to do the color correction at the actual image data,
> but at the input/output level. So I would have guessed color correction
> belongs into the scanner software, the printer software and of course
> gimp's display routines. Support for the latter can be plugged into

Yes, yes and yes again. But because we don't have any CM support so far
I thoght that it's better to have a plugin that does some sort of 
color correction then to keep on hoping that somebody would come up
with an overall strategy for CM. 

> the GIMP using cdisplay modules. I'm wondering what purpose a plug-in 
> would have for serious work. But then having some working code is 
> definitely a good thing! 
 

Can you elaborate a little more about the cdisplay modules? This is the 
first time I'm hearing about these modules. Where can I find more 
information? 

At this time I'm doing the correction on the "live" data because it's
convenient. For the input part it's not a problem because you usually
want to work with the corrected scanned image anyway. The output part
is a bit weird: It's very interesting to see what the color correction
mechanism does to the image. It looks totally screwed on the screen but
printes just fine. In one of the next versions I'm planning on creating
a new image (a copy of the original) to do the output correction so that
the original one is not destroyed. 

There is one aspect of the output transformation for which it makes sense
to do it in a plugin: If you want to do soft proofing with a gamut check
then you have to display the result on the screen. This does not make sense
to do in the print module. One possibility is that the a soft proofing
plugin could query the print plugin about the profile to use and then 
work independently from the print module, or we could have some global
settings for color management that the Gimp application owns, but all the
other parts (input, output, soft proofing, ...) would just use this 
configuration information to find out which profiles to use, or ...

There are so many ways of doing this kind of work that it's probably not
up to me to decide which one to take. What I wanted to do is just put
something out that could be used as a basis for further experiments, but
still is useful for doing some real work.

Karl Heinz

[Gimp-print-devel] Compilation error (was: Andy or Mitch, please read the Help forum)

[Frederic V. <vi...@lc...>]

Hi everybody.

I'm the guy who posted on the help forum the following message :


>  I have previously successfully compiled version 3.1.2 but version
>  3.1.3 does not compile. I receive the error :
>
>  gimp_color_window.c : In function gimp_create_color_adjust_window
>  78 : warning : implicit declaration of function gimp_dialog_new 
>  79 : 'gimp_plugin_help_func' undeclared (first use in this function)
>
>  etc. 
>
>  The unsuccessful compilation was made on Linux (Suse 6.3) whith
>  version 1.1.11 of gimp (and 2.91.66 of gcc). The gimp-devel package
>  is installed. I think the problem is with gimp. Do I need to
>  upgrade to the latest version (I would rather not) ?

Answering to rlk, I only had feed-back from him. As I have seen people
discussing on my problem on this mailing-list, I came here to speed-up
things, if possible. I have tried to play with the Makefile to have
the gtk version working (what follows is from memory, as I do not
write from the computer the experiments were made on). I removed what
concerned the object files gimp_color_window.o and gimp_main_window.o,
but the compilation of "print" failed during hte "link edition"
(sorry, do not know the english expression), because of functions like
"Image_init". The problem seems to come from the gimp libraries. The
commands "nm libgimp.a | grep Image_init" and "nm libgimpui.a | grep
Image_init" returned nothing. Am I doing something wrong here or is
this the expression of another gimp version compatibility problem ?
What is the name of the gtk version of the gimp-plugin ?  Any advice
will be appreciated...

If it can be of any help, I have seen in the archives that some folks
had the same problem than me
(http://www.geocrawler.com/archives/3/1249/2000/4/75/3592172/), and
that Dave Hill proposed some patch
(http://www.geocrawler.com/archives/3/1249/2000/4/75/3592764/).

Thanks in advance.

If I can be of any help to solve this compatibility problem (if it can
be solved whithout upgrading the Gimp)...


Frédéric Vivien.

Re: [Gimp-print-devel] Color Management for Better Prints

[Sven N. <neu...@un...>]

Hi,

> I just finished my first very rough cut of a color manager plugin
> for the Gimp. This plugin uses ICC profiles to make color adjustments
> on images loaded into the application. At this time it can only
> deal with RGB images, and there are several other limitations. It
> can however be used to improve the "color correctness" of images
> printed with the Print Plugin. I have not yet tested it with the
> latest release of the dither code, but what I've seen with the
> earlier versions looked pretty good.

could you explain the purpose of your plug-in in more detail? Usually
you wouldn't want to do the color correction at the actual image data,
but at the input/output level. So I would have guessed color correction
belongs into the scanner software, the printer software and of course
gimp's display routines. Support for the latter can be plugged into
the GIMP using cdisplay modules. I'm wondering what purpose a plug-in 
would have for serious work. But then having some working code is 
definitely a good thing! 


Salut, Sven

[Gimp-print-devel] Color Management for Better Prints

[Karl H. K. <kh...@kh...>]

.. finally! It took me a long time to come up with something
that might be usefull for others as well... 

I just finished my first very rough cut of a color manager plugin
for the Gimp. This plugin uses ICC profiles to make color adjustments
on images loaded into the application. At this time it can only
deal with RGB images, and there are several other limitations. It
can however be used to improve the "color correctness" of images
printed with the Print Plugin. I have not yet tested it with the
latest release of the dither code, but what I've seen with the
earlier versions looked pretty good.

The problem with this type of color correction is that you of course
need a profile for _YOUR_ setup. It's not possible (if you are not
a big corporation that can invest tons of money into comming up with
a pretty good generic profile) to create a profile that will work with
every stc740 or sp870 and any paper/ink combination you throw at it.

I am using a profile generator running in vmware/Win98 to create
my profiles. These profiles need to be redone everytime something
in the dithering changes (or if you modify your paper or even more
important the ink you are using). 

If I find some time next weekend I will generate profiles for the
stc740 and the sp870/1270 that can be downloaded. These will hopefully
give better results than no profiles at all.

If somebody has access to an older Version of Corel Draw (I think
they distributed this with version 7): This package comes with 
the Color Profile Wizard (or whatever name they used in v7). You
need a colorimeter or spectrometer to generate profiles in their
newer software. As far as I know the v7 was also able to use a
calibrated scanner to create profiles that are of course not as
good as the ones generated with a spectrometer, but they are still
good enough for an improvement in color quality. 

The software I'm using (www.wiziwyg.com) is also scanner based. The
actual software can be downloaded from the Internet, you just need their
version of the IT8 target to actually use it.

Unfortunately at this time there is no free software available to 
create printer profiles (anybody interested in writing something? :-)
Scanner profiles can be created under Linux using www.scarse.coloraid.de.

You can always just use the color manager to color correct scanned images
and then print them uncorrected using a set of options that is known to
create good print outs.

A 0.02 version of this software can be downloaded from
http://home.rochester.rr.com/specht/test/color_manager-0.02.tar.gz
It requires the Linux version of the LCMS library from www.lcms.coloraid.de
(Marti is in the process of creating the next release).

This approach could also be used to do the RGB->CMYK transformation in
the print plugin. I just have not yet found a good way of creating CMYK
profiles that could be used for this. Once I have some free time I'm
planning on just using a generic CMYK profile and see what the results
are. This would take care of all the problems related to this transformation
that were discussed the other day on the list.

So, does this sound interesting? I have not announced this to anybody else,
I would like to get some feedback from the people on this list first. It
is related to printing, and in the future I would like to see color
profiles supported in the print plugin.

Karl Heinz

Re: [Gimp-print-devel] 3.2 or 4.0 Release criteria

[Robert L K. <rl...@al...>]

   Date: Wed, 03 May 2000 11:02:23 +0200
   From: Thomas Tonino <tt...@bi...>

   Robert L Krawitz wrote:

   > If we're going to do that, we need to start thinking about release
   > criteria.  The obvious issues to consider are:

   What about using the Linux odd/even model? 3.1 is development, and 3.2
   (or 4.0) would have everything that is good and works in an easy to use
   package.

That's the idea.

   A help system for a printer plugin? Hmmm. I'd rather have the
   bewildering number of choices reduced somewhat myself. As a naive user,
   I have to try something like 3 modes * 8 resolutions * 6 dithers. I'd
   like to select my printer and then find only modes that work for my
   model, are useful, and understandeable. 4 speed/quality settings should
   be enough, and maybe a photo/solid color/b&w lineart/ink saving setting
   that changes dither and other things.

I was thinking along much the same lines; pick a set of controls that
make sense from a user perspective.  Things that I think a user is
concerned about are:

* Desired print quality/speed

* Image type (people know whether they're printing text, or a photo,
  or something in between)

* Paper type (using 1440 dpi on cheap paper is wasteful; using 360 dpi
  on glossy film, likewise) and size

* Image size/positioning

* Printer model

* Paper source (for printers with multiple input trays)

* Printer name

* Black & white vs. grayscale vs. color


Things that users might be concerned about, but belong elsewhere,
might include:

* Brightness

* Contrast

* MAYBE color balance settings and saturation


Things that only advanced users will ever care about:

* Printer command (we should somehow try to autodetect that)

* Gamma

* Dither algorithm

* Ink type (if you're using e. g. MIS monochrome inks, you're an
  advanced user, period).

   As far as print quality is concerned: it can always be improved, and
   that means it is never 'ready' for release.

The former is correct; that doesn't make the latter true.  Clearly you
agree, but I just want to make clear that "release" doesn't mean
"perfect".  There are never any "perfect" releases, and we have to
accept that at some point we have to cut things off.  My issue here
is, is print quality "good enough" to merit a release?

					       So I'd like to see a 'user'
   version with printers and settings that work. Maybe this version has a
   'development' mode as well that gives access to the new printer models,
   or maybe those versions are just in the development version.

I don't want to support two contemporaneous releases.  Marking
printers that are not tested well enough as experimental (maybe having
a separate page to select these printers) might do.  Anyway, I don't
think that 3.2 or 4.0 or whatever we call it will be a single release;
we'll surely do point releases along the way, with new printers
included (that's why getting the printer description architecture
right is important -- if we do it right, we can just add printers to
printers.xml and have everything just work, assuming that the printers
don't need some new feature that we don't know about yet.  We're not
there yet.)

   Gamma is probably good to have as the gamma of different CRTs is quite
   different.

But do most users have a clue what it means?  We can always put
something in the doc discussing how to fine tune the output.
	      
	      The page layout thingy could use margin display etc. I must
   say the thingy looks nice and is useful, but actually it is a strange
   thing as it is very small. Some kind of displayed rows and columns could
   help align stuff on your expensive photo paper.

I like this idea.  I'm not sure I like how the thing scales with paper size.

   > 3) Quality.  I don't mean print quality; I mean robustness,
   >    performance, and correctness.

   If some features of the code are removed performance may increase a bit,
   but I think that increasing performance will be a separate effort. And
   performance may bite quality, although it does not have to be bad. Think
   about re-using random values or using our own random number generator
   (it does not have to be terribly good...)

Performance is really a bit separate here, but a lot of people
complain about the speed (or lack thereof).  Some of this is just a
matter of doing the right constant folding, but some of it is a matter
of having the right tuning points in the dither routine (NOT user
visible directly, but if someone picks a low resolution and low-end
paper and such we should intuit that we should use a faster
algorithm.  Likewise, if someone picks all high-end settings, we know
they expect top quality and not high printer performance.)

   > 4) Documentation.

   For the user? In the UI mostly.

That's what I meant about a help system.

				   For the developer I wouldn't worry. It's
   a 'release' version - but as more people will have a look, it would
   probably be good to have it in shape.

Well, a lot of people on the list complain (with justification, I
think) that the code is poorly documented.  It's a lot easier for
people to code and submit changes if they understand what's going on.

   > 8) Is this a 3.2 or a 4.0 release?  Is it overall a substantial enough
   >    change (I don't think that improved print quality alone would
   >    count) from release 3.0 to merit a new major number, or do we
   >    consider it incremental?

   If the UI is bastard proofed, I think it would justify a 4.0 number.

OK, well that's a specific criterion that I rather tend to agree with.

Thanks!

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] Latest stuff

[Thomas T. <tt...@bi...>]

Robert L Krawitz wrote:

> Could you post 1440 HQ and 1440 Enhanced?  2880x720 is a really
> strange mode that's probably not of much use (I'm probably going to
> rip it out at some point; the vertical oversampling is much more useful).

Ok, I'll do that this evening.

> Are you sure that's an overshoot, or is it just another case of the
> missing yellow?

Saying that cyan and yellow are missing is probably the correct way to
say this.

> That sure looks like a registration problem of some kind, doesn't it...

It does, but the strange thing is that the problem does not seem to have
a direction. Maybe becuase dithering works two-directional?

Ill have a closer look this evening.


Thomas

Re: [Gimp-print-devel] 3.2 or 4.0 Release criteria

[Thomas T. <tt...@bi...>]

Robert L Krawitz wrote:

> If we're going to do that, we need to start thinking about release
> criteria.  The obvious issues to consider are:

What about using the Linux odd/even model? 3.1 is development, and 3.2
(or 4.0) would have everything that is good and works in an easy to use
package. 3.3.x would have new printers built in, and when they reach
'the right quality' they would move to 3.2.x. Or maybe hide the
in-developemnt models under a 'development' part of the UI: see my
answer on print quality.

> 1) What is the minimum required functionality to make a new stable
>    release worthwhile to users?  That should be measured in quality
>    and features.  I believe that we're getting toward that point in
>    terms of devices (well, Epson devices at any rate) and quality
>    (maybe I should try the 3.0-based plugin that comes with the Gimp
>    for comparison some time).  There are other issues, such as
>    device-specific settings, a help system, and so forth that we need
>    to consider.

A help system for a printer plugin? Hmmm. I'd rather have the
bewildering number of choices reduced somewhat myself. As a naive user,
I have to try something like 3 modes * 8 resolutions * 6 dithers. I'd
like to select my printer and then find only modes that work for my
model, are useful, and understandeable. 4 speed/quality settings should
be enough, and maybe a photo/solid color/b&w lineart/ink saving setting
that changes dither and other things.

As far as print quality is concerned: it can always be improved, and
that means it is never 'ready' for release. So I'd like to see a 'user'
version with printers and settings that work. Maybe this version has a
'development' mode as well that gives access to the new printer models,
or maybe those versions are just in the development version.

> 2) What do we need to do with the interface?  It's still rough in some
>    ways: the print coordinates aren't correct (the origin isn't the
>    top left of the paper, it's the top left of the printable area;
>    Gimp users probably don't care too much, but Ghostscript users know
>    what I'm talking about); there are a number of features that are of
>    more interest to developers (such as dithering algorithms, and
>    gamma) than to end users, and there's still a lot of clutter.  We
>    also need to decide which of the two interfaces we're going to
>    support.

Gamma is probably good to have as the gamma of different CRTs is quite
different. The page layout thingy could use margin display etc. I must
say the thingy looks nice and is useful, but actually it is a strange
thing as it is very small. Some kind of displayed rows and columns could
help align stuff on your expensive photo paper.

> 3) Quality.  I don't mean print quality; I mean robustness,
>    performance, and correctness.

If some features of the code are removed performance may increase a bit,
but I think that increasing performance will be a separate effort. And
performance may bite quality, although it does not have to be bad. Think
about re-using random values or using our own random number generator
(it does not have to be terribly good...)

> 4) Documentation.

For the user? In the UI mostly. For the developer I wouldn't worry. It's
a 'release' version - but as more people will have a look, it would
probably be good to have it in shape.

> 5) The Ghostscript driver is a mess right now, and there's no error
>    checking (everyone who has tried using a mode that's not compatible
>    with their printer knows what THAT means).  I think that this is
>    even more important than the Gimp plugin from a strategic point of
>    view.

I personally was more interested in the Ghostscript driver, but I
switched to testing with the GIMP version because that is much easier to
do. Ghostscript probably is more important for the time being. Anyone
know what the Gnome Printing Model is doing? Ghostscript could end up
printing to the Gnome printer, just like the Windows version can print
to the Windows printing layer. I think there should be just one place
where people set up their printer

> 7) Testing.  I know that there are a fair number of people using this;
>    I don't know just how many.  Freshmeat says that about 900 people
>    have hit one of the two download URL's (both on Sourceforge); I
>    haven't found how to get download statistics from Sourceforge, but
>    I'd really like to know how much use it's getting.

Would it be much effort to include a 'feedback' button in the UI?
Probably not, but analyzing the received data might be.

> 8) Is this a 3.2 or a 4.0 release?  Is it overall a substantial enough
>    change (I don't think that improved print quality alone would
>    count) from release 3.0 to merit a new major number, or do we
>    consider it incremental?

If the UI is bastard proofed, I think it would justify a 4.0 number.

> The other thing I'm going to try to do is spin a release once a week,
> if there's enough new material.  The month between 3.1.2 and 3.1.3 was
> quite long, although the dither code was undergoing a lot of changes.

As a non-developer I would not give comments to a mailing list that
quickly. If there is a feedback method that attracts more responses,
that could help us a lot: to collect bugs, find out which settings
people use, etc.


Thomas

Re: [Gimp-print-devel] Latest stuff

[Andy T. <th...@ph...>]

Robert L Krawitz wrote:

> Could everyone go back and test their printers with the latest
> repository?  In particular, could the HP and Canon folks give it a
> try?  I've changed a bunch of constants, and it's possible that that
> will throw off those printers.

I didn't have much time recently to follow the plugin's development as closely
as I'de have liked to but I've noticed there have been fundamental and
fascinating improvements. :-)
And by the way: Any new Canon folks on the list or am I still the only one?
Anyway, as soon as I've installed the newest gimp I'll do some of the test
printing on my Canon - just hoping I'll come to it this week or the week
after... Are there any preferrable testimages? Anything to specifically keep
in mind?

Andy.


--
Andy Thaller
TU Muenchen, Physikdepartment E11       Tel: ++49 (0)89 289 12860
James Franck Str.                       Fax: ++49 (0)89 289 12842
85748 Garching   //  Germany            email:  th...@ph...

[Gimp-print-devel] 3.2 or 4.0 Release criteria

[Robert L K. <rl...@al...>]

I want to start thinking about the next stable release of the plugin.

I've been thinking that this summer would be a good time -- it would
let us get in a significant chunk of development, while still keeping
the release cycle short enough so that we can keep up with the
hardware (new printers seem to come out quite frequently).  That means
we're talking about 3 months from now, give or take.

If we're going to do that, we need to start thinking about release
criteria.  The obvious issues to consider are:

1) What is the minimum required functionality to make a new stable
   release worthwhile to users?  That should be measured in quality
   and features.  I believe that we're getting toward that point in
   terms of devices (well, Epson devices at any rate) and quality
   (maybe I should try the 3.0-based plugin that comes with the Gimp
   for comparison some time).  There are other issues, such as
   device-specific settings, a help system, and so forth that we need
   to consider.

2) What do we need to do with the interface?  It's still rough in some
   ways: the print coordinates aren't correct (the origin isn't the
   top left of the paper, it's the top left of the printable area;
   Gimp users probably don't care too much, but Ghostscript users know
   what I'm talking about); there are a number of features that are of
   more interest to developers (such as dithering algorithms, and
   gamma) than to end users, and there's still a lot of clutter.  We
   also need to decide which of the two interfaces we're going to
   support.

3) Quality.  I don't mean print quality; I mean robustness,
   performance, and correctness.

4) Documentation.

5) The Ghostscript driver is a mess right now, and there's no error
   checking (everyone who has tried using a mode that's not compatible
   with their printer knows what THAT means).  I think that this is
   even more important than the Gimp plugin from a strategic point of
   view.

6) Gimp release status.  We're not tied too tightly to the Gimp, but
   if we can mesh schedules (and if the Gimp people are willing to
   accept a new release when we're ready) it would be to everybody's
   benefit.  I'm sure the Gimp people would rather have a better
   quality solution than what they have now.  Even if the schedules
   don't mesh, I presume that the Gimp folks plan to do several 1.2.x
   updates.  Would they be willing to accept a new print plugin as
   part of an update?  If so, what would the compatibility
   requirements be?  Another reason why it would be desirable to mesh
   schedules.

7) Testing.  I know that there are a fair number of people using this;
   I don't know just how many.  Freshmeat says that about 900 people
   have hit one of the two download URL's (both on Sourceforge); I
   haven't found how to get download statistics from Sourceforge, but
   I'd really like to know how much use it's getting.

8) Is this a 3.2 or a 4.0 release?  Is it overall a substantial enough
   change (I don't think that improved print quality alone would
   count) from release 3.0 to merit a new major number, or do we
   consider it incremental?

I'm throwing this out here to start discussion going.  I'd like the
entire core development team to think about this; I'd also like any
Gimp and other Linux printing people here to comment.  I personally
consider the major strategic goals to be support for a broad range of
printers, including both high end and low end printers, the
Ghostscript driver, quality, and meshing with the Gimp.  Again, we're
looking at a few months out, but we need to start planning now.

The other thing I'm going to try to do is spin a release once a week,
if there's enough new material.  The month between 3.1.2 and 3.1.3 was
quite long, although the dither code was undergoing a lot of changes.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] Stylus photo 870

[Robert L K. <rl...@al...>]

   Date: Wed, 3 May 2000 02:00:35 +0000
   From: Jean-Marc Verbavatz <ver...@if...>

   On May 2,  7:58pm, Robert L Krawitz wrote:

   >    { 0.152, 0x1, 0 },
   >    { 0.255, 0x2, 0 },
   >    { 0.38,  0x3, 0 },
   >    { 0.5,   0x1, 1 },
   >    { 0.67,  0x2, 1 },
   >    { 1.0,   0x3, 1 }
   >
   >    The last 3 values also go for K and Y (simple case).
   >
   > Well, this is easy to fix.  Thank you for doing this.  Would you like
   > to commit the fix?

   Sure if it's also applicable to other printers.

Might as well.  If different printers have different constants, we'll
fix those later.

I consider top quality from the Epson 870/1270 to be a key strategic
goal of this project (along with the Ghostscript driver).  I think we
should be prepared to accept some extra complexity to get this one
right.  The 870 is a recent, state of the art printer, and is widely
regarded to be one of the best, if not the best, inkjet out there (in
a reasonable price range).  This will go a long way toward making
Linux into a good desktop platform.  I'd like to support flagship
printers from other vendors too, but apparently they aren't being too
forthcoming with information.

(Is anyone from Epson reading this?  Does anyone smell opportunity for
hardware vendors?)

   > The balance between light and dark inks is very different from what I've
   > come up with; I came up with .25.  It might be that I'm using
   > different inks, or they might simply be reformulated.

   I just went back to what I had found for 3.1.2 and it was also between 0.35
   and 0.4. 0.25 is definitely too low for me; 0.33 already is (too low).

OK, probably the inks are different.  I should put an Epson cartridge
in my printer and see what happens.

   Primarily, red looks too yellow and blue too magenta to me. Gray is
   not quite gray either. This can probably be fixed by adjusting the
   respective densities but I haven't tried yet.

I've noticed that too.  Does your gray turn out slightly greenish?

   Wow, much better ! I can see color again :) The thresholds look excellent.
   Looks a bit grainy (Dither=2), but that's photo quality again.

Try adaptive random (dither=4).  I need to take a closer look at this
grain issue, since the stuff as of this morning seems to have
regressed a bit.

   By the way, I'm not using the gimp here, but ghostscript.

How many people are using this as a Gimp plugin, and how many as a
Ghostscript driver?

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] Stylus photo 870

[Jean-Marc V. <ver...@if...>]

On May 2,  7:58pm, Robert L Krawitz wrote:

> Welcome!

Thanks

>
>    { 0.152, 0x1, 0 },
>    { 0.255, 0x2, 0 },
>    { 0.38,  0x3, 0 },
>    { 0.5,   0x1, 1 },
>    { 0.67,  0x2, 1 },
>    { 1.0,   0x3, 1 }
>
>    The last 3 values also go for K and Y (simple case).
>
> Well, this is easy to fix.  Thank you for doing this.  Would you like
> to commit the fix?

Sure if it's also applicable to other printers.

> The balance between light and dark inks is very different from what I've
> come up with; I came up with .25.  It might be that I'm using
> different inks, or they might simply be reformulated.

I just went back to what I had found for 3.1.2 and it was also between 0.35
and 0.4. 0.25 is definitely too low for me; 0.33 already is (too low).

>
> Could someone test these on a 740 and a 900 (standard_dither_ranges
> and dot_sizes also needs to be fixed the same way)?
>
>    On my STP870, my values yield absolutely identical densities for each of
the
>    inks/levels. The color balance still needs to be improved.
>
> What's wrong?  Maybe I can make some suggestions.
>
Primarily, red looks too yellow and blue too magenta to me. Gray is not quite
gray either. This can probably be fixed by adjusting the respective densities
but I haven't tried yet.

>    If I understand well, this should therefore apply as well to
print-escp2.c:
>
>    1217,1218c1217,1218
>    <         dither_set_c_ranges(dither, 5, variable_dither_ranges,
v->density);
>    <         dither_set_m_ranges(dither, 5, variable_dither_ranges,
v->density);
>    ---
>    >         dither_set_c_ranges(dither, 6, variable_dither_ranges,
v->density);
>    >         dither_set_m_ranges(dither, 6, variable_dither_ranges,
v->density);
>
> Indeed it should.
>
>    Finally as of the version before today's black was too dark.
>
> Let us know how the version as of this morning works, since that was
> one of the key improvements.  Maybe we can also try lower black
> thresholds (particularly k_lower) with the variable dot sizes.
>

Wow, much better ! I can see color again :) The thresholds look excellent.
Looks a bit grainy (Dither=2), but that's photo quality again.

By the way, I'm not using the gimp here, but ghostscript.


-- 
--
Jean-Marc Verbavatz		<ver...@if...>
5, rue La Fontaine		"http://perso.cybercable.fr/verbavat"
F-75016 Paris

[Gimp-print-devel] Ghostscript driver

[Robert L K. <rl...@al...>]

Would anyone like to take over maintenance of the Ghostscript driver?
I don't have as much time to devote to it as I'd like.  If no one here
wants it, I'll put a job announcement on Sourceforge for it.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] Stylus photo 870

[Robert L K. <rl...@al...>]

   Date: Tue, 2 May 2000 23:46:00 +0000
   From: Jean-Marc Verbavatz <ver...@if...>

   My name is Jean-Marc Verbavatz. I have joined the developers of
   gimp-print a few days ago and would like to introduce myself.

Welcome!

   { 0.152, 0x1, 0 },
   { 0.255, 0x2, 0 },
   { 0.38,  0x3, 0 },
   { 0.5,   0x1, 1 },
   { 0.67,  0x2, 1 },
   { 1.0,   0x3, 1 }

   The last 3 values also go for K and Y (simple case).

Well, this is easy to fix.  Thank you for doing this.  Would you like
to commit the fix?

The balance between light and dark inks is very different from what I've
come up with; I came up with .25.  It might be that I'm using
different inks, or they might simply be reformulated.

Could someone test these on a 740 and a 900 (standard_dither_ranges
and dot_sizes also needs to be fixed the same way)?

   On my STP870, my values yield absolutely identical densities for each of the
   inks/levels. The color balance still needs to be improved.

What's wrong?  Maybe I can make some suggestions.

   I see that these have already been modified in print-escp2.c v 1.134 in the
   meantime and in the same direction except for dark level 2. In particular we
   went from 5 to 6 levels (light 3 was not being used).
   If I understand well, this should therefore apply as well to print-escp2.c:

   1217,1218c1217,1218
   <         dither_set_c_ranges(dither, 5, variable_dither_ranges, v->density);
   <         dither_set_m_ranges(dither, 5, variable_dither_ranges, v->density);
   ---
   >         dither_set_c_ranges(dither, 6, variable_dither_ranges, v->density);
   >         dither_set_m_ranges(dither, 6, variable_dither_ranges, v->density);

Indeed it should.

   Finally as of the version before today's black was too dark.

Let us know how the version as of this morning works, since that was
one of the key improvements.  Maybe we can also try lower black
thresholds (particularly k_lower) with the variable dot sizes.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

[Gimp-print-devel] Stylus photo 870

[Jean-Marc V. <ver...@if...>]

Hi everyone,

My name is Jean-Marc Verbavatz. I have joined the developers of gimp-print a
few days ago and would like to introduce myself.

I first came across gimp-print, as a ghostscript plugin, to drive my stylus
photo 700 a few months ago and was quite impressed. Just over a month ago, I
got a new stylus photo 870 instead and naturally tried gimp-print. That was
with versions 3.1.1 and later 3.1.2. It worked but exhibited a number of
dithering weaknesses and bugs. I fixed some of them and tried to improve the
rendering (mainly for photographs) until I obtained real photo quality, hardly
distinguishable from true photographs. My fixes were against print-3.1.2 and I
reported them to Robert Krawitz who kindly advised me that 3.1.3 was out with
totally different dithering algorithms. He suggested that I should join and I'm
back to the drawing board so to speak.

I am not an expert in printers or in dithering but I am dedicated to quality
and I am ready to spare some ink and time on this.

I have now started testing print-3.1.3 with my stylus photo 870.
It works flawlessly and some of the major bugs I had found in 3.1.2 appear to
be gone. Good. Quality needs to be improved though.
Last night, I made qualitative density comparisons of all the inks and sizes
and this is the best (pretty good actually) setting I could find for
variable_dither_ranges:

{ 0.152, 0x1, 0 },
{ 0.255, 0x2, 0 },
{ 0.38,  0x3, 0 },
{ 0.5,   0x1, 1 },
{ 0.67,  0x2, 1 },
{ 1.0,   0x3, 1 }

The last 3 values also go for K and Y (simple case).
On my STP870, my values yield absolutely identical densities for each of the
inks/levels. The color balance still needs to be improved.

I see that these have already been modified in print-escp2.c v 1.134 in the
meantime and in the same direction except for dark level 2. In particular we
went from 5 to 6 levels (light 3 was not being used).
If I understand well, this should therefore apply as well to print-escp2.c:

1217,1218c1217,1218
<         dither_set_c_ranges(dither, 5, variable_dither_ranges, v->density);
<         dither_set_m_ranges(dither, 5, variable_dither_ranges, v->density);
---
>         dither_set_c_ranges(dither, 6, variable_dither_ranges, v->density);
>         dither_set_m_ranges(dither, 6, variable_dither_ranges, v->density);

Finally as of the version before today's black was too dark.

Thanks for your time,


-- 
--
Jean-Marc Verbavatz		<ver...@if...>
5, rue La Fontaine		"http://perso.cybercable.fr/verbavat"
F-75016 Paris

Re: [Gimp-print-devel] Latest stuff

[Robert L K. <rl...@al...>]

   Date: Tue, 02 May 2000 20:37:31 +0200
   From: Thomas Tonino <tt...@bi...>

   Much better dark tones. Black-to-white wedge also prints a lot better,
   and photos are indeed improved a lot in dark areas. Also took the time
   to test 720 softweave, 1440 High Quality, 1440 Enhanced and the 2880x720
   resolutions. All work, but the high resolutions have strange artefacts.
   The 720 softweave, which does not show the artefacts, and the 2880x720
   version, both printed with Random FLoyd Steinberg, can be found here:

Could you post 1440 HQ and 1440 Enhanced?  2880x720 is a really
strange mode that's probably not of much use (I'm probably going to
rip it out at some point; the vertical oversampling is much more useful).

   http://people.a2000.nl/ztonino/dither/2880x720RandomFS.jpg
   http://people.a2000.nl/ztonino/dither/720SoftweaveRandomFS.jpg

   The cyan in the top right of the 720 version is a scanner problem.
   Problems I see with the 2880 version:

   The light wedge at the top has streks where yellow is missing (you
   cannot see this with the bare eye). Under the 80 of 2880 there is a bit
   of overshoot of magenta at the top, and in the top left corner at the
   top there is some magenta where not other colors were printed.

Are you sure that's an overshoot, or is it just another case of the
missing yellow?

   The biggest issue is the face. That dark areas become very red is not
   that bad, but look at the cyan line at the top right of the head that is
   set just a little bit inside the hair, and the eyebrows that look like
   they're painted in. Seems something is shifting around here.

That sure looks like a registration problem of some kind, doesn't it...

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] Andy or Mitch, please read the Help forum

[Robert L K. <rl...@al...>]

   Date: Tue, 02 May 2000 20:15:40 +0200
   From: Michael Natterer <mit...@cs...>

   >   gimp_color_window.c : In function gimp_create_color_adjust_window
   >   78 : warning : implicit declaration of function gimp_dialog_new
   >   79 : 'gimp_plugin_help_func' undeclared (first use in this function)
   > 
   >   etc.
   > 
   >   The unsuccessful compilation was made on Linux (Suse 6.3) whith
   >   version 1.1.11 of gimp (and 2.91.66 of gcc). The gimp-devel package
   >   is installed. I think the problem is with gimp. Do I need to upgrade
   >   to the latest version (I would rather not) ?

   Unfortunately, you have to upgrade if you want the ui with the libgimp
   widgets.

The problem is that it didn't compile.  It would be OK to degrade to
the GTK-only version if the necessary Gimp stuff is missing; it's not
OK for it to fail to compile.

   Again, unfortunately, this means that all people with versions lower than
   1.1.21 will see only one ui (will not have the choice of two menu entries).

That's fine, just as long as people with lower versions can compile
the plugin.

Re: [Gimp-print-devel] Latest stuff

[Thomas T. <tt...@bi...>]

Robert L Krawitz wrote:

> Could everyone go back and test their printers with the latest
> repository?  In particular, could the HP and Canon folks give it a
> try?  I've changed a bunch of constants, and it's possible that that
> will throw off those printers.

Rsuluts for the Epson Stylus Color 600 with Random Floyd-Steinberg:

Much better dark tones. Black-to-white wedge also prints a lot better,
and photos are indeed improved a lot in dark areas. Also took the time
to test 720 softweave, 1440 High Quality, 1440 Enhanced and the 2880x720
resolutions. All work, but the high resolutions have strange artefacts.
The 720 softweave, which does not show the artefacts, and the 2880x720
version, both printed with Random FLoyd Steinberg, can be found here:

http://people.a2000.nl/ztonino/dither/2880x720RandomFS.jpg
http://people.a2000.nl/ztonino/dither/720SoftweaveRandomFS.jpg

The cyan in the top right of the 720 version is a scanner problem.
Problems I see with the 2880 version:

The light wedge at the top has streks where yellow is missing (you
cannot see this with the bare eye). Under the 80 of 2880 there is a bit
of overshoot of magenta at the top, and in the top left corner at the
top there is some magenta where not other colors were printed.

The biggest issue is the face. That dark areas become very red is not
that bad, but look at the cyan line at the top right of the head that is
set just a little bit inside the hair, and the eyebrows that look like
they're painted in. Seems something is shifting around here.

The original is:

http://people.a2000.nl/ztonino/dither/me2.jpg


Thomas