gimp-print-devel

[Gimp-print-devel] New dither codes

[Thorsten S. <tho...@sc...>]

Hi,

I've done some testing of the new dither codes on my old stylus 440. All
in all, they look much better than what they used to, but there are
still problems.

360 dpi:

hybrid FS and adaptive hybrid: some artefacts in a ligt area next to a
dark one: I get a row of black pixels just next to the dark area.

random FS and adaptive random: zigzag lines in dark-grey areas (greenish
and reddish ones). 

I don't see much difference between the adaptive and non-adaptive
versions

720dpi microweave:

Only tested adaptive random, same artefacts in dark areas, only
stronger, probably because the image in total is noticeable darker (I
didn't adjust the controls). Light skintones are better, darker ones
look very greyish (I expect some experimentation with the levels will
help here). 

720 softweave:
"broken", the image looks very blurry, bottom edge of the image looks
'broken' (i.e as if you abort a print and it has only printed some of
the paths), noticeable banding, looks like some layer is printed a few
pixels too low.


thorsten

-- 
----------------------------------------------------------------------- 
                                                       Thorsten Schnier
                                    
                                             School of Computer Science
                                               University of Birminghan
                                                                       
                                               
T.S...@cs...   
                                                   tho...@sc...

Re: [Gimp-print-devel] Installation problem

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

On Fri, Apr 28, 2000 at 10:45:14AM +0100, ale...@ds... wr=
ote:
> Dear all,=20
>=20
>=20
> I tryed many times to install Gimp-print-3.1.3 under Linux Suse 6.2 but=
=20
> unfortunately I got always the same error message. =20
> When I start the "configure" script, after few seconds appear the=20
> message=20
>=20
> ./configure: LP_DEF: command not found=20
> ./configure: LPSTAT_DEF: command not found=20
> checking for gimptool... /usr/bin/gimptool=20
> checking for GIMP - version >=3D 1.0.0... no=20
> *** Could not run GIMP test program, checking why...=20
> *** The test program failed to compile or link. See the file config.log=
=20
> for the=20
> *** exact error that occured. This usually means GIMP was incorrectly=20
> installed=20
> *** or that you have moved GIMP since it was installed. In the latter=20
> case, you=20
> *** may want to edit the gimptool script: /usr/bin/gimptool=20
> configure: error: Cannot find GIMP libs: Is gimptool in executable=20
> path? =20
>=20
>=20
> What does it mean?=20
> I think that my Gimp version is 1.1.7 and it works well.=20

Alessandro,

you probably installed the gimp RPM from the SuSE distribution. This is
not enough: You also need the libgimpd package, which contains all the
header files, libraries and other support files to compile software=20
using the Gimp libraries.=20

Karl Heinz

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

[Gimp-print-devel] spec files to create gimp-print and ghostscript RPMs

[Mark H. <be...@uk...>]

I've created the following:

  http://www.beanz.uklinux.net/download/ghostscript-5.50.spec
  http://www.beanz.uklinux.net/download/gs.spec.diff
  http://www.beanz.uklinux.net/download/gimp-print.spec

They are basically spec files for building RPMs from print-3.1.3.tar.gz.
The .diff file is a patch against the original RedHat 6.2 ghostscript spec
file.

To build binary RPMs, you'll need to do the following:

Get print-3.1.3.tar.gz and put it in /usr/src/redhat/SOURCES
Copy gimp-print.spec and gs.spec.diff to /usr/src/redhat/SPECS
Install ghostscript-5.50-1.src.rpm (the RH 6.2 ghostscript source RPM).
Apply the patch to the spec file. That is:

  cd /usr/src/redhat/SPECS
  patch -p0 <gs.spec.diff

Rebuild the RPMs. That is:

  rpm -ba /usr/src/redhat/SPECS/ghostscript-5.50.spec
  rpm -ba /usr/src/redhat/SPECS/gimp-print.spec

You should be left with source/binary RPMs in /usr/src/redhat/SRPMS/ and
/usr/src/redhat/RPMS/$ARCH resp.

I've been a little lazy and not changed the name of the ghostscript package
(or the version) so you might have to use --force to install it over the
RedHat ghostscript RPM.

Hopefully someone with a faster/cheaper net connection will make source/binary
RPMs available?

Cheers,
 Mark.

Re: [Gimp-print-devel] Matrix results

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

   Date: Fri, 28 Apr 2000 08:38:53 +0200
   From: Thomas Tonino <tt...@bi...>

   > I noticed that too.  Dark tans did even worse, with nasty green
   > splotches.  I don't understand that at all; I would expect ordered
   > dither to do very well on such regions, and I certainly wouldn't
   > expect splotches.

   Maybe it has to do with the way the matrices interleave: only a single
   matrix is used. If we would use a different matrix per color, or maybe
   nu use 65535-matrixvalue, results would be different.

It's using a different variation on the matrix for each color, but the
matrices aren't random enough so that there's no correlation.  We
probably really do need different matrices for each color.

   Green might work well because cyan and magenta use matrixvalue and
   65535-matrixvalue. Cyan and black use both matrixvalue - is this matrix
   shifted in some place, or rotated perhaps? It could be worthwhile trying
   the same matrix for all colors, or use something simple like a shift of
   half the matrix width. I'll try that.

It's both shifted and rotated.

   > I suggest using 1440 highest quality.  720 softweave is fast, but it
   > shows a lot of banding.  We need 720 to work well (and 360, for that
   > matter), but for absolute highest quality there's no substitute for
   > 1440.

   It definitely does bad a little. I was a bit disappointed with 1440, but
   that may well have been my choice of dither and not a problem with the
   resolution.

All of these printers band a little, especially at high ink density.
I have test shots I've picked up at the Epson booth at the Hunt's
camera show in Boston, made on a 1200, that show banding.  It's worst
in moderately dark areas.  I think it's due to too much ink being
dropped, and pooling up in some cases.  The iterated-2 matrix, when
not used very carefully, is particularly prone to banding at 1440 (and
even at 720 on some of the newer printers) because of its tendency to
print every other dot.  This gives alternate halves of the interleave
very different amounts of ink.  Another reason to avoid that matrix.

The weave algorithm won't currently support an 8-pass solution with 32
jets and a separation of 8 (i. e. the EX and the 600).  It would work
on a 1200 or 1270 (48/6).  If I can fix that (and if you think the
dither code is bad, try reading the weave computation -- I don't even
understand that, and it's my code!) it should result in even smoother
output than the 4 passes used by 1440x720 highest quality (of course,
it will print even slower than it does now).  There might also be a
way to fake it.

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

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

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

Re: [Gimp-print-devel] error_t redefined

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

   Date: Fri, 28 Apr 2000 12:41:59 +0200
   From: Sven Neumann <neu...@un...>

   we have received a bug report stating that gimp-1.1.20 can not be
   compiled on some systems since error_t is already defined in
   /usr/include/errno.h.

   I have changed the offending name to dither_error_t in gimp CVS and
   I suggest you do something similar to your code. Actually, after I
   discovered that the definition is never used, I have commented it
   out.

Thanks.  It's already been cleaned up in the development tree.

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

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

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

[Gimp-print-devel] error_t redefined

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

Hi,

we have received a bug report stating that gimp-1.1.20 can not be compiled
on some systems since error_t is already defined in /usr/include/errno.h.

I have changed the offending name to dither_error_t in gimp CVS and I suggest 
you do something similar to your code. Actually, after I discovered that the
definition is never used, I have commented it out. 


Salut, Sven

[Gimp-print-devel] Installation problem

[<ale...@ds...>]

Dear all,



I tryed many times to install Gimp-print-3.1.3 under Linux Suse 6.2 but
unfortunately I got always the same error message. 

When I start the "configure" script, after few seconds appear the
message


<fontfamily><param>Palatino</param>./configure: LP_DEF: command not
found

./configure: LPSTAT_DEF: command not found

checking for gimptool... /usr/bin/gimptool

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/bin/gimptool

configure: error: Cannot find GIMP libs: Is gimptool in executable
path? 



What does it mean?

I think that my Gimp version is 1.1.7 and it works well.


Thanks in advance



				Alessandro

</fontfamily>

*****************************************

 Alessandro Piras, 

 Dipartimento di Scienze e Tecnologie Chimiche

 Universita' degli Studi di Udine

 via Cotonificio 108, 33100 Udine, Italy

 tel.	+390432-558865

 fax.	+390432-558803

 email	Ale...@ds...

*****************************************

Re: [Gimp-print-devel] Matrix results

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

Robert L Krawitz wrote:

>    Results: my printer prints darker than yesterday (that was with 3.1.3).
> 
> I presume you updated MATRIX4_SIZE appropriately?

Yes. Actually my first try was the 23x23 matrix, but scaled to a
different maximum values than 23x23. The result was that cyan and black
were printed with very high density, while no yellow or magenta were
printed.

> I noticed that too.  Dark tans did even worse, with nasty green
> splotches.  I don't understand that at all; I would expect ordered
> dither to do very well on such regions, and I certainly wouldn't
> expect splotches.

Maybe it has to do with the way the matrices interleave: only a single
matrix is used. If we would use a different matrix per color, or maybe
nu use 65535-matrixvalue, results would be different.

Green might work well because cyan and magenta use matrixvalue and
65535-matrixvalue. Cyan and black use both matrixvalue - is this matrix
shifted in some place, or rotated perhaps? It could be worthwhile trying
the same matrix for all colors, or use something simple like a shift of
half the matrix width. I'll try that.

> I suggest using 1440 highest quality.  720 softweave is fast, but it
> shows a lot of banding.  We need 720 to work well (and 360, for that
> matter), but for absolute highest quality there's no substitute for
> 1440.

It definitely does bad a little. I was a bit disappointed with 1440, but
that may well have been my choice of dither and not a problem with the
resolution.


Thomas

Re: [Gimp-print-devel] Matrix results

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

   Date: Thu, 27 Apr 2000 21:56:07 +0200
   From: Thomas Tonino <tt...@bi...>

   I just put a 73 size matrix in gimp-print in place of the 23 matrix in
   the cvs version. To enable it I replaced all occurrences of DITHERPOINT
   with DITHERPOINT(d, x, y, 4) or similar. Where two DITHERPOINT macros
   were used with a xor, I took one out.

That's an ugly hack, actually, and I think it causes problems.

   Results: my printer prints darker than yesterday (that was with 3.1.3).

I presume you updated MATRIX4_SIZE appropriately?

   Ordered dither does bad for very dark neutral tones. The result is
   splotchy for dark blue/grey, but is fine for dark green. Seems to be a
   problem with black.

I noticed that too.  Dark tans did even worse, with nasty green
splotches.  I don't understand that at all; I would expect ordered
dither to do very well on such regions, and I certainly wouldn't
expect splotches.

   Both ordered and random FS and adaptive random look very sharp. Hybrid
   FS and adaptive hybrid look definitely out of focus. This is all in the
   Photo setting, 720 softweave, Stylus COlor 600, by the way.

Hybrid has some real problems that I don't understand.  I would expect
it to be like random FS, except with better frequency behavior.  But
that isn't the case.

   The results look promising. I wonder where the error diffusion artifacts
   come from. Error diffusion looks so clean, but code turns so complex as
   soon as you make it do the things you want. It does look like a case of
   overflow however.

I believe that.  There are a number of places in the code where things
get awfully close to 2^32, and it's possible that I missed something.
Long long arithmetic is much slower, though...

   I'll try again tomorrow. Then I'll benchmark againt the same CVS version
   that I will be patching. Does anyone have suggestiond for which settings
   to use: My current preference is 720 softweave, Photo, and then use
   Ordered dither and compare to FS Random (favourite it seems). Maybe
   comparing to Hybrid FS or Adaptive Hybrid (hmmm, confusing names :() is
   also a good idea.

I suggest using 1440 highest quality.  720 softweave is fast, but it
shows a lot of banding.  We need 720 to work well (and 360, for that
matter), but for absolute highest quality there's no substitute for
1440.

BTW, how do people feel about random FS vs. adaptive random?  The
adaptive behavior ought to reduce the artifacts in pale regions.

-- 
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] print-3.1.3/Ghost + GS 6.01 + Epson 740

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

   Date: Thu, 27 Apr 2000 20:38:31 +0200
   From: Frank van Maarseveen <F.v...@in...>
   Cc: gim...@li...

   On Wed, Apr 26, 2000 at 07:42:09PM -0400, Robert L Krawitz wrote:
   >    4  720 DPI Highest Quality		(doesn't work)
   >    5  1440 x 720 DPI Microweave		(doesn't work)
   >    6  1440 x 720 DPI Softweave		(ok)
   >    7  1440 x 720 DPI Highest Quality	(doesn't work)
   > 
   >    "doesn't work" means the printout was completely white or
   >    completely black, nothing in between so far.
   > 
   > If I remember right, none of the variable dot size printers will work
   > correctly with modes 4, 7, 8, or 9.

   I thought that the Epson 740 has a fixed dot size: spec says 6 picoliter.

It can generate three different size dots (you'll see that there are
two different ink types enabled for it: single dot size and variable
dot size).  You're not being cheated in any event; 1440x720 Softweave
still gives you four passes.

Re: [Gimp-print-devel] print-3.1.3/Ghost + GS 6.01 + Epson 740

[Frank v. M. <F.v...@in...>]

On Wed, Apr 26, 2000 at 07:42:09PM -0400, Robert L Krawitz wrote:
>    4  720 DPI Highest Quality		(doesn't work)
>    5  1440 x 720 DPI Microweave		(doesn't work)
>    6  1440 x 720 DPI Softweave		(ok)
>    7  1440 x 720 DPI Highest Quality	(doesn't work)
> 
>    "doesn't work" means the printout was completely white or
>    completely black, nothing in between so far.
> 
> If I remember right, none of the variable dot size printers will work
> correctly with modes 4, 7, 8, or 9.
I thought that the Epson 740 has a fixed dot size: spec says 6 picoliter.

-- 
Frank

[Gimp-print-devel] Matrix results

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

Hi dither colleagues,

I just put a 73 size matrix in gimp-print in place of the 23 matrix in
the cvs version. To enable it I replaced all occurrences of DITHERPOINT
with DITHERPOINT(d, x, y, 4) or similar. Where two DITHERPOINT macros
were used with a xor, I took one out.

Results: my printer prints darker than yesterday (that was with 3.1.3).

Ordered dither does bad for very dark neutral tones. The result is
splotchy for dark blue/grey, but is fine for dark green. Seems to be a
problem with black.

Testing with a greyscale (somewhat fuzzy, jpeg) image with some tiny
text shows that ordered leaves the text sharpest. Ordered also has
highest color noise however around the text edges.

Both ordered and random FS and adaptive random look very sharp. Hybrid
FS and adaptive hybrid look definitely out of focus. This is all in the
Photo setting, 720 softweave, Stylus COlor 600, by the way.

Some problems: color while using the 73 size matrix and adaptive hybrid
and hybrid FS looks out of register. Here it is caused by some dark on
the face pic, lips etc, areas being printed in orange, the cyan moved
away to around the edge of these features.

I just found out I did not use the matrix I wanted to use, but one that
has a bit too much clustering. Bear with me while I generate the correct
matrix and will test again. I doubt the difference will be great.

The results look promising. I wonder where the error diffusion artifacts
come from. Error diffusion looks so clean, but code turns so complex as
soon as you make it do the things you want. It does look like a case of
overflow however.

I'll try again tomorrow. Then I'll benchmark againt the same CVS version
that I will be patching. Does anyone have suggestiond for which settings
to use: My current preference is 720 softweave, Photo, and then use
Ordered dither and compare to FS Random (favourite it seems). Maybe
comparing to Hybrid FS or Adaptive Hybrid (hmmm, confusing names :() is
also a good idea.


Thomas

Re: [Gimp-print-devel] Test Image

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

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

>    Date: Mon, 24 Apr 2000 19:28:21 -0400
>    From: Karl Heinz Kremer <kh...@kh...>
> 
>    Somebody asked for a test image the other day. If you have access
>    to a Mac unstuff program (or a Linux version) check out the
>    PhotoDisk test target at ftp://ftp.photodisc.com/pub/test_targets/
> 
> The macunpack program I found at ftp.uni-stuttgart.de couldn\'t unpack it.


I got mine from 

http://www.aladdinsys.com/

Somewhere on this page they offer a Linux beta version. They of course
want your email address and stuff, but the software works.

If somebody can give me 50MG on a ftp server I can upload the unpacked and
gzipped file. My provider does not allow that much space.

Karl Heinz

Re: [Gimp-print-devel] Test Image

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

   Date: Mon, 24 Apr 2000 19:28:21 -0400
   From: Karl Heinz Kremer <kh...@kh...>

   Somebody asked for a test image the other day. If you have access
   to a Mac unstuff program (or a Linux version) check out the
   PhotoDisk test target at ftp://ftp.photodisc.com/pub/test_targets/

The macunpack program I found at ftp.uni-stuttgart.de couldn't unpack it.

Re: [Gimp-print-devel] Dithers in 3.1.3

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

   Date: Wed, 26 Apr 2000 15:15:03 +0200
   From: Thomas Tonino <tt...@bi...>

   > BTW, can we have this discussion on the list, so that others can
   > participate?

   Here we are. I just got CVS set up. When the 'plain matrix' is in the
   source, I'll experiment a lot with them on my lowly Epson 600. Well, at
   least the printers shows any artefacts really well ;)

OK, it's in.  I also added a whole bunch of comments, which hopefully
help explain what's going on in that rat's nest.

-- 
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] Article: adaptive methods for dithering color images

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

   Date: Wed, 26 Apr 2000 16:15:21 +0200
   From: Thomas Tonino <tt...@bi...>

   What Riemersma dither does is look back at (say) the errors of the last
   100 pixels printed, weigh each with a scale factor, and use this as
   error when deciding to print the current pixel.

The problem is in the definition of "last 100 pixels".  The last 100
pixels actually generated are in a line, but I suspect it would work
better with 100 pixels in a semicircle centered on the point printed
(a two-dimensional Riemersma).

   I did make a suggestion to Robert that it might be possible to do
   something with the error buffer. Before using the value in the error
   buffer, distribute it partially away. The result is a very large
   distribution area.

Ah, the joys of open source.  Anyone can do anything.  Particularly
when I get around to writing documentation :-)

   Another suggestion I had was to use the required gray value (of error +
   input) to decide whether to print, and when it is decided to print, lay
   down color dot of the color that needs to be printed most from a color
   error perspective. Keep laying down different color dots in this
   position until the gray value is as it should be. This has the advantage
   of following the human eye sensitivity better than working per color.
   But it probably is very difficult to integrate with variable dot size
   and other clever rastering support.

Actually, what is currently done isn't too different.  It looks at the
value of the input to decide what one or two dot sizes (or tones) are
eligible for printing, and then decides from the input+error whether
to print based upon the scaled size of the dot.  It then decides which
dot to actually print based on a matrix or a random number, depending
upon the dither mode.

   The problem with the above is that for every dot to be printed, one has
   to build a perception model and compare this with the perception model
   of the original image. This is very slow compared to the few shifts and
   adds that make up error distribution (although the implememntation as it
   is now also has quite some decisionmaking built in).

There's a lot of decision making, but I've tried to cut down on the
amount of branching actually going on.  It's the combination of
various decisions that make print_color so ugly.

-- 
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] Dither matrices

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

   Date: Thu, 27 Apr 2000 00:31:40 +0200
   From: Thomas Tonino <tt...@bi...>

   I built a new dither matrix generation program. For every matrix, you
   first choose the first 3 pixels to be set by hand.

That sounds very good.  It lets us generate several different matrices
by just tweaking different initialization parameters.

   The program is still rather slow, as for every level in the matrix
   (width^2) it tests every position (width^2) for distance to any other
   position (width^2).

A reasonable optimization might be to check every position for
distance up to some maximum distance.  I don't know whether that would
ruin the even distribution of values or not; it would certainly speed
things up for large matrices.

-- 
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] Article: adaptive methods for dithering color images

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

   Date: Wed, 26 Apr 2000 14:59:05 +0200
   From: Hrafnkell Eiriksson <he...@kv...>

   What viewing distance do you juse to judge the performance of 
   dithering?

I try to use a variety of distances.  Viewing an 8x10 (20x25 cm) on
glossy film from less than about 30 cm, I can't see any artifacts.

   > It's mostly all cut and try.  I should probably stop coding for a
   > while and actually write some documentation on what's going on.

   I would appreciate that. Its difficult to follow some things in
   the dithering code. 

It does need cleanup.  It's better than it was pre-3.1.3, but it's
already started to accrete.

Re: [Gimp-print-devel] Article: adaptive methods for dithering color images

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

   Date: Wed, 26 Apr 2000 17:27:59 +0200
   From: Hrafnkell Eiriksson <he...@kv...>

   On Wed, Apr 26, 2000 at 05:16:11PM +0200, Jean-Jacques de Jong wrote:
   > I checked with the authors of the above article as inventors and didn't
   > find anything. There is however a black period: patents are published
   > only upon grant in the US and 18 months after their filing date in the
   > other countries. If the patent was filed only in the US, we might well
   > be in the black period.

   The article is published in july 1997. There have passed 34 months since
   it was published. The manuscript was received first in march 1996.
   The work in the article was not supported by any US grants.
   The authors live in Turkey and work there.
   I guess we are outside the black period?

My real point (which I should have made clear) was whether the paper
itself said anything about a patent.  Since it didn't, I'm comfortable
with it.  If someone does have a patent on it and sends us a cease &
desist, we can worry about it then.  Given that we're not selling
this, I suspect that the most anyone could do is ask us to stop using it.

   Actually there is an email address included, ak...@bo....
   Someone might just want to contact her if we find out that the
   work in the article gives us good results.

Well, that's the best suggestion yet :-)  Thank you for injecting some
rationality into 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] Dithers in 3.1.3

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

   Date: Wed, 26 Apr 2000 21:48:41 +0200
   From: Frank van Maarseveen <F.v...@in...>
   Cc: gim...@li...

   On Tue, Apr 25, 2000 at 07:25:16PM -0400, Robert L Krawitz wrote:
   > I'd like something bigger than that.  23x23 is only 469, and that
   > doesn't give enough resolution to handle very pale tones.  73x73 is
   > smaller than ideal also (5329), but it's in the right ballpark.  The
   > matrices currently in use are 128, 81, and 125.  A matrix of size 121
   > (picked out of thin air) would take about 3 weeks to calculate, then.

   Sorry for this dumb question but: you mean the matrix or any picture
   produced with it?

The matrix itself.  Dithering an image from an existing matrix is very
fast.  The matrix would be statically generated.

   Has it been tried to fill such a matrix with the output of a random
   number generator? There are a lot of pretty good RNGs.

Thomas Tonino explained that -- white noise makes a very poor dither
because of the wide range of frequency components.  Blue noise (noise
with dominant high frequency components) would work well, but it's
harder to generate.  That's where a well-designed matrix comes in --
it contains precomputed "noise".

-- 
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] print-3.1.3/Ghost + GS 6.01 + Epson 740

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

   Date: Wed, 26 Apr 2000 23:16:05 +0200
   From: Frank van Maarseveen <F.v...@in...>

   I like the result. For photographs with pale areas the result
   is definately better than ghostscript 6.01 uniprint. Still, I
   think it could be improved.

   For epson 740, the following -dQuality has been tested:

   4  720 DPI Highest Quality		(doesn't work)
   5  1440 x 720 DPI Microweave		(doesn't work)
   6  1440 x 720 DPI Softweave		(ok)
   7  1440 x 720 DPI Highest Quality	(doesn't work)

   "doesn't work" means the printout was completely white or
   completely black, nothing in between so far.

If I remember right, none of the variable dot size printers will work
correctly with modes 4, 7, 8, or 9.  However, that's not a serious
problem; mode 6 is equivalent to mode 7 on other printers (same number
of passes).  I'm not too concerned with the microweave on that
printer, either (it's probably extremely slow).

   -dDither tested:
   0  Hybrid Floyd-Steinberg		(minor artifacts)
   2  Random Floyd-Steinberg		(good)
   4  Adaptive Random Floyd-Steinberg	(good)

   2 and 4 are practically identical.
   Common parameters: -sDEVICE=stp -dModel=12 -dDensity=0.8 -r1440 -dImageType=2

Random and adaptive random should be almost identical, except in very
light areas, where the random Floyd-Steinberg gradually switches to
ordered dithering.  Likewise hybrid and adaptive hybrid.

   In the source I saw a papersize mentioned "4x6". GS bails out at the end
   reporting that it's an unknown paper size however. Same happens for
   "Postcard".

Ghostscript may not support them, but these paper sizes do exist, and
in the form of the Gimp plugin it can certainly support them.

   An SMP enabled dithering would be nice ;-)

For ordered dithering that wouldn't be too hard, although it would
require a fair bit of reorganization.  For Floyd-Steinberg it would be
very tricky, though, because of the error feedback.

   Thanks for the good work!

You're 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

[Gimp-print-devel] Dither matrices

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

I built a new dither matrix generation program. For every matrix, you
first choose the first 3 pixels to be set by hand.

The program then finds the position that is furthest from the other
pixels and puts a pixel there, and so on. At a certain time, every pixel
that can be set is adjacent to another pixel. Before this happens, the
program starts measuring distance to all pixels, applies a weighing
function to each, and chooses the position with the largest total of
weighed distances.

The weighing function must differentiate pixels that are nearby much
more than pixels that are far away, as there are many more pixels
farther away and these are less important.

It seems to work okay so far. As to Frank van Maarsseveen's remark about
pseudo random numbers in a matrix: that will work much faster than calls
to rand(), but not give better results.

The idea about building a matrix is that you can do better than white
noise, by making sure that pixels that print at the same time are
distributed more evenly than random, but not so evenly as to produce a
grid like structure.

I do that now by placing the next dot in the largest hole that was left
by the other dots - i.e. place the next dot on the place on the page
that is lightest.

My approach probably makes sense from a perceptional model: at low
densities, people perceive individual dots. At high densities the
individual dots disappear and something that takes more nearby dots into
account is needed: the more nearby the dot the more important it is.

The program is still rather slow, as for every level in the matrix
(width^2) it tests every position (width^2) for distance to any other
position (width^2).

It may be better to build a perceived model matrix (width^2) and update
it for every pixel that we set (width^2). This is then then checked
every iteration (width^2) for the lowest value (width^2).

That would be a 2*(width^4) operation - much better than width^6.
Mmm.... i'll build that tomorrow. First I'll see what comes out of my 73
pixel wide matrix - if it looks to be of any use.


Thomas

Re: [Gimp-print-devel] Dithers in 3.1.3

[Frank v. M. <F.v...@in...>]

On Tue, Apr 25, 2000 at 07:25:16PM -0400, Robert L Krawitz wrote:
> I'd like something bigger than that.  23x23 is only 469, and that
> doesn't give enough resolution to handle very pale tones.  73x73 is
> smaller than ideal also (5329), but it's in the right ballpark.  The
> matrices currently in use are 128, 81, and 125.  A matrix of size 121
> (picked out of thin air) would take about 3 weeks to calculate, then.
Sorry for this dumb question but: you mean the matrix or any picture
produced with it?

Has it been tried to fill such a matrix with the output of a random
number generator? There are a lot of pretty good RNGs.

-- 
Frank

[Gimp-print-devel] print-3.1.3/Ghost + GS 6.01 + Epson 740

[Frank v. M. <F.v...@in...>]

I like the result. For photographs with pale areas the result
is definately better than ghostscript 6.01 uniprint. Still, I
think it could be improved.

For epson 740, the following -dQuality has been tested:

4  720 DPI Highest Quality		(doesn't work)
5  1440 x 720 DPI Microweave		(doesn't work)
6  1440 x 720 DPI Softweave		(ok)
7  1440 x 720 DPI Highest Quality	(doesn't work)

"doesn't work" means the printout was completely white or
completely black, nothing in between so far.

-dDither tested:
0  Hybrid Floyd-Steinberg		(minor artifacts)
2  Random Floyd-Steinberg		(good)
4  Adaptive Random Floyd-Steinberg	(good)

2 and 4 are practically identical.
Common parameters: -sDEVICE=stp -dModel=12 -dDensity=0.8 -r1440 -dImageType=2

In the source I saw a papersize mentioned "4x6". GS bails out at the end
reporting that it's an unknown paper size however. Same happens for
"Postcard".

An SMP enabled dithering would be nice ;-)

Thanks for the good work!

-- 
Frank

Re: [Gimp-print-devel] Article: adaptive methods for dithering color images

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

Hi

On Wed, Apr 26, 2000 at 05:16:11PM +0200, Jean-Jacques de Jong wrote:
> I checked with the authors of the above article as inventors and didn't
> find anything. There is however a black period: patents are published
> only upon grant in the US and 18 months after their filing date in the
> other countries. If the patent was filed only in the US, we might well
> be in the black period.

The article is published in july 1997. There have passed 34 months since
it was published. The manuscript was received first in march 1996.
The work in the article was not supported by any US grants.
The authors live in Turkey and work there.
I guess we are outside the black period?

Actually there is an email address included, ak...@bo....
Someone might just want to contact her if we find out that the
work in the article gives us good results.

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