gimp-print-devel

[Gimp-print-devel] ESP 750 MODEL_INIT

[<sh...@al...>]

Can someone remind me, was there a reason the ESP 750 is MODEL_INIT_STANDARD
rather than MODEL_INIT_900.  Were there bug reports of problems as _900?

I seem to have a vague recollection of something like this, but my brain
seems to be accessing corrupted memory.  To much exposure to that great
big burning hydrogen ball today.  Anybody else ever see that? ;)

It seems to work ok for me as _900, and it won't work without it over USB.

Eric

[Gimp-print-devel] gimp-print 3.1.4 released

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

This is the Print plugin for the Gimp, version 3.1.4.  This is a
development release.  If this software causes your print head to zoom
off the end of your printer, spilling ink all over your 1000 year old
Persian rug, don't blame us.  Remember, you installed the software.

Changes from 3.1.3:

1) Support for the Hewlett-Packard DeskJet 960.

2) Print quality improvements.

3) Some print speed optimizations.

4) Major fix for hybrid Floyd-Steinberg dithering

-- 
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] First experiences with an 870

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

   Date: Sun, 7 May 2000 02:35:56 +0000
   From: Jean-Marc Verbavatz <ver...@if...>

	   3) Pale tones are very good indeed.  Gray is very neutral.  However,
	   under a loupe there`s some weirdness going on.  I think that the
	   error spread setting (controlling how widely the error is diffused)
	   is too high.  That`s not surprising; the spread settings are set up
	   for single dot size.

   Could that have something to do with my magenta problem ?

Possibly, although it doesn't seem to be a magenta-specific problem.

Re: [Gimp-print-devel] First experiences with an 870

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

         1) The standard Epson density (.6`ish) is all wrong for this printer.
         I had to scale it to 1.3 (which really means 1.3 * .6, or about .8)
         to get anything that looked even remotely reasonable.  Even that`s
              a bit too low (I`m using photo glossy paper).  I also had to
knock
         down both gamma and brightness a bit (.9 gamma and 80 brightness;
         that gamma might be just a bit too low).  Ron van Ostayen suggested
         a value of 1.6 for his ESC 900; that creates solid blacks, but it
         definitely drops too much ink (see below).

         This might explain why people with 900`s are complaining that
         output is too light.  Maybe all the variable dot size printers need
         adjustment.

I had mentionned that in my first mail to you (not to this list).

        2) The ink dries very slowly.

True on most papers. I have found that ink dried very quickly on TDK pro
quality paper. I find it's a very good paper too. Unfortunately a bit
expensive.

        3) Pale tones are very good indeed.  Gray is very neutral.  However,
        under a loupe there`s some weirdness going on.  I think that the
        error spread setting (controlling how widely the error is diffused)
        is too high.  That`s not surprising; the spread settings are set up
        for single dot size.

Could that have something to do with my magenta problem ?

	4) Mid and dark tones are grainy.  It`s less obvious when I push the
        density up.  It might be a sign that the dither algorithm has
        problems here; it might also simply be a sign that the density is
        too low.  The grain looks a little bit like "shadowing" from large
        dots, but not entirely.

I would agree, wouldn't I ?

        5) Using the smallest dot size from the dark inks makes the grain
        worse.  That doesn`t particularly surprise me; it`s not laying down
        a lot of ink, but it`s printing quite dark.  We may be better off
        not using this.  Or maybe we need to find a way to use it only in
        heavy gray situations.

That was my point a few days ago. I would not recommend not using small dots at
all. The problem really occurs with dark cyan, dark magenta and black only
(dark inks). Even with these inks not using small dots will sometimes result in
using too much of the light inks and laying down too much ink.

       6) The printer is nearly silent -- a nice change after the noisy EX.

