

Loop until we have bytes worth of data (final length calculated from image size.).The compression is a variety of RLE Compression using flags. If an image is compressed, each row of data (but not each bitplane) is compressed individually, including the mask data if present. In PBM files the BODY chunk is simpler as uncompressed it is just a continuous stream of bytes containing image data. one bit per pixel, rounded up to the nearest multiple of 16-bits.) If it is compressed then each line is compressed individually and is always a multiple of 16-bits long when compressed. If the image is uncompressed then each line will be made up of (width + 15) / 16 16-bit values (i.e. The bitplanes appear first from 1 to n, followed by the mask plane. In ILBM files the BODY chunk stores the actual image data as interleaved bitplanes (and optional mask) by row. The BODY chunk is usually the last chunk in a file, and the largest. The size of the screen the image is to be displayed on, in pixels, usually 320×200 Pixel aspect, a ratio width:height used for displaying the image on a variety of different screen resolutions for 320x200 5:6 or 10:11 Transparent colour, useful only when mask >= 2 Ignore when reading, set to 0 when writing for future compatibility Other values are theoretically possible, representing other compression methods. this file is just a colormap.)ġ = masked, 2 = transparent color, 3 = lasso (for MacPaint).

Number of planes in bitmap, 1 for monochrome, 4 for 16 color, 8 for 256 color or 0 if there is only a colormap, and no image data. Value is usually 0,0 unless image is part of a larger image or not fullscreen. Where on screen, in pixels, the image's top-left corner is.
DELUXE PAINT 2 HOW TO
It not only defines the image's height/width, but where it is drawn on the screen, how to display it in various screen resolutions and if the image is compressed. The BMHD chunk specifies how the image is to be displayed and is usually the first chunk inside the FORM. Again refer to Interchange File Format (IFF) for further detail about finding and handling chunks. However there are only a limited number of common chunk types used and understood by most programs, and descriptions of these follow. Optional padding byte, only present if lenChunk is not a multiple of 2. Will be the same as the file size minus eight bytes (this field and chunkID are not included in the count)Īctual data of the chunk, made up of the other sub-chunks below Any chunks appearing after BODY are considered 'extra' and many programs will leave them unread and unchanged. This makes them much more flexible, but also much more complex than other formats such as BMP.įor LBMs the BMHD chunk and any other 'vital' chunks must appear before the BODY chunk. Some files were designed to act as palettes for paint programs (pixel data left blank) or to be merged into another image. LBM files usually contain enough information to allow them to be displayed by an image editing program, including image dimensions, palette and pixel data. Another program does not need to know about this and can just skip the chunk and leave it unchanged, or drop the chunk entirely, although that is not an advisable thing for a tool to do automatically.įor details on the chunk structure and how to read them, see Interchange File Format (IFF). For example a program might use a TIME chunk to store the date and time that a file was last edited.

This means that a program does not have to read or decode every chunk in a file, only the ones it wants to deal with or the ones it can understand. Each chunk has a different function and has the same basic format. In essence LBM files consist of a number of consecutive chunks, whose order can, to some extent, be varied.
