ST Picture Formats: Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
|||
| (79 intermediate revisions by 2 users not shown) | |||
| Line 14: | Line 14: | ||
Copyright (C) 1988, 1989, 1990, 1991 by David M. Baggett |
Copyright (C) 1988, 1989, 1990, 1991 by David M. Baggett |
||
Additions 2006-2007 Hans Wessels are public domain. |
Additions 2006-2007 Hans Wessels are public domain. |
||
| + | Additions 2015-2017 Lonny Pursell are public domain. |
||
Non-profit redistribution of this document is permitted, provided |
Non-profit redistribution of this document is permitted, provided |
||
| Line 44: | Line 45: | ||
Contents |
Contents |
||
-------- |
-------- |
||
| + | </pre> |
||
| + | [[Animaster Sprite Bank file format]] *.ASB |
||
| + | [[Animatic Film file format]] *.FLM |
||
| + | [[Art Director file format]] *.ART |
||
| + | [[Calamus Raster Graphic file format]] *.CRG |
||
| + | [[Canvas file format]] *.CNV *.CPT |
||
| + | [[COKE file format]] *.TG1 |
||
| + | [[ColorBurst file format]] *.BST |
||
| + | [[C.O.L.R. Object Editor file format]] *.MUR |
||
| + | [[ComputerEyes Raw Data file format]] *.CE? ? = 1, 2, 3 |
||
| + | [[CrackArt file format]] *.CA? ? = 1, 2, 3 |
||
| + | [[Cybermate Delta Animation file format]] *.DLT |
||
| + | [[Cyber Paint Cell file format]] *.CEL |
||
| + | [[Cyber Paint Sequence file format]] *.SEQ |
||
| + | [[Dali file format]] *.SD? ? = 0, 1, 2 |
||
| + | [[Dali Compressed file format]] *.?PK ? = L, M, H |
||
| + | [[DEGAS file format]] *.PI? ? = 1, 2, 3 (4, 5, 6) |
||
| + | [[DEGAS Elite file format]] *.PI? ? = 1, 2, 3 |
||
| + | [[DEGAS Elite Block file format]] *.BL? ? = 1, 2, 3 |
||
| + | [[DEGAS Elite Compressed file format]] *.PC? ? = 1, 2, 3 |
||
| + | [[DEGAS Elite Font file format]] *.FNT |
||
| + | [[DEGAS Elite Icon file format]] *.ICN |
||
| + | [[DelmPaint file format]] *.DEL *.DPH |
||
| + | [[DeskPic file format]] *.GFB |
||
| + | [[Doodle file format]] *.DOO |
||
| + | [[DUO file format]] *.DU? ? = 1, 2, O |
||
| + | [[DuneGraph file format]] *.DG1 *.DC1 |
||
| + | [[EggPaint file format]] *.TRP |
||
| + | [[EZ-Art Professional file format]] *.EZA |
||
| + | [[FuckPaint file format]] *.PI4 *.PI9 |
||
| + | [[Funny Paint file format]] *.FUN |
||
| + | [[GDOS Font file format]] *.FNT |
||
| + | [[GEM Bit Image file format]] *.IMG |
||
| + | [[GEM Metafile file format]] *.GEM |
||
| + | [[GFA Artist file format]] *.ART |
||
| + | [[GFA Raytrace file format]] *.SA? *.SC? *.SU? ? = L, H |
||
| + | [[GodPaint file format]] *.GOD |
||
| + | [[HighresMedium file format]] *.HRM |
||
| + | [[IFF file format]] *.IFF |
||
| + | [[ImageLab file format]] *.B&W *.B_W |
||
| + | [[Imagic Film/Picture file format]] *.IC? ? = 1, 2, 3 |
||
| + | [[IMG Scan file format]] *.RWL *.RWH *.RAW |
||
| + | [[IndyPaint file format]] *.TRU |
||
| + | [[InShape file format]] *.IIM |
||
| + | [[Lexicor Film file format]] *.FLM |
||
| + | [[MacPaint file format]] *.MAC |
||
| + | [[MegaPaint file format]] *.BLD |
||
| + | [[NEOchrome file format]] *.NEO |
||
| + | [[NEOchrome Animation file format]] *.ANI |
||
| + | [[Overscan Interlaced file format]] *.PCI |
||
| + | [[Pablo Paint file format]] *.PPP *.PA3 |
||
| + | [[PaintPro ST/PlusPaint ST]] *.PIC |
||
| + | [[PaintShop file format]] *.PSC *.DA4 |
||
| + | [[Paintworks file format]] *.CL? *.PG? *.SC? ? = 0, 1, 2 |
||
| + | [[PhotoChrome file format]] *.PCS |
||
| + | [[Picture Packer file format]] *.PP? ? = 1, 2, 3 |
||
| + | [[Picworks file format]] *.CP3 |
||
| + | [[PixArt file format]] *.PIX |
||
| + | [[PL4 file format]] *.PL4 |
||
| + | [[Print-Technik Raw Data file format]] *.HIR |
||
| + | [[Public Painter file format]] *.CMP |
||
| + | [[QuantumPaint file format]] *.PBX |
||
| + | [[Rag-D file format]] *.RAG |
||
| + | [[Rembrandt file format]] *.TCP |
||
| + | [[RGB Intermediate file format]] *.RGB |
||
| + | [[Signum! file format]] *.IMC |
||
| + | [[Spectrum 512 file format]] *.SPU |
||
| + | [[Spectrum 512 Compressed file format]] *.SPC |
||
| + | [[Spectrum 512 Enhanced file format]] *.SPU |
||
| + | [[Spectrum 512 Extended file format]] *.SPX |
||
| + | [[Spectrum 512 Smooshed file format]] *.SPS |
||
| + | [[Spooky Sprites file format]] *.TRE *.TRP |
||
| + | [[STAD file format]] *.PAC |
||
| + | [[STOS Memory Bank file format]] *.MBK |
||
| + | [[Synthetic Arts file format]] *.SRT |
||
| + | [[Tiny file format]] *.TN? ? = 1, 2, 3, Y, (4, 5, 6) |
||
| + | [[TmS Cranach file format]] *.ESM |
||
| + | [[TruePaint Animation file format]] *.TPA |
||
| + | [[TruePaint/Prism Paint file format]] *.TPI *.PNT |
||
| + | [[Video Master file format]] *.FLM *.VID *.VSQ |
||
| + | [[Warp9 Font file format]] *.FNT |
||
| + | [[ZZ_ROUGH file format]] *.RGH |
||
| + | [[PackBits Compression Algorithm]] |
||
| − | NEOchrome *.NEO |
||
| + | <pre> |
||
| − | NEOchrome Animation *.ANI |
||
| − | DEGAS *.PI? ? = 1, 2, 3 (4, 5, 6) |
||
| − | DEGAS Elite *.PI? ? = 1, 2, 3 |
||
| − | DEGAS Elite (Compressed) *.PC? ? = 1, 2, 3 |
||
| − | DEGAS Elite block *.BL? ? = 1, 2, 3 |
||
| − | DEGAS Elite icon *.ICN |
||
| − | CrackArt *.CA? ? = 1, 2, 3 |
||
| − | ArtDirector *.ART |
||
| − | Tiny *.TN? ? = 1, 2, 3, Y, (4, 5, 6) |
||
| − | Spectrum 512 *.SPU |
||
| − | Spectrum 512 (Compressed) *.SPC |
||
| − | Spectrum 512 (Smooshed) *.SPS |
||
| − | Spectrum 512 Extended *.SPX |
||
| − | Photochrome *.PCS |
||
| − | QuantumPaint *.PBX |
||
| − | Art Director *.ART |
||
| − | C.O.L.R. Object Editor Mural *.MUR |
||
| − | Doodle *.DOO |
||
| − | Cyber Paint Sequence *.SEQ |
||
| − | Animatic Film *.FLM |
||
| − | Animaster Sprite Bank *.ASB |
||
| − | STOS *.MBK |
||
| − | GEM Bit Image *.IMG |
||
| − | STAD *.PAC |
||
| − | Imagic Film/Picture *.IC? ? = 1, 2, 3 |
||
| − | IFF *.IFF |
||
| − | HighresMedium *.HRM |
||
| − | Overscan Interlaced *.PCI |
||
| − | Picture Packer *.PP1? ? = 1, 2, 3 |
||
| − | MacPaint *.MAC |
||
| − | RGB Intermediate Format *.RGB |
||
| − | ComputerEyes Raw Data Format *.CE? ? = 1, 2 |
||
| − | FuckPaint *.PI4 *.PI9 |
||
| − | TruePaint *.TPI |
||
| − | DelmPaint *.DEL, *.DPH |
||
| − | EggPaint *.TRP |
||
| − | IndyPaint *.TRU |
||
| − | GodPaint *.GOD |
||
| − | PixArt *.PIX |
||
| − | Canvas *.CNV *.CPT |
||
| − | DuneGraph *.DGU *.DGC |
||
| − | PackBits Compression Algorithm |
||
| − | |||
| − | |||
Introductory Information |
Introductory Information |
||
------------------------ |
------------------------ |
||
| Line 119: | Line 159: | ||
palette entry, since a few programs store special |
palette entry, since a few programs store special |
||
information there (most notably Art Studio). |
information there (most notably Art Studio). |
||
| − | |||
| − | |||
| − | The Formats |
||
| − | ----------- |
||
| − | |||
| − | <NEOchrome> *.NEO |
||
| − | |||
| − | 1 word flag byte [always 0] |
||
| − | 1 word resolution [0 = low res, 1 = medium res, 2 = high res] |
||
| − | 16 words palette |
||
| − | 12 bytes filename [usually " . "] |
||
| − | 1 word color animation limits. High bit (bit 15) set if color |
||
| − | animation data is valid. Low byte contains color animation |
||
| − | limits (4 most significant bits are left/lower limit, |
||
| − | 4 least significant bits are right/upper limit). |
||
| − | 1 word color animation speed and direction. High bit (bit 15) set |
||
| − | if animation is on. Low order byte is # vblanks per step. |
||
| − | If negative, scroll is left (decreasing). Number of vblanks |
||
| − | between cycles is |x| - 1 |
||
| − | 1 word # of color steps (as defined in previous word) to display |
||
| − | picture before going to the next. (For use in slide shows) |
||
| − | 1 word image X offset [unused, always 0] |
||
| − | 1 word image Y offset [unused, always 0] |
||
| − | 1 word image width [unused, always 320] |
||
| − | 1 word image height [unused, always 200] |
||
| − | 33 words reserved for future expansion |
||
| − | 16000 words picture data (screen memory) |
||
| − | ----------- |
||
| − | 32128 bytes total |
||
| − | |||
| − | |||
| − | <NEOchrome Animation> *.ANI |
||
| − | |||
| − | NOTE: To get this feature on versions 0.9 and later select the Grabber |
||
| − | icon and click both mouse buttons in the eye of the second R in the |
||
| − | word GRABBER. |
||
| − | Interestingly enough, some versions of NEO only require you |
||
| − | to press the right button, not both. Hmmm... |
||
| − | |||
| − | 1 long magic number BABEEBEA (hex) (seems to be ignored) |
||
| − | 1 word width of image in bytes (always divisible by 8) |
||
| − | 1 word height of image in scan lines |
||
| − | 1 word size of image in bytes + 10 (!) |
||
| − | 1 word x coordinate of image (must be divisible by 16) - 1 |
||
| − | 1 word y coordinate of image - 1 |
||
| − | 1 word number of frames |
||
| − | 1 word animation speed (# vblanks to delay between frames) |
||
| − | 1 long reserved; should be zero |
||
| − | -------- |
||
| − | 22 bytes total for header |
||
| − | |||
| − | ? words image data (words of screen memory) for each frame, in |
||
| − | order |
||
| − | |||
| − | |||
| − | <DEGAS> *.PI1 (low resolution) |
||
| − | *.PI2 (medium resolution) |
||
| − | *.PI3 (high resolution) |
||
| − | (PI4, PI5, PI6) |
||
| − | |||
| − | 1 word resolution (0 = low res, 1 = medium res, 2 = high res) |
||
| − | Other bits may be used in the future; use a simple bit |
||
| − | test rather than checking for specific word values. |
||
| − | 16 words palette |
||
| − | 16000 words picture data (screen memory) |
||
| − | ----------- |
||
| − | 32034 bytes total |
||
| − | |||
| − | Conny Pettersson of Unit Seventeen proposed to extend the Degas format with |
||
| − | PI4 and PI5 for TT resolutions in a text file accompaning the viewst program: |
||
| − | |||
| − | For saving the pictures, I have extended the standard Degas-format PI0 to |
||
| − | the TT-resolutions. Following is a description of the format I use: |
||
| − | ST-Low TT-Low TT-Medium |
||
| − | Extension PI0 PI4 PI5 |
||
| − | Resolution 1 word: $0000 1 word: $0007 1 word: $0004 |
||
| − | Colormap 16 word 256 word 16 word |
||
| − | Bitmap 32000 bytes 153600 bytes 153600 bytes |
||
| − | Total length 32034 bytes 154114 bytes 153634 bytes |
||
| − | |||
| − | This format is not in wide spread use as datacompression on those huge screens |
||
| − | really makes sence. Nevertheless various file-extension decriptions on the |
||
| − | internet assign the extensions PI4, PI5 and PI6 to TT Degas resolutions. |
||
| − | |||
| − | <DEGAS Elite> *.PI1 (low resolution) |
||
| − | *.PI2 (medium resolution) |
||
| − | *.PI3 (high resolution) |
||
| − | |||
| − | 1 word resolution (0 = low res, 1 = medium res, 2 = high res) |
||
| − | Other bits may be used in the future; use a simple bit |
||
| − | test rather than checking for specific word values. |
||
| − | 16 words palette |
||
| − | For high resolution pictures the least significant bit of |
||
| − | the first word determines whether the picture is black on |
||
| − | white (bit set) or white on black (bit not set) |
||
| − | 16000 words picture data (screen memory) |
||
| − | 4 words left color animation limit table (starting color numbers) |
||
| − | 4 words right color animation limit table (ending color numbers) |
||
| − | 4 words animation channel direction flag (0 = left, 1 = off, 2 = right) |
||
| − | 4 words 128 - animation channel delay in 1/60's of a second. [0 - 128] |
||
| − | (I.e., subtract word from 128 to get 1/60th's of a second.) |
||
| − | ----------- |
||
| − | 32066 bytes total |
||
| − | |||
| − | |||
| − | <DEGAS Elite (Compressed)> *.PC1 (low resolution) |
||
| − | *.PC2 (medium resolution) |
||
| − | *.PC3 (high resolution) |
||
| − | |||
| − | 1 word resolution (same as Degas, but high order bit is set; |
||
| − | i.e., hex 8000 = low res, hex 8001 = medium res, |
||
| − | hex 8002 = high res). Other bits may be used in the |
||
| − | future; use a simple bit test rather than checking |
||
| − | for specific word values. |
||
| − | 16 words palette |
||
| − | For high resolution pictures the least significant bit of |
||
| − | the first word determines whether the picture is black on |
||
| − | white (bit set) or white on black (bit not set) |
||
| − | < 32000 bytes control/data bytes |
||
| − | 4 words left color animation limit table (starting color numbers) |
||
| − | 4 words right color animation limit table (ending color numbers) |
||
| − | 4 words animation channel direction flag [0 = left, 1 = off, 2 = right] |
||
| − | 4 words 128 - animation channel delay in 1/60's of a second. [0 - 128] |
||
| − | (I.e., subtract word from 128 to get 1/60th's of a second.) |
||
| − | ----------- |
||
| − | < 32066 bytes total |
||
| − | |||
| − | Compression Scheme: |
||
| − | |||
| − | PackBits compression is used (see below). Each scan line is compressed |
||
| − | separately; i.e., all data for a given scan line appears before any data |
||
| − | for the next scan line. The scan lines are specified from top to bottom |
||
| − | (i.e., 0 is first). For each scan line, all the data for a given bit plane |
||
| − | appears before any data for the next higher order bit plane. Note that this |
||
| − | is identical to the IFF 'BODY' image data. |
||
| − | To clarify: The first data in the file will be the data for the lowest |
||
| − | order bit plane of scan line zero, followed by the data for the next higher |
||
| − | order bit plane of scan line zero, etc., until all bit planes have been |
||
| − | specified for scan line zero. The next data in the file will be the data |
||
| − | for the lowest order bit plane of scan line one, followed by the data for |
||
| − | the next higher order bit plane of scan line one, etc., until all bit planes |
||
| − | have been specified for all scan lines. |
||
| − | |||
| − | Caveats: |
||
| − | |||
| − | DEGAS Elite's picture loading routine places some restrictions on |
||
| − | compressed DEGAS files: |
||
| − | |||
| − | o Elite uses a 40-byte buffer to store data being decompressed. |
||
| − | |||
| − | o Whenever a control command is encountered, bytes are stuffed |
||
| − | in this buffer. |
||
| − | |||
| − | o The buffer is only emptied when there are EXACTLY 40 |
||
| − | characters in it. |
||
| − | |||
| − | The important conclusion here is that |
||
| − | |||
| − | No control command may cause the buffer to have more than 40 |
||
| − | bytes in it. In other words, all control commands must end on |
||
| − | or before the 40-byte boundary. |
||
| − | |||
| − | Any picture violating the last condition will cause Elite to get a bus |
||
| − | error when the picture is loaded. |
||
| − | |||
| − | <DEGAS Elite block> *.BL1 (low resolution) |
||
| − | *.BL2 (medium resolution) |
||
| − | *.BL3 (high resolution) |
||
| − | Degas Elite block files are IFF files with a BL? extension. In a Degas |
||
| − | block the following IFF chunks are found: ILBM, BMHD, CMAP and BODY. |
||
| − | See the IFF format description. |
||
| − | |||
| − | |||
| − | <DEGAS Elite icon> *.ICN |
||
| − | This file format is an ASCII file describing the ICON in C-format:#define ICON_W 0x00BF |
||
| − | #define ICON_H 0x???? : Height of the icon in lines (hexadecimal value) |
||
| − | #define ICONSIZE 0x???? : Width of the icon in pixels |
||
| − | int image[ICONSIZE] = 0x???? : Size of the icon in words (hexadecimal value) |
||
| − | { |
||
| − | ?? : ICONSIZE words, icon image data (hexadecimal values) |
||
| − | } |
||
| − | |||
| − | |||
| − | <CarckArt> *.CA1 (low resolution) |
||
| − | *.CA2 (medium resolution) |
||
| − | *.CA3 (high resolution) |
||
| − | |||
| − | 1 word 'CA' crackart magic |
||
| − | 1 byte compression: 00 = uncompressed, 01 = compressed |
||
| − | 1 byte resolution: 00 = low res, 01 = medium res, 02 = high res |
||
| − | ?? words palette |
||
| − | For low res pictures there are 16 palette entries |
||
| − | For med res pictures there are 4 palette entries |
||
| − | For high res pictures there are 0 palette entries |
||
| − | ?? bytes Picture data: |
||
| − | For uncompressed pictures 32000 bytes follow |
||
| − | For compressed pictures the compressed data follows |
||
| − | |||
| − | ----------- |
||
| − | < 32057 bytes total |
||
| − | |||
| − | CrackArt data compression: |
||
| − | 1 byte Escape character |
||
| − | 1 byte Delta: initially the 32000 screen memory are |
||
| − | filled with the delta byte |
||
| − | 1 word Offset: offset between two packed bytes; |
||
| − | Offset is added to the current byte position |
||
| − | to calculate the next byte position. When the |
||
| − | next byte position is greater 32000, the next |
||
| − | byte position is the first position of screen |
||
| − | memory not written to |
||
| − | if Offset = 0, the whole screen if filled with |
||
| − | the delta byte, no packed bytes follow |
||
| − | |||
| − | 1 byte Cmd: Command byte |
||
| − | Cmd <> Escape character: Cmd = one literal byte |
||
| − | Cmd = Escape charater: |
||
| − | read 1 control byte |
||
| − | 0: read one byte, n, and one byte, b; |
||
| − | repeat b (n+1) times |
||
| − | 1: read one word, n, and one byte, b; |
||
| − | repeat b (n+1) times |
||
| − | 2: read one byte, if zero: stop else read |
||
| − | one extra byte and to make word n: |
||
| − | repeat Delta (n+1) times |
||
| − | Escape character: output one escape charater |
||
| − | else: read one byte, b; |
||
| − | repeat b cmd times |
||
| − | Decompression stops when Escape 2,0 is found or 32000 bytes have been written |
||
| − | |||
| − | |||
| − | <ArtDirector> *.ART |
||
| − | |||
| − | 32000 bytes Picture data |
||
| − | 8x16 words 8 palettes |
||
| − | 8 bytes 8 palette flags, the first pallete with a nonzero flag is used |
||
| − | 248 bytes ?? possibly animation infromation |
||
| − | ----------- |
||
| − | 32512 bytes total |
||
| − | |||
| − | <Tiny> *.TNY (any resolution) |
||
| − | *.TN1 (low resolution) |
||
| − | *.TN2 (medium resolution) |
||
| − | *.TN3 (high resolution) |
||
| − | |||
| − | Several people have reported sightings of mutated Tiny pictures that |
||
| − | do not follow the standard format, so let's be careful out there. What |
||
| − | is described here is the format that David Mumper's original |
||
| − | TNYSTUFF.PRG produces. The TN4 extension has been found on animated low |
||
| − | resolution files. One can assume the same person(s) will also use TN5 and |
||
| − | TN6 for extensions for animated medium and high resolution. |
||
| − | |||
| − | 1 byte resolution (same as NEO, but +3 indicates rotation |
||
| − | information also follows) |
||
| − | |||
| − | If resolution > 2 { |
||
| − | 1 byte left and right color animation limits. High 4 bits |
||
| − | hold left (start) limit; low 4 bits hold right (end) limit |
||
| − | 1 byte direction and speed of color animation (negative value |
||
| − | indicates left, positive indicates right, absolute value |
||
| − | is delay in 1/60's of a second. |
||
| − | 1 word color rotation duration (number of iterations) |
||
| − | } |
||
| − | |||
| − | 16 words palette |
||
| − | 1 word number of control bytes |
||
| − | 1 word number of data words |
||
| − | 3-10667 bytes control bytes |
||
| − | 1-16000 words data words |
||
| − | ------------- |
||
| − | 42-32044 bytes total |
||
| − | |||
| − | Control byte meanings: |
||
| − | |||
| − | For a given control byte, x: |
||
| − | |||
| − | x < 0 Copy -x of unique words to take from the data section |
||
| − | (from 1 to 128) |
||
| − | x = 0 1 word is taken from the control section which specifies |
||
| − | the number of times to repeat the next data word (from |
||
| − | 128 to 32767) |
||
| − | x = 1 1 word is taken from the control section which specifies |
||
| − | the number of unique words to be taken from the data |
||
| − | section (from 128 - 32767) |
||
| − | x > 1 Specifies the number of times to repeat the next word |
||
| − | taken from the data section (from 2 to 127) |
||
| − | |||
| − | Format of expanded data: |
||
| − | |||
| − | The expanded data is not simply screen memory bitmap data; instead, the |
||
| − | data is divided into four sets of vertical columns. (This results in |
||
| − | better compression.) A column consists of one specific word taken |
||
| − | from each scan line, going from top to bottom. For example, column 1 |
||
| − | consists of word 1 on scanline 1 followed by word 1 on scanline 2, etc., |
||
| − | followed by word 1 on scanline 200. |
||
| − | The columns appear in the following order: |
||
| − | |||
| − | 1st set contains columns 1, 5, 9, 13, ..., 69, 73, 77 in order |
||
| − | 2nd set contains columns 2, 6, 10, 14, ..., 70, 74, 78 in order |
||
| − | 3rd set contains columns 3, 7, 11, 15, ..., 71, 75, 79 in order |
||
| − | 4th set contains columns 4, 8, 12, 16, ..., 72, 76, 80 in order |
||
| − | |||
| − | Note that Tiny partitions the screen this way regardless of resolution; i.e., |
||
| − | these aren't bitplanes. For example, medium resolution only has two bitplanes, |
||
| − | but Tiny still divides medium resolution pictures into four parts. |
||
| − | |||
| − | |||
| − | <Spectrum 512> *.SPU |
||
| − | |||
| − | 80 words first scan line of picture (unused) -- should be zeroes |
||
| − | 15920 words picture data (screen memory) for scan lines 1 through 199 |
||
| − | 9552 words 3 palettes for each scan line (the top scan line is |
||
| − | not included because Spectrum 512 can't display it) |
||
| − | ----------- |
||
| − | 51104 bytes total |
||
| − | |||
| − | Note that the Spectrum 512 mode's three palette changes per scan |
||
| − | line allow more colors on the screen than normally possible, but a |
||
| − | tremendous amount of CPU time is required to maintain the image. |
||
| − | |||
| − | The Spectrum format specifies a palette of 48 colors for each scan line. |
||
| − | To decode a Spectrum picture, one must be know which of these 48 colors |
||
| − | are in effect for a given horizontal pixel position. |
||
| − | |||
| − | Given an x-coordinate (from 0 to 319) and a color index (from 0 to 15), |
||
| − | the following C function will return the proper index into the Spectrum |
||
| − | palette (from 0 to 47): |
||
| − | |||
| − | /* |
||
| − | * Given an x-coordinate and a color index, returns the corresponding |
||
| − | * Spectrum palette index. |
||
| − | * |
||
| − | * by Steve Belczyk; placed in the public domain December, 1990. |
||
| − | */ |
||
| − | int |
||
| − | FindIndex(x, c) |
||
| − | int x, c; |
||
| − | { |
||
| − | int x1; |
||
| − | |||
| − | x1 = 10 * c; |
||
| − | |||
| − | if (1 & c) /* If c is odd */ |
||
| − | x1 = x1 - 5; |
||
| − | else /* If c is even */ |
||
| − | x1 = x1 + 1; |
||
| − | |||
| − | if (x >= x1 && x < x1 + 160) |
||
| − | c = c + 16; |
||
| − | else if (x >= x1 + 160) |
||
| − | c = c + 32; |
||
| − | |||
| − | return c; |
||
| − | } |
||
| − | |||
| − | |||
| − | <Spectrum 512 (Compressed)> *.SPC |
||
| − | |||
| − | 1 word flag word [$5350 or "SP"] |
||
| − | 1 word reserved for future use [always 0] |
||
| − | 1 long length of data bit map |
||
| − | 1 long length of color bit map |
||
| − | <= 32092 bytes compressed data bit map |
||
| − | <= 17910 bytes compressed color bit map |
||
| − | -------------- |
||
| − | <= 50014 bytes total |
||
| − | |||
| − | Data compression: |
||
| − | |||
| − | Compression is via a modified run length encoding (RLE) scheme, |
||
| − | similar to DEGAS compressed and Tiny. The data map is stored as a |
||
| − | sequence of records. Each record consists of a header byte followed by |
||
| − | one or more data bytes. The meaning of the header byte is as follows: |
||
| − | |||
| − | For a given header byte, x: |
||
| − | |||
| − | 0 <= x <= 127 Use the next x + 1 bytes literally (no repetition) |
||
| − | -128 <= x <= -1 Use the next byte -x + 2 times |
||
| − | |||
| − | The data appears in the following order: |
||
| − | |||
| − | 1. Picture data, bit plane 0, scan lines 1 - 199 |
||
| − | 2. Picture data, bit plane 1, scan lines 1 - 199 |
||
| − | 3. Picture data, bit plane 2, scan lines 1 - 199 |
||
| − | 4. Picture data, bit plane 3, scan lines 1 - 199 |
||
| − | |||
| − | Decompression of data ends when 31840 data bytes have been used. |
||
| − | |||
| − | Color map compression: |
||
| − | |||
| − | Each 16-word palette is compressed separately. There are three |
||
| − | palettes for each scan line (597 total). The color map is stored as a |
||
| − | sequence of records. Each record starts with a 1-word bit vector which |
||
| − | specifies which of the 16 palette entries are included in the data |
||
| − | following the bit vector (1 = included, 0 = not included). If a palette |
||
| − | entry is not included, it is assumed to be zero (black). The least |
||
| − | significant bit of the bit vector refers to palette entry zero, while the |
||
| − | most significant bit refers to palette entry 15. Bit 15 must be zero, |
||
| − | since Spectrum 512 does not use palette entry 15. Bit 0 should also be |
||
| − | zero, since Spectrum 512 always makes the background color black. |
||
| − | The words specifying the values for the palette entries indicated in |
||
| − | the bit vector follow the bit vector itself, in order (0 - 15). |
||
| − | |||
| − | NOTE: Regarding Spectrum pictures, Shamus McBride reports the following: |
||
| − | |||
| − | "... [The Picture Formats List] says bit 15 of the color map vector |
||
| − | must be zero. I've encountered quite a few files where [bit 15] is |
||
| − | set (with no associated palette entry)..." |
||
| − | |||
| − | |||
| − | <Spectrum 512 (Smooshed), or Anispec, see below> *.SPS |
||
| − | |||
| − | This format compresses Spectrum 512 pictures better than the standard |
||
| − | method. There are at least two programs that support this format, SPSLIDEX |
||
| − | and ANISPEC, although the two seem to differ slightly in their interpretation |
||
| − | of the format. |
||
| − | One point of interest: Shamus McBride deciphered this format without an ST! |
||
| − | |||
| − | 1 word 5350 (hex) ("SP") |
||
| − | 1 word 0 (reserved for future use) |
||
| − | 1 long length of data bit map |
||
| − | 1 long length of color bit map |
||
| − | <= 32092 bytes compressed data bit map |
||
| − | <= 17910 bytes compressed color bit map |
||
| − | ---------- |
||
| − | < 50014 bytes total |
||
| − | |||
| − | Data compression: |
||
| − | |||
| − | Compression is via a modified run length encoding (RLE) scheme, |
||
| − | similar to that used in Spectrum Compressed (*.SPC) pictures. |
||
| − | |||
| − | The data map is stored as a sequence of records. Each record consists of a |
||
| − | header byte followed by one or more data bytes. The meaning of the header |
||
| − | byte is as follows: |
||
| − | |||
| − | For a given header byte, x (unsigned): |
||
| − | |||
| − | 0 <= x <= 127 Use the next byte x + 3 times |
||
| − | 128 <= x <= 255 Use the next x - 128 + 1 bytes literally |
||
| − | (no repetition) |
||
| − | |||
| − | There are two kinds of *.SPS files. The type is defined by the least significant |
||
| − | bit of the last byte in the color bit map. |
||
| − | |||
| − | If the bit is set the data appears in the same order as *.SPC files: |
||
| − | |||
| − | 1. Picture data, bit plane 0, scan lines 1 - 199 |
||
| − | 2. Picture data, bit plane 1, scan lines 1 - 199 |
||
| − | 3. Picture data, bit plane 2, scan lines 1 - 199 |
||
| − | 4. Picture data, bit plane 3, scan lines 1 - 199 |
||
| − | |||
| − | If the bit is not set the data is encoded as byte wide vertical strips: |
||
| − | |||
| − | Picture data, bit plane 0, scan line 1, MSB. |
||
| − | Picture data, bit plane 0, scan line 2, MSB. |
||
| − | Picture data, bit plane 0, scan line 3, MSB. |
||
| − | . . . |
||
| − | Picture data, bit plane 0, scan line 199, MSB. |
||
| − | Picture data, bit plane 0, scan line 1, LSB. |
||
| − | Picture data, bit plane 0, scan line 2, LSB. |
||
| − | . . . |
||
| − | Picture data, bit plane 0, scan line 199, LSB. |
||
| − | Picture data, bit plane 1, scan line 1, MSB. |
||
| − | . . . |
||
| − | Picture data, bit plane 3, scan line 198, LSB |
||
| − | Picture data, bit plane 3, scan line 199, LSB. |
||
| − | |||
| − | A for loop to process that data would look like |
||
| − | |||
| − | for (plane = 0; plane < 4; plane++) |
||
| − | for (x = 0; x < 320; x += 8) |
||
| − | for (y = 1; y < 200; y++) |
||
| − | for (x1 = 0; x1 < 8; x1++) |
||
| − | image[y, x + x1] = ... |
||
| − | |||
| − | Color map compression: |
||
| − | |||
| − | Color map compression is similar to *.SPC color map compression, but |
||
| − | the map is compressed as a string of bits, rather than words. There are |
||
| − | 597 records (one for each palette). Each record is composed of a 14-bit |
||
| − | header followed by a number of 9-bit palette entries. The 14-bit header |
||
| − | specifies which palette entries follow (1 = included, 0 = not included). |
||
| − | The most significant bit of the header refers to palette entry 1, while |
||
| − | the least significant bit refers to palette 14. Palette entries 0 and 15 |
||
| − | are forced to black (zero). Each palette entry is encoded as "rrrgggbbb". |
||
| − | |||
| − | The format of the palette is described above in the section on uncompressed |
||
| − | Spectrum pictures (*.SPU). |
||
| − | |||
| − | <Spectrum 512 (Anispec)> *.SPS |
||
| − | Format for animated Spectrum pictures. |
||
| − | |||
| − | 1 word 5353 (hex) ("SS") |
||
| − | 30 bytes unknown header bytes |
||
| − | 51104 bytes uncompressed spectrum picture (see SPU format) |
||
| − | ?? bytes animation data (unknown format) |
||
| − | |||
| − | |||
| − | <Spectrum 512 Extended> *.SPX |
||
| − | SPX files are extended Spectrum files with more than 200 lines in the picture, |
||
| − | designed by Gizmo of Electronic Images. With a SPX createor like SPXCRT14.PRG |
||
| − | multiple spectrumpictures can be attachted to become one big .SPX file. There |
||
| − | are two known versions of the format. Version 2 files of the format can be |
||
| − | packed as a whole (including the header) with either Ice 2.10 or Atomik 3.5. |
||
| − | |||
| − | 3 bytes 'SPX', SPX magic header |
||
| − | 1 byte version (01 or 02) |
||
| − | 1 byte graphics compression flag, 0 = unpacked |
||
| − | 1 byte palette compression flag, 0 = unpacked |
||
| − | 1 byte number of 32000 byte screens |
||
| − | 3 bytes reserved |
||
| − | ?? bytes NULL terminated author string |
||
| − | ?? bytes NULL terminated description string |
||
| − | 4 bytes size of (packed) graphics data in bytes |
||
| − | 4 bytes size of (packed) palette data in bytes |
||
| − | ?? bytes (packed) graphics data |
||
| − | ?? bytes (packed) palette data |
||
| − | |||
| − | The number of lines in the picture can be calculated by deviding the size of |
||
| − | the unpacked graphics data by 160. The unpacked SPX picture can be treated as a |
||
| − | Spectrum screen with more than 200 lines. |
||
| − | |||
| − | In version 1 when a compression flag is set the data is packed with Ice 2.10. |
||
| − | |||
| − | In version 2 a special packer is used, graphics and palettes are packed in one chunk. |
||
| − | 4 bytes depacked size |
||
| − | 4 bytes packed size |
||
| − | Like the Ice packer data is packed from end of file to start. The depakcer starts |
||
| − | to read data from packed data start+packed size and to write data to |
||
| − | depacked data start+depacked size. A long is read form packed data into a bitbuffer, |
||
| − | when the bitbuffer is empty it is refilled with a new long from the packed file. |
||
| − | With getbits(n) the n most significat bytes are read from the bitbuffer. |
||
| − | while(bytes read<depacked size) |
||
| − | getbits(1) |
||
| − | 0 : literals |
||
| − | len = getbits(4*(getbits(2)+1)) |
||
| − | read len bytes with getbits(8) and write them to the destination |
||
| − | if(len<>$ffff) do a ptr_len |
||
| − | 1 : ptr_len |
||
| − | ptr = getbits(4*(getbits(2)+1)) |
||
| − | len = getbits(4*(getbits(2)+1)) |
||
| − | copy len+3 bytes from ptr |
||
| − | Note: after a literal there is always a ptr_len except when len was $ffff. |
||
| − | |||
| − | |||
| − | <PhotoChrome> *.PCS (low resolution only) |
||
| − | |||
| − | 1 word 0x0140 (hex) x-resolution (always 320) |
||
| − | 1 word 0x00C8 (hex) y-resolution (always 200) |
||
| − | 1 byte 00 = single screen mode |
||
| − | nonzero value's = alternating screen mode, |
||
| − | bit 0 (0x01) not set: second screen data is xor'ed with first screen |
||
| − | bit 1 (0x02) not set: second color palette is xor'ed with first |
||
| − | 1 byte bit 0 (0x01) set: 50 Hz mode, when not set 60 Hz mode |
||
| − | ?? bytes compressed screen data |
||
| − | ?? bytes compressed palette |
||
| − | ?? bytes compressed second screen data (in case of alternating screens) |
||
| − | ?? bytes compressed second palette |
||
| − | ------------- |
||
| − | > 18 bytes total |
||
| − | |||
| − | Screen compression scheme: |
||
| − | 1 word total number of control bytes that follow |
||
| − | 1 control byte x |
||
| − | x < 0 : copy -x literal bytes (1 - 128) |
||
| − | x = 0 : next word specifies the number of times the following byte |
||
| − | has to be copied (0-65535) |
||
| − | x = 1 : next word specifies the number of bytes to be copied (0-65535) |
||
| − | x > 1 : repeat the next byte x times (2-127) |
||
| − | |||
| − | The 4 bitplanes are separated, first 8000 bytes of the first bitplane, then 8000 bytes |
||
| − | for the second, 8000 bytes for the third and 8000 bytes for the fourth; a total of 32000 bytes. |
||
| − | |||
| − | Palette compression scheme: |
||
| − | the palette compression scheme is the same as the screen compression but it works with |
||
| − | 16 bit words |
||
| − | 1 word total number of control bytes that follow |
||
| − | 1 control byte x |
||
| − | x < 0 : copy -x literal words (1 - 128) |
||
| − | x = 0 : next word specifies the number of times the following word |
||
| − | has to be copied (0-65535) |
||
| − | x = 1 : next word specifies the number of words to be copied (0-65535) |
||
| − | x > 1 : repeat the next word x times (2-127) |
||
| − | |||
| − | In total 9616 palette entries are stored. 200 scanlines with 3 palettes |
||
| − | (48 colors) each, plus one final palette (16 colors). PhotoChrome files |
||
| − | with a few extra entries have been found. The first scanline usually |
||
| − | contains no data. |
||
| − | |||
| − | /* |
||
| − | * Given an x-coordinate and a color index, returns the corresponding |
||
| − | * Photochrome palette index. |
||
| − | * |
||
| − | * by Hans Wessels; placed in the public domain januari, 2008. |
||
| − | */ |
||
| − | int find_pcs_index(int x, int c) |
||
| − | { |
||
| − | int x1=4*c; |
||
| − | int index = c; |
||
| − | if(x>=x1) |
||
| − | { |
||
| − | index+=16; |
||
| − | } |
||
| − | if((x>=(x1+64+12)) && (c<14)) |
||
| − | { |
||
| − | index+=16; |
||
| − | } |
||
| − | if((x>=(132+16)) && (c==14)) |
||
| − | { |
||
| − | index+=16; |
||
| − | } |
||
| − | if((x>=(132+20)) && (c==15)) |
||
| − | { |
||
| − | index+=16; |
||
| − | } |
||
| − | x1=10*c; |
||
| − | if((c&1)==1) |
||
| − | { |
||
| − | x1-=6; |
||
| − | } |
||
| − | if((x>=(176+x1)) && (c<14)) |
||
| − | { |
||
| − | index+=16; |
||
| − | } |
||
| − | return index; |
||
| − | } |
||
| − | |||
| − | <QuantumPaint> *.PBX (low and medium resolution) |
||
| − | |||
| − | 3 bytes 0 |
||
| − | 1 byte mode, 0x00 = 128 color low resolution pciture, |
||
| − | 0x01 = 32 color medium resolution picture, |
||
| − | 0x80 = 512 color picture low resolution picture |
||
| − | 0x81 = 4096 color picture low resolution picture |
||
| − | 1 word 0x8001 = compressed |
||
| − | Quantumpaint v2.00 sets it to 0x8000 for uncompressed files |
||
| − | Quantumpaint v1.00 seems to use 0x0000 for lowras and 0x0333 |
||
| − | for medium res bytes. The PBX viewer only tests for 0x8001. |
||
| − | 122 bytes ?? |
||
| − | total 128 header bytes |
||
| − | ?? bytes palette data; |
||
| − | for uncompressed normal pictures 8 pallete datasets follow: |
||
| − | 16 words: 16 palettes |
||
| − | 1 word: number of the first line this pallet is used |
||
| − | 1 word: 0 the palette is not active, else this pallete is active |
||
| − | 1 word: first color of color cycle |
||
| − | 1 word: last color of color cycle |
||
| − | 1 word: cycle speed, number of vbl's between steps, 0 = fastest |
||
| − | 1 word: 0: no cycling, 1 cycle right, 0xffff cycle left |
||
| − | 2 word: ?? should be zero |
||
| − | __ |
||
| − | 48 bytes per palette |
||
| − | The first palette should always be active and start on line 0 |
||
| − | ___ |
||
| − | 384 bytes palette data for low (128 color) and medium (32 color) pictures |
||
| − | for uncompressed 512 color pictures 6400 words (32 colors per scanline) |
||
| − | for uncompressed 4096 color pictures 12800 words (32 colors per scanline, |
||
| − | 2 palette sets for alternating screens, two 6400 word blocks) |
||
| − | ?? bytes screen data, for uncompressed pictures this is 32000 bytes for all modes |
||
| − | -------- |
||
| − | > 128 bytes total |
||
| − | |||
| − | Compression scheme |
||
| − | Palette and screen data are compressed into one block using packbits compression. |
||
| − | The expanded screen data is not simply screen memory bitmap data; instead, the |
||
| − | data is divided into four sets of vertical columns. (This results in |
||
| − | better compression.) A column consists of one specific word taken |
||
| − | from each scan line, going from top to bottom. For example, column 1 |
||
| − | consists of word 1 on scanline 1 followed by word 1 on scanline 2, etc., |
||
| − | followed by word 1 on scanline 200. |
||
| − | The columns appear in the following order: |
||
| − | |||
| − | 1st set contains columns 1, 5, 9, 13, ..., 69, 73, 77 in order |
||
| − | 2nd set contains columns 2, 6, 10, 14, ..., 70, 74, 78 in order |
||
| − | 3rd set contains columns 3, 7, 11, 15, ..., 71, 75, 79 in order |
||
| − | 4th set contains columns 4, 8, 12, 16, ..., 72, 76, 80 in order |
||
| − | This colmn ordering is just the same as in the Tiny format. |
||
| − | for medium res it is the same only with two stes for the two medium res bitplanes. |
||
| − | |||
| − | /* |
||
| − | * Given an x-coordinate and a color index, returns the corresponding |
||
| − | * QuantumPaint palette index. |
||
| − | * |
||
| − | * by Hans Wessels; placed in the public domain januari, 2008. |
||
| − | */ |
||
| − | int find_pbx_index(int x, int c) |
||
| − | { |
||
| − | int x1 = 10 * c; |
||
| − | if (1 & c) |
||
| − | { /* If c is odd */ |
||
| − | x1 = x1 - 5; |
||
| − | } |
||
| − | else |
||
| − | { /* If c is even */ |
||
| − | x1 = x1 + 1; |
||
| − | } |
||
| − | if(c>7) |
||
| − | { |
||
| − | x1+=12; |
||
| − | } |
||
| − | if(x>=(x1+75)) |
||
| − | { |
||
| − | c = c + 16; |
||
| − | } |
||
| − | return c; |
||
| − | } |
||
| − | |||
| − | |||
| − | <Art Director> *.ART (low resolution only) |
||
| − | |||
| − | 16000 words picture data (screen memory) |
||
| − | 16 words palette |
||
| − | 7 * 16 words 7 more palettes for animation |
||
| − | 8 * 1 byte display time for palettes, use first palette with non zero display time |
||
| − | 248 bytes unknown |
||
| − | ------------- |
||
| − | 32512 bytes total |
||
| − | |||
| − | |||
| − | <C.O.L.R. Object Editor Mural> *.MUR (low resolution only) |
||
| − | |||
| − | 16000 words picture data (screen memory) |
||
| − | (palettes are stored in separate files) |
||
| − | ----------- |
||
| − | 32000 bytes total |
||
| − | |||
| − | |||
| − | <Doodle> *.DOO (high resolution only) |
||
| − | |||
| − | 16000 words picture data (screen memory) |
||
| − | ----------- |
||
| − | 32000 bytes total |
||
| − | |||
| − | |||
| − | <Cyber Paint Sequence> *.SEQ (low resolution only) |
||
| − | |||
| − | This format, while fairly complex, yields excellent compression of animated |
||
| − | images while offering reasonably fast decompression times. |
||
| − | |||
| − | 1 word magic number [$FEDB or $FEDC] |
||
| − | 1 word version number |
||
| − | 1 long number of frames |
||
| − | 1 word speed (high byte is vblanks per frame) |
||
| − | 118 bytes reserved |
||
| − | --------- |
||
| − | 128 bytes total for .SEQ header |
||
| − | |||
| − | for each frame { |
||
| − | 1 word type (ignored?) |
||
| − | 1 word resolution [always 0] |
||
| − | 16 words palette |
||
| − | 12 bytes filename [usually " . "] |
||
| − | 1 word color animation limits [not used] |
||
| − | 1 word color animation speed and direction [not used] |
||
| − | 1 word number of color steps [not used] |
||
| − | 1 word x offset for this frame [0 - 319] |
||
| − | 1 word y offset for this frame [0 - 199] |
||
| − | 1 word width of this frame, in pixels (may be 0, see below) |
||
| − | 1 word height of this frame, in pixels (may be 0, see below) |
||
| − | 1 byte operation [0 = copy, 1 = exclusive or] |
||
| − | 1 byte storage method [0 = uncompressed, 1 = compressed] |
||
| − | 1 long length of data in bytes (if the data is compressed, this |
||
| − | will be the size of the compressed data BEFORE decompression) |
||
| − | 60 bytes reserved |
||
| − | -------- |
||
| − | 128 bytes total for frame header |
||
| − | |||
| − | ? bytes data |
||
| − | } |
||
| − | |||
| − | Frames are "delta-compressed," meaning that only the changes from one |
||
| − | frame to the next are stored. On the ST, .SEQ files are always full-screen |
||
| − | low resolution animations, so the sequence resulting from expanding all the |
||
| − | data will be n 320 by 200 pixel low resolution screens, where n is given in |
||
| − | the .SEQ header. |
||
| − | |||
| − | Since only the changes from frame to frame are stored, image data for a |
||
| − | frame will rarely be 320x200 (except for the very first frame, which will |
||
| − | always be a full screen). Instead what is stored is the smallest rectangular |
||
| − | region on the screen that contains all the changes from the previous frame to |
||
| − | the current frame. The x offset and y offset in the frame header determine |
||
| − | where the upper left corner of the "change box" lies, and the width and height |
||
| − | specify the box's size. |
||
| − | |||
| − | Additionally, each "change box" is stored in one of five ways. For each |
||
| − | of these, the screen is assumed to have the full-screen image from the last |
||
| − | frame on it. |
||
| − | |||
| − | o uncompressed copy: The data for this frame is uncompressed image data, |
||
| − | and is simply copied onto the screen at position (x, y) specified |
||
| − | in the frame header. |
||
| − | |||
| − | o uncompressed eor: The data for this frame is exclusive or'ed with the |
||
| − | screen at position (x, y). |
||
| − | |||
| − | o compressed copy: The data for this frame must be decompressed (see |
||
| − | below), and then copied onto the screen at position (x, y) specified |
||
| − | in the frame header. |
||
| − | |||
| − | o compressed eor: The data for this frame must be decompressed (see |
||
| − | below), and then exclusive or'ed with the screen RAM at position (x, y). |
||
| − | |||
| − | o null frame: The width and/or height of this frame is 0, so this |
||
| − | frame is the same as the previous frame. |
||
| − | |||
| − | Of the 5 methods above, the one that results in the smallest amount |
||
| − | of data being stored for a particular is used for that frame. |
||
| − | |||
| − | Compression Scheme: |
||
| − | |||
| − | Compression is similar to that employed by Tiny, but is not quite as |
||
| − | space-efficient. |
||
| − | |||
| − | Control word meanings: |
||
| − | |||
| − | For a given control word, x: |
||
| − | |||
| − | x < 0 Absolute value specifies the number of unique words to |
||
| − | take from the data section (from 1 to 32767). |
||
| − | x > 0 Specifies the number of times to repeat the next word |
||
| − | taken from the data section (from 1 to 32767). |
||
| − | |||
| − | Note that a control word of 0 is possible but meaningless. |
||
| − | |||
| − | Format of expanded data: |
||
| − | |||
| − | The expanded data is not simply screen memory bitmap data; instead the four |
||
| − | bitplanes are separated, and the data within each bitplane is presented |
||
| − | vertically instead of horizontally. (This results in better compression.) |
||
| − | |||
| − | To clarify, data for a full screen would appear in the following order: |
||
| − | |||
| − | bitplane 0, word 0, scanline 0 |
||
| − | bitplane 0, word 0, scanline 1 |
||
| − | ... |
||
| − | bitplane 0, word 0, scanline 199 |
||
| − | bitplane 0, word 1, scanline 0 |
||
| − | bitplane 0, word 1, scanline 1 |
||
| − | ... |
||
| − | bitplane 0, word 1, scanline 199 |
||
| − | ... |
||
| − | bitplane 0, word 79, scanline 199 |
||
| − | bitplane 1, word 0, scanline 0 |
||
| − | ... |
||
| − | bitplane 3, word 79, scanline 199 |
||
| − | |||
| − | Note however, that the data does not usually refer to an entire screen, but |
||
| − | rather to the smaller "change box," whose size is given in the frame header. |
||
| − | |||
| − | |||
| − | <Animatic Film> *.FLM (low resolution only) |
||
| − | |||
| − | 1 word number of frames |
||
| − | 16 words palette |
||
| − | 1 word speed (0 - 99; value is 99 - # vblanks to delay between frames) |
||
| − | 1 word direction (0 = forwards, 1 = backwards) |
||
| − | 1 word end action (what to do after the last frame) |
||
| − | 0 = pause, then repeat from beginning |
||
| − | 1 = immediately repeat from beginning |
||
| − | 2 = reverse (change direction) |
||
| − | 1 word width of film in pixels |
||
| − | 1 word height of film in pixels |
||
| − | 1 word Animatic version number (major) [< 2] |
||
| − | 1 word Animatic version number (minor) |
||
| − | 1 long magic number 27182818 (hex) |
||
| − | 3 longs reserved for expansion (should be all zeros) |
||
| − | -------- |
||
| − | 32 words total for header |
||
| − | |||
| − | ? words image data (words of screen memory) for each frame, in order |
||
| − | |||
| − | |||
| − | <Animaster Sprite Bank> *.ASB (low resolution only) |
||
| − | |||
| − | 1 word number of frames - 1 |
||
| − | 1 word ? |
||
| − | 1 byte maximum width, in pixels |
||
| − | 1 byte maximum height, in pixels |
||
| − | 16 words palette |
||
| − | -------- |
||
| − | 38 bytes total for header |
||
| − | |||
| − | For each frame { |
||
| − | 1 word width of this frame (in pixels) - 1 |
||
| − | 1 word height of this frame (in pixels) - 1 |
||
| − | 1 word ? |
||
| − | ? words image data (words of screen memory) |
||
| − | } |
||
| − | |||
| − | |||
| − | <STOS> *.MBK |
||
| − | |||
| − | 9 words ? |
||
| − | 1 long $19861987 (magic number?) |
||
| − | 1 long offset from this long to header for low resolution |
||
| − | parameter block (if past end of file, no low res frames) |
||
| − | 1 long offset from this long to header for med resolution |
||
| − | parameter block (if past end of file, no med res frames) |
||
| − | 1 long offset from this long to header for high resolution |
||
| − | parameter block (if past end of file, no high res frames) |
||
| − | 1 word number of low resolution frames |
||
| − | 1 word number of medium resolution frames |
||
| − | 1 word number of high resolution frames |
||
| − | |||
| − | For each frame { |
||
| − | 1 long offset to data (probably only used internally by STOS) |
||
| − | 1 byte width in words (multiply by 16 to get width in pixels) |
||
| − | 1 byte height in pixels |
||
| − | 1 byte X hotspot location |
||
| − | 1 byte Y hotspot location |
||
| − | } |
||
| − | |||
| − | (The format implies other stuff could be here.) |
||
| − | |||
| − | 1 long ["PALT" $50414C54] |
||
| − | 16 words palette |
||
| − | |||
| − | ? words of data for each frame, in the order mentioned in the |
||
| − | header. Monoplanar mask data follows image data for each |
||
| − | frame. |
||
| − | ---------- |
||
| − | ? words total |
||
| − | |||
| − | The frames often seem to be in semi-random order, not necessarily in |
||
| − | the order they are to be animated. |
||
| − | |||
| − | |||
| − | <GEM Bit Image> *.IMG |
||
| − | |||
| − | 1 word version number of image file [1] |
||
| − | 1 word length of header in words [usually 8] |
||
| − | 1 word number of color planes [1 for monochrome] |
||
| − | 1 word pattern length in bytes [1-8, usually 2 for screen images] |
||
| − | 1 word pixel width in microns (1/1000 mm, 25400 microns per inch) |
||
| − | 1 word pixel height in microns |
||
| − | 1 word line width in pixels |
||
| − | 1 word number of lines |
||
| − | ------- |
||
| − | ? words header length defined in 2nd word of header |
||
| − | |||
| − | ? bytes data |
||
| − | |||
| − | NOTES: If the image is a color image (planes > 1), the planes are stored |
||
| − | separately starting with plane 0. There is, however, no standard way of |
||
| − | storing the color palette. Some programs may save the palette in separate |
||
| − | files, some may extend the header. For this reason, you should never |
||
| − | assume the header is 8 words long, always get the header length from the |
||
| − | 2nd word of the header. Also, the line width in the 7th word is the number |
||
| − | of pixels in a line. Since the data is encoded in byte-wide packets, the |
||
| − | actual unpacked line width is always a multiple of 8, and may be 1-7 pixels |
||
| − | longer than the length specified in the header. |
||
| − | |||
| − | For each byte x in the data section, |
||
| − | |||
| − | x = 0 Pattern/scanline run. |
||
| − | Read the next byte, n (unsigned). |
||
| − | |||
| − | If n > 0 then: |
||
| − | Read a number of bytes equal to the "pattern |
||
| − | length" word in the header. Repeat this |
||
| − | pattern n times. |
||
| − | |||
| − | If n = 0 then: |
||
| − | Scanline run. Data for the next scanline |
||
| − | is to be used multiple times. Read the |
||
| − | following record: |
||
| − | |||
| − | 1 byte flag byte [$FF] |
||
| − | 1 byte number of times to use |
||
| − | next scanline data |
||
| − | |||
| − | The data for the next scanline follows, |
||
| − | compressed normally. |
||
| − | |||
| − | x = 80 (hex) Uncompressed bit string. The next byte |
||
| − | determines the number of bytes to use |
||
| − | literally. The literal data bytes follow. |
||
| − | |||
| − | otherwise Solid run. The value of x determines |
||
| − | what to draw. The high bit specifies whether |
||
| − | the pixels are set or cleared. A 1 indicates |
||
| − | a byte-run using $FF, a 0 indicates a byte-run |
||
| − | using $00. The low 7 bits, taken as an unsigned |
||
| − | quantity, specify the length of the run in bytes. |
||
| − | |||
| − | |||
| − | <STAD> *.PAC (high resolution only) |
||
| − | |||
| − | 4 bytes "pM86" (vertically packed) or "pM85" (horizontally packed) |
||
| − | 1 byte id byte |
||
| − | 1 byte pack byte (most frequently occurring byte in bitmap) |
||
| − | 1 byte "special" byte |
||
| − | ------- |
||
| − | 7 bytes total for header |
||
| − | |||
| − | ? bytes data |
||
| − | |||
| − | The data is encoded as follows. For each byte x in the data section: |
||
| − | |||
| − | x = id byte Read one more byte, n. Use pack byte |
||
| − | n + 1 times. |
||
| − | x = "special" byte Read two more bytes, d, and n (in order). |
||
| − | Use byte d n + 1 times. |
||
| − | otherwise Use byte x literally. |
||
| − | |||
| − | |||
| − | <Imagic Film/Picture> *.IC1 (low resolution) |
||
| − | *.IC2 (medium resolution) |
||
| − | *.IC3 (high resolution) |
||
| − | |||
| − | 4 bytes "IMDC" |
||
| − | 1 word resolution (0 = low res, 1 = medium res, 2 = high res) |
||
| − | 16 words palette |
||
| − | 1 word date (GEMDOS format) |
||
| − | 1 word time (GEMDOS format) |
||
| − | 8 bytes name of base picture file (for delta compression), or zeroes |
||
| − | 1 word length of data (?) |
||
| − | 1 long registration number |
||
| − | 8 bytes reserved |
||
| − | 1 byte compressed? (0 = no, 1 = yes) |
||
| − | |||
| − | If compressed { |
||
| − | 1 byte delta-compressed? (-1 = no, > -1 = yes) |
||
| − | 1 byte ? |
||
| − | 1 byte escape byte |
||
| − | } |
||
| − | ------- |
||
| − | 65 bytes total for header (68 bytes if compressed) |
||
| − | |||
| − | ? bytes data |
||
| − | |||
| − | Compressed data may be either stand-alone or delta-compressed (relative |
||
| − | to the base picture named in the header). Delta compression involves |
||
| − | storing only how the picture differs from the base picture (i.e., only |
||
| − | portions of the screen that have changed are stored). This is used to |
||
| − | to encode animated sequences efficiently. |
||
| − | |||
| − | Compressed data, stand-alone: |
||
| − | |||
| − | For each byte x in the data section: |
||
| − | |||
| − | x = escape byte Read one more byte, n. (n is unsigned). |
||
| − | |||
| − | If n >= 2, use the next byte n times. |
||
| − | If n = 1, keep reading bytes until a |
||
| − | byte k not equal to 1 is encountered. |
||
| − | Then read the next byte d. |
||
| − | If the number of 1 bytes encountered is o, |
||
| − | use d (256 * o + k) times. I.e., |
||
| − | |||
| − | if (n == 1) { |
||
| − | o = 0; |
||
| − | while (n == 1) { |
||
| − | o++; |
||
| − | n = next byte; |
||
| − | } |
||
| − | |||
| − | k = n; |
||
| − | d = next byte; |
||
| − | |||
| − | Use d (256 * o + k) times. |
||
| − | } |
||
| − | else { |
||
| − | d = next byte; |
||
| − | Use d (n) times. |
||
| − | } |
||
| − | |||
| − | x != escape byte Use x literally. |
||
| − | |||
| − | Compressed data, delta compressed: |
||
| − | |||
| − | For each byte x in the data section: |
||
| − | |||
| − | x = escape byte Read one more byte, n. (n is unsigned). |
||
| − | |||
| − | If n >= 3, use the next byte n times. |
||
| − | If n = 1, do the same as for n = 1 in |
||
| − | stand-alone compression (above). |
||
| − | If n = 2, then set n = next byte. |
||
| − | If n = 0, end of picture. |
||
| − | If n >= 2, take n bytes from base |
||
| − | picture. |
||
| − | If n = 1, do the same as for n = 1 |
||
| − | in stand-alone compression (above), |
||
| − | but take (256 * o + k) bytes from |
||
| − | base picture. |
||
| − | |||
| − | x != escape byte Use x literally. |
||
| − | |||
| − | |||
| − | <IFF Format> *.IFF |
||
| − | |||
| − | 4 bytes "FORM" (FORM chunk ID) |
||
| − | 1 long length of file that follows |
||
| − | 4 bytes "ILBM" (InterLeaved BitMap file ID) |
||
| − | |||
| − | 4 bytes "BMHD" (BitMap HeaDer chunk ID) |
||
| − | 1 long length of chunk [20] |
||
| − | 20 bytes 1 word = image width in pixels |
||
| − | 1 word = image height in lines |
||
| − | 1 word = image x-offset [usually 0] |
||
| − | 1 word = image y-offset [usually 0] |
||
| − | 1 byte = # bitplanes |
||
| − | 1 byte = mask (0=no, 1=impl., 2=transparent, 3=lasso) |
||
| − | 1 byte = compressed [1] or uncompressed [0] |
||
| − | 1 byte = unused [0] |
||
| − | 1 word = transparent color (for mask=2) |
||
| − | 1 byte = x-aspect [5=640x200, 10=320x200/640x400, 20=320x400] |
||
| − | 1 byte = y-aspect [11] |
||
| − | 1 word = page width (usually the same as image width) |
||
| − | 1 word = page height (usually the same as image height) |
||
| − | |||
| − | 4 bytes "CMAP" (ColorMAP chunk ID) |
||
| − | 1 long length of chunk [3*n where n is the # colors] |
||
| − | 3n bytes 3 bytes per RGB color. Each color value is a byte |
||
| − | and the actual color value is left-justified in the |
||
| − | byte such that the most significant bit of the value |
||
| − | is the MSB of the byte. (ie. a color value of 15 ($0F) |
||
| − | is stored as $F0) The bytes are stored in R,G,B order. |
||
| − | |||
| − | 4 bytes "CRNG" (Color RaNGe chunk ID) |
||
| − | 1 long length of chunk [8] |
||
| − | 8 bytes 1 word = reserved [0] |
||
| − | 1 word = animation speed (16384 = 60 steps per second) |
||
| − | 1 word = active [1] or inactive [0] |
||
| − | 1 byte = left/lower color animation limit |
||
| − | 1 byte = right/upper color animation limit |
||
| − | |||
| − | 4 bytes "CAMG" (Commodore AMiGa viewport mode chunk ID) |
||
| − | 1 long length of chunk [4] |
||
| − | 1 long viewport mode bits: |
||
| − | bit 2 = interlaced |
||
| − | bit 7 = half-bright |
||
| − | bit 11 = HAM |
||
| − | bit 15 = high res |
||
| − | |||
| − | 4 bytes "BODY" (BODY chunk ID) |
||
| − | 1 long length of chunk [# bytes of image data that follow] |
||
| − | ? bytes actual image data |
||
| − | |||
| − | NOTES: Some of these chunks may not be present in every IFF file, and may |
||
| − | not be in this order. You should always look for the ID bytes to find a |
||
| − | certain chunk. All chunk IDs are followed by a long value that tells the |
||
| − | size of the chunk (note that "ILBM" is not a chunk ID). This is the number of |
||
| − | bytes that FOLLOW the 4 ID bytes and size longword. The exception to this is |
||
| − | the FORM chunk. The size longword that follows the FORM ID is the size of the |
||
| − | remainder of the file. The FORM chunk must always be the first chunk in an |
||
| − | IFF file. |
||
| − | |||
| − | The R,G,B ranges of AMIGA and ST are different (AMIGA 0...15, ST 0...7), |
||
| − | as is the maximum number of bitplanes (AMIGA: 5, ST: 4). |
||
| − | |||
| − | Format of body data |
||
| − | |||
| − | An expanded picture is simply a bitmap. The packing method is PackBits |
||
| − | (see below), and is identical to MacPaint and DEGAS Elite compressed. |
||
| − | |||
| − | The (decompressed) body data appears in the following order: |
||
| − | |||
| − | line 1 plane 0 ... line 1 plane 1 ... ... line 1 plane m |
||
| − | [line 1 mask (if appropriate)] |
||
| − | line 2 plane 0 ... line 2 plane 1 ... ... line 2 plane m |
||
| − | [line 2 mask (if appropriate)] |
||
| − | ... |
||
| − | line x plane 0 ... line x plane 1 ... ... line x plane m |
||
| − | [line x mask (if appropriate)] |
||
| − | |||
| − | The FORM chunk identifies the type of data: |
||
| − | |||
| − | "ILBM" = interleaved bit map |
||
| − | "8SVX" = 8-bit sample voice |
||
| − | "SMUS" = simple music score |
||
| − | "FTXT" = formatted text (Amiga) |
||
| − | |||
| − | The ST version of DPAINT has a different format in the body data. Within |
||
| − | the BODY chunk there is a VDAT chunk. In every VDAT chunk data is compressed |
||
| − | in columns, like in the Tiny format. Only the compression routine is slightly |
||
| − | different. |
||
| − | 4 bytes 'VDAT' vertical bitplane data |
||
| − | 4 bytes length of cunk |
||
| − | ?? bytes compressed data |
||
| − | |||
| − | Data compression format: |
||
| − | 2 bytes cmd_cnt number of cmd bytes |
||
| − | |||
| − | while(cmd_cnt>0) |
||
| − | 1 byte cmd 0: read two bytes, count |
||
| − | output 2*count literal bytes |
||
| − | 1: read two bytes, count and read 2 bytes, data (1 word) |
||
| − | output data count times |
||
| − | <0: output 2*(128-(cmd&0x7f)) literal bytes |
||
| − | >2: read 2 bytse, data (1 word) |
||
| − | output data (cmd&0x7f) times |
||
| − | |||
| − | |||
| − | <HighresMedium> *.HRM |
||
| − | |||
| − | This format is found in only one demo: "HighResMode" by Paradox. The |
||
| − | pictures are interlaced in medium resolution with 35 colors per line. |
||
| − | The files are packed with Ice. The unpacked format is as follows: |
||
| − | 64000 bytes screen data, 160 bytes per scanline, 400 lines |
||
| − | 28000 bytes palette data, 70 bytes per line |
||
| − | ----- |
||
| − | 96000 bytes |
||
| − | |||
| − | /* |
||
| − | * Given an x-coordinate and a color index, returns the corresponding |
||
| − | * HighResMedium palette index. |
||
| − | * |
||
| − | * by Hans Wessels; placed in the public domain januari, 2008. |
||
| − | */ |
||
| − | int find_hrm_index(int x, int c) |
||
| − | { |
||
| − | x+=80; |
||
| − | if(c==0) |
||
| − | { |
||
| − | return -1+4*(int)((x+0)/80); |
||
| − | } |
||
| − | else if(c==1) |
||
| − | { |
||
| − | return 4*(int)((x-8)/80); |
||
| − | } |
||
| − | else if(c==2) |
||
| − | { |
||
| − | return 1+4*(int)((x-40)/80); |
||
| − | } |
||
| − | return 2+4*(int)((x-48)/80); |
||
| − | } |
||
| − | |||
| − | |||
| − | <Overscan Interlaced> *.PCI |
||
| − | |||
| − | This format is found in only one demo: "Tobias Richter Fullscreen |
||
| − | Slideshow". The pictures are in an interlaced overscan format and |
||
| − | use a separate pallette per scanline (16 colors). The resolution of |
||
| − | the screendata is 352 x 278 pixels, with 176 words per line. |
||
| − | The files are packed with the Ice. The unpacked format is as follows: |
||
| − | 48928 bytes screen data first screen |
||
| − | 48928 bytes screen data second screen |
||
| − | 8896 bytes color data first screen |
||
| − | 8896 bytes color data second screen |
||
| − | ------ |
||
| − | 115648 bytes total |
||
| − | |||
| − | The screen data is stored in 4 seperate bitplane blocks: first all data |
||
| − | of bitplane 0, then all data of bitplane 1, then the data of bitplane 2 |
||
| − | and last the data of bitplane 3. |
||
| − | |||
| − | |||
| − | <Picture Packer> *.PP1 (low resolution) |
||
| − | *.PP2 (medium resolution) |
||
| − | *.PP3 (high resolution) |
||
| − | |||
| − | This is a STOS packed screen without the STOS MBK header in front of the |
||
| − | data. Although the STOS screen format has a flag for the resolution this |
||
| − | flag is set to medium resolution for all *.PP? files. The only correct |
||
| − | resolution info is in the extension. A realy brainded format. |
||
| − | |||
| − | |||
| − | <MacPaint> *.MAC |
||
| − | |||
| − | 1 long version number [0=ignore header, 2=header valid] |
||
| − | 38 * 8 bytes 8x8 brush/fill patterns. Each byte is a pattern row, |
||
| − | and the bytes map the pattern rows top to bottom. The |
||
| − | patterns are stored in the order they appear at the bottom |
||
| − | of the MacPaint screen top to bottom, left to right. |
||
| − | 204 bytes unused |
||
| − | ------------- |
||
| − | 512 bytes total for header |
||
| − | |||
| − | < 51200 bytes compressed bitmap data |
||
| − | ------------- |
||
| − | < 51712 bytes total |
||
| − | |||
| − | NOTE: The version number is actually a flag to MacPaint to indicate if |
||
| − | the brush/fill patterns are present in the file. If the version is 0, |
||
| − | the default patterns are used. Therefore you can simply save a MacPaint |
||
| − | file by writing a blank header (512 $00 bytes), followed by the packed |
||
| − | image data. |
||
| − | |||
| − | Bitmap compression: |
||
| − | |||
| − | The bitmap data is for a 576 pixel by 720 pixel monochrome image. |
||
| − | The packing method is PackBits (see below). There are 72 bytes per |
||
| − | scan line. Each bit represents one pixel; 0 = white, 1 = black. |
||
| − | |||
| − | |||
| − | <RGB Intermediate Format> *.RGB (low resolution only) |
||
| − | |||
| − | This format was invented by Lars Michael to facilitate conversions between |
||
| − | standard ST picture formats and higher resolution formats like GIF and IFF. |
||
| − | It supports 12 bits of color resolution by keeping the red, green and blue |
||
| − | components in separate bit planes. |
||
| − | |||
| − | 1 word resolution (ignored) |
||
| − | 16 word palette (ignored) |
||
| − | 16000 words red plane (screen memory) |
||
| − | 1 word resolution (ignored) |
||
| − | 16 word palette (ignored) |
||
| − | 16000 words green plane (screen memory) |
||
| − | 1 word resolution (ignored) |
||
| − | 16 word palette (ignored) |
||
| − | 16000 words blue plane (screen memory) |
||
| − | ------------ |
||
| − | 96102 bytes total |
||
| − | |||
| − | The format was derived by concatenating three DEGAS .PI1 files together -- |
||
| − | one for each color gun. The RGB value for a pixel is constructed by looking |
||
| − | at the appropriate pixel in the red plane, green plane, and blue plane. The |
||
| − | bitplanes are in standard ST low resolution screen RAM format, but where pixel |
||
| − | values in screen RAM refer to palette entries (0 through 15), pixel values |
||
| − | here correspond to absolute R, G, and B values. The red, green, and blue |
||
| − | components for each pixel range from 0 to 15 (4 bits), yielding a total of |
||
| − | 12 bits of color information per pixel. Not coincidentally, this is exactly |
||
| − | the format of ST palette entries (although on ST's without the extended |
||
| − | palette only the lower 3 bits of each color component are used). |
||
| − | |||
| − | You can view a single bit plane on a standard ST by splitting the .RGB file |
||
| − | into its three DEGAS .PI1 components and setting the palette to successively |
||
| − | brighter shades of gray. |
||
| − | |||
| − | |||
| − | <ComputerEyes Raw Data Format> *.CE1 (low resolution) |
||
| − | *.CE2 (medium resolution) |
||
| − | |||
| − | 1 long [$45594553 or "EYES"] |
||
| − | 1 word resolution [0 = low res, 1 = medium res] |
||
| − | 8 words ? |
||
| − | If resolution = 0 { |
||
| − | 64000 bytes red plane, 320 x 200, 1 pixel per byte |
||
| − | 64000 bytes green plane, 320 x 200, 1 pixel per byte |
||
| − | 64000 bytes blue plane, 320 x 200, 1 pixel per byte |
||
| − | ------------ |
||
| − | 192022 bytes total |
||
| − | } |
||
| − | else If resolution = 1 { |
||
| − | 128000 words 640 x 200, 1 pixel per word |
||
| − | ------------ |
||
| − | 256022 bytes total |
||
| − | } |
||
| − | |||
| − | This is almost two formats in one: |
||
| − | |||
| − | Low resolution: |
||
| − | |||
| − | The planes are arranged vertically, instead of horizontally. |
||
| − | The first byte is the red component of pixel (0,0), the second is |
||
| − | (0,1), |
||
| − | and the third (0,2). The 201st corresponds to (1,0), etc. The 64001st |
||
| − | byte is the green component of (0,0). |
||
| − | Only the low six bits of each byte are used. |
||
| − | |||
| − | Medium resolution: |
||
| − | |||
| − | The picture is arranged vertically, instead of horizontally. |
||
| − | The first word is pixel (0,0), the second is (0,1), and the third |
||
| − | (0,2). The 200th is (1,0) etc. |
||
| − | Each word is divided up into the RGB values for the corresponding |
||
| − | pixel, as follows: |
||
| − | |||
| − | Bit: (MSB) 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 (LSB) |
||
| − | -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- |
||
| − | 0 B4 B3 B2 B1 B0 G4 G3 G2 G1 G0 R4 R3 R2 R1 R0 |
||
| − | |||
| − | Bit 15 is not used. |
||
| − | |||
| − | |||
| − | <FuckPaint> *.PI4, *.PI9 |
||
| − | |||
| − | Fuckpaint was an early Atari Falcon drawing program. The format is |
||
| − | still popular because its simplicity. The PI4 extension is used for |
||
| − | 320x240 pictures, the PI9 for 320x200 pictures. Except for the extension |
||
| − | the two formats are exact the same. |
||
| − | |||
| − | 256 long Palette 256 colors, in Falcon format, R, G, 0, B |
||
| − | 38400 words Picture data, 8 interleaved bitplanes |
||
| − | ----------- |
||
| − | 77824 bytes total |
||
| − | |||
| − | |||
| − | <TruePaint> *.TPI |
||
| − | <PrismPaint> *.PNT |
||
| − | |||
| − | 1 long $504e5400 'PNT ' TruePaint Magic |
||
| − | 1 word $0100 ???? file version |
||
| − | 1 word palette_size Might be there in true color |
||
| − | 1 word x_size |
||
| − | 1 word y_size |
||
| − | 1 word bits_per_pixel |
||
| − | 1 word compression, $0000 uncompressed, $0001 prsimpaint compressed |
||
| − | 1 long picture_data_size = ((x_size+15)&0xffff0)*y_size*bits_per_pixel/8 |
||
| − | (uncompressed) |
||
| − | 108 bytes $0 |
||
| − | --------- |
||
| − | 128 bytes total for header |
||
| − | |||
| − | 3*palette_size words Palette data, RGB, values 0..1000. The colors are in |
||
| − | VDI order |
||
| − | |||
| − | picture_data_size bytes Interleaved bitplanes for bits_per_pixel<16, a 16 bit |
||
| − | word per pixel for 16-bit pictures, RRRRrGGGGGgBBBBBb. |
||
| − | The line length is a multiple of 16 pixels for all bit depths |
||
| − | The prismpaint compressed format uses the packbits compression algorithm. For every |
||
| − | scanline the bitplanes are compressed seperately. The falcon high color resolution |
||
| − | (16 bit) is compressed as if there were 16 bitplanes, which there are not. |
||
| − | |||
| − | |||
| − | <DelmPaint> *.DEL, *.DPH |
||
| − | |||
| − | Delmpaint is a 256 color painting package. It works in 320x200 and 320x240 but |
||
| − | there is no difference in the file type. From a .DEL file you can not tel whether |
||
| − | it is a 320x200 or a 320x240 file. The same is true for a *.DPH file, which is |
||
| − | either a 640x400 or a 640x480 file. The bigger format is always assumed. |
||
| − | |||
| − | *.DEL format: |
||
| − | The *.DEL format contains 3 compressed blocks which are decompressed 32000 bytes. |
||
| − | Those three blocks joined together are the depacked file. |
||
| − | Paked: |
||
| − | 1 long length of 1st packed block |
||
| − | 1 long length of 2nd packed block |
||
| − | ??? bytes 1st packed block, depacked 32000 bytes |
||
| − | ??? bytes 2nd packed block, depacked 32000 bytes |
||
| − | ??? bytes 3rd packed block, depacked 32000 bytes |
||
| − | The blocks are packed with the same algorithm as used in Crackart |
||
| − | |||
| − | Depacked: |
||
| − | 256 longs Palette 256 colors, in Falcon format, R, G, 0, B |
||
| − | 38400 words Picture data, 8 interleaved bitplanes |
||
| − | |||
| − | *.DPH format: |
||
| − | The *.DPH format contains 11 compressed blocks which are decompressed 32000 bytes. |
||
| − | Those three blocks joined together are the depacked file. |
||
| − | Paked: |
||
| − | 10 long length of 11st to 10th packed block |
||
| − | |||
| − | ??? bytes 1st packed block, depacked 32000 bytes |
||
| − | ??? bytes 2nd packed block, depacked 32000 bytes |
||
| − | .... |
||
| − | ??? bytes 1th packed block, depacked 32000 bytes |
||
| − | The blocks are packed with the same algorithm as used in Crackart |
||
| − | |||
| − | Depacked: |
||
| − | 256 longs Palette 256 colors, in Falcon format, R, G, 0, B |
||
| − | 38400 words Picture 1 320x240 data, 8 interleaved bitplanes |
||
| − | 38400 words Picture 2 320x240 data, 8 interleaved bitplanes |
||
| − | 38400 words Picture 3 320x240 data, 8 interleaved bitplanes |
||
| − | 38400 words Picture 4 320x240 data, 8 interleaved bitplanes |
||
| − | Finally you have to join the pictures into one huge 640x480 picture. |
||
| − | Take 320 bytes from picture 1, then 320 from 2, repeat 240 times, do |
||
| − | the same for picture 3 and 4. |
||
| − | |||
| − | |||
| − | <EggPaint> *.TRP |
||
| − | |||
| − | 1 long 'TRUP' file ID |
||
| − | 1 word xres |
||
| − | 1 word yres |
||
| − | xres*yres*2 bytes Falcon true color data, word RRRRRGGGGGGBBBBB |
||
| − | Packed EggPaint pictures are packed with ICE 2.4. |
||
| − | |||
| − | |||
| − | <IndyPaint> *.TRU |
||
| − | |||
| − | 1 long 'Indy' file ID |
||
| − | 1 word xres |
||
| − | 1 word yres |
||
| − | 248 bytes 0 |
||
| − | xres*yres*2 bytes Falcon true color data, word RRRRRGGGGGGBBBBB |
||
| − | |||
| − | |||
| − | <GodPaint> *.GOD |
||
| − | |||
| − | 1 word file ID, 'G4' and $0400 have been seen. The GodPaint |
||
| − | program ignores the ID. |
||
| − | 1 word xres |
||
| − | 1 word yres |
||
| − | xres*yres*2 bytes Falcon true color data, word RRRRRGGGGGGBBBBB |
||
| − | |||
| − | <PixArt> *.PIX |
||
| − | |||
| − | 1 long 'PIXT' file ID |
||
| − | 1 word version, $0001 or $0002 |
||
| − | 1 byte chunky (0) or planar (1) |
||
| − | 1 byte #bitplanes |
||
| − | 1 word xres (always a multiple of 16) |
||
| − | 1 word yres |
||
| − | 1 word unknown |
||
| − | 1 word unknown (version $0002 only) |
||
| − | --------- |
||
| − | 14 or 16 byte toltal headersize |
||
| − | |||
| − | 3*n bytes palette, only for bitdepth 2, 4, 8. |
||
| − | ???? bytes image data, chunky or planar for bit depth 2, 4, 8 |
||
| − | for bit depth 16 alway chunkey, Falcon RGB format |
||
| − | (RRRRRGGGGGGBBBBB) |
||
| − | |||
| − | |||
| − | <Canvas> *.CNV, *.CPT |
||
| − | |||
| − | Canvas is a simple drawing program for the Atari ST. The simplest file |
||
| − | format it uses is .CNV. The format has no infor on the resolution of |
||
| − | the image. The colors are stored in VDI order. |
||
| − | |||
| − | 48 bytes palette, value 0-7 per byte, RGB in VDI order. |
||
| − | 32000 bytes image data |
||
| − | |||
| − | |||
| − | The CPT format is a compressed format: |
||
| − | 16 words palette |
||
| − | 1 word resolution (0=low, 1=med, 2=high resolution) |
||
| − | ??? words compressed data, uncompressed 32000 bytes |
||
| − | |||
| − | Packing algorithm: first all runlength data is transfered. Then the |
||
| − | gaps that haven't been filled with runlengthdata is filled with the |
||
| − | remaining data from file. |
||
| − | Runlength data: |
||
| − | 1 word repeat count |
||
| − | 1 word offset |
||
| − | n words run length data (n=4 low, 2 med, 1 high) |
||
| − | The n words run length data are repeated (repeat count +1) times from |
||
| − | offset bytes from the start of the file. When repeat count $FFFF signifies |
||
| − | the end of the run length data (the offset and run length data still folow |
||
| − | the $FFFF repeat count). |
||
| − | ??? words data to fill the gaps that haven't been filled with run |
||
| − | length data. |
||
| − | |||
| − | |||
| − | <DuneGraph> *.DGU, *.DGC |
||
| − | The *.DGU is a simple uncompressed format: |
||
| − | 3 bytes 'DGU' file ID ($444755) |
||
| − | 1 byte version number (1) |
||
| − | 1 word xres (320) |
||
| − | 1 word yres (200) |
||
| − | 256 long palette, Falcon format, RG0B |
||
| − | 64000 bytes picture data, 320x200, 8 bitplanes (other resolutions have not been seen) |
||
| − | |||
| − | The *.DC1 is a simple compressed format: |
||
| − | 3 bytes 'DGC' file ID ($444743) |
||
| − | 1 byte packing method (0, 1, 2 or 3) |
||
| − | 1 word xres |
||
| − | 1 word yres |
||
| − | 1 word unknown ($00ff) |
||
| − | 256 long palette, Falcon format, RG0B |
||
| − | ??? bytes compressed picture data |
||
| − | Compressed picture data: |
||
| − | Method 0: no compression, 64000 bytes, 320x200, 8 bitplanes |
||
| − | For method 1 to 3 the bit planes are unmixed, so first you get all |
||
| − | data for bit plane 0, then bit plane one etc. |
||
| − | Method 1: simple runlength on byte level |
||
| − | 1 long size of compressed data, including this long |
||
| − | do |
||
| − | 1 byte repeat count |
||
| − | 1 byte data |
||
| − | write (repeat count+1) times data |
||
| − | until you run out of compressed data |
||
| − | Method 2: simple runlength on word level |
||
| − | 1 long size of compressed data, including this long |
||
| − | do |
||
| − | 1 word repeat count |
||
| − | 1 word data |
||
| − | write (repeat count+1) times data |
||
| − | until you run out of compressed data |
||
| − | Method 3: simple runlength on long level |
||
| − | 1 long size of compressed data, including this long |
||
| − | do |
||
| − | 1 word repeat count |
||
| − | 1 long data |
||
| − | write (repeat count+1) times data |
||
| − | until you run out of compressed data |
||
| − | |||
| − | |||
| − | <PackBits Compression Algorithm> |
||
| − | |||
| − | The following packing algorithm originated on the Mac, was adopted by |
||
| − | Electronic Arts/Commodore for use in the IFF standard, and then by Tom |
||
| − | Hudson for use in DEGAS Elite. The algorithm is currently used in |
||
| − | MacPaint, IFF, and DEGAS Elite compressed file formats. Each scan line |
||
| − | is packed separately, and packing never extends beyond a scan line. |
||
| − | |||
| − | For a given control byte 'n': |
||
| − | 0 <= n <= 127 : use the next n + 1 bytes literally (no repetition). |
||
| − | -127 <= n <= -1 : use the next byte -n + 1 times. |
||
| − | n = -128 : no operation, not used. |
||
------------------------------------------------------------------------- |
------------------------------------------------------------------------- |
||
Latest revision as of 21:43, 11 February 2017
ST Picture Formats
------------------
Edited by:
David Baggett, Hans Wessels
5640 Vantage Point Road
Columbia, MD 21044 USA
(301) 596-4779
(Please report errors or additions to H.Wessels@C12H22O11_atari_.org.)
(Please remove the _atari_ part when sending me an e-mail.)
Copyright (C) 1988, 1989, 1990, 1991 by David M. Baggett
Additions 2006-2007 Hans Wessels are public domain.
Additions 2015-2017 Lonny Pursell are public domain.
Non-profit redistribution of this document is permitted, provided
the document is not modified in any way.
Reproduction of this document in whole or in part for commercial
purposes is expressly forbidden without the prior written consent
of David M. Baggett.
The information presented here is not guaranteed to be correct.
The editor and contributors will in no event be liable for direct,
indirect, incidental, or consequential damages resulting from the
use of the information in this document.
This document is the product of many hours of volunteer work by a
large number of people. Please respect this -- do not violate the
distribution policy.
CONTRIBUTORS
Steve Belczyk Phil Blanchfield Jason Blochowiak John Brochu**
David Brooks Daniel Deimert Neil Forsyth Stefan Hoehn
Gerfried Klein G. "Maddog" Knauss Ken MacLeod Shamus McBride
Jim McCabe Lars Michael Darek Mihocka David Mumper
George Nassas Jim Omura George Seto Joe Smith
Greg Wageman Roland Waldi* Gerry Wheeler
Contents
--------
Animaster Sprite Bank file format *.ASB Animatic Film file format *.FLM Art Director file format *.ART Calamus Raster Graphic file format *.CRG Canvas file format *.CNV *.CPT COKE file format *.TG1 ColorBurst file format *.BST C.O.L.R. Object Editor file format *.MUR ComputerEyes Raw Data file format *.CE? ? = 1, 2, 3 CrackArt file format *.CA? ? = 1, 2, 3 Cybermate Delta Animation file format *.DLT Cyber Paint Cell file format *.CEL Cyber Paint Sequence file format *.SEQ Dali file format *.SD? ? = 0, 1, 2 Dali Compressed file format *.?PK ? = L, M, H DEGAS file format *.PI? ? = 1, 2, 3 (4, 5, 6) DEGAS Elite file format *.PI? ? = 1, 2, 3 DEGAS Elite Block file format *.BL? ? = 1, 2, 3 DEGAS Elite Compressed file format *.PC? ? = 1, 2, 3 DEGAS Elite Font file format *.FNT DEGAS Elite Icon file format *.ICN DelmPaint file format *.DEL *.DPH DeskPic file format *.GFB Doodle file format *.DOO DUO file format *.DU? ? = 1, 2, O DuneGraph file format *.DG1 *.DC1 EggPaint file format *.TRP EZ-Art Professional file format *.EZA FuckPaint file format *.PI4 *.PI9 Funny Paint file format *.FUN GDOS Font file format *.FNT GEM Bit Image file format *.IMG GEM Metafile file format *.GEM GFA Artist file format *.ART GFA Raytrace file format *.SA? *.SC? *.SU? ? = L, H GodPaint file format *.GOD HighresMedium file format *.HRM IFF file format *.IFF ImageLab file format *.B&W *.B_W Imagic Film/Picture file format *.IC? ? = 1, 2, 3 IMG Scan file format *.RWL *.RWH *.RAW IndyPaint file format *.TRU InShape file format *.IIM Lexicor Film file format *.FLM MacPaint file format *.MAC MegaPaint file format *.BLD NEOchrome file format *.NEO NEOchrome Animation file format *.ANI Overscan Interlaced file format *.PCI Pablo Paint file format *.PPP *.PA3 PaintPro ST/PlusPaint ST *.PIC PaintShop file format *.PSC *.DA4 Paintworks file format *.CL? *.PG? *.SC? ? = 0, 1, 2 PhotoChrome file format *.PCS Picture Packer file format *.PP? ? = 1, 2, 3 Picworks file format *.CP3 PixArt file format *.PIX PL4 file format *.PL4 Print-Technik Raw Data file format *.HIR Public Painter file format *.CMP QuantumPaint file format *.PBX Rag-D file format *.RAG Rembrandt file format *.TCP RGB Intermediate file format *.RGB Signum! file format *.IMC Spectrum 512 file format *.SPU Spectrum 512 Compressed file format *.SPC Spectrum 512 Enhanced file format *.SPU Spectrum 512 Extended file format *.SPX Spectrum 512 Smooshed file format *.SPS Spooky Sprites file format *.TRE *.TRP STAD file format *.PAC STOS Memory Bank file format *.MBK Synthetic Arts file format *.SRT Tiny file format *.TN? ? = 1, 2, 3, Y, (4, 5, 6) TmS Cranach file format *.ESM TruePaint Animation file format *.TPA TruePaint/Prism Paint file format *.TPI *.PNT Video Master file format *.FLM *.VID *.VSQ Warp9 Font file format *.FNT ZZ_ROUGH file format *.RGH
PackBits Compression Algorithm
Introductory Information
------------------------
word = 2 bytes
long = 4 bytes
palette = Hardware color palette, stored as 16 words. First word is
color register zero (background), last word is color register
15. Each word has the form:
Bit: (MSB) 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 (LSB)
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0 0 0 0 0 R2 R1 R0 0 G2 G1 G0 0 B2 B1 B0
R2 = MSB of red intensity
R0 = LSB of red intensity
G2 = MSB of green intensity
G0 = LSB of green intensity
B2 = MSB of blue intensity
B0 = LSB of blue intensity
Intensity ranges from 0 (color not present) to 7 (highest
intensity).
Example: { red = 7, green = 3, blue = 5 } -> 0735 (hex)
Caveat: It is wise to mask off the upper four bits of each
palette entry, since a few programs store special
information there (most notably Art Studio).
-------------------------------------------------------------------------
* Roland Waldi contributed extensive information on the following formats:
GEM, IMG, Doodle, STAD, Imagic Film/Picture, Art Director, IFF
** John Brochu, ST picture formats guru, provided sage advice and many
corrections to the following formats:
NeoChrome, DEGAS Elite Compressed, Spectrum 512 Compressed,
GEM Bit Image, IFF, MacPaint
Magazine References
- ST Format, issue 31, p123.
Back to Graphics