gimp-print-devel

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

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

Michael Natterer wrote:
> 
> I have restricted the test to Gimp 1.1.16 or better so the current
> cvs version should build for everybody.
> 
> Robert, I will add the code which requires Gimp 1.1.21 tonight (just
> in case you plan to make a release to day).
> 
> bye,
> --Mitch
> 
I've been having problems getting the repository to compile for about a
week or so.  I finally got gimp 1.1.21 downloaded and compiled (a story
all by itself), but have still been unsuccessful.  I get the following
error:
checking for GIMP - version >= 1.0.0... no
*** Could not run GIMP test program, checking why...
*** The test program failed to compile or link. See the file config.log
for the
*** exact error that occured. This usually means GIMP was incorrectly
installed
*** or that you have moved GIMP since it was installed. In the latter
case, you
*** may want to edit the gimptool script: /usr/local/bin/gimptool
configure: error: Cannot find GIMP libs: Please run ldconfig
make: *** [config.status] Error 1
print> 

As far as I can tell, the libs are where they've always been, and
gimptool --version returns version 1.1.21.  My sandbox still compiles
fine with an older version of configure.  As I'm getting fairly close to
getting the notebook GUI done I'd like to make sure I can get everything
to compile from the repository.  Any help would be appreciated.

Steve

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

Re: [Gimp-print-devel] More stuff

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

   Date: Thu, 04 May 2000 12:57:49 +0200
   From: Ron van Ostayen <R.A...@Wb...>

   Quality   Time(s)  FileSize     Printing time (time cat tiger0..9.prn >
   /dev/lp0)
     0        33.2     1986522       18.5  OK but top margin is approx
   0.9cm smaller than for other settings.
     1       112.1     7118815       68.0  OK
     2       110.6     7118808       error in output (empty pages and
   garbage)
     3       116.1         955 !!
     4      signal 11
     5       191.5     9977020      121.0  OK
     6       190.2         605 !!
     7       198.7        2042 !!
     8       356.4        2127 !!
     9       390.9        1549 !!

   I have succesfully tested 3.1.3 with quality setting 0,1,2,3,5,6 and 8
   so the last changes seem to have broken some settings.

Could you retest settings 2, 3, and 6?

BTW, were you using ordered dither (dither=1)?  I think that might
account for the file size of 3, 6, 7, 8, and 9.  That bug should be
fixed.  Try dither=2 (random Floyd-Steinberg) and dither=4 (adaptive
random Floyd-Steinberg).

I know the rendering time is awful...please bear with this for a while
longer...

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

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

   Date: Thu, 04 May 2000 22:04:21 +0200 (CEST)
   From: regis rampnoux <re...@re...>

   On 03-May-00 Robert L Krawitz wrote:

   > No, what UNIX command to use to send the file to the printer..

   Users like me can put it in the configuration file.

If you know what it is.  You shouldn't have to know.

   > Well, I don't understand how that works.  The printer doesn't know
   > what kind of ink cartridge is in the printer; if you try to send
   > something to the printer, presumably something will create the color
   > separations and send each color to the printer.  Without something or
   > other to tell it, how will the driver know that "yellow" is really
   > some percent gray?  Surely you have to tell it somehow that you're
   > trying to print a black and white picture using special inks, rather
   > than a color picture using color inks (or a black and white picture
   > using color inks), no?

   No, I only put the gray cartridge, I chose UCR separation, correct
   the saturation. and select "color ink".  The driver do separations
   in CYMK and add the two extras layers for the ligth cyan and
   magenta.  Choice of UCR should be better than GGR, but I don't
   tried the two on the same picture.

What is UCR separation?  Why would you correct the saturation for
printing black and white, which has no saturation?

Basically, what it sounds like is that the architecture of the Windows
driver is simply different from ours.

   When you print a grayscale picture in color mode do you use only
   black ink, or all colors inks and black ink? The difference beetwen
   UCR and GCR is that in UCR the black ink is used only for the dark
   grays.

