gimp-print-devel

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

[Jean-Jacques de J. <jea...@hp...>]

sh...@al... wrote:
> 
> > Isn't it better just to let possible patent holders send a
> > "cease and desist" letter asking us to stop using their patented methods?
> 
> I don't think so.  It would mean having to go back and rip out a lot of
> working code if such a letter actually arrived.  It's a lot of work which
> is better avoided.  It's actually simpler and easier to check if it's
> patented.  If it is, that's still not a show-stopper.  Some patent holders
> grant royalty-free licenses to free software.
> 

This is a nice place to check for patents:

http://ep.espacenet.com/espacenet/ep/en/e_net.htm?search5

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.

JJJ

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

[Jean-Jacques de J. <jea...@hp...>]

Hrafnkell Eiriksson wrote:
> 
> On Wed, Apr 26, 2000 at 08:32:08AM -0400, Robert L Krawitz wrote:
> > That sounds very interesting.  We just have to make sure there's no
> > patent on it.
> 
> Isn't it better just to let possible patent holders send a
> "cease and desist" letter asking us to stop using their patented methods?
> If we don't look we are not willingly infringing the patent?
> I think I've seen this advice from someone somewhere.
> Any lawyers?

This is dangerous, especially in the US. However, I don't suspect patent
holders wanting to go any further than that (i.e. so far as suing a free
software developer). But anyway, this would mean a load of work dumped
in the trash can!
 
> Actually this method is rather obvious to "a master of the art" (as I
> think it is called in patent laws). Linear filtering is
> basic stuff to anyone learning signal processing and image analysis.
> Choosing coefficients for a linear filter kernel using the LMS
> algorithm is usually the subject of second course in signal processing.
> Just the fact that the signal happens to be an quantized image should
> not be considered enough to allow for a patent. (I think :)
 
This is a difficult question. In practice you have to convince a judge
who is likely to find the slightest technical improvement difficult to
understand, thus non obvious and patentable.

> And remember, software patents do not exist here in Europe :)
 
Ouch! NO! There are thousands of patents in Europe covering software in
the form of methods, which is about just as bad.

JJJ

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

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

On Wed, Apr 26, 2000 at 04:15:21PM +0200, Thomas Tonino wrote:
> Actually, it is not lowpass filtering, but it is determining how far the
> noise propagates. There is a thing called a 'Riemersma dither' that uses

Yes. What I meant is that there is a lowpass effect in it 
(although not 100% in the sense of linear filters). I probably should
never have mentioned it, its just the way I was thinkng about it when
I wrote my reply.

> An extension of that model would be something that actually knows about
> printer and observer capabilities, calculates the value of what has been
> produced so far, and bases a decision on that. That could be in the form

Ok, I'll admit, I've been searching for articles that might be interesting
for the project and that might teach me something about dithering methods :)
I've found two that describe model based dithering (based on a printer 
model and a perception model):

Thrasyvoulos N. Pappas and David L. Neuhoff: 
"Least-Squares Model-Based Halftoning"
IEEE Transactions on image processing, vol 8, no 8. august 1997

Thrasyvoulos N. Pappas:
"Model-Based Halftoning of Color Images"
IEEE Transactions on image processing, vol 6, no 7, july 1999

The model based methods are very interesting. They exploit characteristics
of the human visual system to get the best possible dithering.
They also compensate for dot overlap and such things (and use it to
get even better results).

I might have found even more articles but the printouts are not on
the surface of the pile of papers on my desk so I can't see them now :)

There is also an interesting book:
http://www.spie.org/web/abstracts/oepress/MS154.html
it includes the original paper by Floyd and Steinberg among other things.

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

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

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

Hrafnkell Eiriksson wrote:

> Yes photos and all natural images are "lowpass" in nature, that is they
> are mostly smooth regions. Spreading the error over a large area is ok there.
> Line art has hard edges, hard edges means high frequency content,
> so spreading the error there is worse, its a kind of lowpass filtering.

Actually, it is not lowpass filtering, but it is determining how far the
noise propagates. There is a thing called a 'Riemersma dither' that uses
a table to find the density printed so far. This means that your errors
do not prapagate all over the page. If you think about it, it is a bit
strange what happens if you print two dots. If one dot is printed a
little too small because of rounding, the other dot has a good chance of
getting a little bigger!

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.

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

