These tags declares a loss-less image bitmap. It has a small header followed by an optional colormap and the bitmap data. When we have a colormap, the bitmap data is an array of indices in the colormap aligned to 4 bytes on a per row basis.
There are three supported formats:
Format
No.
(bits)Color Format Comments Without
AlphaWith
Alpha3
(8 bits(1))RGB RGBA Uses a colormap with up to 256 entries of 24 or 32 bits colors. 4
(16 bits(1))RGB555 RGB555 There is no alpha available in this format. The data is saved in big endian (it is NOT a U16 like some documentations say it is). The colors looks like this (most significant bit first): 0RRRRRGGGGGBBBBB. You should certainly always use the DefineBitsLossless tag for this format. 5
(32 bits)XRGB ARGB Uses a strange order for the components. Most probably because the alpha was added later and thus inserted in place of the X to keep some backward compatibility with older versions.
(1) the data must be 32 bits aligned (4 bytes) on a per row basis. In 8 bits, you may have to add up to three bytes at the end of each row (4 - width & 3
whenwidth & 3
is not zero.). In 16 bits, you need to add two bytes at the end of each row when the width of the image is odd.
The f_colormap, f_indices and f_bitmap are all compressed with the ZLIB scheme.
WATCH OUT: the f_colormap and f_indices are compressed as one large block.
WARNING: These tags require you to save the swf_tag in long format (i.e. f_tag_and_size & 0x3F == 0x3F even if the size is smaller than 63.)
WARNING: An image cannot always be scaled more than 64×. Trying to enlarge it more may result in a rectangle of one color. The 64× is cumulative. So a sprite of an image × 3 inside another sprite × 10 inside another sprite × 4 results in scaling of 120 and this is likely to break the image. This seems to be true mainly when there is a rotation or skew.