gimp-print-devel

Re: [Gimp-print-devel] Andy or Mitch, please read the Help forum

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

Robert L Krawitz wrote:
> 
> I noticed across the following message:
> 
>   BY: vivien
>   DATE: 04/28/00 08:59
>   SUBJECT: Compilation error
> 
>   I have previously successfully compiled version 3.1.2 but version
>   3.1.3 does not compile. I receive the error :
> 
>   gimp_color_window.c : In function gimp_create_color_adjust_window
>   78 : warning : implicit declaration of function gimp_dialog_new
>   79 : 'gimp_plugin_help_func' undeclared (first use in this function)
> 
>   etc.
> 
>   The unsuccessful compilation was made on Linux (Suse 6.3) whith
>   version 1.1.11 of gimp (and 2.91.66 of gcc). The gimp-devel package
>   is installed. I think the problem is with gimp. Do I need to upgrade
>   to the latest version (I would rather not) ?

Hi,

Unfortunately, you have to upgrade if you want the ui with the libgimp
widgets.

However, I'm about to check in a better check for the new features which
are needed for this. Since Gimp 1.1.21 (yesterday) there is a new function
gimp_ui_init() which is needed for allocating private colormaps on 8 bit
displays correctly.

Again, unfortunately, this means that all people with versions lower than
1.1.21 will see only one ui (will not have the choice of two menu entries).

Hm, but I think nailing down gimp-print's Gimp-only interface to the
upcoming Gimp 1.2 is the right thing to do (TM).

commit follows (hopefully) tonight...

bye,
--Mitch

[Gimp-print-devel] Latest stuff

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

I managed to significantly reduce the amount of ink last night.  The
change wasn't all that complicated; to tell the truth, I largely
removed some old code that was duplicating what I was trying to do and
thereby increased the CMY levels too much.  Right now the old code is
still #ifdef'ed out.

It had the side effect of improving the saturation.  I did a test
print on glossy paper last night and found less banding (mostly due to
the reduced amount of ink), too.  At a saturation of 1.1, the result
is slightly more saturated, lighter (which is NOT due to the reduced
amount of ink) and a bit warmer overall than before at a saturation of
1.2.  This hasn't entirely eliminated the greenish cast on some gray
tones, but it's much better.  There are still some problems with
certain dark tones (particularly dark greens and browns) not being
perfectly smooth.

The color settings I'm using right now are all defaults except for red
of 98 (which is probably due to the ink set I'm using), saturation of
1.1, and gamma of 1.177 (which might be a touch too bright).  So it's
quite likely that default settings will actually work quite well right
now.

Also, I've renamed 1440x1440 two-pass to 1440x720 enhanced mode, which
is a more accurate description.  It also does a lot better now, and
seems to be useful to get really high quality.  Unfortunately, many of
the newer printers won't support it, so I'll have to do some work on
the Epson driver for that.

I got one report of very good quality (but less than stellar speed)
from a 900 from 3.1.3.

Could everyone go back and test their printers with the latest
repository?  In particular, could the HP and Canon folks give it a
try?  I've changed a bunch of constants, and it's possible that that
will throw off those printers.

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

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

   Date: Tue, 02 May 2000 18:49:21 +0800
   From: Nick Urbanik <ni...@vt...>

   Robert L Krawitz wrote:

   > BTW, what is people's overall impression of print quality between
   > 3.1.2, 3.1.3, and the current repository?

   I installed 3.1.3 last night with Gimp 1.1.20 (with resize patch).  On our
   Stylus 440, 720 DPI microweave resulted in a strange vertical streaking.
   The picture (of our baby, of course!) is okay except for this streaking,
   which makes the printout a throw away.

What exactly does the streaking look like?  Could you put a sample on
a web site or send one to me somehow?

   720 High Quality I have never had working in any version.   Last night, on
   3.1.3, the "printing" progress meter at the bottom of the image in the Gimp
   window stopped just a millimetre or two from the end.  I'll check it out
   again soon.

720 HQ won't work.  I'm surprised you saw what you did (it should have
just confused the printer), but the weird print head on the 440 is
hard to make work.

   720 Softweave is fast, but the resolution of the image looks poor: it has
   less ink density and appears to have lost detail, but the speed is nice.

That's interesting.  The dither doesn't do anything different from 720
microweave.

-- 
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] PHP error stops our site dead!

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

   Date: Tue, 02 May 2000 18:38:38 +0800
   From: Nick Urbanik <ni...@vt...>

   My attempts to reach http://gimp-print.sourceforge.net/ over the last few
   days have always resulted in (only) the message:

   Parse error: parse error, expecting `')'' in state.php3 on line 39

   Is someone looking at fixing this?  Or have I bookmarked the wrong
   location?

That was my fault.  I updated the printer list and couldn't log in
over the weekend to pull over the update.

Re: [Gimp-print-devel] Print quality

[Nick U. <ni...@vt...>]

Robert L Krawitz wrote:

> BTW, what is people's overall impression of print quality between
> 3.1.2, 3.1.3, and the current repository?

I installed 3.1.3 last night with Gimp 1.1.20 (with resize patch).  On our
Stylus 440, 720 DPI microweave resulted in a strange vertical streaking.
The picture (of our baby, of course!) is okay except for this streaking,
which makes the printout a throw away.

Version 3.1.2 worked fine in 720 Microweave.

720 High Quality I have never had working in any version.   Last night, on
3.1.3, the "printing" progress meter at the bottom of the image in the Gimp
window stopped just a millimetre or two from the end.  I'll check it out
again soon.

720 Softweave is fast, but the resolution of the image looks poor: it has
less ink density and appears to have lost detail, but the speed is nice.

I am having problems reading the web site, and cannot remember the CVS
login commands, so haven't tried the current repository.

Thanks to the great work you are doing.  I would have much poorer pictures
without your excellent efforts.

--
Nick Urbanik, Dept. of Electrical & Communications Engineering
Hong Kong Institute of Vocational Education (Tsing Yi)
email: ni...@vt..., ni...@io...
Tel:   (852) 2436 8660, (825) 2436 8492   Fax: (852) 2436 8643
pgp ID: 7529555D fingerprint: 53 B6 6D 73 52 EE 1F EE EC F8 21 98 45 1C 23 7B

[Gimp-print-devel] PHP error stops our site dead!

[Nick U. <ni...@vt...>]

Dear folks,

My attempts to reach http://gimp-print.sourceforge.net/ over the last few
days have always resulted in (only) the message:

Parse error: parse error, expecting `')'' in state.php3 on line 39

