gimp-print-devel

[Gimp-print-devel] dither_cmyk broken

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

Hi all

The latest changes in print-dither.c (from 1.14 to 1.16) have
apparently broken dither_cmyk when black is used (i.e. CMYK mode).

It still works fine in CMY mode, but in CMYK mode the image
"fades" towards the bottom right and the colours aren't right.

Robert, if you still have the Tux logo I sent you, try printing
to file using "Deskjet 500C/540C" (CMY) and then "Deskjet 550C/560C"
(CMYK), then pcl-unprinting them.

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] build failure - printdefy.h

[Keith P. <em...@mt...>]

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

      From: Keith Parks <em...@mt...>
   
      Nicholas Piper <ni...@ni...>
   
         During make, gcc fails with the following;

      Looks like a dependancy issue in the makefile but I'm not
      qualified to fix it.
   
   OK, I believe I've fixed it.  My make evidently does things in an
   order which doesn't break things.
   
Works fine now, thanks.

Keith.

Re: [Gimp-print-devel] Re: HP DeskJet 9xx support?

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

Robert L Krawitz wrote:
> 
>    Date: Sat, 18 Mar 2000 13:05:44 -0500 (EST)
>    From: Eddie Maddox <ed...@mn...>
> 
>    I'm new to GIMP. I also just bought an HP DeskJet 952C printer. All the
>    9xx models support 2400x1200 resolution and the use of both premium and
>    real photographic paper.
> 
>    The GIMP 1.0.4 print config does not have the HP 900 series listed.  So, I
>    found that the 600 series is, for now, the next best to select. But it
>    only has 600x600.  Nor does it list photographic paper, only plain and
>    premium.
> 
>    Does HP publish the PCL (Printer Control Language) docs still? Or a
>    Technical Reference Manual? How may I obtain such? (I can't write code,
>    but I write little shell scripts some times.)
> 
>    So, when can we expect the next stable GIMP release with HP DeskJet 9xx
>    support?
> 
> Eddie,
> 
> I've forwarded this to gim...@so..., where we're
> working on the next generation Gimp print plugin.
> 

Hi Eddie

I am currently looking after the PCL driver for Gimp Print,
mainly to make sure that it carries on working!

Adding "photo" to the list of paper types is easy (I'll submit
it asap).

Adding extra resolutions is also easy, but the difficult bits are
the rest, for example:-

1/ I assume that the 900 series is two-cartridge (i.e. Black and CMY).
Do you know if there are any printers in the range that do NOT
use two carts? (e.g. my DJ 600 is single cart, but others in the
6xx range are two cart).

2/ There is currently no support for "photo ink" cartridges.

3/ Do you know how many levels of dither the 900 series supports?
The current driver does 2 level dithers only unless you select
the Deskjet 800 at 300 dpi (does this work on your printer?)
This is called "CRet" printing in the HP documentation.
I know that "PhotoRet" now exists, but I have no info on it (see
2/ above!).

4/ How many ink colours does the colour cartridge have? Is it just
CMY or are there "light" versions as well.

5/ What resolutions does your printer support? 

If you can provide me with some information I can put code in
for you to test.

I found that a good place to look for information about the HP
printers is in the Ghostscript driver by Martin Lottermoser at
ftp://ftp.sbs.de/pub/graphics/ghostscript/pcl3/pcl3.html
He has been through most, if not all, of the HP documentation
(and support people!) and gleaned as much of the information
as he could. Reading his comments it appears that much of the
HP documentation is out-of-date.

Dave Hill

-- 
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] Epson Stylus 660

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

Hrafnkell Eiriksson wrote:
> 
> Hi
> 
> I have just bought a Epson Stylus Color 660. I just installed
> v3.1.1 of the gimp-print plugin. I see that the Stylus 660
> is not listed in the setup for supported printers.

I have a Stylus Color 600. Haven't seen it print with the small dots the
UPD driver from Ghostscript uses. The 720 DPI modes work for the 600,
but the dots used are larger than what Ghostscript is using in the UPD
driver. We humble users can probably help here by doing a lot of
testing.

Even though the result from gimp-print is much much grainier (looks
indeed like 360 DPI) the colors and tones look better than
Ghostscript-UPD's.

> PS: Is the patent situation with dithering algorithms complicated?