Mixture of color & black.  At low levels it's all color; in the dark
midtones and darker black starts to mix in.

-- 
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] More stuff

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

   Date: Thu, 04 May 2000 16:11:01 +0200
   From: Ron van Ostayen <R.A...@Wb...>

   > One pass, and bidirectional.

   Now I'm confused.  The printer head goes across the page dumping ink,
   and returns dumping ink.  Then the paper is moved forward approx. 1.4cm.

Hmm.  I see what you mean.  At 360 dpi, the 900 prints *every* row.
In theory, at any rate.

   I would call this 2-pass, bidirectional?

   The windows driver uses a mixed approach:  When color is needed it uses
   the same approach as gimp-print but when (black) text or figures are
   printed then the head goes across the page dumping ink, the
   paper is moved forward 1.4cm, the head returns dumping ink, and the
   paper is moved forward approx. 1.4cm.

   I would call this 1-pass, bidirectional?

OK, I think I have a clue what's going on here.

You'll find this in print-escp2.c:

  if (use_glossy_film)
    dither_set_black_upper(dither, 1.0);
  else
    dither_set_black_upper(dither, 1.0);

Try changing the 1.0 to .99 (make it less than one by greater than one
part in 65536).  See if that makes a difference.  What *may* account
for your problem is that even in pure black regions the driver's
dropping some color ink.  If that doesn't work, try printing something
with -dColor=0 as a test.  This will print black ink only.

   Furthermore the windows driver uses a much faster method of paper
   transport across empty areas.  The gimp-print driver is very slow across
   empty areas.

I know.  I've partially optimized it, but not completely.  That
shouldn't be all that hard to get right.  It's possible that what
looks empty isn't entirely, but it's possible to figure that out from
the print file, if what I eventually do to fix it doesn't solve the
problem.

   And yet the windows printer dump file size is about 2x as large.

Now that's very interesting.  I wonder why.

   During rendering the difference is a more pronounced: Printing 10 pages
   of my report to file takes about 20s in windows and 220s in gimp-print!!

Yeah, the dithering still needs some performance tuning...

   The quality of in particular the windows text is much better than the
   gimp-print output.  Figures and photos are comparable.

What's the difference (more specifically)?

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

> No, what UNIX command to use to send the file to the printer..

Users like me can put it in the configuration file.
 
> Well, I don't understand how that works.  The printer doesn't know
> what kind of ink cartridge is in the printer; if you try to send
> something to the printer, presumably something will create the color
> separations and send each color to the printer.  Without something or
> other to tell it, how will the driver know that "yellow" is really
> some percent gray?  Surely you have to tell it somehow that you're
> trying to print a black and white picture using special inks, rather
> than a color picture using color inks (or a black and white picture
> using color inks), no?

No, I only put the gray cartridge, I chose UCR separation, correct the
saturation. and select "color ink".
The driver do separations in CYMK and add the two extras layers for the ligth
cyan and magenta.
Choice of UCR should be better than GGR, but I don't tried the two on the same
picture.

When you print a grayscale picture in color mode do you use only black ink, or
all colors inks and black ink? The difference beetwen UCR and GCR is that in
UCR the black ink is used only for the dark grays.





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

Re: [Gimp-print-devel] Latest stuff

[Dave H. <da...@mi...>]

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.

Sorry I haven't got(ten) round to this yet. I've been busy and not
able to keep up with the flow of dithering changes. I'll have a try
this weekend.

BTW, I have asked HP the "big question" about releasing details
of their newer printers, so far no answer!

Dave

-- 
Dave Hill, Kempston, Bedford UK		da...@mi...
				davehill at users.sourceforge.net
Sicth munce ago, I cutn't evun spel enjuneer, and now I are one!

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

[Michael N. <mit...@cs...>]