Is someone looking at fixing this?  Or have I bookmarked the wrong
location?

--
Nick Urbanik, Dept. of Electrical & Communications Engineering
Hong Kong Institute of Vocational Education (Tsing Yi)
email: ni...@vt..., ni...@io...
Tel:   (852) 2436 8660, (825) 2436 8492   Fax: (852) 2436 8643
pgp ID: 7529555D fingerprint: 53 B6 6D 73 52 EE 1F EE EC F8 21 98 45 1C 23 7B

Re: [Gimp-print-devel] New dither codes

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

   Date: Mon, 01 May 2000 10:33:32 +0200
   From: Thomas Tonino <tt...@bi...>

   Robert L Krawitz wrote:

   > Best thing to do is to stick it in print-dither.c.

   I put both output and C source into print/Matgen. I'd prefer to see the
   matrix be in a #include as I do not like 401 (or more) lines of data in
   the source.

That's reasonable.  Thanks.

Re: [Gimp-print-devel] New dither codes

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

Robert L Krawitz wrote:

> Best thing to do is to stick it in print-dither.c.

I put both output and C source into print/Matgen. I'd prefer to see the
matrix be in a #include as I do not like 401 (or more) lines of data in
the source.

Currently it is just there for people to experiment. When I'm really
happy we have to decide: throw out the current ordered dither (I think
it is useful for laser printers or other devices that have trouble with
isolated dots) or add an extra dither choice (there are too many to test
'em all).

The way I tested the new matrix really is a hack. I do not want to
commit that.


Thomas

Re: [Gimp-print-devel] New dither codes

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

   Date: Mon, 01 May 2000 00:45:56 +0200
   From: Thomas Tonino <tt...@bi...>

cvs add matgen.c
cvs commit matgen.c

   The program used to generate it is fairly short but takes about 5 hours
   to run on my (333MHz PII) machine. I think it could use a tiny bit of
   randomization. I'll try that soon. Any suggestions/instructions on what
   to do with the generated matrix? When I'm happy with randomization I
   could build a 113 x 113 matrix in a few days CPU.

Best thing to do is to stick it in print-dither.c.

Re: [Gimp-print-devel] New dither codes

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

Hi folks,

I just generated a new dither with a rather simple algorithm that starts
with 3 pixels you choose manually, and then continues finding the
position that has the largest total distance from all the pixels that
are already on. The distance per pixel is mangled before it is added to
the total, otherwise things do not work.

The dither is a bit too regular to my taste, but it works well. The good
thing: ordered dither is not splotchy any more, although a few light
speckles remain.

Ordered dither output is now fully acceptible even though the matrix
looks a tad too regular to me. All irregularities follow from placement
of the 3 initial pixels - that is not much.

This is a 73x73 matrix. It is 401 lines of C source. What shall I do
with it? Put it in my CVS directory, and then use some magic CVS command
to bring it to sourceforge?

The program used to generate it is fairly short but takes about 5 hours
to run on my (333MHz PII) machine. I think it could use a tiny bit of
randomization. I'll try that soon. Any suggestions/instructions on what
to do with the generated matrix? When I'm happy with randomization I
could build a 113 x 113 matrix in a few days CPU.

/* Dither matrix generation */
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <time.h>

#define HSIZE 73
#define VSIZE 73
#define HSIZE2 (HSIZE/2)
#define VSIZE2 (VSIZE/2)
#define TRUE 1
#define FALSE 0
/* X1, Y1, etc are initial bits to be set in the matrix. Choose well!!
*/
#define X1 2
#define Y1 1
#define X2 48
#define Y2 24
#define X3 24
#define Y3 49

int main(void)
{
int x, y, xd, yd, i, j, bitcount, largehole, largetotal,
result[HSIZE*VSIZE];
float distance, thishole, maximum, total;
int initial[HSIZE*VSIZE];

/* Set up array with zeroes and a number of 'ones' */
bitcount=0;
for ( x=0; x<HSIZE; ++x )
  for ( y=0; y<VSIZE; ++y )
    {
    initial[x+y*HSIZE]=FALSE;
    result[x+y*HSIZE]=0;
    }

initial[X1+Y1*HSIZE]=TRUE;
result[X1+Y1*HSIZE]=bitcount++;
initial[X2+Y2*HSIZE]=TRUE;
result[X2+Y2*HSIZE]=bitcount++;
initial[X3+Y3*HSIZE]=TRUE;
result[X3+Y3*HSIZE]=bitcount++;

while (bitcount < VSIZE*HSIZE)
  {
  maximum=0;
/* Start looking for the largest hole */
  for ( i=0; i<HSIZE; ++i )
    for ( j=0; j<VSIZE; ++j )
      {
      total=0;
/* check only if it is a hole right now */
      if (initial[i+j*HSIZE]==FALSE)
        {
        for ( x=0; x<HSIZE; ++x )
          for ( y=0; y<VSIZE; ++y )
/* scan all positions, find distance, munge and add */
            if (initial[x+y*HSIZE]==TRUE)
              {
              xd = abs(x - i);
              yd = abs(y - j);
              if (xd > HSIZE2)
                xd = HSIZE - xd;
              if (yd > VSIZE2)
                yd = VSIZE - yd;
              distance = sqrt(xd*xd+yd*yd);
              total+=(1-1/distance);
              }
        if (total > maximum)
          {
/* it is the largest so far */
          largetotal = i+j*HSIZE;
          maximum = total;
          }
	}
      }
/* put a "1" in the largest hole */
  initial[largetotal] = TRUE;
  result[largetotal]=bitcount++;

/* print the result so far */
  for ( i=0; i<HSIZE; ++i )
    {
    for ( j=0; j<VSIZE; ++j )
      if (initial[i+j*HSIZE])
        printf("@");
      else
        printf("-");

    printf("\n");
    }
  }
/* print result */
printf("\n\n");
for (j=0; j<HSIZE*VSIZE; ++j)
  printf("%d, ",result[j]);
printf("\n\n");
}

Re: [Gimp-print-devel] How to use special Inks?

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

   Date: Fri, 25 Feb 2000 23:29:23 +0100 (CET)
   From: regis rampnoux <re...@re...>

   >  MIS Sixtone Inkset - 15%-LC, 25%-C, 45%-LM, 50%-Y, 75%-M,  100%-K

   I interpret (I hope that it is right) the value as:
   for gray between 0-15% use ink from light cyan  
   for 16-25% from cyan
   for 26-45% from light magenta 
   ... 

   This should be interresting to dithering B&W photographies?
   Do you need inks to try?
   who can/want have a look about this?

OK, I think all the necessary infrastructure is in place to work on
this...

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

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

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

Re: [Gimp-print-devel] New dither codes

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

   Date: Sun, 30 Apr 2000 01:19:31 +0200
   From: Thomas Tonino <tt...@bi...>

   Robert L Krawitz wrote:

   I think there is a problem in semantics with CMYK color. There are 4
   values to control what is essentially a 3 dimensional color space. If I
   ignore this, the code seems to do the following:

   1 - Finds how dark the requested CMY values are - but not the requested
   K value (tk).

Well, the problem is that we're being handed RGB, so we don't really
have a "requested" K value; we have to compute one.

There's a whole bunch of code in there that I don't entirely
understand; the stuff that adjusts the K value.  Or rather, I think I
understand in a general sense what it does, but I don't entirely
understand how it interacts with my later handling of black.  I tried
ripping it out the other night, and the results weren't too good.  I
do want to figure out what's going on in there.

   2 - Finds what is more black: the requested K or the value computed
   above (not sure about this, this would bite us if people feed color
   separated data with its own black curve to us).

Yes, it would.  Currently we don't support CMY or CMYK input, though.

   3 - We find where this black level is in the range between the upper and
   lower settings mentioned above.
   4 - If below, print the CMY values. If above, print black. If in
   between, use a dither to determine whether black will be used or CMY.

Almost right.  If it decides not to use black, the black is
redistributed back to the CMY.

   Am I missing something if I think we could just generate black according
   to steps 1, 2 and 3 and put this black value in the K buffer - and have
   the actual rendering dither decide where black must be printed? Where
   this dither prints black, CMY do not show up. I do not see what the
   extra dither here gains us. But I see a possible problem: it may decide
   not to print CMY at a certain pixel. Then the final dither comes along,
   finds no CMY and thus prints no CMY, but if it also does not have enough
   error yet for printing K, it leaves a hole - giving reduced density
   where CMY moves into black.

What the extra dither does is eliminate all printing of black in
light areas, which makes for a much smoother texture (try setting
k_upper and k_lower to zero and see what happens...you won't like it.
It's even worse on a 6-color printer.)

   Actually, step 1 seems a bit strange to me. It looks like a darkness is
   computed by adding densities. In offset printing, the color is analyzed
   in a different way. As first approximation, we would take the lowest of
   CMY and use that as a K value. Adding CMY is bad when printing saturated
   colors: for say a dark blue (which is magenta and red, and some yellow
   to make it real dark) the driver would decide that part of the CMY can
   be replaced with K because it is so dark - but it really should not
   replace more CMY than there is Y to replace.

I thought about this some more.  The way darkness is computed is
strange, but we're computing "darkness", not "black", here.  That's
important -- pure C has a certain amount of "darkness", even though
there's no black whatsoever.  The idea is to avoid using black ink
when the darkness is not great enough to hide the solid black
speckles.

Darkness is not K; it's used to decide how we're going to print K.
There's a difference.  If we print K as CMY, we don't simply print a
C, M, and Y dot; the K->CMY values are added back into the CMY and
normal dithering takes place on the CMY values.

I still don't think that the way darkness is computed is optimal,
though.  It really needs more careful thought.

   The dither algorithm will then produce a K every now and then. When the
   K is produced, and at the same time a CM or Y would be printed, this dot
   is not shown - but for the error diffusion it works out as if it is -
   the color effectively disappears under the black dot. You have to rely
   on printer registration here - or you have to make the switch around 30%
   coverage, when there is often white between dots and misalignment
   doesn't matter that much.

On most paper, at least, dots are not simple square or rectangular
pixels; they spread out and overlap somewhat.  That's why we don't
want a target density of 1.0, but instead something less (about .6 for
most Epson printers at 720 dpi; half that at 1440 dpi).  At 360 dpi,
though, where individual dots are more visible, this might matter.  I
haven't investigated it.

   In offset printing it is normal to leave color behind black ink. In some
   cases, colors are boosted a bit when there is a lot of black - so a
   shadow in a colored object still feels black. Given that our dither
   takes care of the total amount of ink buildup, I feel it is better to
   just adjust the amount of black and let the dither handle the rest. With
   the above, we cannot get above 200 % - unless we believe it is not a
   good idea to remove all color from under black. Dark saturated colors
   will then get a 300% coverage. Maybe we need another mechanism to adjust
   those: not by shifting them to black, but by making them lighter
   overall.

We don't want more than 200% coverage.  In fact, I don't think we even
*want* 200% coverage.  It's simply too much ink, and aside from the
expense, it will bleed through uncoated paper.

   I just tried patching the code but now I get only an abrupt transition
   from greenish (CMY) to grey (K). Guess I'm a stupid coder or the black
   dither is not behaving as I expected. What I did was use this in
   print-dither.c instead of the dither lookup function. Be warned, it is
   useless, but shows my plan:

		 else if (kdarkness < ub) /* Probabilistic */
		   {
		     if (rb == 0)
		       bk = ok;
		     else
		       bk = ok * ( (kdarkness - lb) / rb );
		   }
		 else		/* All black */

I tried this too a while back, and it definitely doesn't work very
well.  It might work with ordered dither, but it's not useful with
error diffusion.  In fact, the interaction between error diffusion and
this dither might be the source of some problems.

   This doesn't really matter for the point I was trying to make. Say ===
   is black formed by CMY and K is black formed by black ink. The layers
   could add as follows:

   === === === === === === === === === === === ===
   K K K K K K K K K K K K K K K K K K K K K K K K

   In this case - and this is a very ordered dither - the black does not
   make the CMY any darker. CMY would not print where black is printed
   (nice idea - but hey, are black and CMY perfectly in registration?) but
   still 25 % of the paper will be white - even though you did add 50%
   black to the 75% grey that you had.

I don't know about offset printing, but in this context, the black
very definitely makes CMY look darker.  Pure CMY (from ink jet
printers, at any rate) is not very black.  Black, on the other hand,
completely hides anything else printed on that spot.

Also, with what you presented above, 25% of the paper will not be
white at all; this pattern will result in a fully covered paper, and
in fact the bleed-through will be heavy if the paper is not coated,
and if it is, there will probably be heavy pooling of ink.  Think dot
gain in this context.

   Or something similar. That is, after the fixed dither an ink removal
   algorithm removes pixels that do not add to the image, but just soak the
   paper.

Ink removal might be a good thing to investigate; we just have to
figure out what can be safely removed.

BTW, what 1440 buys us is mostly more points for the dither algorithm
to work with.  It doesn't really buy us more resolution on paper,
since the dots are too big.  The 1440x1440 and 2880x720
pseudo-resolutions attempt to do the same thing to an even greater
degree.

-- 
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] New dither codes

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

Robert L Krawitz wrote:

> The current default is to start adding black at 30%.  With plain
> paper, it goes to all black at 50%; with glossy film (which works well
> for glossy paper, too), it goes to all black at 80%.  At anything much
> less than 30%, the black dots start to become very noticeable.  It's
> probably worth a try, though (play with the dither_set_black_lower and
> dither_set_black_upper calls in print-escp2.c).

I think there is a problem in semantics with CMYK color. There are 4
values to control what is essentially a 3 dimensional color space. If I
ignore this, the code seems to do the following:

1 - Finds how dark the requested CMY values are - but not the requested
K value (tk).
2 - Finds what is more black: the requested K or the value computed
above (not sure about this, this would bite us if people feed color
separated data with its own black curve to us).
3 - We find where this black level is in the range between the upper and
lower settings mentioned above.
4 - If below, print the CMY values. If above, print black. If in
between, use a dither to determine whether black will be used or CMY.

Am I missing something if I think we could just generate black according
to steps 1, 2 and 3 and put this black value in the K buffer - and have
the actual rendering dither decide where black must be printed? Where
this dither prints black, CMY do not show up. I do not see what the
extra dither here gains us. But I see a possible problem: it may decide
not to print CMY at a certain pixel. Then the final dither comes along,
finds no CMY and thus prints no CMY, but if it also does not have enough
error yet for printing K, it leaves a hole - giving reduced density
where CMY moves into black.

Actually, step 1 seems a bit strange to me. It looks like a darkness is
computed by adding densities. In offset printing, the color is analyzed
in a different way. As first approximation, we would take the lowest of
CMY and use that as a K value. Adding CMY is bad when printing saturated
colors: for say a dark blue (which is magenta and red, and some yellow
to make it real dark) the driver would decide that part of the CMY can
be replaced with K because it is so dark - but it really should not
replace more CMY than there is Y to replace.

I would suggest finding the lowest of CMY, adding this to any K that we
were given (probably will need a correction here later, as 100% CMY and
100% K should add up to 100% K, not 200%), determine how much of this K
we are going to print as CMY, subtracting this from the CMY and using it
as the K.

The dither algorithm will then produce a K every now and then. When the
K is produced, and at the same time a CM or Y would be printed, this dot
is not shown - but for the error diffusion it works out as if it is -
the color effectively disappears under the black dot. You have to rely
on printer registration here - or you have to make the switch around 30%
coverage, when there is often white between dots and misalignment
doesn't matter that much.

In offset printing it is normal to leave color behind black ink. In some
cases, colors are boosted a bit when there is a lot of black - so a
shadow in a colored object still feels black. Given that our dither
takes care of the total amount of ink buildup, I feel it is better to
just adjust the amount of black and let the dither handle the rest. With
the above, we cannot get above 200 % - unless we believe it is not a
good idea to remove all color from under black. Dark saturated colors
will then get a 300% coverage. Maybe we need another mechanism to adjust
those: not by shifting them to black, but by making them lighter
overall.

I just tried patching the code but now I get only an abrupt transition
from greenish (CMY) to grey (K). Guess I'm a stupid coder or the black
dither is not behaving as I expected. What I did was use this in
print-dither.c instead of the dither lookup function. Be warned, it is
useless, but shows my plan:

	      else if (kdarkness < ub) /* Probabilistic */
		{
		  if (rb == 0)
		    bk = ok;
		  else
  		    bk = ok * ( (kdarkness - lb) / rb );
		}
	      else		/* All black */


>    If CMY print all at 70 % and you add 30% black, the black has very
>    little effect on overall density, because it overlaps most of the CMY. I
>    guess this is what is happening.
> 
> Not really; no CMY is ever printed if black is.  This works fine for
> single dot size, but it may not work right for variable dot size.

This doesn't really matter for the point I was trying to make. Say ===
is black formed by CMY and K is black formed by black ink. The layers
could add as follows:

=== === === === === === === === === === === ===
K K K K K K K K K K K K K K K K K K K K K K K K

In this case - and this is a very ordered dither - the black does not
make the CMY any darker. CMY would not print where black is printed
(nice idea - but hey, are black and CMY perfectly in registration?) but
still 25 % of the paper will be white - even though you did add 50%
black to the 75% grey that you had.

>    1440x720 is very ugly in ordered dither mode, as only half the dots are
>    not printed. 1440 mode thus is only useable with some kind of error
>    diffusion or other mechanism that can use half dot spacings. Ordered
>    dither inherently cannot do this because a dot position that is printed
>    at level X will also be printed at a level higher than X.
> 
> Hmm.  I found 1440x720 quite usable with the iterated-2 ordered dither
> -- much better than 720x720.  However, it does band a lot.

I think iterated-2 is regular enough not to be a problem. The question
becomes: does going to 1440 gain you something in with this dither? If
the first and last dots of a span are always printed, and you do not
mind having some dot aggregration, you can cluster printer dots when you
reached a certain density of single dots per mm:

X   XX    XXX     XXXX

This would print as:

X   XX    X X     XX X

Or something similar. That is, after the fixed dither an ink removal
algorithm removes pixels that do not add to the image, but just soak the
paper.


Thomas

Re: [Gimp-print-devel] New dither codes

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

   Date: Sat, 29 Apr 2000 16:05:32 +0200
   From: Thomas Tonino <tt...@bi...>

   Other results: I went from rotating and inverting the matrix to just
   shidting it in X and Y directions. For ordered dither, this made no big
   difference, but the splotches are not colored any more. I think I know
   where the splotches originate from. If I print a white-to-black wedgeit
   really prints as a white-to-grey, then grey-to-darkgreen, then
   green-to-darkgrey (that dark grey is a bit lighter than the green) and
   then to black. This is on Canon coated paper, but plain paper is
   similar. It seems black has to be added earlier than it is now - at
   least it has to be added in larger amounts.

Actually, at least for photo printers I think it's the cyan that's the
problem -- the difference in darkness between the dark and light cyan
inks is just too great.  That, of course, doesn't apply to you.
However, when I printed my test shot using no light inks (emulating a
600), I got much more accurate grays (very little green tint).

Re: [Gimp-print-devel] New dither codes

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

   Date: Sat, 29 Apr 2000 14:26:18 +0200
   From: Hrafnkell Eiriksson <he...@kv...>

   On Sat, Apr 29, 2000 at 07:40:46AM -0400, Robert L Krawitz wrote:
   > Actually, there are different dot sizes that can be chosen in 360 dpi
   > mode.  Even with the largest, things are too light.

   For all Epson printers? Not only those with variable dot size?
   I would actually love to be able to look at the size and shape
   of the dots in a microscope. Does anyone have access to such a
   device and can digitize images from it? :) 

