[comp.sys.amiga] grey scale --> HAM picture

skinner@unc.cs.unc.edu (Andrew Skinner) (01/31/89)

I would like to be able to look at the results of work when I am at home.
A reasonable approximation would do, so I'd like to be able to convert
picture files produced at school to HAM mode pictures, to be displayed
by standard programs.  Does anyone have any free source code I could use
to convert (8 bit greyscale) images to HAM mode?  I'm sure it would be an
interesting and useful project for me, but I just don't have time.  Obviously,
something more general (24 bit RGB to HAM) would be nice, but most of our
stuff currently is greyscale, so I'll take what I can get.  I can do an ftp if
there is something on line.
My email address is:
skinner@unc.cs.unc.edu

Thanks,
andy skinner

mp1u+@andrew.cmu.edu (Michael Portuesi) (01/31/89)

skinner@unc.cs.unc.edu (Andrew Skinner) writes:
> Does anyone have any free source code I could use
> to convert (8 bit greyscale) images to HAM mode? 

There is no need to use HAM mode for greyscale images.  The Amiga
display hardware can only generate 16 shades (4 bits) of grey, which can be
displayed simultaneously in any resolution without using HAM.  Better
for you would be a program that converts 8 bit greyscale to 4 bit
greyscale, and saves the results in IFF.

Also, by not using HAM mode, you can display the pictures in high
resolution, which is 640x400 versus the maximum 320x400 that HAM mode
offers.

--
Michael Portuesi / Information Technology Center / Carnegie Mellon University
INET:   mp1u+@andrew.cmu.edu / BITNET: mp1u+@andrew
UUCP:   ...harvard!andrew.cmu.edu!mp1u+

"I'm very sorry, Master, but that WAS the backup system" -- Slave

skinner@pooh.cs.unc.edu (Andrew Skinner) (02/01/89)

In article <6432@thorin.cs.unc.edu> skinner@unc.cs.unc.edu (Andrew Skinner) writes:
>
>A reasonable approximation would do, so I'd like to be able to convert
>picture files produced at school to HAM mode pictures, to be displayed
>by standard programs.  Does anyone have any free source code I could use
>to convert (8 bit greyscale) images to HAM mode?  I'm sure it would be an