Frederic Vivien wrote:
> 
> Robert L Krawitz <rl...@al...> writes:
> 
> > 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.
> 
> The reason is : because I am a dummy! I have re-done the experiments
> this morning, cleanly. Here is the result :
> 
> As reported before, the compilation of gimp_color_window.c fails because
> of the compatibility problem :
> gimp_color_window.c:78: warning: implicit declaration of function
> `gimp_dialog_new'
> gimp_color_window.c:79: `gimp_plugin_help_func' undeclared (first use in
> this function
> 
> I then remove gimp_color_window.c and gimp_color_window.o from the
> makefile. Then the compilation of gimp_main_window.c fails like this
> of gimp_color_window.c did. I then remove gimp_main_window.c and
> gimp_main_window.o from the Makefile, clean everything and then the
> compilation fails with:
> 
> gcc  -g -O2  -o print  print-canon.o print-dither.o print-escp2.o
> print-pcl.o print-ps.o print-util.o print.o
> gtk_color_window.o gtk_main_window.o -L/usr/lib -lgimpui -lgimp
> -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext
> -lX11 -lm
> print.o: In function `do_print_dialog':
> /home/frederic/Printer/print-3.1.3/print.c:651: undefined reference to
> `gimp_create_main_window'
> collect2: ld returned 1 exit status
> make: *** [print] Error 1
> 
> Thus it looks (if I'm not mistaking once again) like it is not
> possible to compile only the gtk version (print seems to be the only
> binary using gtk_main_window... etc.).

Yes, there was a buggy test for the required Gimp version in print_gimp.h,
thus trying to build the Gimp-only ui for all Gimp 1.1.x versions.

I have restricted the test to Gimp 1.1.16 or better so the current
cvs version should build for everybody.

Robert, I will add the code which requires Gimp 1.1.21 tonight (just
in case you plan to make a release to day).

bye,
--Mitch

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

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

Robert L Krawitz <rl...@al...> writes:

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

The reason is : because I am a dummy! I have re-done the experiments
this morning, cleanly. Here is the result :

As reported before, the compilation of gimp_color_window.c fails because
of the compatibility problem :
gimp_color_window.c:78: warning: implicit declaration of function
`gimp_dialog_new'
gimp_color_window.c:79: `gimp_plugin_help_func' undeclared (first use in
this function           

I then remove gimp_color_window.c and gimp_color_window.o from the
makefile. Then the compilation of gimp_main_window.c fails like this
of gimp_color_window.c did. I then remove gimp_main_window.c and
gimp_main_window.o from the Makefile, clean everything and then the
compilation fails with:

gcc  -g -O2  -o print  print-canon.o print-dither.o print-escp2.o
print-pcl.o print-ps.o print-util.o print.o
gtk_color_window.o gtk_main_window.o -L/usr/lib -lgimpui -lgimp
-L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext
-lX11 -lm
print.o: In function `do_print_dialog':
/home/frederic/Printer/print-3.1.3/print.c:651: undefined reference to
`gimp_create_main_window'
collect2: ld returned 1 exit status
make: *** [print] Error 1

Thus it looks (if I'm not mistaking once again) like it is not
possible to compile only the gtk version (print seems to be the only
binary using gtk_main_window... etc.).


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

OK. I will wait for version 3.1.4.

Thanks,


Frédéric Vivien.

Re: [Gimp-print-devel] More stuff

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

Robert L Krawitz wrote:
> 
>    Date: Thu, 04 May 2000 12:57:49 +0200
>    From: Ron van Ostayen <R.A...@Wb...>
> 
>    Robert L Krawitz wrote:
> 
>    > There are some bug fixes for the ESC 440 (so it should finally do
>    > softweave correctly), and another bug fix for 360 dpi mode that may
>    > improve performance on the ESC 900.  I've also incorporated
>    > Jean-Marc's new ink constants for the ESP 870.
> 
>    I've tested this on my ESC900.
>    The 360dpi mode is a bit faster and the floating point exception is
>    removed.
> 
> OK.  But it's still somewhat slower than the Windows driver?

Yes.  See below.

> 
>    Is this a 2-pass mode or 1-pass?  I believe the windows driver is
>    1-pass.
> 
>    Is this a bi-directional printing mode?  I suspect it is uni-directional
>    and i think it could/should be bi-directional.
> 
> One pass, and bidirectional.

Now I'm confused.  The printer head goes across the page dumping ink,
and returns dumping ink.  Then the paper is moved forward approx. 1.4cm.

I would call this 2-pass, bidirectional?

The windows driver uses a mixed approach:  When color is needed it uses
the same approach as gimp-print but when (black) text or figures are
printed then the head goes across the page dumping ink, the
paper is moved forward 1.4cm, the head returns dumping ink, and the
paper is moved forward approx. 1.4cm.

I would call this 1-pass, bidirectional?

Furthermore the windows driver uses a much faster method of paper
transport across empty areas.  The gimp-print driver is very slow across
empty areas.

As a consequence, the gimp-driver is still about 2x slower during
printing than the
windows driver.  

And yet the windows printer dump file size is about 2x as large.

During rendering the difference is a more pronounced: Printing 10 pages
of my report to file takes about 20s in windows and 220s in gimp-print!!

Printing to paper of the windows printer dump file in linux takes about
80s.
Printing to paper of the gimp-print printer dump file in linux takes
about 150s.

The quality of in particular the windows text is much better than the
gimp-print output.  Figures and photos are comparable.

> 
>    However some errors occur in the other quality settings.
> 
>    Quality   Time(s)  FileSize     Printing time (time cat tiger0..9.prn >
>    /dev/lp0)
>      0        33.2     1986522       18.5  OK but top margin is approx
>    0.9cm smaller than for other settings.
>      1       112.1     7118815       68.0  OK
>      2       110.6     7118808       error in output (empty pages and
>    garbage)
>      3       116.1         955 !!
>      4      signal 11
>      5       191.5     9977020      121.0  OK
>      6       190.2         605 !!
>      7       198.7        2042 !!
>      8       356.4        2127 !!
>      9       390.9        1549 !!
> 
>    I have succesfully tested 3.1.3 with quality setting 0,1,2,3,5,6 and 8
>    so the last changes seem to have broken some settings.
> 
> Basically, all the softweave modes are shot by the look of it.  It's
> not obvious to me why that is the case right now...
> 

Ron van Ostayen

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

Re: [Gimp-print-devel] HP deskjet 690c and 815C

[<po...@as...>]

On Thu, 4 May 2000, Henk Verleye wrote:

> In the supported printer list for the gimp-print project, the HP DeskJet
> 600 series is there.  Does this also include the 690 series (= a 6 ink

the 815C doesn't seem to be included in the 800 series at least.

I can't get anything usefull out of it at least. The 600 driver works
"good".

(Okay, this could be a very old version of gimp)

---
/Pållen - http://www.astrakan.hig.se/~pollen
          telnet://mumindalen.astrakan.hig.se

[Gimp-print-devel] HP deskjet 690c

[Henk V. <he...@so...>]

In the supported printer list for the gimp-print project, the HP DeskJet
600 series is there.  Does this also include the 690 series (= a 6 ink
printer, similar to the Epson Stylus Photo series, only with a HP PCL
interface) ?
If not, what do you need to add it (the printer codes? information about
the colour of the inks? other things?)?
I may be able to deliver most of what's needed.
I haven't taken any look into the code itself, so at this point in time I
cannot add the HPDJ690c (should it be lacking) myself, but I may be able
to do it in the future, if needed (at one time I already made a linux
driver for that printer, but that was outside the GNU community; if I
receive the data in a colour-separated and dithered form, I'm able get
things through to the printer).

Another question: an appeal was launched to test the existing code on
various printer models.  I may be able to test it with an Epson Stylus
Photo 1200 printer.  Is there any standard test procedure that I can use?

Henk Verleye

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

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

   Date: Thu, 04 May 2000 10:25:12 +0200
   From: Thomas Tonino <tt...@bi...>

   In 1440Enhanced an extra line shows up in the face. It seems tohave
   constant distance from the hair. On my monitor, it is about a millimeter
   away. The missing yellow in the top could be caused by a printer
   problem.

   2880x720 shows the extra line on the face at a larger distance and
   darker. The missing yellow in the top shows up most clearly here. The
   shadows under the lower lips does not look good, but this may be a
   gamma/curves problem. But let's disregard this resolution.

   1440 High Quality looks okay, but suffers a bit from the wormy textures.
   Maybe thowse works are also cousing the other problems I've seen, and I
   should switch to adaptive Floyd-Steinberg.

I couldn't reproduce any of this stuff...

Re: [Gimp-print-devel] More stuff

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

   Date: Thu, 04 May 2000 12:57:49 +0200
   From: Ron van Ostayen <R.A...@Wb...>

   Robert L Krawitz wrote:

   > There are some bug fixes for the ESC 440 (so it should finally do
   > softweave correctly), and another bug fix for 360 dpi mode that may
   > improve performance on the ESC 900.  I've also incorporated
   > Jean-Marc's new ink constants for the ESP 870.

   I've tested this on my ESC900.  
   The 360dpi mode is a bit faster and the floating point exception is
   removed.

OK.  But it's still somewhat slower than the Windows driver?

   Is this a 2-pass mode or 1-pass?  I believe the windows driver is
   1-pass.

   Is this a bi-directional printing mode?  I suspect it is uni-directional
   and i think it could/should be bi-directional.

One pass, and bidirectional.

   However some errors occur in the other quality settings.

   Quality   Time(s)  FileSize     Printing time (time cat tiger0..9.prn >
   /dev/lp0)
     0        33.2     1986522       18.5  OK but top margin is approx
   0.9cm smaller than for other settings.
     1       112.1     7118815       68.0  OK
     2       110.6     7118808       error in output (empty pages and
   garbage)
     3       116.1         955 !!
     4      signal 11
     5       191.5     9977020      121.0  OK
     6       190.2         605 !!
     7       198.7        2042 !!
     8       356.4        2127 !!
     9       390.9        1549 !!

   I have succesfully tested 3.1.3 with quality setting 0,1,2,3,5,6 and 8
   so the last changes seem to have broken some settings.

Basically, all the softweave modes are shot by the look of it.  It's
not obvious to me why that is the case right now...

Re: [Gimp-print-devel] More stuff

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

Robert L Krawitz wrote:
> 
> There are some bug fixes for the ESC 440 (so it should finally do
> softweave correctly), and another bug fix for 360 dpi mode that may
> improve performance on the ESC 900.  I've also incorporated
> Jean-Marc's new ink constants for the ESP 870.
> 

I've tested this on my ESC900.  
The 360dpi mode is a bit faster and the floating point exception is
removed.

Is this a 2-pass mode or 1-pass?  I believe the windows driver is
1-pass.

Is this a bi-directional printing mode?  I suspect it is uni-directional
and i think it could/should be bi-directional.

However some errors occur in the other quality settings.

#!/bin/sh
for q in 0 1 2 3 4 5 6 7 8 9 
do
   echo Quality $q:
   time gs -q -dNOPAUSE -dBATCH -dSAFER \
      -sDEVICE=stp -dMODEL=13 -sPAPERSIZE=a4 \
      -dQuality=$q -sOutputFile=tiger$q.prn tiger.ps 
done

Quality   Time(s)  FileSize     Printing time (time cat tiger0..9.prn >
/dev/lp0)
  0        33.2     1986522       18.5  OK but top margin is approx
0.9cm smaller than for other settings.
  1       112.1     7118815       68.0  OK
  2       110.6     7118808       error in output (empty pages and
garbage)
  3       116.1         955 !!
  4      signal 11
  5       191.5     9977020      121.0  OK
  6       190.2         605 !!
  7       198.7        2042 !!
  8       356.4        2127 !!
  9       390.9        1549 !!
  
I have succesfully tested 3.1.3 with quality setting 0,1,2,3,5,6 and 8
so the last changes seem to have broken some settings.

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

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

Hi,

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

as I said, it is always a good thing to have some working code. We'll
want to include some sort of color management with Gimp-2.0.  

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

Read the code. I'm sorry, but AFAIK that's the only source of information 
so far. There are two modules implemented in the current developers 
version (CVS or 1.1.21). Have a look at

	modules/cdisplay_gamma.c
	modules/cdisplay_highcontrast.c

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

You could store that information using parasites. That would easily 
allow to have different plug-ins share the same profile data.

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

It wasn't my intention to discourage you. It's nice to see that someone
starts to take color managment for GIMP serious.



Salut, Sven

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

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

Robert L Krawitz wrote:

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

I'll try to explain. The 720Softweave is impeccable to be as far as the
artifacts are concerned. The face-hair border looks fine and so do the
shadows under the lower lip and between the lips.

In 1440Enhanced an extra line shows up in the face. It seems tohave
constant distance from the hair. On my monitor, it is about a millimeter
away. The missing yellow in the top could be caused by a printer
problem.

2880x720 shows the extra line on the face at a larger distance and
darker. The missing yellow in the top shows up most clearly here. The
shadows under the lower lips does not look good, but this may be a
gamma/curves problem. But let's disregard this resolution.

1440 High Quality looks okay, but suffers a bit from the wormy textures.
Maybe thowse works are also cousing the other problems I've seen, and I
should switch to adaptive Floyd-Steinberg.


Thomas

[Gimp-print-devel] More stuff

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

I've reduced the use of black ink, which should improve the graininess
people saw in dark-mid gray tones.  I got too aggressive last time in
an attempt to reduce ink use, but unfortunately it went too far.

There are some bug fixes for the ESC 440 (so it should finally do
softweave correctly), and another bug fix for 360 dpi mode that may
improve performance on the ESC 900.  I've also incorporated
Jean-Marc's new ink constants for the ESP 870.

Now I gotta go eat.  I want to cut 3.1.4 soon, though, because there
seem to be a lot of improvements over 3.1.3 already.

-- 
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] Color Management for Better Prints

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

   Date: Wed, 3 May 2000 20:40:25 -0400
   From: Karl Heinz Kremer <kh...@kh...>

   Everything is already there. The LCMS library can work on either an
   array of bytes of RGB values or on three values from a table (for
   indexed images), it will write it's output into a new array (or
   return just the values for the color index). All I have to do
   is open two profiles, connect them to a transformation. This
   transformation then gets a pointer to the input data, a=20
   pointer to the output data and that's it.=20

Well, lessee...we already call an RGB->RGB function (or black, or
indexed, but whatever), so I guess it shouldn't be too hard to do the
same thing using LCMS...

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

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

On Wed, May 03, 2000 at 07:55:50PM -0400, Robert L Krawitz wrote:
>    Date: Wed, 3 May 2000 09:54:15 -0000
>    From: Karl Heinz Kremer <kh...@kh...>
>=20
>    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.
>=20
> Yes, this sounds extremely interesting.  What kind of facilities would
> the plugin (and Ghostscript driver) need to take advantage of this?
> Of course, Ghostscript needs much the same treatment...


Everything is already there. The LCMS library can work on either an
array of bytes of RGB values or on three values from a table (for
indexed images), it will write it's output into a new array (or
return just the values for the color index). All I have to do
is open two profiles, connect them to a transformation. This
transformation then gets a pointer to the input data, a=20
pointer to the output data and that's it.=20

