#HAM format, anyone?
9 messages in this thread
Coming from an IBMer, I've always had a little bit of trouble with a graphic
format that seems to be somewhat "native" to the Amiga. Could anyone possibly
fill me in on the Hold And Modify (HAM) format? I would be most interested in
knowing the encoding of this graphics format…
If anyone could spare the time (possibly uploading it for other potential
programmers…?) to type it and send a note my way, I would be appreciative!
-Steve Mulhern
Steve,
I'm no graphics expert, but I believe the basis behind HAM is that the
color palette changes for each scan line.
DJ
Eulogio, even though I appreciate the input, I am sitting here and actually
contemplating this…from my experience, the WORST possible form of compression
one can have on a graphics image would be in the Windows BMP format (which it
considers "native", of course!). This requires a sizing string (for example,
800 x 600), a colour depth indicator (256), and then 3 bits per color to
"define" that color (ie. Pure red would be 255-0-0). Following that would be
64000 bits of "pattern" information (in a 256 color graphic) which would
specify which palette position to color that specific dot…no run-length
encoding (such as a PCX, TIFF, JPG, GIF) to shrink the thing.
Microminds…..errr, Microsoft did this not to save disk space, but to make an
otherwise crawling application somewhat faster at loading graphics, at the
premium price of disk space.
What you are describing to me is something that would have to re-define the
color every scan line, therefore, in a complicated HAM, actually taking up more
disk space than Windows native BMP format?
From what (little) I've been able to hammer out (which, considering I am typing
from an IBM keyboard, and have no accessibility to an Amiga) is that the
beginning 15 (hex) characters in a HAM format is an indentification string,
similiar to an IFF file (which, if you look at any IFF format through a HEX
viewer, you'll see FORM….ILBM starting it off). Most, if not all, graphics
images start out with this. Also following that should be six hex bytes which
will specify x coordinants, y coordinants, and colour depth. Following that,
depending on the graphics format used, is either the color palette information
(red/blue/green or red/blue/green/black), or "plane" information. (I am aware
that some graphics have more than one "plane" (as I've seen some "moving"
images, as well as some "hidden" images brought to life))…just how to decode
the native Amiga HAMs, as well as colour IFF/LBM files, eludes me…
— Steve
Steve,
Well, Eulogio gave you some bad information. The way HAM is encoded (I
don't recall the actual bit patterns, but they're unimportant):
There are two flavo(u)rs of HAM, HAM6 and HAM8, each uses two bits
to encode whether to load a color from a palette of (16 or 64…the
remaining bits in the code) or whether to set the red/green/blue gun
to an absolute value (using the remaining bits). The original Amiga
had only 4 bits per 'gun' therefore a total of 4096 colo(u)rs; these
could all be displayed in HAM by directly setting the relevant color
registers, even tho only one could be set per pixel.
Sorry, I didn't intend it to be an explanation of how it's done,
merely that "I believed" the palette effectively changes, or can
change, in some way from scan line to scan line. It WAS somewhat
misleading, but not totally untrue, since you are modifying the
palette on the fly. See how easy it is to rationalize ignorance
<G>? Didn't mean to confuse you!
Eulogio,
You _can't_ confuse ME <grin>. I'm already confused!!
Any pixel in a HAM image can draw its color from two sources: From the
palette (just like any other picture) or from the pixel immediatelly
to the left of it!
For Example a 6 bit HAM: Every pixel uses 6 bits to determine a color
If the most signif bit is set the Least signif 4 bits point to a
color in a 16 Color Table. If the Most signif bit is not set then the
Least signif 5 bits tell the display how to change either the R, G or
B component of the previous pixel.
I am a little hazy on the details, but if it is more than curiosity
mail me a FAX number and I will send you detailed info on the
standard.
HAM (Hold And Modify) format, without knowing the specific
encoding, was a cheat that the Amiga people came up with to allow
more color on screen (up to 4096) using as little space as possible
on disk at the expense of clarity (If not done *absolutely* right can
produce incredible amounts of artifacts.)
HAM is good in some aspects and wishy-washy at others.
Here is what HAM is in a nutshell:
An Amiga standard IFF picture with a 16 color palette. You can
achive more colors than the base by changing one color register at a
time (going right.)
Example:
You have a base color light grey background (Red 13, Grn 13, Blu
13) and you want to put down a color (one that isn't on your base
palette) lets say it's a lavender (Red 11, Grn12, Blu 14).
The computer looks to the left of that color and tries to pic
an intermediate by changing one of the color registers.
The computer then looks to the left of *that* color and tries
to pick another intermediate by changing one register.
And so it goes, until there is a band of pixels, different by
one register, from the background to the foreground.
My above example looks like this left to right:
R13 G13 B13 (light grey Background) One of the base colors.
R11 G13 B13
R11 G12 B13
R11 G12 B14 (lavender foreground) Not one of the base colors.
So, to get the pixel the color that I wanted the computer *had* to put
down two other pixels.
This loose way of playing with color *can* and does work… if you know
what you're doing. But I would not recommend using it for anything but
display work because in printed form these "artifacts" can blow the whole
shee-bang.
I hope this clears things up for you.
Keep it cool
~Brian Silva
Yes- that does do quite a bit as far as clarifying the issue at
hand…looking it over, it could result in quite a bit of "savings"
as far as drive space.
With what you are describing, is there a certain "bit" presence to
look for (IE- If bytes 7 and 6 are set, increase red "gun" by bits
3-2-1-0) for decoding purposes? (The entire reasoning to this line
of questioning is to try to "decode" and "recode" the HAM format of
files through creative programming on a non-Amiga).