For most of them, at any rate.  Maybe not the newer ones.  I've
inspected it with an 8x loupe, and it's very noticeable.

Re: [Gimp-print-devel] New dither codes

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

   Date: Sat, 29 Apr 2000 16:05:32 +0200
   From: Thomas Tonino <tt...@bi...>

   Robert L Krawitz wrote:

   > For some reason, the 360 dpi prints seem to be much lighter on every
   > printer.  Try bumping up the density to 1.5 at 360 dpi and see if it
   > helps.  How fast was this mode?

   360 DPI on the Stylus Color 600 seems to produce smaller dots than 720
   or for that matter 1440 HQ.

720 and up produce the same size dots on my EX, no matter what I set
for the dot size.  360 does seem to be capable of producing even
smaller dots.  I haven't figured this one out at all.

   I think this is really strange: the code that selects the smallest dots
   on 800 and IIs (and more) does not do so on the 600. I would expect more
   discrepancies with other printers.

In this case, even the Photo and the Photo EX have different settings
in this regard.  The doc for the EX says that 0x4 is "super micro
dots", but that doesn't appear to be the case; 0x4 produces larger
dots than 0x3.  I think we're just going to have to try empirically
with each printer to figure out what works best.

   Other results: I went from rotating and inverting the matrix to just
   shidting it in X and Y directions. For ordered dither, this made no big
   difference, but the splotches are not colored any more. I think I know
   where the splotches originate from. If I print a white-to-black wedgeit
   really prints as a white-to-grey, then grey-to-darkgreen, then
   green-to-darkgrey (that dark grey is a bit lighter than the green) and
   then to black. This is on Canon coated paper, but plain paper is
   similar. It seems black has to be added earlier than it is now - at
   least it has to be added in larger amounts.