=2E.. and of course you need a way to specify the path to the
profiles.=20


Other than that a fast CPU would help :-) Actually it's not that
bad: The LCMS library is optimized for speed.=20

Karl Heinz

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

Re: [Gimp-print-devel] Color management

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

   Date: Wed, 3 May 2000 20:25:42 -0400
   From: Karl Heinz Kremer <kh...@kh...>

   On Wed, May 03, 2000 at 08:11:31PM -0400, Robert L Krawitz wrote:
   > Interesting that this hit LinuxToday just today.  Agfa Monotype is
   > apparently making their stuff available, although there aren't any
   > real details on it.  I'm presuming it will not be open source; a free
   > solution would be highly desirable.

   As I understand the press release this solution is not even free
   as in beer. I think they are just offering a Linux solution=20
   in addition to a Windows/Mac/other Unix solutions to the same
   conditions.

That doesn't surprise me.  You'll note that one followup comment was
about implications for the Gimp.  I think it would be quite nice to
have our own answer to this stuff, somehow...

Re: [Gimp-print-devel] Color management

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

On Wed, May 03, 2000 at 08:11:31PM -0400, Robert L Krawitz wrote:
> Interesting that this hit LinuxToday just today.  Agfa Monotype is
> apparently making their stuff available, although there aren't any
> real details on it.  I'm presuming it will not be open source; a free
> solution would be highly desirable.

