[comp.sys.sgi] Fooling with 'tops' and 'imgexp' utilities

dhinds@portia.Stanford.EDU (David Hinds) (04/10/91)

I'm curious about the parameters for the 'tops' program.  I remember reading
that the default halftone screens on Laserwriters were very nonoptimal; are
there some values that work better with 'tops', or are its defaults as good
as they can be?  Also, I can't seem to get a plain white background with my
printed images.  I used the 'invert' program to flip the screen black to
white, but it comes out as a sparse dot pattern on our laser printer.  So,
I tried using 'imgexp {files} 10 245' to force the very light and very dark
areas to true white and black.  When I look at the images before and after
with 'hist', however, they seem to have exactly the same grey scale ranges!
There are still lots of vertices with grey values in the 251..254 range.
'imgexp' does seem to work if I ask for more extreme range reductions.

 -David Hinds
  dhinds@cb-iris.stanford.edu

fouts@tom.dallas.sgi.com (Christopher L. Fouts) (04/12/91)

In article <1991Apr10.010515.19951@leland.Stanford.EDU>, dhinds@portia.Stanford.EDU (David Hinds) writes:
|> I'm curious about the parameters for the 'tops' program.  I remember reading
|> that the default halftone screens on Laserwriters were very nonoptimal; are
|> there some values that work better with 'tops', or are its defaults as good
|> as they can be?  Also, I can't seem to get a plain white background with my
|> printed images.  I used the 'invert' program to flip the screen black to
|> white, but it comes out as a sparse dot pattern on our laser printer.  So,
|> I tried using 'imgexp {files} 10 245' to force the very light and very dark
|> areas to true white and black.  When I look at the images before and after
|> with 'hist', however, they seem to have exactly the same grey scale ranges!
|> There are still lots of vertices with grey values in the 251..254 range.
|> 'imgexp' does seem to work if I ask for more extreme range reductions.

There is a slight bug (feature?) in the routine to convert RGB to black and
white.  In tops.c (as of 3.3.2), the routine rgbrowtobw has the following line:

            *obuf++ = (77*(*rbuf++) + 150*(*gbuf++) + 28*(*bbuf++))>>8;

Notice that for a gray RGB value (rbuf = gbuf = bbuf = value ), this is the
same as

	    *obuf = ( (77+150+28) * value ) >> 8 ;   or
		  = ( 255 * value ) / 256

Thus white RGB values (value = 255) get rounded off to 254, which results in
a very sparse dithering.  Correct this by adding 1 to the constant of your
choice, such that the total is 256, as in

            *obuf++ = (77*(*rbuf++) + 150*(*gbuf++) + 29*(*bbuf++))>>8;
						      ^^
 
-- 
Chris L. Fouts                           email: fouts@dallas.sgi.com
Systems Engineer                         vmail: 8714
SGI - Dallas                             phone: 214-788-4122

"To me, boxing is like a ballet except that there is no dancing, no
 choreography, and the dancers hit each other." - Saturday Night Live

dhinds@elaine18.Stanford.EDU (David Hinds) (04/13/91)

In article <1991Apr10.010515.19951@leland.Stanford.EDU> dhinds@portia.Stanford.EDU I wrote:
>I'm curious about the parameters for the 'tops' program.  I remember reading
>that the default halftone screens on Laserwriters were very nonoptimal; are
>there some values that work better with 'tops', or are its defaults as good
>as they can be?

To answer my own question, there is an article in the July 1990 BYTE on how
to choose the halftone screen parameters.  The screen set by 'tops' isn't on
their chart, but by extrapolation, it looks like it might even be worse than
the default on the Laserwriter.  They recommend several sets of parameters:
106-spot-per-inch/35-degree, 85-spot/35-degree, and 135-spot/25-degree.
These offer fewer grey levels than the default values, but they look so much
smoother than the defaults that there is no comparison.  These parameters
should work well on any 300dpi printer.

>Also, I can't seem to get a plain white background with my
>printed images.  I used the 'invert' program to flip the screen black to
>white, but it comes out as a sparse dot pattern on our laser printer.

The 'tops' program doesn't seem to want to produce images with plain white
areas.  When I convert an 8-bit greyscale image with values 0..255 according
to 'istat', I get a Postscript file with pixel values 0..254.  If I invert
the image and repeat, I still get a file with values 0..254.  There doesn't
seem to be any way to get plain white (255), though if I simply edit the
image files and look, they clearly contain pixels with this value.

 -David Hinds
  dhinds@cb-iris.stanford.edu