The current default is to start adding black at 30%.  With plain
paper, it goes to all black at 50%; with glossy film (which works well
for glossy paper, too), it goes to all black at 80%.  At anything much
less than 30%, the black dots start to become very noticeable.  It's
probably worth a try, though (play with the dither_set_black_lower and
dither_set_black_upper calls in print-escp2.c).

I also get slightly greenish medium to dark grays.  I can partially
correct gray with the color controls, but it's imperfect.

   If CMY print all at 70 % and you add 30% black, the black has very
   little effect on overall density, because it overlaps most of the CMY. I
   guess this is what is happening.

Not really; no CMY is ever printed if black is.  This works fine for
single dot size, but it may not work right for variable dot size.

   1440x720 is very ugly in ordered dither mode, as only half the dots are
   not printed. 1440 mode thus is only useable with some kind of error
   diffusion or other mechanism that can use half dot spacings. Ordered
   dither inherently cannot do this because a dot position that is printed
   at level X will also be printed at a level higher than X.

Hmm.  I found 1440x720 quite usable with the iterated-2 ordered dither
-- much better than 720x720.  However, it does band a lot.

-- 
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] New dither codes

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

Robert L Krawitz wrote:

> For some reason, the 360 dpi prints seem to be much lighter on every
> printer.  Try bumping up the density to 1.5 at 360 dpi and see if it
> helps.  How fast was this mode?

