Misplaced Pages

#569430

29-603: A characteristic feature of the format is that it stores bitmaps in the form of interleaved bit planes , which gives the format its name; this reflects the way the Amiga graphics hardware natively reads graphics data from memory. Packbits , a simple form of compression is supported to make ILBM files more compact. On the Amiga, these files are not associated with a particular file extension , though as they started being used on PC systems where extensions are systematically used, they employed

58-836: A .lbm or occasionally a .pbm extension. ILBM is an implementation of the IFF file format consisting of a number of consecutive chunks, whose order can, to some extent, be varied. Each chunk has a different function and has the same basic format. 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. ILBM files usually contain enough information to allow them to be displayed by an image editing program, including image dimensions, palette and pixel data. Some files were designed to act as palettes for paint programs (pixel data left blank) or to be merged into another image. This makes them much more flexible, but also much more complex than other formats such as BMP. For ILBMs

87-414: A LONG "viewport mode". This lets you specify Amiga display modes like "dual playfield" and "hold and modify". It is, not surprisingly, rare outside of Amiga games. If you need to convert or display files that might contain meaningful CAMG chunks, see the 'Notes on working with ILBM files' below. The CMAP chunk contains the image's palette and consists of 3-byte RGB values for each colour used. Each byte

116-506: A colour map and no image data. Often used to store a palette of colours that can be applied to an image separately. In this case the BODY chunk should be empty and the numPlanes field in the BMHD chunk will be 0. Some ILBM files contain 'true-colour' information rather than indexed colours. These so-called 'deep images' files have no CMAP chunk and usually have 24 or 32 bitplanes. The standard ordering for

145-472: Is a variety of RLE Compression using flags. It can be decoded as follows: For the compression routine, it's best to encode a 2 byte repeat run as a replicate run except when preceded and followed by a literal run, in which case it is best to merge the three into one literal run. Always encode >3 byte repeats as replicate runs. A CAMG chunk is specifically for the Commodore Amiga computer. It stores

174-407: Is a way to control how to scatter zero or more source bitplanes into a deeper destination image. Some readers may ignore DEST. The low order depth number of bits in planePick, planeOnOff, and planeMask correspond one-to-one with destination bitplanes. Bit 0 with bitplane 0, etc. Any higher order bits should be ignored. "1" bits in planePick mean "put the next source bitplane into this bitplane", so

203-406: Is always 0) are control flags which indicate how to use the first 4 (or 6) bitplanes. If the first pixel of a scanline is a modification pixel, then modify and use the image border colour. Note that when using 4 bits to modify a colour component you should use the 4 bits in the upper 4 bits of the component AND in the lower 4 bits (to avoid reducing the overall colour gamut). When using 6 bits this

232-460: Is because the images were edited in DeluxePaint, then imported directly into the game's files. Bit plane A bit plane of a digital discrete signal (such as image or sound) is a set of bits corresponding to a given bit position in each of the binary numbers representing the signal. For example, for 16-bit data representation there are 16 bit planes: the first bit plane contains

261-399: Is between 0 and 255 inclusive. The chunk is 3 × numColours bytes long. The number of colours in the palette will be 2 ^ numBitplanes . This chunk is optional and a default palette will be used if it is not present. It is possible to have fewer entries than expected (e.g. 7 colours for a 4-plane '16 colour' bitmap for example.) Remember that if this has an odd number of colours, as per

290-485: Is handled depends on the program using the image. The only data stored here is the sprite order, used by many programs to place the sprite in the foreground (a sprite of order 1 appears behind one of order 0, etc.) It is optional. The TINY chunk contains a small preview image for various graphics programs, including Deluxe Paint. It is compressed and is similar in format to the BODY chunk. Sometimes an ILBM file contains only

319-571: Is less important, but you can still put the 2 most significant bits of the modification bits into the least significant two bits of the colour component. PBM images cannot exist in hold and modify mode. Most utilities that work with ILBM and PBM files are rather dated, such as MacPaint or Deluxe Paint . IrfanView allows viewing files, is free for non commercial use, and can work under Linux. Netpbm can convert images from ILBM to its own PPM format and back. The Deluxe Paint-inspired GrafX2 pixel art graphics editor can load and save ILBM files, but

SECTION 10

#1733084899570

348-515: Is limited to 256 colors maximum, so HAM or 24-bit ILBM images will not show all colors. ImageMagick and GraphicsMagick can also display and convert ILBM images if the ilbmtoppm and ppmtoilbm utilities from Netpbm are installed. In the Commander Keen Dreams series of games, compressed standalone ILBM images are used for title screens, but the game does not read most of the ILBM chunks. This

377-502: Is more critical to preserve the more significant ones. As illustrated in the image above, the early bitplanes, particularly the first, may have constant runs of bits, and thus can be efficiently encoded by run-length encoding . This is done (in the transform domain) in the Progressive Graphics File image format, for instance. Some computers displayed graphics in bit-plane format , most notably PC with EGA graphics card,

406-400: Is set to 1, it contributes a value of 2 , otherwise it contributes nothing. Therefore, bit planes can contribute half of the value of the previous bit plane. For example, in the 8-bit value 10110101 (181 in decimal) the bit planes work as follows: Bit plane is sometimes used as synonymous to Bitmap ; however, technically the former refers to the location of the data in memory and the latter to

435-494: Is set; use the lower 5 bits as an index into the colour map, but the actual colour to be used should be half as bright, which can be achieved by shifted the RGB components of the colour one bit to the right. Alternatively, create a colour map with 64 entries, and copy the lower 32 entries into the upper half, converting them to half brightness; then use all 6 bitplanes as a colour index. PBM images cannot exist in extra half-brite mode. If