JPEG used 8x8 pixel blocks to prevent fringing to occur too far from the
hard edge that caused it. With dither, the mechanism is rather
different. If less than half the error is transferred to the next pixel
horrible effects can occur. Say only 10% is transferred to the next
pixel, 10% two pixels to the right, etc. If we would print 60% gray
level, the pixel would be black, The second would be black too, as only
10% of the 40% that was printed too much is transferred there as error.
Only when one gets on the order of 10 pixels away do white pixels start
to form. This is actually okay for very light tints.

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.

By adjusting the amount that is re-distributed according to the density
of the current color pixel, one can prevent the above 'clipping' effect
from occuring.

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.

An extension of that model would be something that actually knows about
printer and observer capabilities, calculates the value of what has been
produced so far, and bases a decision on that. That could be in the form
of a heuristic that looks at the input value, looks at the immediate
area that has been printed so far and compare to what it should have
been, and determines what option would be the best fit. That could be as
simple as a two-dimensional version of Riemersma, or as complex as
something that also looks at contrast and disregards sharply contrasting
areas (i.e. if the background was just a bit too light here, do not make
the text on it any darker).

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


Thomas

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

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

> Isn't it better just to let possible patent holders send a 
> "cease and desist" letter asking us to stop using their patented methods?

I don't think so.  It would mean having to go back and rip out a lot of
working code if such a letter actually arrived.  It's a lot of work which
is better avoided.  It's actually simpler and easier to check if it's
patented.  If it is, that's still not a show-stopper.  Some patent holders
grant royalty-free licenses to free software.

> If we don't look we are not willingly infringing the patent?

That's not really true.

> I think I've seen this advice from someone somewhere.

Yeah, I've seen it posted on various "IANAL" slashdot comments.  Not really
the best place for legal advice.

The only difference this can possibly make is that the patent holder could
sue for extra damages if we knew we were in violation of the patent.  He
can still sue for the normal amount of damages even if we had truly never
heard of him before.  Trust me, whether he gets tripple damages or just
single damages doesn't matter to people like us, it could spell bankruptcy
either way.

It's better to check.

Eric

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

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

Robert L Krawitz wrote:

> Epson printers can only print dots at a spacing of 1/720 (or in some
> cases 1/360).  However, the carriage can be positioned to 1/1440 in
> many of these printers.  So what it does is generate the line at
> 1/1440 resolution, and then split it into two or four pieces by
> de-interleaving and printing each row separately.  The high and
> highest quality modes go further, up to a total of four passes per
> row.  In order to further reduce banding, each subpass is printed with
> a different jet.  It turns out that for the photo-quality glossy film
> it's essential to do something like this -- print too much ink too
> quickly and it all beads together, and the result is awful.  Printing
> the same image at 720 dpi and at 1440 dpi highest quality yields very
> different results -- at 720 dpi, there are heavy blotches; at 1440 dpi
> things are smooth.
> 
> It's possible to put ink at every position, but it's not a great
> idea to do so.  Most of the printers seem to be designed for about 60%
> coverage ("density") at 720 dpi, so at 1440 dpi the density is divided
> by two.

Yup. My point is that it matters which pixels you leave out to get at
the 60% coverage. It may be possible to have the Floyd-Steinberg
algorithm handle this, but it is also possible to do postprocessing of
some kind. I once had a dot matrix printer that did allow 360 DPI
horizontally, more or less. The problem was it would only print every
other dot. So when you printed:

XXXXX
XXXXXX

Out came:

X X X
X X X

Dot overlap with these printers was huge of course. But I got much
better text by sending the following to the printer, which would print
exactly as sent:

X X X
X X  X

It may be worthwhile to do something like this after the error diffusion
steps, which then could build to a 100 % covered area that later gets
transformed to something that doesn't soak the paper. This may not be a
huge win compared to Floyd-Steinberg doing this work for us. It is more
of a knee-jerk reaction of me to the comment that for 1440 DPI we only
print every other dot - but I realize that it probably works out just
fine if you print lines in alternating directions. But then it might
not, as the resulting pattern may be interfering in horrible manners
with any chequerboard patterns that might be in the generated dither.

I thionk that I used a very simple algorithm for the dot matrix: if 3
dots are 'on' sequentially, and only then, take out the middle dot.

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


Thomas

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

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

On Wed, Apr 26, 2000 at 08:32:08AM -0400, Robert L Krawitz wrote:
> That sounds very interesting.  We just have to make sure there's no
> patent on it.

Isn't it better just to let possible patent holders send a 
"cease and desist" letter asking us to stop using their patented methods?
If we don't look we are not willingly infringing the patent?
I think I've seen this advice from someone somewhere.
Any lawyers?