360 DPI on the Stylus Color 600 seems to produce smaller dots than 720
or for that matter 1440 HQ.

I think 360 is supposed to use larger dots. The dot size selections vary
between models, so it seems easy enough to get mixed up:

Model:  600             IIs,ProXL  800,850
Value:
0x00    Default         Default    Default
0x01    N/A             Small      Micro
0x02    Micro           Standard   Normal(single)
0x03    Normal(single)  N/A        Normal(double)
0x04    Normal(double)  N/A        N/A

I think this is really strange: the code that selects the smallest dots
on 800 and IIs (and more) does not do so on the 600. I would expect more
discrepancies with other printers.

Other results: I went from rotating and inverting the matrix to just
shidting it in X and Y directions. For ordered dither, this made no big
difference, but the splotches are not colored any more. I think I know
where the splotches originate from. If I print a white-to-black wedgeit
really prints as a white-to-grey, then grey-to-darkgreen, then
green-to-darkgrey (that dark grey is a bit lighter than the green) and
then to black. This is on Canon coated paper, but plain paper is
similar. It seems black has to be added earlier than it is now - at
least it has to be added in larger amounts.

If CMY print all at 70 % and you add 30% black, the black has very
little effect on overall density, because it overlaps most of the CMY. I
guess this is what is happening.