That is a pleasure, isn't it ? I'm no longer afraid of wakening my son at 3 am.

       7) I think the high density results in too much ink being dropped
       (which is bad because of the slow drying ink and its expense).
       Jean-Marc Verbavatz had an idea about an ink budget.  I think
       that`s a great idea and needs some more study.  We also need to
       look at other ink reduction techniques.

Yes, increasing density until you get solid colors is not the answer. I'll
try to implement that again with the current version of gimp-print.

For a full description of this printer's features one should add that the
bottom margin is quite small ~6-7 mm as far as I can tell and it does not keep
printing on the next page if you go over the margin.


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

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

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

   Date: Sun, 7 May 2000 01:54:48 +0000
   From: Jean-Marc Verbavatz <ver...@if...>

   I've tried to work on grays. The patch below improves the gray
   balance for me.  As you can see the magenta density will increase
   by ~17% (0.85 vs 1.0) and the cyan density by ~11% (0.9 vs
   1.0). Now grays look gray. Of course, the color balance changes
   slightly as well. As the values are absolutely empirical, they may
   need to be tweaked, but they look good to me.

Careful with that.  Setting the highest value to anything other than 1
may lead to instability or other problems.

   I still see it with the latest version even on black and white
   pictures (printed in color). Therefore, it is not due to the
   images. Moreover It did not happen with gimp-print 3.1.2 (even on
   the same photographs). It occurs at low densities indeed (although
   not extremely low), but only in proximity of higher densities.
   Therefore not on flat tones, but either at transitions or in
   regions of very variable density. I haven't yet looked if it
   occurred with all the dithering algorithms (only 3 and 4).

Hmm...

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

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

On May 5, 10:22pm, Robert L Krawitz wrote:
> Subject: Re: [Gimp-print-devel] Stylus photo 870
>    Date: Fri, 5 May 2000 23:51:30 +0000
>    From: Jean-Marc Verbavatz <ver...@if...>
>
>    > Huh.  That's very interesting, and doesn't accord with my experience.
>    > I would expect stock 3.1.3 to be the least grainy, followed by the
>    > current repository and then 3.1.2.  3.1.2 might be denser, which would
>    > reduce the perceived grain.
>
>    Right, this is not what I meant. Saying that the current repository
>    was lousy was an overstatement. I meant it's too dark to tell. For
>    3.1.2 I meant a version that I had modified. I would otherwise
>    agree with you.
>
> The current repository prints too dark?  I thought I reduced the
> density.

Well I should think twice before typing. I meant the lastest release (3.1.3) as
of last week printed too much black to tell about grain. The current repository
is grainy but getting better everyday and 3.1.2, as I had modified it, was
best.
Let's forget about this statement I have some news.

>    I think the density ratio between colors is simply not one. I'll
>    send you a patch over the week end, that mostly fixes grays. To get
>    it absolutely right, we need to address the grain issue first
>    though. To fix red and blue, the only thing I came up with were hue
>    adjustements.
>
> I think you're probably correct.  See my next message, though, about
> grain.

I read the message, got the new version and it doesn't seem to have changed a
lot in my particular case.

I've tried to work on grays. The patch below improves the gray balance for me.
As you can see the magenta density will increase by ~17% (0.85 vs 1.0) and the
cyan density by ~11% (0.9 vs 1.0). Now grays look gray. Of course, the color
balance changes slightly as well. As the values are absolutely empirical, they
may need to be tweaked, but they look good to me.

--- ../print-escp2.c	Sun May  7 02:26:31 2000
+++ print-escp2.c	Sun May  7 02:31:12 2000
@@ -206,6 +206,26 @@
   { 1.0,   0x3, 1 }
 };

+static simple_dither_range_t variable_c_dither_ranges[] =
+{
+  { 0.137, 0x1, 0 },
+  { 0.228, 0x2, 0 },
+  { 0.342,  0x3, 0 },
+  { 0.45,   0x1, 1 },
+  { 0.60,  0x2, 1 },
+  { 0.9,   0x3, 1 }
+};
+
+static simple_dither_range_t variable_m_dither_ranges[] =
+{
+  { 0.129, 0x1, 0 },
+  { 0.215, 0x2, 0 },
+  { 0.323,  0x3, 0 },
+  { 0.425,   0x1, 1 },
+  { 0.567,  0x2, 1 },
+  { 0.85,   0x3, 1 }
+};
+
 static simple_dither_range_t standard_dither_ranges[] =
 {
   { 0.5,   0x1, 1 },
@@ -1219,8 +1239,8 @@
       dither_set_k_ranges_simple(dither, 3, dot_sizes, v->density);
       if (escp2_has_cap(model, MODEL_6COLOR_MASK, MODEL_6COLOR_YES))
 	{
-	  dither_set_c_ranges(dither, 6, variable_dither_ranges, v->density);
-	  dither_set_m_ranges(dither, 6, variable_dither_ranges, v->density);
+	  dither_set_c_ranges(dither, 6, variable_c_dither_ranges, v->density);
+	  dither_set_m_ranges(dither, 6, variable_m_dither_ranges, v->density);
 	}
       else
 	{


>    Yes indeed. The new k_lower in print-escp2 .138, looks better already.
That
>    does not totally fix the problem, but helps very much.
>
> We can always tweak it a bit more.

I think k_lower is fine. I tried to play with k_upper. In vain, but this gave
me some ideas that I'll try to play with in the next couple of days.

>    Have you tried to print a black and white picture in color mode ?
>    I've noticed that, beyond the greenish tone, it shows diffuse
>    magenta grains, particularly around transitions and I could not
>    figure out why. Interestingly, I've noticed that (now that black is
>    better), grain in color pictures was mostly magenta as well and in
>    fact localized in exactly the same regions. Is it just me ?
>
> You know, I've seen some oddities with (not so diffuse) magenta in
> some things at extremely low densities.  At this point, I don't know
> if it's due to the image or if magenta alone is somehow being handled
> incorrectly.
>
I still see it with the latest version even on black and white pictures
(printed in color). Therefore, it is not due to the images. Moreover It did not
happen with gimp-print 3.1.2 (even on the same photographs). It occurs at low
densities indeed (although not extremely low), but only in proximity of higher
densities.
Therefore not on flat tones, but either at transitions or in regions of very
variable density. I haven't yet looked if it occurred with all the dithering
algorithms (only 3 and 4).


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

[Gimp-print-devel] First experiences with an 870

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

Well, I hooked up the 870 today.  Here's the first things I noticed:

1) The standard Epson density (.6'ish) is all wrong for this printer.
   I had to scale it to 1.3 (which really means 1.3 * .6, or about .8)
   to get anything that looked even remotely reasonable.  Even that's
   a bit too low (I'm using photo glossy paper).  I also had to knock
   down both gamma and brightness a bit (.9 gamma and 80 brightness;
   that gamma might be just a bit too low).  Ron van Ostayen suggested
   a value of 1.6 for his ESC 900; that creates solid blacks, but it
   definitely drops too much ink (see below).

   This might explain why people with 900's are complaining that
   output is too light.  Maybe all the variable dot size printers need
   adjustment.

2) The ink dries very slowly.

3) Pale tones are very good indeed.  Gray is very neutral.  However,
   under a loupe there's some weirdness going on.  I think that the
   error spread setting (controlling how widely the error is diffused)
   is too high.  That's not surprising; the spread settings are set up
   for single dot size.

4) Mid and dark tones are grainy.  It's less obvious when I push the
   density up.  It might be a sign that the dither algorithm has
   problems here; it might also simply be a sign that the density is
   too low.  The grain looks a little bit like "shadowing" from large
   dots, but not entirely.

5) Using the smallest dot size from the dark inks makes the grain
   worse.  That doesn't particularly surprise me; it's not laying down
   a lot of ink, but it's printing quite dark.  We may be better off
   not using this.  Or maybe we need to find a way to use it only in
   heavy gray situations.

6) The printer is nearly silent -- a nice change after the noisy EX.

7) I think the high density results in too much ink being dropped
   (which is bad because of the slow drying ink and its expense).
   Jean-Marc Verbavatz had an idea about an ink budget.  I think
   that's a great idea and needs some more study.  We also need to
   look at other ink reduction techniques.

8) Printing multiple images on the same page by means of multiple
   print runs is troublesome.  Think slow-drying ink.  Also, even
   after having dried for over 5 hours, the rollers still managed to
   pick some ink off the paper.  This is less than thrilling from a
   development standpoint; I like to print very small images 25 to a
   page.

So we have some work to do on this...

-- 
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] packaging or: trying to break bogus MS patents

[<sh...@al...>]

> No, because gimp-print (the current gimp-print) is not part of the
> official gimp package.  It should be distributed as an addon.

Actually, I believe the official debian gimp package includes quite
a bit that is not part of the official gimp package.

Eric

Re: [Gimp-print-devel] packaging or: trying to break bogus MS patents

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

   From: sh...@al...
   Date: Sat, 06 May 2000 10:30:42 -0400

   I think gimp-print will need to be removed from the official debian
   gimp package and separated into its own package.  This is not so hard
   to do.

No, because gimp-print (the current gimp-print) is not part of the
official gimp package.  It should be distributed as an addon.

Re: [Gimp-print-devel] packaging or: trying to break bogus MS patents

[<sh...@al...>]

(Quick review for Ben and Torsten: We're discussing how to package
Gimp's print plug-in for Debian.  Gimp-print is trying to separate
itself from the Gimp and become a generalized printer driver package.
It currently works from within Ghostscript as well as from the Gimp.)

> I thought I put everything in there (except a 1 MB
> gs-aladdin_5.50-8.diff file -- should that be in there?)

Hmm.  Possibly, but I'm not sure what's in it.  I'm surprised it's that
long.  Can you put a copy of it somewhere where I can grab it and then
I'll take a look at it and decide if it needs to be included or not.
It may be better to include a script which can generate such a file,
but I'd still like to get a copy of it to see what he's done.

I'm not really sure how gimp-print should be packaged in the first place.
Debian already includes gimp-print as part of the main gimp package and
ghostscript is also available as a separate package.

I think gimp-print will need to be removed from the official debian
gimp package and separated into its own package.  This is not so hard
to do.

Unfortunately, ghostscript is not as easy to handle.  Since there is no
plug-in architecture, and the gimp-print driver must be actually compiled
into ghostscript, I think the only way to optionally provide gimp-print
at this time would be to have alternative ghostscript packages.

There are also legal issues involved with making a gs-aladdin-gimp-print
package.  I don't think such a beast could be legally distributed.
Using gnu ghostscript should work, though, and has no licensing problems.
Anyone care to comment on that?

Eric

Re: [Gimp-print-devel] gs6.21 + gimp-print pre3.1.4 + STC900 problems

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

Robert L Krawitz wrote:
> 
>    Date: Sat, 06 May 2000 15:47:24 +0200
>    From: Ron van Ostayen <R.A...@Wb...>
> 
>       time gs -q -dNOPAUSE -dBATCH -sDEVICE=stp -dModel=13 \
>          -dQuality=0 -sOutputFile=tiger0.prn tiger.ps
> 
>    default: 28s
>    using inlined functions print_color, update_dither, calc_rgb_to_hsv and
>    calc_hsv_to_rgb: 21.5s.
> 
>    Other quality settings have different differences but the speedup is
>    there.
>    Perhaps you use a different gcc and processor?
> 
>    gcc version 2.95.2 19991024 (release)
> 
> I'm using a Celeron at 450 MHz (4.5*100).  Faster, but smaller,
> cache.  Also, I'm using 2.7.2.3.
> 
> I presume you've recompiled with NO profiling.

Yep.

> 
> --
> 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

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

Re: [Gimp-print-devel] gs6.21 + gimp-print pre3.1.4 + STC900 problems

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

   Date: Sat, 06 May 2000 15:47:24 +0200
   From: Ron van Ostayen <R.A...@Wb...>

      time gs -q -dNOPAUSE -dBATCH -sDEVICE=stp -dModel=13 \
	 -dQuality=0 -sOutputFile=tiger0.prn tiger.ps

   default: 28s
   using inlined functions print_color, update_dither, calc_rgb_to_hsv and
   calc_hsv_to_rgb: 21.5s.

   Other quality settings have different differences but the speedup is
   there.
   Perhaps you use a different gcc and processor?

   gcc version 2.95.2 19991024 (release)

I'm using a Celeron at 450 MHz (4.5*100).  Faster, but smaller,
cache.  Also, I'm using 2.7.2.3.

I presume you've recompiled with NO profiling.

-- 
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 pre3.1.4 + STC900 problems

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

Robert L Krawitz wrote:
> 
>    Date: Sat, 06 May 2000 14:37:35 +0200
>    From: Ron van Ostayen <R.A...@Wb...>
> 
>    Nevertheless I think the code would speed up a lot if all functions that
>    are called for every dot are inlined.
> 
> BTW, I just ran a test, and got no improvement at all.
> --

   time gs -q -dNOPAUSE -dBATCH -sDEVICE=stp -dModel=13 \
      -dQuality=0 -sOutputFile=tiger0.prn tiger.ps

default: 28s
using inlined functions print_color, update_dither, calc_rgb_to_hsv and
calc_hsv_to_rgb: 21.5s.

Other quality settings have different differences but the speedup is
there.
Perhaps you use a different gcc and processor?

gcc version 2.95.2 19991024 (release)

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

Re: [Gimp-print-devel] gs6.21 + gimp-print pre3.1.4 + STC900 problems

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

BTW, my profile (with everything inlined) looks very different indeed:

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ms/call  ms/call  name    
 92.29     31.61    31.61     4810     6.57     6.57  dither_cmyk
  5.84     33.61     2.00     4810     0.42     0.42  rgb_to_rgb
  1.11     33.99     0.38    28860     0.01     0.01  escp2_pack
  0.41     34.13     0.14   130669     0.00     0.00  weave_parameters_by_row
  0.26     34.22     0.09        1    90.00    90.00  init_dither
  0.09     34.25     0.03     4810     0.01     0.11  escp2_write_weave
  0.00     34.25     0.00    38480     0.00     0.00  get_errline

Re: [Gimp-print-devel] gs6.21 + gimp-print pre3.1.4 + STC900 problems

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

   Date: Sat, 06 May 2000 15:36:18 +0200
   From: Ron van Ostayen <R.A...@Wb...>

   >    Nevertheless I think the code would speed up a lot if all functions that
   >    are called for every dot are inlined.
   > 
   > That's probably true.

   Is this something you'll implement in upcoming releases?

I'll consider it.  Like I said, for me it did nothing at all (when
measured with a stopwatch, compiled -O2).

Re: [Gimp-print-devel] gs6.21 + gimp-print pre3.1.4 + STC900 problems

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

Robert L Krawitz wrote:
> 
>    Date: Sat, 06 May 2000 14:37:35 +0200
>    From: Ron van Ostayen <R.A...@Wb...>
> 
>    As you can see, update_dither and print_color have been succesfully
>    inlined and more important the runtime is MUCH better.
>    However, the performance gain is smaller if you run code without debug
>    and profiling information.  The gain is about 30%.  But I think this is
>    substantial enough to put the change into the repository (Robert?).
> 
> If the gain is substantial when compiling optimized then it's worth
> doing.  Don't trust any gains made with anything not compiled with the
> appropriate -O flag.

These tests were performed using -O2 -pg.  
-O2 is the default ghostscript setting.

> 
> BTW, you might also want to try compiling -O6 -funroll-loops or some
> other options.

In my experience you can gain a few percent using agressive optimization
settings.
We're looking for algorithmic optimizations here in order to speed the
code up a lot more.

> 
>    Nevertheless I think the code would speed up a lot if all functions that
>    are called for every dot are inlined.
> 
> That's probably true.

Is this something you'll implement in upcoming releases?

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

Re: [Gimp-print-devel] gs6.21 + gimp-print pre3.1.4 + STC900 problems

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

   Date: Sat, 06 May 2000 14:37:35 +0200
   From: Ron van Ostayen <R.A...@Wb...>

   Nevertheless I think the code would speed up a lot if all functions that
   are called for every dot are inlined.

BTW, I just ran a test, and got no improvement at all.
-- 
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 pre3.1.4 + STC900 problems

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

   Date: Sat, 06 May 2000 14:37:35 +0200
   From: Ron van Ostayen <R.A...@Wb...>

   As you can see, update_dither and print_color have been succesfully
   inlined and more important the runtime is MUCH better.  
   However, the performance gain is smaller if you run code without debug
   and profiling information.  The gain is about 30%.  But I think this is
   substantial enough to put the change into the repository (Robert?).

If the gain is substantial when compiling optimized then it's worth
doing.  Don't trust any gains made with anything not compiled with the
appropriate -O flag.

BTW, you might also want to try compiling -O6 -funroll-loops or some
other options.

   Nevertheless I think the code would speed up a lot if all functions that
   are called for every dot are inlined.

That's probably true.

-- 
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] EPSON Stylus 840

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

   Date: Sat, 6 May 2000 10:04:15 +0200
   From: Hrafnkell Eiriksson <he...@kv...>

   On Fri, May 05, 2000 at 08:12:50PM -0400, Robert L Krawitz wrote:
   > That indicates that the support for the 860 isn't correct yet.  It's a
   > new printer, and I only just got doc (which unfortunately I can't
   > share yet) on it.  I can't promise when it will be working.

   Did you sign a NDA? Do you know why Epson only wants one person 
   on the project to have the docs? 
   Seems to me a strange way to support an open project.

No, I did not sign an NDA.  For now, I'm simply respecting their
wishes as relayed to me.  Supposedly the doc will be officially
released soon.  It doesn't prevent me from actually using the
information, though.

-- 
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] packaging or: trying to break bogus MS patents

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

   From: sh...@al...
   Date: Fri, 05 May 2000 22:40:24 -0400

   I'll assume that no one will mind if I add a debian subdir with the
   necessary scripts.

Go right ahead.

   However, before I reinvent the wheel, I noticed in the Ghost/README file
   there is a reference to some work toward this contributed by Stuart Miles,
   as well as some references to additional files which he was going to send
   but are not in CVS.

I thought I put everything in there (except a 1 MB
gs-aladdin_5.50-8.diff file -- should that be in there?)

   Robert, do you have these files?

   Eventually, if we can get binary packages for at least i386 RH, Suse, and
   Debian on the sourceforge site, that could really increase our user-base.

Yup.

[Gimp-print-devel] gs6.21 + gimp-print pre3.1.4 + STC900 problems

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

Robert L Krawitz wrote:
> 
>    Date: Fri, 05 May 2000 22:33:08 +0200
>    From: Ron van Ostayen <R.A...@wb...>
> 
>    Each sample counts as 0.01 seconds.
>      %   cumulative   self              self     total
>     time   seconds   seconds    calls  ms/call  ms/call  name
>     58.38     48.02    48.02     7650     6.28     8.45  dither_cmyk
>     20.23     64.66    16.64 187272000     0.00     0.00  print_color
>     18.73     80.07    15.41     7650     2.01     2.01  rgb_to_rgb
>      0.97     80.87     0.80   151700     0.01     0.01
>    mem_true24_fill_rectangle
>      0.52     81.30     0.43    24857     0.02     0.02  escp2_pack
>      0.16     81.43     0.13  3521567     0.00     0.00
>    gs_debug_c
>    <snip>
> 
>    OK. The results are clear.  dither_cmyk is expensive because it
>    takes a long time each time its called.  I looked at this routine
>    and I must say: I haven't got a clue what's going on :-).
> 
>    print_color is expensive partly because it's called so many times.
>    This routine can therefore perhaps run faster if the large number of
>    arguments to the routine is reduced, perhaps by combining them in a
>    structure or by moving them to global space.
> 
>    rgb_to_rgb is expensive because it takes a long time each time its
>    called.
> 
> Well, dither_cmyk and rgb_to_rgb are really just loops over all the
> pixels in a row.  print_color is actually called four times per
> iteration (once per color), except when black is printed, when it's
> called only once.
> 
> I'm surprised (and not entirely displeased) to see print_color taking
> so little time, actually.  You might try marking it inline to see if
> that improves matters any.  The calls are quick enough that things

Debug and profiling information but NO inlining: 46s

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 32.58      9.28     9.28     3825     2.43     5.01  dither_cmyk
 26.58     16.85     7.57     3825     1.98     1.98  rgb_to_rgb
 20.22     22.61     5.76 46818000     0.00     0.00  update_dither
 14.50     26.74     4.13 46818000     0.00     0.00  print_color
  3.05     27.61     0.87   151700     0.01     0.01 
mem_true24_fill_rectangle 

OK. I have inlined update_dither, print_color, calc_rgb_to_hsv and
calc_hsv_to_rgb. (with debug and profiling information)
Runtime: 22.3s !!

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 56.80     11.86    11.86     3825     3.10     3.10  dither_cmyk
 35.15     19.20     7.34     3825     1.92     1.92  rgb_to_rgb
  3.74     19.98     0.78   151700     0.01     0.01 
mem_true24_fill_rectangle
  0.62     20.11     0.13    14283     0.01     0.01 
escp2_pack                

As you can see, update_dither and print_color have been succesfully
inlined and more important the runtime is MUCH better.  
However, the performance gain is smaller if you run code without debug
and profiling information.  The gain is about 30%.  But I think this is
substantial enough to put the change into the repository (Robert?).

> just might; each call is taking less than 100 NANOseconds.  I figure
> they're all running out of cache, which is good, but that's still
> amazingly fast.  What kind of processor do you have?

Nothing special.  A dual PII-450 system (ASUS P2B-DS, 128Mb).  However
ghostscript isn't compiled with SMP support.

> 
> Also, try setting saturation to 1.0 to see if rgb_to_rgb speeds up any
> (and if so, how much).  The real problem is dither_cmyk, though.  I

-dSaturation=1.0 : 46s (includes debug and profiling information,
therefore not optimal)

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 32.58      9.28     9.28     3825     2.43     5.01  dither_cmyk
 26.58     16.85     7.57     3825     1.98     1.98  rgb_to_rgb
 20.22     22.61     5.76 46818000     0.00     0.00  update_dither
 14.50     26.74     4.13 46818000     0.00     0.00  print_color
  3.05     27.61     0.87   151700     0.01     0.01 
mem_true24_fill_rectangle 

-dSaturation=1.2 : 65s (include debug and profiling information, no
inline functions)

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 29.09     12.31    12.31     3825     3.22     5.61  rgb_to_rgb
 22.19     21.70     9.39     3825     2.45     5.02  dither_cmyk
 12.90     27.16     5.46 46818000     0.00     0.00  update_dither
 10.96     31.80     4.64 11704500     0.00     0.00  calc_rgb_to_hsv
 10.66     36.31     4.51 11704500     0.00     0.00  calc_hsv_to_rgb
 10.30     40.67     4.36 46818000     0.00     0.00  print_color
  1.91     41.48     0.81   151700     0.01     0.01 
mem_true24_fill_rectangle 

Although dither_cmyk is big, a lot of time is also spend in rgb_to_rgb
even with saturation=1.0.  Once again, a lot of this extra time is
required to log profiling information.  

Nevertheless I think the code would speed up a lot if all functions that
are called for every dot are inlined.

> think I know in general what's wrong there, but actually fixing it
> won't be trivial.

I was afraid it wouldn't be.

> 
> BTW, I couldn't reproduce your ESC900 problem.  That output below is
> definitely for the 900.  Trust me, even if you don't know what to look
> for, I do :-)  Double check what model you're using.  Also, after you
> check out the CVS repository, do "make ghost" before copying the .c
> and .h files from Ghost into your GhostScript source.
> 

I rechecked my batch file again and I finally found the error.

#!/bin/sh
for q in 0 1 2 3
do
   echo Quality $q
   time gs -q -dNOPAUSE -dBATCH -sDEVICE=stp -dMODEL=13 \
      -dQuality=$q -sOutputFile=tiger$q.prn tiger.ps
done   

The -dMODEL=13 is wrong of course. It should be -dModel=13.  Sometimes
you just HAVE to make a mistake like that.
I have rechecked all quality modes and those that should work on an
ESC900 do work.  


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

Re: [Gimp-print-devel] Autoconfig trouble...

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

Hi,

> [amalmin@skaro print]$ aclocal 
> aclocal: configure.in: 43: macro `AM_PATH_GIMP' not found in library
> 
> 	But that still doesn't work...AM_PATH_GIMP is called in configure.in...
> but doesn't seem to be defined anywhere else...
> 
> 	My gimp is:
> 
> [amalmin@skaro print]$ gimp -v
> GIMP version 1.1.17