464-426: The Amiga and Atari ST , contrasting with the more common packed format . This allowed certain classes of image manipulation to be performed using bitwise operations (especially by a blitter chip), and parallax scrolling effects. Some motion estimation algorithms can be performed using bit planes (e.g. after the application of a filter to turn salient edge features into binary values). This can sometimes provide

493-555: The BMHD (Bit Map HeaDer) chunk and any other 'vital' chunks must appear before the BODY chunk. Any chunks appearing after BODY are considered 'extra' and many programs will leave them unread and unchanged. The BMHD chunk specifies how the image is to be displayed and is usually the first chunk inside the FORM . 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

522-550: The BODY chunk. Deluxe Paint normally writes 4 CRNG chunks in an ILBM when the user asks it to "Save Picture". Commodore's Graphicraft program uses CCRT for Colour Cycling Range and Timing . This chunk contains a CycleInfo structure. Like CRNG it is a nonstandard chunk. The data is similar to a CRNG chunk. A program would probably only use one of these two methods of expressing colour cycle data. You could write out both if you want to communicate this information to both DeluxePaint and Graphicraft. The optional property DEST

551-480: The IFF specification the chunk will be padded by one byte to make it an even number of bytes long, but the pad byte is not included in the chunk's length field. The colour range chunk is 'nonstandard'. It is used by Electronic Arts' Deluxe Paint program to identify a contiguous range of colour registers or a "shade range" and colour cycling. There can be zero or more CRNG chunks in an ILBM file, but all should appear before

580-525: The ILBM file contains a CAMG chunk in which bit 11 is set (i.e. 0x800 in hexadecimal) the file expects to make use of the HAM (Hold-And-Modify) mode of the Amiga chipset. In HAM6 format the colour map will have up to 16 entries, but the image will have 6 (or possibly 5 bitplanes). In HAM8 format the colour map will have up to 64 entries but the image will have 8 (or possibly 7 bitplanes). The last two bitplanes (if an odd number of bitplanes assume an extra bitplane which

609-453: The ILBM file contains a CAMG chunk in which bit 7 is set (i.e. 0x80 in hexadecimal). The file expects to make use of the EHB (Extra Half-Brite) mode of the Amiga chipset. The colour map will have no more than 32 entries, but the image will have 6 bitplanes. The most significant bitplane should be regarded as a flag, when unset, use the lower 5 bits as an index into the colour map as usual. When the flag

SECTION 20

#1733084899570

638-404: The bitplanes will put the least significant bit of the red component first: R0 R1 R2 R3 R4 R5 R6 R7 G0 G1 G2 G3 G4 G5 G6 G7 B0 B1 B2 B3 B4 B5 B6 B7 If there are 32 bit planes, the last 8 bit planes will be an alpha channel: R0 R1 ... R7 G0 ... G7 B0 ... B6 B7 A0 A1 A2 A3 A4 A5 A6 A7 An image containing no colour map and only 8 bitplanes may be a greyscale image: I0 I1 I2 I3 I4 I5 I6 I7 If

667-518: The data itself. One aspect of using bit-planes is determining whether a bit-plane is random noise or contains significant information. One method for calculating this is to compare each pixel (X, Y) to three adjacent pixels (X − 1, Y) , (X, Y − 1) and (X − 1, Y − 1) . If the pixel is the same as at least two of the three adjacent pixels, it is not noise. A noisy bit-plane will have 49% to 51% pixels that are noise. As an example, in PCM sound encoding

696-434: The destination bitmap (depth planes deep) not in the source bitmap (numPlanes planes deep). The optional GRAB chunk locates a "handle" or "hotspot" of the image relative to its upper left corner, e.g., when used as a mouse cursor or a "paint brush". It is optional. The SPRT chunk indicates that an image is intended to be a sprite. It should thus have a mask plane or transparent colour and shouldn't be fullscreen. How this

725-402: The first bit in the sample denotes the sign of the function, or in other words defines the half of the whole amplitude values range, and the last bit defines the precise value. Replacement of more significant bits result in more distortion than replacement of less significant bits. In lossy media compression that uses bit-planes it gives more freedom to encode less significant bit-planes and it

754-460: The image is compressed. The content of this chunk is as follows: The BODY chunk is usually the last chunk in a file, and the largest. In ILBM files the BODY chunk stores the actual image data as interleaved bitplanes (and optional mask) by row. The bitplanes appear first from 1 to n, followed by the mask plane. If the image is uncompressed then each line will be made up of (width + 15) / 16 16-bit values (i.e. one bit per pixel, rounded up to

783-427: 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. In PBM files, the BODY chunk is simpler as uncompressed it is just a continuous stream of bytes containing image data. If an image is compressed, each row of data (but not each bitplane) is compressed individually, including the mask data if present. The compression

812-433: The number of "1" bits should equal numPlanes. "0" bits mean "put the corresponding bit from planeOnOff into this bitplane". Bits in planeMask gate writing to the destination bitplane: "1" bits mean "write to this bitplane" while "0" bits mean "leave this bitplane alone". The normal case (with no DEST chunk) is equivalent to planePick = planeMask = (2 ^ numPlanes) - 1 . Remember that color numbers are formed by pixels in

841-412: The set of the most significant bit, and the 16th contains the least significant bit. It is possible to see that the first bit plane gives the roughest but the most critical approximation of values of a medium, and the higher the number of the bit plane, the less is its contribution to the final stage. Thus, adding a bit plane gives a better approximation. If a bit on the nth bit plane on an m-bit dataset

#569430