1440x720 is very ugly in ordered dither mode, as only half the dots are
not printed. 1440 mode thus is only useable with some kind of error
diffusion or other mechanism that can use half dot spacings. Ordered
dither inherently cannot do this because a dot position that is printed
at level X will also be printed at a level higher than X.

The new matrix that I built is useless. I'll have to try something else
- I'm thinking about using blue noise now. Generating white noise, and
filtering it to remove the low frequencies. Actually, Floyd-Steinberg is
pretty good at removing low frequencies: that is why floyd-steinberg
with a random threshold does very well.



Thomas

Re: [Gimp-print-devel] New dither codes

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

On Sat, Apr 29, 2000 at 07:40:46AM -0400, Robert L Krawitz wrote:
> Actually, there are different dot sizes that can be chosen in 360 dpi
> mode.  Even with the largest, things are too light.

For all Epson printers? Not only those with variable dot size?
I would actually love to be able to look at the size and shape
of the dots in a microscope. Does anyone have access to such a
device and can digitize images from it? :) 

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

Re: [Gimp-print-devel] New dither codes

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

   Date: Sat, 29 Apr 2000 11:47:49 +0200
   From: Hrafnkell Eiriksson <he...@kv...>

   On Fri, Apr 28, 2000 at 06:57:49PM -0400, Robert L Krawitz wrote:
   > For some reason, the 360 dpi prints seem to be much lighter on every
   > printer.  Try bumping up the density to 1.5 at 360 dpi and see if it

   Could the reason be less dot overlap? The printer must use the same 
   dotsize for all resolutions but when running in 360dpi the dots
   dont touch and are even a little apart?

