CompuServe Messages

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