The responses I have gotten (thanks) all tell me that I only have 16 shades of
grey, so HAM won't help.  I know that.  My own question is whether it would
be better to have some near-grey colors in between grey shades (using HAM--I
know they wouldn't really be grey), or to just use the 16 I have.  The second
is easier, and I wouldn't have considered it without the replies I got.  But
I'd like to get as much color resolution as I can, since I want to look at
high quality 3D renderings.  I can probably do the second, given time to do
it, without problem.  I can do the first, too, given HAM docs and, again, time.
(I'm not a graphics beginner.)  What I would like is similar code, that I can
use without taking lots of time from the work that produces the pictures I
want to see.
The other thing I learned from the responses was that HAM didn't give me full
resolution.  I either didn't know that or had forgotten.  I think I will try
to just use the 4 bits I've got, for now.
Thanks again,
andy skinner
skinner@unc.cs.unc.edu

c60a-1fy@web-2a.berkeley.edu (Anon) (02/01/89)

In article <6432@thorin.cs.unc.edu> skinner@unc.cs.unc.edu (Andrew Skinner) writes:
>
>I would like to be able to look at the results of work when I am at home.
>A reasonable approximation would do, so I'd like to be able to convert
>picture files produced at school to HAM mode pictures, to be displayed
>by standard programs.  Does anyone have any free source code I could use
>to convert (8 bit greyscale) images to HAM mode?  I'm sure it would be an

Whatta you want ham for?  There are only 16 shades of grey in the palette 
anyway, you ham won't gain you anything.  Just use the 4 msb's and convert
to a 4-plane hires picture.

dale@boing.UUCP (Dale Luck) (02/01/89)

In article mp1u+@andrew.cmu.edu (Michael Portuesi) writes:
#skinner@unc.cs.unc.edu (Andrew Skinner) writes:
#> Does anyone have any free source code I could use
#> to convert (8 bit greyscale) images to HAM mode? 
#
#There is no need to use HAM mode for greyscale images.  The Amiga
#display hardware can only generate 16 shades (4 bits) of grey, which can be
#displayed simultaneously in any resolution without using HAM.  Better
#for you would be a program that converts 8 bit greyscale to 4 bit
#greyscale, and saves the results in IFF.
#

Not completely true, by using the mono output of the 500 or the 2000 you
can get closer to few thousand shades of grey. The rgb values are weighted
differently to produce a single luminance value. It is probably close
to .587g .299g and .11b or something like that.
-- 
Dale Luck     GfxBase/Boing, Inc.
{uunet!cbmvax|pyramid}!amiga!boing!dale

mikes@lakesys.UUCP (Mike Shawaluk) (02/01/89)

In article <19763@agate.BERKELEY.EDU> c60a-1fy@web-2a.berkeley.edu (Anon) writes:
>In article <6432@thorin.cs.unc.edu> skinner@unc.cs.unc.edu (Andrew Skinner) writes:
>>
>>I would like to be able to look at the results of work when I am at home.
>>A reasonable approximation would do, so I'd like to be able to convert
>>picture files produced at school to HAM mode pictures, to be displayed
>>by standard programs.  Does anyone have any free source code I could use
>>to convert (8 bit greyscale) images to HAM mode?  I'm sure it would be an
>
>Whatta you want ham for?  There are only 16 shades of grey in the palette 
>anyway, you ham won't gain you anything.  Just use the 4 msb's and convert
>to a 4-plane hires picture.

This reply to Andrew's original message, and a few others, have pointed out
that HAM won't buy anything in regard to viewing grey-scale images, since
there are only 16 possible shades of grey that can be generated using the
Amiga's 4096 color pallette.  However, Andrew didn't say (at least I didn't
SEE him say it; I don't have the original article, only replies to his
posting) what the resolution of the 8-bit grey scale images was.  If they are
less that 640 by 400, then additional grey shade can be generated by
dithering.  I won't go into a technical discussion of it here, because I'm
not that well-versed on the technical details, but only on the fact that it
should work, provided that the images being imported are of a lower pixel
resolution that 640 x 400.  I should mention that you probably wouldn't be
able to get 256 levels of grey by dithering, even if you went to 320 by 200
effective resolution, and that you'd probably get some flicker because of the
interlace, although if the images are smoothly shaded, the flicker should be
pretty minimal.  Would someone with the appropriate technical background on
graphics and dithering please fill in the gaps in what I've said above (i.e,
tell me if I'm full of $#!+ or not...)

-- 
   - Mike Shawaluk
     ...!uunet!marque!lakesys!mikes

waynet@mongo.uucp (Wayne Thompson) (02/04/89)

In article <613@boing.UUCP> dale@boing.UUCP (Dale Luck) writes:

   Not completely true, by using the mono output of the 500 or the 2000 you
   can get closer to few thousand shades of grey. The rgb values are weighted
   differently to produce a single luminance value. It is probably close
   to .587g .299g and .11b or something like that.
   -- 
   Dale Luck     GfxBase/Boing, Inc.
   {uunet!cbmvax|pyramid}!amiga!boing!dale

Does anyone have have the actual weighting values?

Wayne

dan@ivucsb.UUCP (Dan Howell) (02/12/89)

Another thing you might consider is dithering.  Add a random number between
-8 and +8 to the original 8 bit value, making sure not to overflow or
underflow, and take the 4 MSBs of the result.  This should give a result
which will have an apparent grey-scale resolution much higher than 4 bits,
and will also eliminate the "contouring" effect of short-word-length
quantization.

 
-- Dan Howell  <...!pyramid!nessus!ivucsb!dan>  <dan@ivucsb.UUCP>
-- * Note new address path.  Do not use comdesign, use nessus instead. *

rokicki@polya.Stanford.EDU (Tomas G. Rokicki) (02/13/89)

If you're going to add that random number, accumulate the errors and
apply to the next bit so you don't get too much of grain.

-tom

elbaum@reed.UUCP (Daniel Elbaum) (02/13/89)

In article <338@lakesys.UUCP> mikes@lakesys.UUCP (Mike Shawaluk) writes:
>In article <19763@agate.BERKELEY.EDU> c60a-1fy@web-2a.berkeley.edu (Anon) writes:
>>In article <6432@thorin.cs.unc.edu> skinner@unc.cs.unc.edu (Andrew Skinner) writes:
>>>
>>>I'd like to be able to convert picture files produced at school to HAM
>>>mode pictures, to be displayed [as monochrome images].
>>
>>There are only 16 shades of grey in the palette anyway, [so] ham won't
>>gain you anything.
>
>HAM won't buy anything in regard to viewing grey-scale images
>[but] additional grey shade can be generated by dithering.


If your image is 320 x 200, you can get 60 shades of grey.  Allocate
a hi-res screen, and use a 2 x 2 pixel square (call it a tetrad) for
each pixel in the original image.  Each element of the tetrad can take
on any of 16 shades of grey.  Varying the shade of one tetrad element
(tetrel?) would result in a small incremental change in the shade of
the whole tetrad.  To the eye (I've tried this) the pixels within
the tetrad disappear, so that the smallest apparent element of the
picture is the tetrad rather than the pixel.

It's like building four stacks of coins so that they're all about the same
height.  If you have 64 coins and can't put more than 16 in a single
stack, you start by laying down one coin, then one beside it, then
one below the first, then one below the second, so you have a
square.  Then repeat the process, so eventually you have a 2 x 2
square of coins 16 coins deep.  Each time you put down a new coin,
you increase the total number of coins by one.

But you don't get 64 shades of grey on the screen, since you can't
have a zero-bit-plane display.  In other words, you really only have
15 coins for each stack.  Since you get four increments in tetrad
value for each pixel value, you end up with 60 shades of grey.

I used this technique to display character-graphics pictures (you
know, the pinups made up of ASCII characters) with very good
results.  Resolution does suffer, but the shading turns out nicely.



-- 
                      :                       Daniel Elbaum
 Responsible for all  :               tektronix!reed!elbaum
 disclaimed postings  :                              elbaum@reed.bitnet