Actually, there are different dot sizes that can be chosen in 360 dpi
mode.  Even with the largest, things are too light.

(I've also noticed that the printer sometimes drops multiple dots in
360 dpi mode, but that's another matter.)

Re: [Gimp-print-devel] New dither codes

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

On Fri, Apr 28, 2000 at 06:57:49PM -0400, Robert L Krawitz wrote:
> For some reason, the 360 dpi prints seem to be much lighter on every
> printer.  Try bumping up the density to 1.5 at 360 dpi and see if it

Could the reason be less dot overlap? The printer must use the same 
dotsize for all resolutions but when running in 360dpi the dots
dont touch and are even a little apart?

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

[Gimp-print-devel] Photo mode

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

I've made what may be a significant improvement to photo mode.  In
some smooth midtone areas, photo mode tended to produce spidery lines,
mostly vertical, and some very fine patterning in some other smooth
midtone areas.  I believe I've solved that while retaining the
smoother texture in pale areas.

Photo mode should also work well in other contexts now.  It's probably
a bit slower, although that's not certain (I don't notice the difference).

-- 
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] Andy or Mitch, please read the Help forum

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

I noticed across the following message:

  BY: vivien
  DATE: 04/28/00 08:59
  SUBJECT: Compilation error

  I have previously successfully compiled version 3.1.2 but version
  3.1.3 does not compile. I receive the error :

  gimp_color_window.c : In function gimp_create_color_adjust_window 
  78 : warning : implicit declaration of function gimp_dialog_new 
  79 : 'gimp_plugin_help_func' undeclared (first use in this function) 

  etc. 

  The unsuccessful compilation was made on Linux (Suse 6.3) whith
  version 1.1.11 of gimp (and 2.91.66 of gcc). The gimp-devel package
  is installed. I think the problem is with gimp. Do I need to upgrade
  to the latest version (I would rather not) ?

  Thanks for the help. 


  Frederic Vivien

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

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

I've added them to the repository.  I might take a crack at building
SuSE RPM's from this, although not right now (I'm trying to fine tune
the dither code).

-- 
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] Print quality

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

BTW, what is people's overall impression of print quality between
3.1.2, 3.1.3, and the current repository?

Re: [Gimp-print-devel] New dither codes

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

   Date: Fri, 28 Apr 2000 22:53:41 +0100
   From: Thorsten Schnier <tho...@sc...>

   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.

The hybrid algorithms are beginning to look like real non-starters.
And I had such high hopes for them!  Sigh.

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

What settings are you using (in particular, photograph vs. line art
vs. solid color)?

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

You'll see a difference in very pale areas, but that's it.

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

For some reason, the 360 dpi prints seem to be much lighter on every
printer.  Try bumping up the density to 1.5 at 360 dpi and see if it
helps.  How fast was this mode?

Try setting the saturation to 1.2~1.4.

   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.

Hmm.  Did the print try to continue on another page?  I'd really like
to see what that's like.

Try 720 highest quality.  720 softweave will show a lot of banding.