Actually this method is rather obvious to "a master of the art" (as I
think it is called in patent laws). Linear filtering is 
basic stuff to anyone learning signal processing and image analysis.
Choosing coefficients for a linear filter kernel using the LMS
algorithm is usually the subject of second course in signal processing.
Just the fact that the signal happens to be an quantized image should
not be considered enough to allow for a patent. (I think :)

And remember, software patents do not exist here in Europe :)
 
> dark colors, and have different combinations for different kinds of
> images (photos use wider spread than line art, for example).

Yes photos and all natural images are "lowpass" in nature, that is they
are mostly smooth regions. Spreading the error over a large area is ok there.
Line art has hard edges, hard edges means high frequency content,
so spreading the error there is worse, its a kind of lowpass filtering.

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

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

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

[Gimp-print-devel] Photo quality glossy film

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

I tried playing around with some of this recently (my wife and I want
to make a print from one of our wedding photos).  It's really nice
stuff.

The print characteristics are quite different from anything else, and
it takes rather different printer settings to work properly.  Most
importantly, it must be printed very slowly, to allow the ink to dry,
since the surface does not absorb ink.  This means that 1440 dpi
highest quality is required.  720 dpi softweave lays down too much ink
too quickly, with the result that everything blobs up.  However,
there's little sense in using this expensive media (I'm using
relatively cheap third party glossy film that I picked up at a show)
with anything less than maximum quality.

On the other hand, this paper requires very precise density
calibration, since the ink doesn't spread out (unless too much is laid
down too quickly).  For that reason, it also requires a more gentle
transition between CMY and K than ordinary paper does, since the black
won't spread out to fill the inter-dot gaps.  I suspect that a density
of .95 works well (since .9 was too low and 1.0 appears a bit too high).

Finally, the color balance is very neutral.

I've checked in preliminary support for glossy film to the Epson driver.

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

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

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

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

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

   Date: Wed, 26 Apr 2000 13:50:51 +0200
   From: Hrafnkell Eiriksson <he...@kv...>

   I would like to point you to an interesting article on using
   a Least Mean Square algorithm to choose the coefficients for
   the error diffusion filter kernel:

   Lale Akarun, Yasemin Yardimci and A. Enis Cetin:
   "Adaptive Methods for Dithering Color Images"
   IEEE Transactions on Image Processing, vol 6, no 7, july 1997.

That sounds very interesting.  We just have to make sure there's no
patent on it.

   "The scaling of the error diffusion filter coefficients is an important
    step in the performance of the algorithm. This scaling coefficient 
    controls the balance of false edges and color impulses; it can,
    therefore be varied in different regions of an image to
    achive different goals."

That's very interesting.  That's one of the few things I haven't
seriously tried.  I've found that adaptive filter coefficients are
helpful.  What I do now is use a wider spread for pale colors than for
dark colors, and have different combinations for different kinds of
images (photos use wider spread than line art, for example).

   The main point with that is that the coefficient of the Floyd Steinberg
   (and other) filter kernels sum up to one. By making the sum up to f.x.
   0.9 the effects of quantization error accumulation that leads to a
   disturbing color impulse in pale areas can be reduced.
   A first thing to try might be to use some heuristics to change a scale
   factor. I have a feeling that rlk has developed some heuristics he uses,
   at least in his head when playing with the dithering algorithms, that
   might be used.

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.

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

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

Hi

I would like to point you to an interesting article on using
a Least Mean Square algorithm to choose the coefficients for
the error diffusion filter kernel:

Lale Akarun, Yasemin Yardimci and A. Enis Cetin:
"Adaptive Methods for Dithering Color Images"
IEEE Transactions on Image Processing, vol 6, no 7, july 1997.

Quotes form the conclusion:
"The appearance of color impulses is greatly eliminated and smoother
 color transitions are achived"

and

"Both of the adaptive error diffusion algorithms show a distinct improvement
 in performance when compared with the Floyd-Steinberg filter"

Given that I have some time available after my exams this summer I 
would like to try to implement the algorithm.

One thing that some might like to try out from the article:

"The scaling of the error diffusion filter coefficients is an important
 step in the performance of the algorithm. This scaling coefficient 
 controls the balance of false edges and color impulses; it can,
 therefore be varied in different regions of an image to
 achive different goals."

The main point with that is that the coefficient of the Floyd Steinberg
(and other) filter kernels sum up to one. By making the sum up to f.x.
0.9 the effects of quantization error accumulation that leads to a
disturbing color impulse in pale areas can be reduced.
A first thing to try might be to use some heuristics to change a scale
factor. I have a feeling that rlk has developed some heuristics he uses,
at least in his head when playing with the dithering algorithms, that
might be used.