I found out that at least the 'void-and-cluster ordered dithering
method' has been patented. Strange, because ordered dither (which is
done at the printer side) has been done for ages, and the ordered dither
that is used is not a mechanism, but a pre-generated data set. And that
would be copyrighted, not patented. And because the initial data set is
random, almost all of these would turn out to be unique. But in any
case: just using the void-and-cluster method gives results that are too
coarse for ink jet printing.

It might be worthwhile to try the few matrices that are on my website (
http://people.a2000.nl/ztonino/dither/files/64C for example) as the
randomizing data in the FS process. It is bound to be less visible than
true random noise. If the patent problems are too complicated for a
production environment, I'm willing to spend a day or more on an
"artistically created" equivalent. The good thing about void-and-cluster
generated random data is that it is of higher frequency than normal
random data: blue noise as opposed to white noise.


Thomas Tonino

[Gimp-print-devel] Epson Stylus 660

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

Hi

I have just bought a Epson Stylus Color 660. I just installed
v3.1.1 of the gimp-print plugin. I see that the Stylus 660
is not listed in the setup for supported printers.

I've been able to get output from the plugin in 360dpi mode 
when choosing Stylus 460, printing to a file and then catting
the file to /dev/lp0 (I'm currently using CUPS as a printing system
and it only accepts fileformats it understands, not raw data to
send to the printer).
When choosing higher resulutions the printer just feeds lots of
paper through it.

Can I help in getting the printer supported? I can both read
and write C code (I'm trying to understand print-escp2.c as
I am pretty sure my printer uses that printing language).
I've seen the documents on http://www.ercipd.com/isv/edr_docs.htm
but they don't mention the Stylus 660.
Are those documents the documents you use when writing the gimp-print
plugin?

Btw. I know that you guys are trying to improve the dithering code.
I just did a quick search for articles on error diffusion and inkjet
printing in the online article database at my university. I found
an article called "Error diffusion with ink reduction for high
quality and high resolution ink jet printing" by Joseph Shu at
Epson Palo Alto Labs. Have you seen it? It appeared in the proceedings of
IEEE International Conference on Image Processing 1995.

Thanks
  Hrafnkell

PS: Is the patent situation with dithering algorithms complicated?

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

[Gimp-print-devel] Re: HP DeskJet 9xx support?

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

   Date: Sat, 18 Mar 2000 13:05:44 -0500 (EST)
   From: Eddie Maddox <ed...@mn...>

   I'm new to GIMP. I also just bought an HP DeskJet 952C printer. All the
   9xx models support 2400x1200 resolution and the use of both premium and
   real photographic paper.

   The GIMP 1.0.4 print config does not have the HP 900 series listed.  So, I
   found that the 600 series is, for now, the next best to select. But it
   only has 600x600.  Nor does it list photographic paper, only plain and
   premium. 

   Does HP publish the PCL (Printer Control Language) docs still? Or a
   Technical Reference Manual? How may I obtain such? (I can't write code,
   but I write little shell scripts some times.)

   So, when can we expect the next stable GIMP release with HP DeskJet 9xx
   support?

Eddie,

I've forwarded this to gim...@so..., where we're
working on the next generation Gimp print plugin.

-- 
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] build failure - printdefy.h

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

   Date: Sat, 18 Mar 2000 23:57:38 +0000 (GMT)
   From: Keith Parks <em...@mt...>

   Nicholas Piper <ni...@ni...>

      During make, gcc fails with the following;

      gcc -DPACKAGE=\"print\" -DVERSION=\"3.1.2\" -DYYTEXT_POINTER=1 
   -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DRETSIGTYPE=void  -I. -I.  -I.               
		    -I/usr/X11R6/include -I/usr/local/lib/glib/include 
   -I/usr/local/include         -I/usr/local/include -DLOCALEDIR=\"""\"          
   -Wall                                                                   
   -DLPR_COMMAND=\"/usr/bin/lpr\"                              -g -O2 -c 
   printdefl.c
      In file included from printdefl.l:28:
      printdef.h:12: printdefy.h: No such file or directory
      make: *** [printdefl.o] Error 1

      I do aclocal;autoconf;automake;./configure;make and nothing seems
      amiss until then. This has happened for about a week now, but I
      thought I'd not mention it incase it went away again :-)

   Same here, but if I do a "make printdefy.h" after the failure, and then
   make again, everything completes OK.

   Looks like a dependancy issue in the makefile but I'm not
   qualified to fix it.

OK, I believe I've fixed it.  My make evidently does things in an
order which doesn't break things.

Re: [Gimp-print-devel] build failure - printdefy.h

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

   Date: Sat, 18 Mar 2000 14:07:11 +0000
   From: Nicholas Piper <ni...@ni...>

   During make, gcc fails with the following;

   gcc -DPACKAGE=\"print\" -DVERSION=\"3.1.2\" -DYYTEXT_POINTER=1 -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DRETSIGTYPE=void  -I. -I.  -I.                                -I/usr/X11R6/include -I/usr/local/lib/glib/include -I/usr/local/include         -I/usr/local/include -DLOCALEDIR=\"""\"          -Wall                                                                   -DLPR_COMMAND=\"/usr/bin/lpr\"                              -g -O2 -c printdefl.c
   In file included from printdefl.l:28:
   printdef.h:12: printdefy.h: No such file or directory
   make: *** [printdefl.o] Error 1

   I do aclocal;autoconf;automake;./configure;make and nothing seems
   amiss until then. This has happened for about a week now, but I
   thought I'd not mention it incase it went away again :-)

See if updating Makefile.am solves this problem.

Re: [Gimp-print-devel] build failure - printdefy.h

[Keith P. <em...@mt...>]

Nicholas Piper <ni...@ni...>

   During make, gcc fails with the following;
   
   gcc -DPACKAGE=\"print\" -DVERSION=\"3.1.2\" -DYYTEXT_POINTER=1 
-DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DRETSIGTYPE=void  -I. -I.  -I.               
                 -I/usr/X11R6/include -I/usr/local/lib/glib/include 
-I/usr/local/include         -I/usr/local/include -DLOCALEDIR=\"""\"          
-Wall                                                                   
-DLPR_COMMAND=\"/usr/bin/lpr\"                              -g -O2 -c 
printdefl.c
   In file included from printdefl.l:28:
   printdef.h:12: printdefy.h: No such file or directory
   make: *** [printdefl.o] Error 1
   
   I do aclocal;autoconf;automake;./configure;make and nothing seems
   amiss until then. This has happened for about a week now, but I
   thought I'd not mention it incase it went away again :-)

Same here, but if I do a "make printdefy.h" after the failure, and then
make again, everything completes OK.

Looks like a dependancy issue in the makefile but I'm not
qualified to fix it.

Keith.

[Gimp-print-devel] build failure - printdefy.h

[Nicholas P. <ni...@ni...>]

During make, gcc fails with the following;

gcc -DPACKAGE=\"print\" -DVERSION=\"3.1.2\" -DYYTEXT_POINTER=1 -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DRETSIGTYPE=void  -I. -I.  -I.                                -I/usr/X11R6/include -I/usr/local/lib/glib/include -I/usr/local/include         -I/usr/local/include -DLOCALEDIR=\"""\"          -Wall                                                                   -DLPR_COMMAND=\"/usr/bin/lpr\"                              -g -O2 -c printdefl.c
In file included from printdefl.l:28:
printdef.h:12: printdefy.h: No such file or directory
make: *** [printdefl.o] Error 1

I do aclocal;autoconf;automake;./configure;make and nothing seems
amiss until then. This has happened for about a week now, but I
thought I'd not mention it incase it went away again :-)

Nick.

-- 
Part 1 MEng Cybernetics; Reading, UK       http://www.nickpiper.co.uk/
Change PGP actions of my mailer or fetch key see website 2048/BEC44395 
OSS/Palm/iB/Crypto/Philosophy/Python/Asimov/MD/S25/GDay/B182/Ash/James

Re: [Gimp-print-devel] cvs help

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

> I just discovered that I can't be in my project working directory, I
> have to be in the actual print directory (I work in a different one to
> make sure nothing stomps over what I'm working on).

Oooh, that's really dangerous.  It's very easy to accidently back
out changes done by other people that way.  It's recommended that you
always work in just one directory.

There's no possible way for CVS to stomp on anything you've done.
If CVS notes a conflict during an update, it will make a backup
copy of the file you were working on.

Eric

[Gimp-print-devel] The repository

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

I've backed out the repository as of earlier this evening (print.c,
print.h, and Makefile.am).  Everything should compile now.

[Gimp-print-devel] The repository's busted

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

Right now nothing compiles.  Updates as things progress...

[Gimp-print-devel] Re: print print.h

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

On Thu, Mar 16, 2000 at 06:17:09PM -0800, Steve Miller wrote:
> Update of /cvsroot/gimp-print/print
> In directory cvs1.i.sourceforge.net:/tmp/cvs-serv12485
>=20
> Modified Files:
> 	print.h=20
> Log Message:

Steve,

please add log messages to your commits. Without them it is
really hard to understand what you did.

And, more important: Please update all your changes so that
the project compiles. I just spent some time tracking down
why you removed "image_type" from print.h. Only to see
that it's now back in again. But now something else is wrong,
I get the following error message:

print-util.c:499: conflicting types for `compute_lut'
print.h:234: previous declaration of `compute_lut'
make: *** [print-util.o] Error 1      =20

Is it possible that your problems (or mine :-) are caused
by an out of date gimp-print tree on your system? It's=20
usually a good idea to update the tree right before you
do a commit. This will in the worst case leave you with
conflicts that you can resolve on your system before you
do the actual commit.=20

Karl Heinz


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

Re: [Gimp-print-devel] cvs help

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

   Date: Thu, 16 Mar 2000 19:51:03 -0700
   From: "S. Miller" <sm...@rn...>
   CC: gimp-print-devel <gim...@li...>

   I just discovered that I can't be in my project working directory, I
   have to be in the actual print directory (I work in a different one to
   make sure nothing stomps over what I'm working on).  It turns out that
   none of the files I originally thought I committed actually were.  I
   copied everything into the real dir and tried again - everything worked
   (but I'm still getting this annoying log popping up).  But I do seem to
   be missing a file called print-printers.c, included from print-util.c
   (line 370).

It looks like a lot of stuff I added in 1.43 got smashed.  Did you do
a proper update and merge before committing?

Re: [Gimp-print-devel] cvs help

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

   Date: Thu, 16 Mar 2000 19:51:03 -0700
   From: "S. Miller" <sm...@rn...>
   CC: gimp-print-devel <gim...@li...>

   I just discovered that I can't be in my project working directory, I
   have to be in the actual print directory (I work in a different one to
   make sure nothing stomps over what I'm working on).  It turns out that
   none of the files I originally thought I committed actually were.  I
   copied everything into the real dir and tried again - everything worked
   (but I'm still getting this annoying log popping up).  But I do seem to
   be missing a file called print-printers.c, included from print-util.c
   (line 370).

print-printers.c gets built -- it's a generated file.

Re: [Gimp-print-devel] cvs help

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

   Date: Thu, 16 Mar 2000 19:02:26 -0700
   From: "S. Miller" <sm...@rn...>
   CC: gim...@li...

   Log message unchanged or not specified
   a)bort, c)ontinue, e)dit, !)reuse this message unchanged for remaining
   dirs
   Action: (continue) c
   cvs server: Up-to-date check failed for `Makefile.am'
   cvs [server aborted]: correct above errors first!
   cvs commit: saving log message in /tmp/cvsLzItSh

You have to first do a cvs update to pick up the changes (and merge
them in with yours).  After you do a cvs update, the commit will work.

   This was in spite of my doing a touch just before the commit.

   After two attempts at the makefile, I give up for today.  Could someone
   else try it?  The two gtk*.c files need to be added as source files. 
   With that, Step 1 is done.  This version mostly separates the GUI from
   the plug-in, and pulls the color, saturation, etc sliders into a
   separate popup.  There is a lingering problem with the two media option
   menus I will get fixed this weekend. Much more cleanup work remains, but
   it should be releasable by Monday morning.

Re: [Gimp-print-devel] cvs help

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

Karl Heinz Kremer wrote:
> 
> On Thu, Mar 16, 2000 at 07:02:26PM -0700, S. Miller wrote:
> > Trying again this evening:
> > In an emacs buffer called cvsrv3aU9:
> >
> > CVS:
> > ----------------------------------------------------------------------
> > CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
> > CVS:
> > CVS: Committing in .
> > CVS:
> > CVS: Modified Files:
> > CVS:  Makefile.am
> > CVS: Added Files:
> > CVS:  gtk_main_window.c gtk_color_window.c print_gimp.h
> > CVS:
> > ----------------------------------------------------------------------
> >
> > I discovered that when I killed the emacs window, I got a prompt
> > (apparantly written by some ex-DOS person) to abort, continue, or
> > reuse.  Choosing continue, it finished the commit (as far as I can
> > tell).  However, Makefile.am failed as follows:
> >
> > Log message unchanged or not specified
> > a)bort, c)ontinue, e)dit, !)reuse this message unchanged for remaining
> > dirs
> > Action: (continue) c
> > cvs server: Up-to-date check failed for `Makefile.am'
> > cvs [server aborted]: correct above errors first!
> > cvs commit: saving log message in /tmp/cvsLzItSh
> 
> Did you modify the log message? I just got a commit message regarding
> Makefile.am, but without a change log. When I do a cvs log Makefile.am
> I get the following:
> 
> revision 1.22
> date: 2000/03/17 02:00:13;  author: smiller;  state: Exp;  lines: +14 -28
> *** empty log message ***
> 
> So I guess your commit did work, the software (emacs) just did not
> like that your empty log message. Which file did you touch?
> 
> Karl Heinz
> 
Further adventures:

I just discovered that I can't be in my project working directory, I
have to be in the actual print directory (I work in a different one to
make sure nothing stomps over what I'm working on).  It turns out that
none of the files I originally thought I committed actually were.  I
copied everything into the real dir and tried again - everything worked
(but I'm still getting this annoying log popping up).  But I do seem to
be missing a file called print-printers.c, included from print-util.c
(line 370).

Steve



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

Re: [Gimp-print-devel] cvs help

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

Robert L Krawitz wrote:
> 
> That command looks correct.  What is the log stuff that you got?
> 
> --
Trying again this evening:
In an emacs buffer called cvsrv3aU9:

CVS:
----------------------------------------------------------------------
CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
CVS: 
CVS: Committing in .
CVS: 
CVS: Modified Files:
CVS: 	Makefile.am 
CVS: Added Files:
CVS: 	gtk_main_window.c gtk_color_window.c print_gimp.h 
CVS:
----------------------------------------------------------------------

I discovered that when I killed the emacs window, I got a prompt
(apparantly written by some ex-DOS person) to abort, continue, or
reuse.  Choosing continue, it finished the commit (as far as I can
tell).  However, Makefile.am failed as follows:

Log message unchanged or not specified
a)bort, c)ontinue, e)dit, !)reuse this message unchanged for remaining
dirs
Action: (continue) c
cvs server: Up-to-date check failed for `Makefile.am'
cvs [server aborted]: correct above errors first!
cvs commit: saving log message in /tmp/cvsLzItSh

This was in spite of my doing a touch just before the commit.

After two attempts at the makefile, I give up for today.  Could someone
else try it?  The two gtk*.c files need to be added as source files. 
With that, Step 1 is done.  This version mostly separates the GUI from
the plug-in, and pulls the color, saturation, etc sliders into a
separate popup.  There is a lingering problem with the two media option
menus I will get fixed this weekend. Much more cleanup work remains, but
it should be releasable by Monday morning.

Thanks,

Steve

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

Re: [Gimp-print-devel] Halftoning algorithms

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

This is just a quickie reply...your note contains a lot of technical
meat, far more than I know myself, and I need to digest it.

   Date: Thu, 16 Mar 2000 12:55:10 +0100
   From: Thomas Tonino <tt...@bi...>

   The gaussian blur needs to be larger than the largest distance between
   pixels to be printed. Calculating big gaussian blurs may be slow, but it
   can be optimized fairly well. Now compare the current pixel to the color
   formed by the blurred surrounding pixels and determine the optimal dot
   to print. Update the gaussian buffer with the current printed dot and
   move on to the next pixel to be printed.

It needs a bit more support in the infrastructure to make this
practical.  Right now the model is that the dither routine is passed a
row of input and generates a corresponding row of output.  That
doesn't allow for any lookahead or write behind, which would allow
much more flexibility.

   > BTW, something else that I've done, which seems to have done a lot to
   > eliminate the diagonals so common with error diffusion, is to
   > distribute the error over a variable number of pixels.  Specifically,
   > the lighter the tone, the broader the region over which the error is
   > distributed.

   Seems to be a good idea. Larger and different error distribution
   matrices have also been proposed in the past. Some I have found are:

Actually, what I'm doing is a pseudo-Gaussian.  It winds up with
something like

0  0  x  3  0
0  0  5  0  0

when there's a lot of ink.  Where dots are sparser, though, it becomes
(for example)

0   0   0   x  60   0  0
5  10  15  20  15  10  5

which is pseudo-Gaussian.  It works very well, but there are very fine
horizontal rows that (to my eye, at least) aren't very unpleasant.
Obviously it isn't really Gaussian, but triangular is close enough for
a first cut and fast computationally.  Interestingly, I tried
something like this:

0   0   0   x  30  20  10
5  10  15  20  15  10   5

and wound up with lots of grain again.  I *think* that the problem
here is the correlation between the two rows.

   Burkes:

   0  0  x  8  4
   2  4  8  4  2   /32

That's similar to what I tried and didn't like.

   Steven:

    0  0  0  x  0 32  0
   12  0 26  0 30  0 16
    0 12  0 26  0 12  0
    5  0 12  0 12  0  5   /200

I like the look of this one and of your suggestion.

   Basically the 0's in the above are places where we prefer pixels if the
   current dot is printed, the 1's are neutral and the 2's are discouraged.
   I do not know if the effect is sufficient - I feel the gaussian method
   may be better eventually because it has a perception model built in. It
   would even be possible to calculate wider gaussians for color and a
   tighter gaussian for perceived brightness, and determine what needs to
   be printed from the various results: the largest error gets corrected,
   basically.

   Sounds like quite a project though.

I think that we should start off with experimenting with the diffusion
matrix, just because it's easier to start with.  Of course, right now
we only support a two-row matrix, but that can always change...

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

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

   Date: Thu, 16 Mar 2000 16:08:05 +1100
   From: Chris Bitmead <ch...@ni...>

   I am looking for an A3 Photo printer, preferably one which works
   with Linux.  The Epson 1270 appears to be the best A3 printer
   judging by specs.

   I see that the 1270 is listed as "untested" and the variable size
   droplet feature is unsupported under Linux. Does this imply that
   the printer probably works, not including the variable droplet
   feature, or does it imply that it may not work at all?

The 1270 is completely untested thus far.  The variable drop size
stuff is tested to some degree (on a 740, primarily, although a few
people have used 1200's), but don't expect particularly good results
yet.  Also, it may or may not be back compatible with the 1200 -- I
assumed that it was (with no particular justification) and simply used
the 1200 driver for it.

   If I'm wanting an A3 printer should I get the Epson and use under
   Windows till better Linux support comes out or is there a better
   printer choice?

Well, if you can find a used Photo EX it's known that you'll get
pretty good results with it, because that's what I have and not too
surprisingly I've put the most effort into tuning it.  It's an
obsolete (or at least obsolescent) printer.

Of course, if you get a 1270 and want to help out by testing or even
coding that would be most welcome :-)

-- 
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] cvs help

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

   Date: Wed, 15 Mar 2000 20:57:11 -0700
   From: "S. Miller" <sm...@rn...>

   Then I did  cvs
   -ds...@cv...:/cvsroot/gimp-print commit
   gtk_main_window.c gtk_color_window.c print.c Makefile.am
   which is just sitting there (after accepting my password).  I did get an
   emacs window popped up with some log stuff in it, but nothing seems to
   be going out.  First, is the command I used correct?  If so, what else
   might I have done wrong or not done?  Any help would be greatly
   appreciated.

That command looks correct.  What is the log stuff that you got?

-- 
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] Halftoning algorithms

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

Karl Heinz Kremer wrote:

> I'm not sure if Thomas Tonino is on the list...I'm reading his message
> on geocrawler and I have comments on it.  If he's not, could someone
> forward him the message?  His email address doesn't appear in the
> archived message.

Yes, I'm on the digest.

> I once experimented with only allowing one dot to be printed if the
> density at that point was less than one.  It didn't help too much.

I think the other color will then be printed adjacent to the current
dot. This doesn't help much I would expect. The key is to print the
first dot much earlier, the second a lot later. It may be better to
leave yellow out of the darkness calculation - yellow is not very dark.

[ instability ]

> The problem was that not
> enough ink was getting printed to discharge all of the error, and the
> built-up error got printed out in white areas very strangely.  I wound
> up having to cap the accumulated error to avoid this.

The pseudocode has a while loop that keeps finding colors to print for
the current pixel, until the total error is gone. But it may well be
possible to have two colors at a maximum negative and two others at a
maximum positive error threshold. For pixels in values of 0 to 100 % in
a 4 color system I would expect the worst case to be the following case:

- All pixels are at 12.5 % error, giving a sum of 50% which is
threshold.
- The system fires one of the colors, bringing it to - 87.5% error.
- The other colors rise to 46 % ( 3 * 46 - 87.5 is just above the
threshold of 50) and one of them fires.
- This leaves one color in -87.5 % and another in 46 - 100 = -54 %. Now
the two remaining colors could rise to a sum of 191.5, so 96 % each. If
one colors prints now, we are left with the following state:

- 87.5%
- 54 %
- 4 %
+ 96 %

The gray value of this error is within bounds as is to be expected. The
color errors are double the errors of the non brightness aware dither.

This may be a problem or it may not be, but it points to an inherent
problem in Floyd-Steinberg: it is not built on a model of human vision.
Say we print two objects quite a distance apart. If one object gets too
little ink, the other one gets too much. This is not neccessary for
correct percetion: making one line thicker does not make th eother line
seem any thinner. It is the root of the color bleed problem described
above: what basically happens is that the system can and will compensate
for a lack of ink in one place by putting that ink on a totally
different place on the page.

It may be worthwhile to use a different method of dithering. Dithering
works because the eye sees things a little blurred. By modeling how that
blur works, we can get a better result.

By calculating a gaussian blur of the surrounding pixels (as far as they
have been printed) one gets a better match to perception: nearby pixels
have larger influence than pixels father away.

The gaussian blur needs to be larger than the largest distance between
pixels to be printed. Calculating big gaussian blurs may be slow, but it
can be optimized fairly well. Now compare the current pixel to the color
formed by the blurred surrounding pixels and determine the optimal dot
to print. Update the gaussian buffer with the current printed dot and
move on to the next pixel to be printed.

> BTW, something else that I've done, which seems to have done a lot to
> eliminate the diagonals so common with error diffusion, is to
> distribute the error over a variable number of pixels.  Specifically,
> the lighter the tone, the broader the region over which the error is
> distributed.

Seems to be a good idea. Larger and different error distribution
matrices have also been proposed in the past. Some I have found are:

Burkes:

0  0  x  8  4
2  4  8  4  2   /32

Stucki:

0  0  x  8  4
2  4  8  4  2
1  2  4  2  1   /42

Sierra:

0  0  x  5  3
2  4  5  4  2
0  2  3  2  0   /32

Steven:

 0  0  0  x  0 32  0
12  0 26  0 30  0 16
 0 12  0 26  0 12  0
 5  0 12  0 12  0  5   /200

I have no idea of what the design goal for these matrices is. Other ways
to decrease squigglies could be to forbid or discourage printing in
certain patterns and to distribute the error mainly to the place where
you do not want more dots to be printed:

      x  2  1
0  1  2  1  0
1  0  1  0  1   /10

Basically the 0's in the above are places where we prefer pixels if the
current dot is printed, the 1's are neutral and the 2's are discouraged.
I do not know if the effect is sufficient - I feel the gaussian method
may be better eventually because it has a perception model built in. It
would even be possible to calculate wider gaussians for color and a
tighter gaussian for perceived brightness, and determine what needs to
be printed from the various results: the largest error gets corrected,
basically.

Sounds like quite a project though.


Thomas Tonino
tt...@bi...

[Gimp-print-devel] Epson Stylus Photo 1270

[Chris B. <ch...@ni...>]

Hi,

I am looking for an A3 Photo printer, preferably one which works with
Linux.
The Epson 1270 appears to be the best A3 printer judging by specs.

I see that the 1270 is listed as "untested" and  the variable size
droplet
feature is unsupported under Linux. Does this imply that the printer
probably
works, not including the variable droplet feature, or does it imply that
it may not work at all?

If I'm wanting an A3 printer should I get the Epson and use under
Windows
till better Linux support comes out or is there a better printer choice?

Chris

[Gimp-print-devel] cvs help

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

I have some new GUI stuff ready to commit but can't seem to get cvs to
cooperate.  First I did:
 cvs -ds...@cv...:/cvsroot/gimp-print add
gtk_main_window.c gtk_color_window.c
 That seemed to work.

Then I did  cvs
-ds...@cv...:/cvsroot/gimp-print commit
gtk_main_window.c gtk_color_window.c print.c Makefile.am
which is just sitting there (after accepting my password).  I did get an
emacs window popped up with some log stuff in it, but nothing seems to
be going out.  First, is the command I used correct?  If so, what else
might I have done wrong or not done?  Any help would be greatly
appreciated.

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