As I understand the press release this solution is not even free
as in beer. I think they are just offering a Linux solution=20
in addition to a Windows/Mac/other Unix solutions to the same
conditions.

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

[Gimp-print-devel] Color management

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

Interesting that this hit LinuxToday just today.  Agfa Monotype is
apparently making their stuff available, although there aren't any
real details on it.  I'm presuming it will not be open source; a free
solution would be highly desirable.

http://linuxtoday.com/stories/21196_flat.html

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

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

   Date: Wed, 3 May 2000 09:54:15 -0000
   From: Karl Heinz Kremer <kh...@kh...>

   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.

Yes, this sounds extremely interesting.  What kind of facilities would
the plugin (and Ghostscript driver) need to take advantage of this?
Of course, Ghostscript needs much the same treatment...

-- 
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 23:21:37 +0000
   From: Jean-Marc Verbavatz <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.

I should quit being such a cheapskate.  Then again, I sometimes burn
through a cartridge a week, doing all this testing.

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

We have to solve this.  The repository is much better than even 3.1.3,
but it's still not perfect.

   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.

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.

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

I hope not, but it's been exceedingly difficult to get right thus far.

   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.

Actually, gray IS printed as CMY (and LC and LM as appropriate) until
it gets quite dark.  And currently, there's some CMY mixed in all the
way to almost 100% black.