Just a thought...

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

Re: [Gimp-print-devel] Re: dithering stuff

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

On Tue, Apr 25, 2000 at 02:54:51PM -0700, Raph Levien wrote:
>=20
> Indeed. I expect to be releasing it as GPL soon, as planned. However,
> our son was just born yesterday, so I'm not doing things at 100%
> efficiency yet.

Bad timing... How could you do that when you are just about to release
important software... :-) Congratulations. Hope the mother and the baby
are doing fine.

Karl Heinz

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

[Gimp-print-devel] Tonight's stuff

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

I made minor improvements tonight.  Some tones (particularly dark tans
and yellows) will be smoother.  Try adaptive random again -- I made
some improvements to it that should make it a bit more subtle.

Re: [Gimp-print-devel] Epson 740

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

   Date: Tue, 25 Apr 2000 20:19:07 +0200
   From: Frank van Maarseveen <F.v...@in...>

   I created a test picture containing RGBCMY colored rectangles at
   various angles (but not the 0, 90, 180, 270 degree special cases).
   Within a rectangle the selected color intensity varies from 0 to 100%.
   The low intensity end (i.e. paper is almost white) seems to be a stress
   test case for dithering. Most algorithms produce all kinds of small
   artifacts due to regularities in the dispersion of dots. This is exactly
   what I see when printing camera pictures with light areas (paper on a
   desk, tropical beach, light blue sky with a few clouds).

Yup, pale areas are really nasty.  I have a number of test images that
have pale areas.  What Epson seems to do in some cases is to use
almost a step function between nothing and slightly darker regions,
which results in better smoothness at the expense of color fidelity.

   I've given it a few thought and my guess is that these artifacts
   (kind of curves, waving patterns or something) might disappear
   when the error dispersion is done with a probability inverse
   to [the square] of the distance of the center of the pixel using
   a random angle. kind of. I'm sure there are statistical functions
   (from calculus) which are applicable to my idea. But maybe this
   is all silly or is already being done in a way.

