mirror/aseprite
1
0
Fork 0
mirror of https://github.com/aseprite/aseprite.git synced 2025-01-15 19:52:05 +00:00
Code Issues Packages Projects Releases Wiki Activity

Convert Aseprite file format specs into a .md file

Browse Source
This commit is contained in:
David Capello 2016-12-06 16:32:06 -03:00
parent b7f773566e
commit c84a18b2f4
5 changed files with 115 additions and 577 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

235
docs/files/ase.txt → docs/ase-file-specs.md
View File

@ -1,39 +1,37 @@
ASE Files (.ASE) Format description
Copyright (C) 2001-2016 by David Capello
----------------------------------------------------------------------
Aseprite File Format (.ase/.aseprite) Specifications
====================================================
> Copyright (C) 2001-2016 by David Capello
1. [References](#1-references)
2. [Introduction](#2-introduction)
3. [Header](#3-header)
4. [Frames](#4-frames)
5. [Chunk Types](#5-chunk-types)
6. [File Format Changes](#6-file-format-changes)
1. References
2. Introduction
3. Header
4. Frames
5. New chunk types
6. File Format Changes
========================================
1. References
========================================
-------------
ASE files use Intel (little-endian) byte order.
BYTE An 8-bit unsigned integer value
WORD A 16-bit unsigned integer value
SIGNED WORD A 16-bit signed integer value
DWORD A 32-bit unsigned integer value
BYTE[n] "n" bytes.
STRING length=WORD (how many characters to read next)
string=BYTE[length]
The \0 character isn't included.
PIXEL Pixel format:
- In RGB images, each pixel have 4 bytes in
this order Red, Green, Blue, Alpha.
- In Grayscale images, each pixel have 2 bytes
in the order Value, Alpha.
- In Indexed images, each pixel uses 1 byte (the index).
Data Type | Details |
--------------- | -------------------------------- |
BYTE | An 8-bit unsigned integer value
WORD | A 16-bit unsigned integer value
SIGNED WORD | A 16-bit signed integer value
DWORD | A 32-bit unsigned integer value
BYTE[n] | "n" bytes.
STRING | WORD: string length (number of bytes)
| BYTE[length]: characters (in UTF-8)
| The \0 character is not included.
PIXEL | One pixel, depending on the image pixel format:
| **RGB**: Each pixel have 4 bytes in this order Red, Green, Blue, Alpha.
| **Grayscale**: Each pixel have 2 bytes in the order Value, Alpha.
| **Indexed**: Each pixel uses 1 byte (the index).
========================================
2. Introduction
========================================
---------------
The format is much like FLI/FLC files, but with different magic number
and differents chunks. Also, the color depth can be 8, 16 or 32 for
@ -43,78 +41,71 @@ type=11 or type=4). For color depths more than 8bpp, palettes are
optional. See fli.txt for details.
To read the sprite:
* Read the ASE header (section 3)
* For each frame do (how many frames? the ASE header has that
information):
+ Read the frame header (section 4)
+ For each chunk in this frame (how many chunks? the frame header
has that information)
- Read the chunk (it should be layer information, a cel or a
palette)
* Read the [ASE header](#3-header)
* For each frame do (how many frames? the ASE header has that information):
+ Read the [frame header](#4-frames)
+ For each chunk in this frame (how many chunks? the frame header has that information)
- Read the chunk (it should be layer information, a cel or a palette)
========================================
3. Header
========================================
---------
A 128-byte header (same as FLC/FLI header, but with other magic
number):
A 128-byte header (same as FLC/FLI header, but with other magic number):
DWORD File size
WORD Magic number (0xA5E0)
WORD Frames
WORD Width in pixels
WORD Height in pixels
WORD Color depth (bits per pixel)
32 bpp = RGBA
16 bpp = Grayscale
8 bpp = Indexed
DWORD Flags:
1 = Layer opacity has valid value
WORD Speed (milliseconds between frame, like in FLC files)
DEPRECATED: You should use the frame duration
field from each frame header
DWORD Set be 0
DWORD Set be 0
BYTE Palette entry (index) which represent transparent
color in all non-background layers (only for Indexed
sprites).
BYTE[3] Ignore these bytes
WORD Number of colors (0 means 256 for old sprites)
BYTE[94] For future (set to zero)
Field | Details |
------------- | -------------------------------- |
DWORD | File size
WORD | Magic number (0xA5E0)
WORD | Frames
WORD | Width in pixels
WORD | Height in pixels
WORD | Color depth (bits per pixel)
| 32 bpp = RGBA
| 16 bpp = Grayscale
| 8 bpp = Indexed
DWORD | Flags:
| 1 = Layer opacity has valid value
WORD | Speed (milliseconds between frame, like in FLC files) **DEPRECATED:** You should use the frame duration field from each frame header
DWORD | Set be 0
DWORD | Set be 0
BYTE | Palette entry (index) which represent transparent color in all non-background layers (only for Indexed sprites).
BYTE[3] | Ignore these bytes
WORD | Number of colors (0 means 256 for old sprites)
BYTE[94] | For future (set to zero)
========================================
4. Frames
========================================
---------
After the header come the "frames" data. Each frame has this little
header of 16 bytes:
DWORD Bytes in this frame
WORD Magic number (always 0xF1FA)
WORD Number of "chunks" in this frame
WORD Frame duration (in milliseconds)
BYTE[6] For future (set to zero)
Field | Details |
----------- | -------------------------------- |
DWORD | Bytes in this frame
WORD | Magic number (always 0xF1FA)
WORD | Number of "chunks" in this frame
WORD | Frame duration (in milliseconds)
BYTE[6] | For future (set to zero)
Then each chunk format is:
DWORD Chunk size
WORD Chunk type
BYTE[] Chunk data
Field | Details |
----------- | -------------------------------- |
DWORD | Chunk size
WORD | Chunk type
BYTE[] | Chunk data
5. Chunk Types
--------------
========================================
5. Chunk types
========================================
Old palette chunk (0x0004)
----------------------------------------
### Old palette chunk (0x0004)
Ignore this chunk if you find the new palette chunk (0x2019) Aseprite
v1.1 saves both chunks 0x0004 and 0x2019 just for backward
compatibility.
```
WORD Number of packets
+ For each packet
BYTE Number of palette entries to skip from the last packet (start from 0)
@ -123,13 +114,13 @@ compatibility.
BYTE Red (0-255)
BYTE Green (0-255)
BYTE Blue (0-255)
```
Old palette chunk (0x0011)
----------------------------------------
### Old palette chunk (0x0011)
Ignore this chunk if you find the new palette chunk (0x2019)
```
WORD Number of packets
+ For each packet
BYTE Number of palette entries to skip from the last packet (start from 0)
@ -138,14 +129,14 @@ Ignore this chunk if you find the new palette chunk (0x2019)
BYTE Red (0-63)
BYTE Green (0-63)
BYTE Blue (0-63)
```
Layer Chunk (0x2004)
----------------------------------------
### Layer Chunk (0x2004)
In the first frame should be a set of layer chunks to determine the
entire layers layout:
```
WORD Flags:
1 = Visible
2 = Editable
@ -177,14 +168,14 @@ Layer Chunk (0x2004)
Note: valid only if file header flags field has bit 1 set
BYTE[3] For future (set to zero)
STRING Layer name
```
Cel Chunk (0x2005)
----------------------------------------
### Cel Chunk (0x2005)
This chunk determine where to put a cel in the specified
layer/frame.
```
WORD Layer index (see NOTE.2)
SIGNED WORD X position
SIGNED WORD Y position
@ -210,11 +201,11 @@ Cel Chunk (0x2005)
BYTE[] Compressed "Raw Cel" data. Details about the
compression method:
http://www.ietf.org/rfc/rfc1951.txt
```
### Mask Chunk (0x2016) DEPRECATED
Mask Chunk (0x2016) DEPRECATED
----------------------------------------
```
SIGNED WORD X position
SIGNED WORD Y position
WORD Width
@ -224,17 +215,17 @@ Mask Chunk (0x2016) DEPRECATED
BYTE[] Bit map data (size = height*((width+7)/8))
Each byte contains 8 pixels (the leftmost pixels are
packed into the high order bits)
```
Path Chunk (0x2017)
----------------------------------------
### Path Chunk (0x2017)
Never used.
Frame Tags Chunk (0x2018)
----------------------------------------
### Frame Tags Chunk (0x2018)
```
WORD Number of tags
BYTE[8] For future (set to zero)
+ For each tag
@ -248,11 +239,11 @@ Frame Tags Chunk (0x2018)
BYTE[3] RGB values of the tag color
BYTE Extra byte (zero)
STRING Tag name
```
### Palette Chunk (0x2019)
Palette Chunk (0x2019)
----------------------------------------
```
DWORD New palette size (total number of entries)
DWORD First color index to change
DWORD Last color index to change
@ -266,15 +257,15 @@ Palette Chunk (0x2019)
BYTE Alpha (0-255)
+ If has name bit in entry flags
STRING Color name
```
User Data Chunk (0x2020)
----------------------------------------
### User Data Chunk (0x2020)
Insert this user data in the last read chunk. E.g. If we've read a
layer, this user data belongs to that layer, if we've read a cel, it
belongs to that cel, etc.
```
DWORD Flags
1 = Has text
2 = Has color
@ -285,14 +276,16 @@ belongs to that cel, etc.
BYTE Color Green (0-255)
BYTE Color Blue (0-255)
BYTE Color Alpha (0-255)
```
### Notes
Notes
----------------------------------------
#### NOTE.1
NOTE.1: The child level is used to show the relationship of this
layer with the last one read, for example:
The child level is used to show the relationship of this layer with
the last one read, for example:
```
Layer name and hierarchy Child Level
-----------------------------------------------
- Background 0
@ -301,11 +294,14 @@ NOTE.1: The child level is used to show the relationship of this
|- My set1 1
| `- Layer2 2
`- Layer3 1
```
#### NOTE.2
NOTE.2: The layer index is a number to identify any layer in the
sprite, for example:
The layer index is a number to identify any layer in the sprite, for
example:
```
Layer name and hierarchy Layer index
-----------------------------------------------
- Background 0
@ -314,18 +310,17 @@ NOTE.2: The layer index is a number to identify any layer in the
|- My set1 3
| `- Layer2 4
`- Layer3 5
```
6. File Format Changes
----------------------
========================================
File Format Changes
========================================
1. The first change from the first release of the new .ase format,
is the new frame duration field. This is because now each frame
can have different duration.
1) The first change from the first release of the new .ase format,
is the new frame duration field. This is because now each frame
can have different duration.
How to read both formats (old and new one)? You should set all
frames durations to the "speed" field read from the main ASE
header. Then, if you found a frame with the frame-duration
field > 0, you should update the duration of the frame with
that value.
How to read both formats (old and new one)? You should set all
frames durations to the "speed" field read from the main ASE
header. Then, if you found a frame with the frame-duration
field > 0, you should update the duration of the frame with
that value.

243
docs/files/fli.txt
View File

@ -1,243 +0,0 @@
Flic Files (.FLI) Format description:
The details of a FLI file are moderately complex, but the
idea behind it is simple: don't bother storing the parts of a
frame that are the same as the last frame. Not only does this
save space, but it's very quick. It's faster to leave a pixel
alone than to set it.
A FLI file has a 128-byte header followed by a sequence of
frames. The first frame is compressed using a bytewise run-length
compression scheme. Subsequent frames are stored as the
difference from the previous frame. (Occasionally the first
frame and/or subsequent frames are uncompressed.) There is one
extra frame at the end of a FLI which contains the difference
between the last frame and the first frame.
The FLI header:
byte size name meaning
offset
0 4 size Length of file, for programs that want
to read the FLI all at once if possible.
4 2 magic Set to hex AF11. Please use another
value here if you change format (even to
a different resolution) so Autodesk
Animator won't crash trying to read it.
6 2 frames Number of frames in FLI. FLI files have
a maxium length of 4000 frames.
8 2 width Screen width (320).
10 2 height Screen height (200).
12 2 depth Depth of a pixel (8).
14 4 flags Must be 0.
18 2 speed Number of video ticks between frames.
20 4 next Set to 0.
24 4 frit Set to 0.
28 100 expand All zeroes -- for future enhancement.
Next are the frames, each of which has a header:
byte size name meaning
offset
0 4 size Bytes in this frame. Autodesk Animator
demands that this be less than 64K.
4 2 magic Always hexadecimal F1FA
6 2 chunks Number of 'chunks' in frame.
8 8 expand Space for future enhancements. All
zeros.
After the frame header come the chunks that make up the
frame. First comes a color chunk if the color map has changed
from the last frame. Then comes a pixel chunk if the pixels have
changed. If the frame is absolutely identical to the last frame
there will be no chunks at all.
A chunk itself has a header, followed by the data. The
chunk header is:
byte size name meaning
offset
0 4 size Bytes in this chunk.
4 2 type Type of chunk (see below).
There are currently five types of chunks you'll see in a FLI
file.
number name meaning
11 FLI_COLOR Compressed color map
12 FLI_LC Line compressed -- the most common type
of compression for any but the first
frame. Describes the pixel difference
from the previous frame.
13 FLI_BLACK Set whole screen to color 0 (only occurs
on the first frame).
15 FLI_BRUN Bytewise run-length compression -- first
frame only
16 FLI_COPY Indicates uncompressed 64000 bytes soon
to follow. For those times when
compression just doesn't work!
The compression schemes are all byte-oriented. If the
compressed data ends up being an odd length a single pad byte is
inserted so that the FLI_COPY's always start at an even address
for faster DMA.
FLI_COLOR Chunks
The first word is the number of packets in this chunk. This
is followed directly by the packets. The first byte of a packet
says how many colors to skip. The next byte says how many colors
to change. If this byte is zero it is interpreted to mean 256.
Next follows 3 bytes for each color to change (one each for red,
green and blue).
FLI_LC Chunks
This is the most common, and alas, most complex chunk. The
first word (16 bits) is the number of lines starting from the top
of the screen that are the same as the previous frame. (For
example, if there is motion only on the bottom line of screen
you'd have a 199 here.) The next word is the number of lines
that do change. Next there is the data for the changing lines
themselves. Each line is compressed individually; among other
things this makes it much easier to play back the FLI at a
reduced size.
The first byte of a compressed line is the number of packets
in this line. If the line is unchanged from the last frame this
is zero. The format of an individual packet is:
skip_count
size_count
data
The skip count is a single byte. If more than 255 pixels
are to be skipped it must be broken into 2 packets. The size
count is also a byte. If it is positive, that many bytes of data
follow and are to be copied to the screen. If it's negative a
single byte follows, and is repeated -size_count times.
In the worst case a FLI_LC frame can be about 70K. If it
comes out to be 60000 bytes or more Autodesk Animator decides
compression isn't worthwhile and saves the frame as FLI_COPY.
FLI_BLACK Chunks
These are very simple. There is no data associated with
them at all. In fact they are only generated for the first frame
in Autodesk Animator after the user selects NEW under the FLIC
menu.
FLI_BRUN Chunks
These are much like FLI_LC chunks without the skips. They
start immediately with the data for the first line, and go line-
by-line from there. The first byte contains the number of
packets in that line. The format for a packet is:
size_count
data
If size_count is positive the data consists of a single byte
which is repeated size_count times. If size_count is negative
there are -size_count bytes of data which are copied to the
screen. In Autodesk Animator if the "compressed" data shows signs
of exceeding 60000 bytes the frame is stored as FLI_COPY instead.
FLI_COPY Chunks
These are 64000 bytes of data for direct reading onto the
screen.
-----------------------------------------------------------------------
And here's the PRO extensions:
-----------------------------------------------------------------------
This is supplemental info on the AutoDesk Animator FLI and FLC formats.
The following is an attempt at describing the newer chunks and frames
that are not described in the Turbo C FLI library documentation.
Chunk type Chunk ID
---------- -----------
FLI_DELTA 7 (decimal)
First WORD (16 bits) is the number of compressed lines to follow. Next
is the data for the changing lines themselves, always starting with the
first line. Each line is compressed individually.
The first WORD (16 bits) of a compressed line is the number of packets in
the line. If the number of packets is a negative skip -packets lines.
If the number of packets is positive, decode the packets. The format of
an individual packet is:
skip_count
size_count
data
The skip count is a single byte. If more than 255 pixels are to be
skipped, it must be broken into 2 packets. The size_count is also a byte.
If it is positive, that many WORDS of data follow and are to be copied to
the screen. If it is negative, a single WORDS value follows, and is to be
repeated -size_count times.
Chunk type Chunk ID
---------- -----------
FLI_256_COLOR 4 (decimal)
The first WORD is the number of packets in this chunk. This is followed
directly by the packets. The first byte of a packet is how many colors
to skip. The next byte is how many colors to change. If this number is
0, (zero), it means 256. Next follow 3 bytes for each color to change.
(One each for red, green and blue).
The only difference between a FLI_256_COLOR chunk (type 4 decimal) and a
FLI_COLOR chunk (type 11 decimal) is that the values in the type 4 chunk
range from 0 to 255, and the values in a type 11 chunk range from 0 to 63.
NOTE: WORD refer to a 16 bit int in INTEL (Little Endian) format.
WORDS refer to two-bytes (16 bits) of consecutive data. (Big Endian)
.FLC special frames and chunks
FLC's may contain all the above chunks plus one other:
Chunk type Chunk ID
---------- -----------
FLI_MINI 18 (decimal) 12 (Hex)
From what I understand, this is a miniture 64 x 32 version of the first
frame in FLI_BRUN format, used as an button for selecting flc's from
within Animator Pro. Simply do nothing with this chunk.
FLC New Frame
FLC's also contains a frame with the magic bytes set to hex 00A1. This
is the first frame in the .flc file. Actually it isn't a frame at all
but to have several chunks within it that specify file location info
specific to Animator Pro. IE: filepath, font to use, and .COL file info.
This FRAME may be skipped while loading. That's right! Ignore it! The
frame header is the same length as all other frames. So you may read the
frame header, then skip past the rest of the frame.
NOTE: When reading the FLI header on the newer FLI and FLC files, the
FLI signature bytes are AF12 instead of AF11 used in the older FLI files.
Also, you cannot ignore the screen width and height they may not be
320 x 200.
Allowable screen sizes include:
320 x 200, 640 x 480, 800 x 600, 1280 x 1024
NOTE: the delay value between frames appears to be in 1000th's of a
second instead of 70th's.
If you have any questions or more info on the FLI or FLC formats,
please let me know.
Mike Haaland
(corrected by P. Oliver 30 May 1997 using information supplied by Reeves Hall)
CompuServe : 72300,1433
Delphi : MikeHaaland
Internet : mike@htsmm1.las-vegas.nv.us
Usenet : ...!htsmm1.las-vegas.nv.us!mike

51
docs/files/msk.txt
View File

@ -1,51 +0,0 @@
MSK Format
Intel byte order
Information from File Format List 2.0 by Max Maischein.
--------!-CONTACT_INFO----------------------
If you notice any mistakes or omissions, please let me know! It is only
with YOUR help that the list can continue to grow. Please send
all changes to me rather than distributing a modified version of the list.
This file has been authored in the style of the INTERxxy.* file list
by Ralf Brown, and uses almost the same format.
Please read the file FILEFMTS.1ST before asking me any questions. You may find
that they have already been addressed.
Max Maischein
Max Maischein, 2:244/1106.17
Max_Maischein@spam.fido.de
corion@informatik.uni-frankfurt.de
Corion on #coders@IRC
--------!-DISCLAIMER------------------------
DISCLAIMER: THIS MATERIAL IS PROVIDED "AS IS". I verify the information
contained in this list to the best of my ability, but I cannot be held
responsible for any problems caused by use or misuse of the information,
especially for those file formats foreign to the PC, like AMIGA or SUN file
formats. If an information it is marked "guesswork" or undocumented, you
should check it carefully to make sure your program will not break with
an unexpected value (and please let me know whether or not it works
the same way).
Information marked with "???" is known to be incomplete or guesswork.
Some file formats were not released by their creators, others are regarded
as proprietary, which means that if your programs deal with them, you might
be looking for trouble. I don't care about this.
--------------------------------------------
The MSK files are mask files used by the Autodesk Animator and Animator Pro
packages. Two types of MSK files exist. The Animator Pro version is simply a PIC
file with the depth 1; A MSK file created by the original Animator is exactly
8000 bytes long. There is no file header or other control information in the
file. It contains the image bit map, 1 bit per pixel, with the leftmost pixels
packed into the high order bits of each byte. The size of the image is fixed at
320x200. The image is stored left-to-right, top-to-bottom.
EXTENSION:MSK
OCCURENCES:PC
PROGRAMS:Autodesk Animator
SEE ALSO:PIC,FLIc

71
docs/files/pic.txt
View File

@ -1,71 +0,0 @@
PIC Format
Intel byte order
Information from File Format List 2.0 by Max Maischein.
--------!-CONTACT_INFO----------------------
If you notice any mistakes or omissions, please let me know! It is only
with YOUR help that the list can continue to grow. Please send
all changes to me rather than distributing a modified version of the list.
This file has been authored in the style of the INTERxxy.* file list
by Ralf Brown, and uses almost the same format.
Please read the file FILEFMTS.1ST before asking me any questions. You may find
that they have already been addressed.
Max Maischein
Max Maischein, 2:244/1106.17
Max_Maischein@spam.fido.de
corion@informatik.uni-frankfurt.de
Corion on #coders@IRC
--------!-DISCLAIMER------------------------
DISCLAIMER: THIS MATERIAL IS PROVIDED "AS IS". I verify the information
contained in this list to the best of my ability, but I cannot be held
responsible for any problems caused by use or misuse of the information,
especially for those file formats foreign to the PC, like AMIGA or SUN file
formats. If an information it is marked "guesswork" or undocumented, you
should check it carefully to make sure your program will not break with
an unexpected value (and please let me know whether or not it works
the same way).
Information marked with "???" is known to be incomplete or guesswork.
Some file formats were not released by their creators, others are regarded
as proprietary, which means that if your programs deal with them, you might
be looking for trouble. I don't care about this.
--------------------------------------------
PIC files contain images in an uncompressed format. Both the original Animator
and Animator Pro from Autodesk produce PIC files. The file formats are
different; Animator Pro produces a hierarchial block oriented file, while the
original Animator file is a simpler fixed format. See PIC(Pro) for further
information on the Animator Pro PIC format.
The original Animator uses this format to store a single-frame picture image.
This format description applies to both PIC and original Animator CEL files. The
file begins with a 32 byte header, as follows:
OFFSET Count TYPE Description
0000h 1 word ID=9119h
0002h 1 word Width of image; PIC files have always a width
of 320, CEL images may have any value.
0004h 1 word Height of image, 200 for a PIC, any value for
a CEL file.
0006h 1 word X offset of image, always 0 for a PIC image,
may be nonzero in a CEL image.
0008h 1 word Y offset of image. Zero for a PIC file.
000Ah 1 byte Bits per pixel (8)
000Bh 1 byte Compresion flag, always zero
000Ch 1 dword Size of the image data in bytes
0010h 16 byte reserved(0)
Immediately following the header is the color map. It contains all 256 palette
entries in rgb order. Each of the r, g, and b components is a single byte in the
range of 0-63. Following the color palette is the image data, one byte per
pixel, from left to right, top to bottom.
EXTENSION:PIC,CEL
OCCURENCES:PC
PROGRAMS:Autodesk Animator
SEE ALSO:CEL,FLIc,PIC(PRO)

92
docs/files/picpro.txt
View File

@ -1,92 +0,0 @@
PIC(PRO) Format
Intel byte order
Information from File Format List 2.0 by Max Maischein.
--------!-CONTACT_INFO----------------------
If you notice any mistakes or omissions, please let me know! It is only
with YOUR help that the list can continue to grow. Please send
all changes to me rather than distributing a modified version of the list.
This file has been authored in the style of the INTERxxy.* file list
by Ralf Brown, and uses almost the same format.
Please read the file FILEFMTS.1ST before asking me any questions. You may find
that they have already been addressed.
Max Maischein
Max Maischein, 2:244/1106.17
Max_Maischein@spam.fido.de
corion@informatik.uni-frankfurt.de
Corion on #coders@IRC
--------!-DISCLAIMER------------------------
DISCLAIMER: THIS MATERIAL IS PROVIDED "AS IS". I verify the information
contained in this list to the best of my ability, but I cannot be held
responsible for any problems caused by use or misuse of the information,
especially for those file formats foreign to the PC, like AMIGA or SUN file
formats. If an information it is marked "guesswork" or undocumented, you
should check it carefully to make sure your program will not break with
an unexpected value (and please let me know whether or not it works
the same way).
Information marked with "???" is known to be incomplete or guesswork.
Some file formats were not released by their creators, others are regarded
as proprietary, which means that if your programs deal with them, you might
be looking for trouble. I don't care about this.
--------------------------------------------
This format description applies to both PIC and MSK files created with the
Autodesk Animator Pro package. The file begins with a 64-byte header defined
as follows:
Offset Length Name Description
0000h 1 dword The size of the whole file including the size
of this header.
0004h 1 word ID=9500h
0006h 1 word Width of the image
0008h 1 word Height of the image
000Ah 1 word X offset of image
000Ch 1 word Y offset of image
000Eh 1 dword User ID, set to zero
0012h 1 byte Bits per pixel (8 for PIC, 1 for MSK)
0013h 45 byte reserved (0)
Following the file header are the data blocks for the image. Each data block
within a PIC or MSK file is formatted as follows:
OFFSET Count TYPE Description
0000h 1 dword The size of the block, including this header.
0004h 1 word Data type ID :
0 - Color palette info
1 - Byte-per-pixel image data
2 - Bit-per-pixel mask data
0006h ? byte Data
The type values in the block headers indicate what type of graphics data the
block contains.
In a PIC_CMAP block, the first 2-byte word is a version code;
currently this is set to zero. Following the version word are all 256 palette
entries in rgb order. Each of the r, g, and b components is a single byte in the
range of 0-255. This type of block appears in PIC files; there will generally be
no color map block in a MSK file.
In a PIC_BYTEPIXELS block, the image data appears immediately following the
6-byte block header. The data is stored as one byte per pixel, in left-to-right,
topD to-bottom sequence.
In a PIC_BITPIXELS block, the bitmap data appears immediately following the
6-byte block header. The data is stored as bits packed into bytes such that the
leftmost bits appear in the high-order positions of each byte. The bits are
stored in left-to-right, top-to bottom sequence. When the width of the bitmap is
not a multiple of 8, there will be unused bits in the low order positions of the
last byte on each line. The number of bytes per line is ((width+7)/8). This type
of block appears in MSK files.
EXTENSION:PIC,MSK
OCCURENCES:PC
PROGRAMS:Autodesk Animator Pro
REFERENCE:
SEE ALSO:PIC,FLT