The quick and dirty solution is to find out where aclocal is located. That 
will most probably be either /usr/bin/aclocal or /usr/local/bin/aclocal. 
Then locate the directories holding the m4 scripts aclocal needs. That will 
most probably be /usr/share/aclocal and /usr/local/share/aclocal. Now move 
all m4 scripts together into the directory that matches the path of your 
aclocal binary, remove the empty directory and create a link pointing to 
the place you moved the files to. Now aclocal should be able to find all 
its m4 scripts and future installations will go to the correct place.



Salut, Sven

Re: [Gimp-print-devel] EPSON Stylus 840

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

On Sat, May 06, 2000 at 10:04:15AM +0200, Hrafnkell Eiriksson wrote:
> On Fri, May 05, 2000 at 08:12:50PM -0400, Robert L Krawitz wrote:
> > That indicates that the support for the 860 isn't correct yet.  It's a
> > new printer, and I only just got doc (which unfortunately I can't
> > share yet) on it.  I can't promise when it will be working.
>=20
> Did you sign a NDA? Do you know why Epson only wants one person=20
> on the project to have the docs?=20
> Seems to me a strange way to support an open project.
>=20

The document is not releases yet, that's the reason why Robert
can not share it at this time. Please wait until it shows
up on their developer relatesion web site.