That helps (I use a triangular function rather than an inverse square
because it's easier to compute), but it doesn't entirely solve the
problem, either.  The other thing that helps somewhat is to reverse
direction each pass.  But I've not been able to do anything yet that
eliminates the patterns altogether.

-- 
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 00:25:22 +0200
   From: Thomas Tonino <tt...@bi...>

   If the pixels from this that are lower than a certain constant are
   printed the resulting distribution of pixels is pretty even. It is
   adapted from a well-known method in that during the build a filter is
   applied that punishes pixels that are about 2 pixels or a multiple
   thereof away from the current pixel. Actually, if I prevent my software
   from doing a dot-space-dot at all unless there is no other choice,
   interesting clustery/wormy patterns develop that might be useful for
   laser printers one day - although the worms are very likely to show up
   because of printer mechanism directionality - so for now here is a
   non-wormy one.

It still seemed to generate a fair bit of patterning, in the form of
horizontal lines.  The lines are softer than with the iterated-2
matrix, but it still created a banded effect.  I tried checkerboarding
it, and that created other problems (possibly resonances with some of
the other matrices).

Can you think of any kind of matrix based on hexagonal or octagonal
primitives?  Those will create a more circular effect (octagonal) or a
dense pack effect (hexagonal) which may be less objectionable.

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

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

On Mon, Apr 24, 2000 at 07:49:38PM -0400, Robert L Krawitz wrote:
> 			 =20
> 			  The printer does great, the dithering
>    algorithms are getting better by the hour.=3D20
>=20
> I'm glad *someone* approves :-)
>=20

I finally got around to printing the Windows generated images.
They were also printed in 720dpi resolution. The best quality
dithering algorithm was the Random F/S, which pretty much is
what everybody else is saying. The quality of the Gimp images
is still not at par with the Windows driver, but it's much=20
better than the last time I did a similar comparison.=20

Karl Heinz

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

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

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

   Date: Wed, 26 Apr 2000 00:25:22 +0200
   From: Thomas Tonino <tt...@bi...>

   The photo that I tried with skin colors and some lights and darks.

   I like Random Floyd-Steinberg and Hybrid Floyd-Steinberg best: these
   seem to be good choices for the 600. The light parts are really even and
   the skin tones are not suffering from strings of cyan dots.

I've found random Floyd-Steinberg works best on photographs, too.

   A problem with Hybrid FS, at least with the Image Types: Solid Colors
   setting, is that an image that has a light part at the top gets a
   somewhat darkish line at the very top. This effect is absent with Random
   Floyd-Steinberg, but is extreme in the default settings on 'Solid
   Colors' on 1440 DPI softweave.

The hybrid algorithm uses Floyd-Steinberg, but it uses a matrix to
generate the random numbers used to decide whether to print.  I
thought it would work well, but it doesn't seem to do particularly
well.  Possibly the way it uses the matrix is problematic.

   The ordered dither works nicely for dark colors, but light colors show
   diagonal lines very well. That may improve with other ordered matrices.
   I've attached a small one that doesn't have too many chequerboard like
   patterns and is not a power of 2 size.

The ordered dither handles very light tones well in the sense that it
manages to lay down ink even in very pale areas.  Floyd-Steinberg has
great difficulty with that.

   1440 HQ in the Photo setting seems to produce a kind of out-of-sync
   effect. It looks like colors do not register well, but the direction of
   a shift (if any) seems inconsistent.

Hmm.  What dither algorithm are you using?  I've used 1440 HQ
emulating a 600 on my EX (they're very similar, except that the EX has
light cyan and magenta) and I haven't seen stuff like that.  How does
720 highest quality do?

   What do people think is a decent size for an ordered dither matrix? 23
   pixels - the one I've attached here - is not too bad to calculate as it
   takes around a minute, but much bigger ones really take long as the
   speed is dependent on the 6th power of the matrix width.

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.

The problem is that very pale regions can use amazingly little ink.
It's not uncommon for the LUT to have quite a few points very close to
65536 (no ink).

   I'll try 73 as the next matrix size - that should take around a day, but
   is still rather small on a printer scale. On the other hand, it probably
   doesn't pay to make dots that are more than a millimeter apart to be
   very neatly distributed - and if it is the matrix generation can be
   optimized quite a bit.

The real problem is dealing with the very pale regions.  If we can
come up with a way to do that, I think 73 would be good enough.

[Gimp-print-devel] Re: dithering stuff

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

   Date: Tue, 25 Apr 2000 14:54:51 -0700
   From: Raph Levien <ra...@ac...>

   Indeed. I expect to be releasing it as GPL soon, as planned. However,
   our son was just born yesterday, so I'm not doing things at 100%
   efficiency yet.

Well, mazel tov!  When everyone's settled down, perhaps your baby
pictures will make good tests of skin tones :-)

-- 
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] Dithers in 3.1.3

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

Hi Dither/useability folks

I did some testing on the Epson Stylus Color 600 - a printer that has 4
colors and no variable dot size.

The photo that I tried with skin colors and some lights and darks.

I like Random Floyd-Steinberg and Hybrid Floyd-Steinberg best: these
seem to be good choices for the 600. The light parts are really even and
the skin tones are not suffering from strings of cyan dots.

A problem with Hybrid FS, at least with the Image Types: Solid Colors
setting, is that an image that has a light part at the top gets a
somewhat darkish line at the very top. This effect is absent with Random
Floyd-Steinberg, but is extreme in the default settings on 'Solid
Colors' on 1440 DPI softweave.

The ordered dither works nicely for dark colors, but light colors show
diagonal lines very well. That may improve with other ordered matrices.
I've attached a small one that doesn't have too many chequerboard like
patterns and is not a power of 2 size.

1440 HQ in the Photo setting seems to produce a kind of out-of-sync
effect. It looks like colors do not register well, but the direction of
a shift (if any) seems inconsistent.

What do people think is a decent size for an ordered dither matrix? 23
pixels - the one I've attached here - is not too bad to calculate as it
takes around a minute, but much bigger ones really take long as the
speed is dependent on the 6th power of the matrix width.

I'll try 73 as the next matrix size - that should take around a day, but
is still rather small on a printer scale. On the other hand, it probably
doesn't pay to make dots that are more than a millimeter apart to be
very neatly distributed - and if it is the matrix generation can be
optimized quite a bit.

I'm not enough of a C hacker to see how I should fit this into the
source - the driver currently does too many clever things. The following
is 23 rows of 23 columns concatenated. The lowest number is 0 - the
highest is 23*23-1:

221, 473, 75, 190, 416, 67, 143, 356, 257, 43, 297, 239, 496, 0, 189,
478, 26, 211, 509, 136, 192, 526, 119, 290, 158, 396, 256, 12, 485, 185,
462, 420, 133, 466, 405, 116, 429, 335, 142, 425, 277, 50, 439, 269, 56,
430, 333, 45, 501, 363, 97, 332, 293, 53, 314, 350, 84, 41, 270, 367,
58, 206, 388, 344, 197, 305, 366, 106, 412, 219, 455, 60, 163, 410, 231,
379, 128, 227, 479, 173, 229, 513, 150, 307, 523, 111, 71, 494, 129, 8,
489, 147, 16, 380, 202, 272, 524, 32, 155, 515, 6, 109, 432, 289, 79,
451, 242, 11, 415, 265, 167, 403, 337, 284, 249, 347, 74, 487, 323, 114,
443, 281, 243, 383, 325, 213, 392, 319, 48, 275, 180, 468, 328, 22, 449,
184, 87, 464, 196, 433, 261, 39, 207, 306, 397, 183, 73, 457, 36, 159,
465, 124, 376, 441, 89, 222, 507, 54, 240, 517, 132, 310, 386, 149, 460,
417, 91, 23, 500, 137, 259, 361, 68, 253, 503, 199, 34, 357, 286, 153,
382, 294, 360, 35, 278, 65, 102, 170, 354, 481, 233, 343, 423, 177, 511,
413, 105, 349, 292, 118, 491, 63, 235, 483, 101, 216, 428, 179, 504,
338, 255, 30, 200, 298, 100, 13, 308, 83, 279, 220, 2, 406, 446, 164,
395, 435, 168, 28, 474, 144, 401, 1, 224, 438, 391, 127, 426, 493, 205,
352, 475, 175, 321, 522, 141, 209, 340, 51, 113, 312, 370, 77, 322, 266,
104, 470, 78, 316, 477, 57, 169, 374, 146, 47, 431, 94, 368, 262, 19,
497, 250, 186, 512, 252, 121, 528, 161, 365, 296, 188, 214, 24, 247,
271, 440, 117, 241, 402, 27, 194, 461, 331, 130, 390, 427, 10, 212, 450,
46, 418, 334, 15, 508, 399, 112, 516, 411, 64, 520, 336, 131, 484, 303,
98, 414, 225, 59, 345, 273, 398, 300, 195, 92, 258, 458, 135, 288, 369,
160, 40, 302, 228, 364, 62, 274, 381, 7, 245, 454, 317, 154, 469, 82,
139, 480, 5, 208, 351, 238, 70, 447, 232, 329, 453, 4, 181, 467, 204,
151, 525, 171, 49, 505, 108, 217, 37, 375, 326, 521, 387, 85, 488, 52,
125, 498, 88, 148, 490, 311, 107, 444, 267, 95, 422, 283, 198, 378, 304,
514, 237, 174, 61, 157, 419, 182, 282, 359, 191, 251, 424, 372, 210, 38,
385, 348, 44, 324, 362, 134, 21, 448, 115, 287, 437, 226, 276, 471, 20,
320, 459, 55, 291, 9, 81, 280, 506, 76, 201, 492, 120, 69, 486, 246,
187, 342, 33, 408, 495, 355, 110, 264, 404, 96, 502, 346, 162, 482, 341,
165, 407, 299, 254, 409, 176, 309, 384, 72, 499, 260, 99, 145, 42, 203,
377, 138, 172, 218, 389, 315, 122, 18, 248, 434, 140, 31, 456, 223, 14,
476, 234, 166, 421, 313, 371, 244, 452, 301, 29, 436, 268, 25, 442, 215,
394, 472, 66, 230, 518, 126, 330, 445, 152, 358, 17, 80, 463, 3, 339,
123, 519, 236, 327, 510, 103, 193, 527, 93, 156, 353, 285, 373, 90, 263,
393, 86, 318, 400, 295, 178

If the pixels from this that are lower than a certain constant are
printed the resulting distribution of pixels is pretty even. It is
adapted from a well-known method in that during the build a filter is
applied that punishes pixels that are about 2 pixels or a multiple
thereof away from the current pixel. Actually, if I prevent my software
from doing a dot-space-dot at all unless there is no other choice,
interesting clustery/wormy patterns develop that might be useful for
laser printers one day - although the worms are very likely to show up
because of printer mechanism directionality - so for now here is a
non-wormy one.

The following are two pieces of the sliced and repeated matrix:

XX  X       X  X  X X  XX  X       X  X  X X  
  X   X  X X        X X  X   X  X X        X X
  X    X     XX XX       X    X     XX XX     
 X  X   X  XX     X  X  X  X   X  XX     X  X 