I think that the black threshold is a bit too low right now.  It's
also possible that the density value that's being used to compute the
size of the black dot is wrong.  Try changing this:

	  tk = print_color(d, &(d->k_dither), bk, bk, k, x, row, kptr,
			   NULL, bit, length, 0, 0, 0, 0);

to

	  tk = print_color(d, &(d->k_dither), bk, bk - d->k_lower, k, x, row, kptr,
			   NULL, bit, length, 0, 0, 0, 0);

What this will do is decide what kind of black dot to print based on
the difference between the black value and the lowest value at which
black is printed, rather than the absolute black value.  So that would
use smaller dots.  Let me know how it works.

   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.

Not at all.  You're coming up with entirely too many good ideas and
expressing them entirely too well for that :-)  Please, keep those
ideas and code flowing!

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

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

   Date: Wed, 03 May 2000 23:38:20 +0200 (CEST)
   From: regis rampnoux <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?  ...

No, what UNIX command to use to send the file to the printer..

   > * 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, I don't understand how that works.  The printer doesn't know
what kind of ink cartridge is in the printer; if you try to send
something to the printer, presumably something will create the color
separations and send each color to the printer.  Without something or
other to tell it, how will the driver know that "yellow" is really
some percent gray?  Surely you have to tell it somehow that you're
trying to print a black and white picture using special inks, rather
than a color picture using color inks (or a black and white picture
using color inks), no?

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

There's some stuff; check out README.dither (which is a bit out of date).

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