Karl Heinz

--=20
Karl Heinz Kremer                                      kh...@kh...
                                                http://www.khk.net

Re: [Gimp-print-devel] EPSON Stylus 840

[Hrafnkell E. <he...@kv...>]

On Fri, May 05, 2000 at 08:12:50PM -0400, Robert L Krawitz wrote:
> That indicates that the support for the 860 isn't correct yet.  It's a
> new printer, and I only just got doc (which unfortunately I can't
> share yet) on it.  I can't promise when it will be working.

Did you sign a NDA? Do you know why Epson only wants one person 
on the project to have the docs? 
Seems to me a strange way to support an open project.

Better than nothing though!

-- 
//-----------------------//-------------------------------------------------
//  Hrafnkell Eiriksson  // 
//  he...@kv...        // 
//  TF3HR                //  "Blessed are they who go around in circles,
//                       //   for they shall be known as Wheels"        

Re: [Gimp-print-devel] Hybrid Floyd-Steinberg, again

[S. M. <sm...@rn...>]

Robert L Krawitz wrote:
> 
> Well, I just found a major, if trivial, bug in hybrid Floyd-Steinberg
> that accounts for all of the ugliness in that mode (specifically, a
> missing break in a case statement).  It looks vastly better now (both
> the adaptive and the pure hybrid variants).  I strongly urge everyone
> to give it another try.
> 
These look pretty good - both on my Rasputin image and a photo of Bryce
Canyon.  Both came out slightly contrasty and the photo is a little too
dark with the default settings, but these are several orders of
magnitude better than a couple of months ago. Color balance is
reasonably good and there is very little grain left in the blue sky
(this was at 720 microweave).

Steve

-----------------------------------------
Just because I have a short attention span
doesn't mean I
------------------------------------------