X    XX  X          X  X    XX  X          X  
  X       X  XX XX  X    X       X  XX XX  X  
 X  X  XX  X      X  XX X  X  XX  X      X  XX
X  X  X     X  X  X    X  X  X     X  X  X    
   X    X X  X   X  X     X    X X  X   X  X  
 X   X    X    X X    X X   X    X    X X    X
X  X  X     X      X   X  X  X     X      X   
   X    XX    XX X   X    X    XX    XX X   X 
 XX  X    XX  X   X  X  XX  X    XX  X   X  X 
X     XX    X      X   X     XX    X      X   
    X         XX X    X    X         XX X    X
  X  X  X XX        X    X  X  X XX        X  
X  X    X    X  X  X  XX  X    X    X  X  X  X
      X    X  X   X          X    X  X   X    
 XX  X   X     XX   XX  XX  X   X     XX   XX 
X   X  X  X XX  X  X   X   X  X  X XX  X  X   
X      X   X      X    X      X   X      X    
  XX     X    X X    XX  XX     X    X X    XX


  XX  X  X X  X X    XX  XX  X  X X  X X    XX
   XX XX XX  X  X XX  X   XX XX XX  X  X XX  X
XX  X   X  XX XX  X XX XX  X   X  XX XX  X XX 
  XX XX  X X   X X  X X  XX XX  X X   X X  X X
  XX  XX  X  XX XX X  X  XX  XX  X  XX XX X  X
 X  X   XX XX  X  X  X  X  X   XX XX  X  X  X 
X  X XX  X  X  X  X XX X  X XX  X  X  X  X XX 
X X    X  X  XX XX  X  X X    X  X  XX XX  X  
 XX XX XX XX   X  X  XX XX XX XX XX   X  X  XX
X  X  X  X  XX X  XXX  X  X  X  X  XX X  XXX  
X  X  X X X  X  XX  X  X  X  X X X  X  XX  X  
 XX XX X  XX  XX X   XX XX XX X  XX  XX X   XX
X  X  X  X  X  X  XX   X  X  X  X  X  X  XX   
X  X X  XX  X XX X  XX X  X X  XX  X XX X  XX 
 XX  X  X XX  X   X  X  XX  X  X XX  X   X  X 
X  X  XX X  XX  X  X  XX  X  XX X  XX  X  X  X
X  XX X  X  X XX XX X XX  XX X  X  X XX XX X X
 XX  X  X XX   X X  X   XX  X  X XX   X X  X  
X  XX  XX X  X  X  XX XX  XX  XX X  X  X  XX X
X  X  X X  XX X  XX    X  X  X X  XX X  XX    
 XX  XX  X  X  XX   XX  XX  XX  X  X  XX   XX 

As you can see, there is not much on-off-on-off in this output - the
preference if on-off-off-on and (less likely) on-on-off-off.

Thomas

[Gimp-print-devel] Re: dithering stuff

[Raph L. <ra...@ac...>]

Robert L Krawitz wrote:
> 
> I ran a few experiments just now.  For the test patterns that I use,
> I've found that ordered dither works very nicely, but I just tried
> printing a thumbnail of a photograph, and the ordered dither looks
> awful.  Random Floyd-Steinberg works best for that.
> 
> This should come as no real surprise to anyone, but I think that
> having the choice of dithering algorithms really comes in handy.  At
> some point this should feed into a set of default profiles for
> photographs, line art, etc. (which we have a start on).
> 
> I'm really looking forward to (hopefully) getting your stuff, Raph!

Indeed. I expect to be releasing it as GPL soon, as planned. However,
our son was just born yesterday, so I'm not doing things at 100%
efficiency yet.

Thanks for keeping me up to date - I'll do my best to do the same.

Raph

Re: [Gimp-print-devel] Epson 740

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

On Mon, Apr 24, 2000 at 07:29:52PM -0400, Robert L Krawitz wrote:
>    Date: Mon, 24 Apr 2000 19:54:27 +0200
>    From: Frank van Maarseveen <F.v...@in...>
> 
>    I'm trying gimp 1.0.4 + print-3.1.3 on a RedHat 6.1 box for
>    this printer. This doesn't look good. I have tried various
>    settings in the file->print menu but at best the color dithering
>    was much worse than with ghostscript: I tried versions 5.10 and 6.01, both
>    with .upp files for the Epson 740 which I got from another place.
> 
> What kind of image did you try to print?
I created a test picture containing RGBCMY colored rectangles at
various angles (but not the 0, 90, 180, 270 degree special cases).
Within a rectangle the selected color intensity varies from 0 to 100%.
The low intensity end (i.e. paper is almost white) seems to be a stress
test case for dithering. Most algorithms produce all kinds of small
artifacts due to regularities in the dispersion of dots. This is exactly
what I see when printing camera pictures with light areas (paper on a
desk, tropical beach, light blue sky with a few clouds).

I've given it a few thought and my guess is that these artifacts
(kind of curves, waving patterns or something) might disappear
when the error dispersion is done with a probability inverse
to [the square] of the distance of the center of the pixel using
a random angle. kind of. I'm sure there are statistical functions
(from calculus) which are applicable to my idea. But maybe this
is all silly or is already being done in a way.

Good news:
I tried the print-3.1.3 "Ghost" subdir with ghostscript 6.01
and the very first impression is that "stp" is better that uniprint.

-- 
Frank

Re: [Gimp-print-devel] stylus 660, gs 6.01

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

   Date: Tue, 25 Apr 2000 12:25:19 +0200
   From: Hrafnkell Eiriksson <he...@kv...>
   Cc: gim...@so...

   On Mon, Apr 24, 2000 at 07:51:14PM -0400, Robert L Krawitz wrote:
   > BTW, I just checked in an attempt at a driver for the 660 (and code
   > for the 640 that *might* work at 1440).  Folks with 660's and 640's,
   > please give it a try.

   Well.. defenetly improved support for the 660 :)
   It now at least puts ink on the paper instead of ejecting blank pages on
   my epson stylus 660 :) But its not working correctly.
   I tried 720 highes quality mode and the image looks very strange,
   like the paper isn't being advanced engough in each step.
   The result is a compressed fuzzy image.

Ah.  I suspected that that might be the case.  I need to find another
way to handle this problem.

Re: [Gimp-print-devel] stylus 660, gs 6.01

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

   Date: Tue, 25 Apr 2000 12:27:26 +0200
   From: Hrafnkell Eiriksson <he...@kv...>
   Cc: gim...@so...

   On Mon, Apr 24, 2000 at 07:51:14PM -0400, Robert L Krawitz wrote:
   > BTW, I just checked in an attempt at a driver for the 660 (and code
   > for the 640 that *might* work at 1440).  Folks with 660's and 640's,
   > please give it a try.

   Oh and the stylus-660 is missing from printers.xml

Not any more :-)

-- 
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 660, gs 6.01

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

   Date: Mon, 24 Apr 2000 19:31:34 -0700
   From: "S. Miller" <sm...@rn...>

   This is a good point, although I suspect the majority of gimp users have
   at least some control over print queue definitions.

That isn't necessarily true, and anyway system printer queues aren't
really the right way to handle this.  Virtual printers or print
profiles defined within the plugin itself are the way to go here, and
it shouldn't be that hard to implement something like that.

Re: [Gimp-print-devel] stylus 660, gs 6.01

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

On Mon, Apr 24, 2000 at 07:51:14PM -0400, Robert L Krawitz wrote:
> BTW, I just checked in an attempt at a driver for the 660 (and code
> for the 640 that *might* work at 1440).  Folks with 660's and 640's,
> please give it a try.

Oh and the stylus-660 is missing from printers.xml
-- 
//-----------------------//-------------------------------------------------
//  Hrafnkell Eiriksson  // 
//  he...@kv...        // 
//  TF3HR                //  "Blessed are they who go around in circles,
//                       //   for they shall be known as Wheels"        

Re: [Gimp-print-devel] stylus 660, gs 6.01

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

On Mon, Apr 24, 2000 at 07:51:14PM -0400, Robert L Krawitz wrote:
> BTW, I just checked in an attempt at a driver for the 660 (and code
> for the 640 that *might* work at 1440).  Folks with 660's and 640's,
> please give it a try.

Well.. defenetly improved support for the 660 :)
It now at least puts ink on the paper instead of ejecting blank pages on
my epson stylus 660 :) But its not working correctly.
I tried 720 highes quality mode and the image looks very strange,
like the paper isn't being advanced engough in each step.
The result is a compressed fuzzy image.

1440 Highest quality is even more strange. It streched a small image over
a whole A4 page an to the to of the next one.
It prints one band of the image, then advances the paper by
the size of the band and prints almost the same band again, 
only shifted a little bit. This results in a streched out image
that repeats parts of itself again and again.

720 softweave mode seems to work best, but its a little bit like
720 highest quality mode.

Thanks for taking the time to add this first support for the 660.

Where can I find a description of all the different printing modes,
that is what microweave and softweave means?

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