--- /dev/null
+\r
+\r
+Ian Ashdown\r
+byHeart Software\r
+620 Ballantree Road\r
+West Vancouver, B.C.\r
+Canada V7S 1W3\r
+\r
+Issue 1: 91/02/12\r
+Issue 2: 91/03/27\r
+Issue 3: 91/08/08\r
+Issue 4: 91/08/11\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+ PCX Graphics\r
+\r
+ by \r
+\r
+ Ian Ashdown\r
+ byHeart Software\r
+\f\r
+Looking to add monochrome or full-color bit-mapped graphics to your \r
+application programs? If so, you might consider the PCX graphics file \r
+format. Originally developed in 1982 by ZSoft Corporation for their PC \r
+Paintbrush (R) products, it has become a de facto industry standard for \r
+storing and transferring bit-mapped images on MS-DOS machines. It can \r
+support displays of any resolution using palettes of up to 256 \r
+simultaneous colors, and is very simple to implement. Furthermore, it's \r
+not limited to MS-DOS and OS/2-based machines; the PCX format is \r
+applicable to any environment supporting bit-mapped graphics. \r
+\r
+Today, more commercial programs support ZSoft's PCX format than any \r
+other, including Aldus-Microsoft's Tag Image File Format (TIFF). \r
+However, unlike TIFF with its publicly-available technical \r
+specifications, the PCX file format has never been completely documented. \r
+When ZSoft first created PC Paintbrush, the only video displays they had \r
+to contend with were two monochrome adapters (Hercules and Tecmar) and \r
+the IBM Color Graphics Adapter (CGA). They have since quietly modified \r
+and extended their format on several occasions to support EGA, VGA and \r
+SuperVGA displays. Documentation is scarce, incomplete and sometimes \r
+contradictory. There's a small booklet available from ZSoft that \r
+describes the current version (with several omissions), a sample Pascal \r
+program from their CompuServe forum (GO WINAPB), a few magazine articles, \r
+and chapters in a few books (see the references at the end of this \r
+article). \r
+\r
+Personally, I think it's about time to remedy this situation. The \r
+following is a complete set of technical specifications for the current \r
+version of PCX. All of the information has been derived from printed \r
+information provided by ZSoft and conversations with their Technical \r
+Services department. This is it, folks! We now have formal (if not \r
+exactly official) specifications to work with when including the PCX \r
+graphics file format in our application programs. \r
+\r
+My original plan was to include sample C source code for reading and \r
+writing PCX image files. However, both this article and the source code \r
+grew to the extent that one had to go. If you don't want to develop your \r
+own PCX file handling routines from scratch, PCX_LIB is available through \r
+the CUG Library as CUG Volume #???. It includes fully commented C source \r
+code for reading and writing PCX image files, complete with software \r
+drivers for Hercules, CGA, EGA, and VGA display adapters.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+ p. 1\r
+\f\r
+PCX Specifications \r
+\r
+The PCX graphics file format (Version 5) is designed to store monochrome \r
+and color bit-mapped images of any resolution with palettes of up to 256 \r
+simultaneous colors. It was originally designed for MS-DOS \r
+microcomputers, but is adaptable to other bit-mapped graphic \r
+environments. A simple but effective byte-oriented, run-length encoding \r
+scheme is used to compress the image data.\r
+\r
+There are two or three sections to a PCX graphics file - a 128-byte \r
+header, the encoded image data (which can be of any length) and an \r
+optional 256-color palette (see Figure 1). This palette is appended to \r
+the file only if the image contains more than 16 colors. \r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+ p. 2\r
+\f\r
+1. PCX File Header\r
+\r
+The file header describes the graphical environment in which the image is \r
+to be displayed. The information contained in the header is somewhat \r
+device-dependent in that the PCX file format implicitly assumes the \r
+presence of a standard IBM PC-compatible display adapter. Furthermore, \r
+the specific type and video mode of the adapter needed to display the \r
+image correctly cannot be uniquely determined from the file header \r
+information. It is in general the user's responsibility to ensure that \r
+the correct video mode has been selected before displaying a PCX image. \r
+\r
+The file header structure is shown in Figure 2. A complete description \r
+of each structure member is as follows: \r
+\r
+1.1 PCX Flag\r
+\r
+A constant value (0x0a) that signifies a PCX image file. \r
+\r
+1.2 Version\r
+\r
+Indicates the PCX file format version. It can be one of five values: \r
+\r
+ 0 - Version 2.5 of PC Paintbrush.\r
+ 2 - Version 2.8 (with palette information).\r
+ 3 - Version 2.8 (without palette information).\r
+ 4 - PC Paintbrush for Windows (not 3.0).\r
+ 5 - Version 3.0 and greater of PC Paintbrush and Paintbrush Plus, \r
+ including Publisher's Paintbrush. \r
+\r
+Most commercial programs supporting the PCX file format conform to \r
+Version 5. See Section 3, "Color Palettes", for further information. \r
+\r
+1.3 Encoding (1)\r
+\r
+A constant value (0x01) that indicates run-length encoding was used to \r
+encode and compress the image data. \r
+\r
+1.4 Bits per Pixel\r
+\r
+The number of bits per pixel per color plane (typically 1, 2, 4 or 8). \r
+\r
+1.5 Window\r
+\r
+A structure with the following members: \r
+\r
+ Name Bytes Description\r
+\r
+ xul 2 Upper left corner horizontal position\r
+ yul 2 Upper left corner vertical position\r
+ xlr 2 Lower right corner horizontal position\r
+ ylr 2 Lower right corner vertical position\r
+\r
+These members describe the position and size of the image within the \r
+display, and are measured in pixels (starting with zero). \r
+\r
+\r
+\r
+\r
+\r
+ p. 3\r
+\f\r
+1.6 HDPI (2)\r
+\r
+"Horizontal dots per inch". The value represents the horizontal \r
+resolution of the device used to create the image. \r
+\r
+1.7 VDPI (2)\r
+\r
+"Vertical dots per inch". The value represents the vertical resolution \r
+of the device used to create the image. \r
+\r
+1.8 Color Map\r
+\r
+The color palette to be used when displaying an image with 16 or fewer \r
+colors. See Section 3, "Color Palettes", for further information. \r
+\r
+1.9 Reserved\r
+\r
+This member was used to indicate the appropriate MS-DOS video mode in \r
+previous PCX file format versions. It is ignored in Version 5, but\r
+should be set to zero.\r
+\r
+1.10 NPlanes\r
+\r
+The number of color planes used to display the image (typically 1 or 4). \r
+See Section 3, "Color Palettes", for further information. \r
+\r
+1.11 Bytes per Line\r
+\r
+The number of bytes required for a buffer when decoding one color plane \r
+scan line. This value should be an even number (for compatibility with \r
+some existing commercial programs). See Section 2, "Image Encoding and \r
+Decoding", for further information. \r
+\r
+1.12 Palette Info (3)\r
+\r
+A bit-mapped variable indicating how to interpret the color palette. \r
+Only the lowest two bits are significant; the others are ignored. It \r
+can have one of two possible values: \r
+\r
+ 0x01 - color or black & white\r
+ 0x02 - grayscale\r
+\r
+If the variable is set to 0x02 (grayscale), the color palette must be set \r
+to shades of gray. \r
+\r
+1.13 HScreen Size (4)\r
+\r
+Horizontal screen size in pixels.\r
+\r
+1.14 VScreen Size (4)\r
+\r
+Vertical screen size in pixels.\r
+\r
+1.15 Filler\r
+\r
+Blank space to fill out 128-byte header. All bytes within this member \r
+should be set to zero. \r
+\r
+\r
+ p. 4\r
+\f\r
+Notes\r
+\r
+1. ZSoft has reserved the right to change the encoding scheme for better \r
+ image compression performance in future versions. \r
+\r
+2. Horizontal and vertical resolution for video display adapters is \r
+ defined as the total number of displayed pixels for the current video \r
+ mode. For scanners, it is defined in terms of dots per inch. (These \r
+ values are provided for information only. They are not required for \r
+ encoding or decoding PCX image files.) \r
+\r
+3. The "palette info" member of the file header was used in previous \r
+ versions of the PCX file format to indicate whether the palette \r
+ represented a color or grayscale palette. If it was set to 0x02 (as a \r
+ bitmap - the upper 6 bits could be set at random), the file decoding \r
+ functions could assume a default grayscale palette if necessary. \r
+ However, the palette already had a true (and possibly nonlinear) \r
+ grayscale, so the "palette info" member was never really used by \r
+ ZSoft. The current PC Paintbrush IV and IV Plus products simply \r
+ ignore it. \r
+\r
+4. The "HScreen Size" and "VScreen Size" members were added to Version 5 \r
+ of the PCX format to support PC Paintbrush IV Version 1.02 and IV Plus \r
+ Version 1.0. Since earlier Version 5 PCX files may contain \r
+ uninitialized data in place of these members, ZSoft specifically \r
+ recommends that they not be used to determine the appropriate video \r
+ mode for displaying the files.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+ p. 5\r
+\f\r
+2. Image Encoding and Decoding \r
+\r
+The PCX graphics file format considers an image to be a contiguous \r
+sequence (block) of eight-bit bytes representing a bit-mapped raster \r
+display. A simple byte-oriented, run-length encoding (RLE) scheme is\r
+used to compress the display data. When the display is represented by\r
+more than one color plane (such as color images on EGA displays), each\r
+scan line is stored sequentially by color plane. \r
+\r
+The run-length encoding scheme uses a byte pair consisting of a "count" \r
+byte and a following "data" byte to represent sequences of display bytes \r
+with the same value. A count byte is uniquely identified by having its \r
+two most significant bits set; its six least significant bits are used to \r
+represent the count value (1 to 63). The following data byte is the \r
+value that is repeated in the display data the number of times indicated \r
+by the count value. \r
+\r
+Any display data byte which is not part of a sequence of bytes of the \r
+same value and which does not have its two most significant bits set is \r
+stored as itself in the encoded image data. Single display data bytes \r
+with a value of 0xc0 or greater are encoded with a count value of one. \r
+\r
+2.1. Decoding\r
+\r
+Decoding display data from encoded image data is done on a line-by-line \r
+basis. The pixel dimensions of the displayed image are calculated as: \r
+\r
+ horz_size = Window.xlr - Window.xul + 1\r
+\r
+and\r
+\r
+ vert_size = Window.ylr - Window.yul + 1\r
+\r
+The number of bytes required to buffer one complete scan line for all \r
+color planes in sequence is: \r
+\r
+ buffer_size = NPlanes * Bytes per Line\r
+\r
+Since there are always an integral number of bytes in the buffer, there \r
+may be unused data at the end of each color plane scan line if the number \r
+of bits per pixel is other than eight. This unused data should be masked \r
+off when transferring the line buffer contents to the video display \r
+adapter memory. \r
+\r
+In theory, each color plane scan line may contain an even or odd number \r
+of bytes. However, some application programs expect an even number of \r
+bytes. ZSoft ensures that their products create PCX files with an even \r
+number of bytes per color plane scan line, and recommends that other \r
+programs do the same for compatibility. Of course, decoding functions \r
+should be able to read files with either an even or odd number of bytes \r
+per color plane scan line. \r
+\r
+Decoding begins with the first scan line and proceeds by examining each \r
+byte of the encoded image data. If the two most significant bits of the \r
+byte are set, the lower six bits indicate how many times the next byte is \r
+\r
+\r
+\r
+\r
+ p. 6\r
+\f\r
+Decoding begins with the first scan line and proceeds by examining each \r
+byte of the encoded image data. If the two most significant bits of the \r
+byte are set, the lower six bits indicate how many times the next byte is \r
+to be duplicated in the line buffer. If these two bits are not set, the \r
+byte itself is copied (once) to the line buffer. A count is kept of the \r
+number of bytes in the line buffer. The current scan line is complete \r
+when its value equals "buffer_size". \r
+\r
+If the display contains more than one color plane, each plane is decoded \r
+in sequence. The order in which they are decoded is device-dependent. \r
+For instance, the Enhanced Graphics Adapter has four color planes ordered \r
+as blue, green, red and intensity. The beginning of each color plane \r
+scan line within the line buffer is given by: \r
+\r
+ offset = plane_number * Bytes per Line\r
+\r
+where "plane_number" is a number between 0 and NPlanes - 1. \r
+\r
+A decoding break occurs at the end of each scan line. That is, an \r
+encoding byte pair can only represent a contiguous sequence of bytes \r
+within the current scan line. However, this is not necessarily true for \r
+color planes. An encoding byte pair may represent a contiguous sequence \r
+of identical bytes that extends across two color planes for one display \r
+image scan line. \r
+\r
+Decoding continues until all scan lines (as indicated by "vert_size") \r
+have been decoded. Some older versions of PC Paintbrush padded the image \r
+with extra (uninitialized) scan lines so that all blocks of scan lines (8 \r
+or 16 lines) read from the file were the same size. The image data was \r
+read until end-of-file was returned. ZSoft no longer uses this \r
+technique, since it conflicts with the appended color palette (see \r
+Subsection 3.3, "VGA 256-Color Palettes"). The extra data read could \r
+also overrun the user's image buffer. \r
+\r
+A sample C function to decode a complete image scan line (all color planes)\r
+from a PCX file is shown in Figure 3. \r
+\r
+2.2. Encoding\r
+\r
+Encoding display image data is also done on a line-by-line basis, \r
+following the order of scan lines stored in the display adapter's memory \r
+buffer. The current scan line is encoded for each color plane on a per-\r
+byte basis. As noted above, ZSoft recommends that all color plane scan \r
+lines be padded if necessary to ensure they contain an even number of \r
+bytes. \r
+\r
+ZSoft also recommends that the data used to pad the last one or two bytes \r
+of a scan line represent white data. Apparently, some application \r
+programs display this data when printing or faxing the files.\r
+\r
+A sample C function to encode a single monochrome or color image scan \r
+line for a PCX file is shown in Figure 4.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+ p. 7\r
+\f\r
+3. Color Palettes \r
+\r
+The PCX file format supports color palettes of up to 16 colors in the \r
+file header. Larger palettes (up to a maximum of 256 colors) are stored \r
+in an optional color palette that is appended to the encoded image data \r
+portion of the file. \r
+\r
+The file header color palette has two different formats, both designed \r
+for IBM PC-compatible machines. A device-specific palette is used for \r
+Color Graphics Adapters (CGA), and a standard R-G-B palette is used for \r
+Enhanced Graphics Adapters (EGA), Multicolor Graphics Adapters (MCGA), \r
+Video Graphics Adapters (VGA) and extended Video Graphics Adapters \r
+(SuperVGA). \r
+\r
+ZSoft's PC Paintbrush products no longer support the CGA color palette. \r
+The following information is provided only for compatibility with older \r
+PCX files. \r
+\r
+3.1. CGA Color Palettes\r
+\r
+The PCX format supports eight possible CGA color palettes for video modes \r
+4 (320x200 4-color graphics) and 5 (320x200 monochrome graphics, color \r
+burst off). Each palette consists of a background color and three \r
+foreground colors (or shades of grey). The background can be one of 16 \r
+colors, the value for which is stored in the first byte of the PCX file \r
+header Color Map member. Only the upper four bits are significant; the \r
+value must be right-shifted by four bits (or divided by 16) to determine \r
+the appropriate CGA hardware palette register value. \r
+\r
+The foreground color palette is specified by the fourth byte of the Color \r
+Map, which has the following structure: \r
+\r
+ Name Bit Description\r
+\r
+ Color Burst Enable 7 0 - color\r
+ 1 - monochrome\r
+ Palette 6 0 - yellow\r
+ 1 - white\r
+ Intensity 5 0 - dim\r
+ 1 - bright\r
+\r
+The lower five bits are ignored. \r
+\r
+Most published descriptions of the ROM BIOS call "Set CGA Palette" \r
+(Interrupt 16, Function 11) document only two palettes, obtainable by \r
+setting register BL to 0x00 or 0x01. This is equivalent to the "Palette" \r
+bit above. However, the palette intensity (equivalent to the "Intensity" \r
+bit above) can be selected using bit 4 of the BL register (0 = dim, 1 = \r
+bright). \r
+\r
+The original CGA display adapter was designed for use with NTSC composite \r
+video monitors and color televisions. The "color burst" is a periodic \r
+burst of a 3.58 MHz signal superimposed on the composite video signal to \r
+synchronize the phase of the monitor's internal 3.58 MHz oscillator. \r
+(Without synchronization, the picture has drifting color bars.) The \r
+presence or absence of the burst determines whether the image is \r
+displayed in color or monochrome. \r
+\r
+\r
+ p. 8\r
+\f\r
+The "Color Burst Enable" bit above actually indicates whether the MS-DOS \r
+video mode is to be 4 (color) or 5 (monochrome). However, the color \r
+burst signal has no meaning for RGB monitors. Video mode 5 will produce \r
+only two distinct color palettes on CGA displays adapters with RGB \r
+monitors, and three distinct palettes on EGA, VGA and SuperVGA display \r
+adapters emulating a CGA display. \r
+\r
+Under video mode 6 (640 x 200 2-color graphics), the first byte of the\r
+CGA color palette specifies the foreground color (i.e. - the color of\r
+the displayed pixels).\r
+\r
+3.2. EGA/VGA 16-Color Palettes\r
+\r
+The 16-color palette for EGA, MCGA, VGA and SuperVGA displays is an array \r
+of 16 elements, each a structure with the following members: \r
+\r
+ Name Bytes Description\r
+\r
+ Red 1 Red intensity\r
+ Green 1 Green intensity\r
+ Blue 1 Blue intensity\r
+\r
+All color map entries are stored as unsigned bytes with values ranging \r
+between 0 and 255. Where display adapters support fewer intensity \r
+levels, the value of each color map entry is interpreted by dividing its \r
+value by 256/n, where n is the number of allowable intensity levels \r
+(typically 2, 4 or 16). \r
+\r
+3.3. VGA 256-Color Palettes\r
+\r
+The 256-color palette for MCGA, VGA and SuperVGA displays is an array of \r
+256 elements, each a structure with the same members as the EGA/VGA 16-\r
+color palette, which is appended to the encoded image data portion of the \r
+file (see Figure 1). It is always preceded by a constant byte flag with\r
+the value 0x0c (12 decimal). \r
+\r
+Only Version 5 PCX-format files support 256-color palettes, and then only \r
+when the image has more than 16 colors. ZSoft recommends the following \r
+technique to determine if a 256-color palette is present: first verify \r
+that the file version number is 5, then count back 769 bytes from the end \r
+of the file. If the value of this byte is not 0x0c, the optional 256-\r
+color palette is not present and the EGA/VGA 16-color file header palette \r
+should be used. \r
+\r
+It is possible that a Version 5 PCX-format file with a valid file header \r
+palette can have the value 0x0c in the 769th byte from the end of the \r
+encoded image data. The above technique would then falsely indicate the\r
+presence of an appended 256-color palette. To avoid this problem, it is \r
+necessary to first decode the image and note the file position where the \r
+encoded image data section ends before counting back 769 bytes from the \r
+end of the file. If the supposed 256-color palette flag is located in \r
+the image data section, then the file header palette should be used \r
+instead.\r
+\r
+\r
+\r
+\r
+\r
+\r
+ p. 9\r
+\f\r
+3.4. 24-Bit Color \r
+\r
+Future versions of ZSoft's Publisher's Paintbrush will support up to 16.7 \r
+million simultaneous colors. The PCX file format will be based on three \r
+color planes (red, green and blue), with 8 bits per pixel per plane. \r
+There will be no color palette, since the color of each pixel will be \r
+fully specified by the encoded image data. \r
+\r
+3.5. Disabling the Palette \r
+\r
+It is occasionally necessary to disable the color palette of a PCX file \r
+in order to correctly display the image. In other words, the current \r
+(default) setting of the display adapter's palette registers are used. \r
+This can be done by changing the PCX file version number from '5' to '3' \r
+(i.e. - PC Paintbrush Version 2.8 without palette information). The file \r
+decoding functions must then check the file version number and ignore the \r
+color palette if it is set to '3'.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+ p. 10\r
+\f\r
+4. Other Environments \r
+\r
+While the PCX file format was designed for MS-DOS machines, it is \r
+nevertheless possible to display PCX images on other machines. It will \r
+generally be necessary to map the image representation (i.e. - window \r
+dimensions, number of color planes, bits per pixel per plane, and the \r
+color palette) to the capabilities of the display hardware. \r
+\r
+It is also necessary to remember that all information in a PCX-format \r
+file is stored as either 8-bit bytes or 16-bit words. Words are stored \r
+in the big-endian format characteristic of 80x86-based machines. That \r
+is, the eight least significant bits (lower byte) are stored first, \r
+followed by the eight most significant bits (upper byte). If PCX-format \r
+files are transferred to little-endian machines (such as those based on \r
+680x0 and Z8000 processors), the order of bytes within each word will \r
+have to be reversed before they can be interpreted. (This applies to the \r
+file header only, since the encoded image data and optional 256-color \r
+palette are stored as bytes.)\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+ p. 11\r
+\f\r
+References \r
+\r
+Azer, S. [1988]. "Working With PCX Files", Microcornucopia, No. 42 \r
+(July-August), p. 42.\r
+\r
+Lindley, C.A. [1990]. Practical Image Processing in C, John Wiley & Sons \r
+Inc., New York, N.Y.\r
+\r
+Luze, M. [1991]. "Printing PCX Files", C Gazette, Vol. 5:2 (Winter 1990 -\r
+1991), pp. 11-22.\r
+\r
+Phoenix Technologies Ltd. [1989]. System BIOS for IBM PC/XT/AT Computers \r
+and Compatibles, Addison-Wesley, Reading, MA.\r
+\r
+Quirk, K. [1989]. "Translating PCX Files", Dr. Dobb's Journal, Vol. 14:8 \r
+(August), pp. 30-36, 105-108.\r
+\r
+Rimmer, S. [1990]. Bit-Mapped Graphics, Windcrest Books, Blue Ridge \r
+Summit, PA.\r
+\r
+ZSoft Corporation [1988]. PCX Technical Reference Manual Revision 4,\r
+ZSoft Corporation, Marietta, GA.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+ p. 12\r
+\f\r
+Figures\r
+\r
++--------------------------------------------+\r
+| File Header (128 bytes) |\r
++--------------------------------------------+\r
+| Encoded Image Data (variable length) |\r
++--------------------------------------------+\r
+| Optional Color Palette (769 bytes) |\r
++--------------------------------------------+\r
+\r
+Figure 1 - Basic PCX File Format\r
+\r
+\r
+Name Bytes Description \r
+\r
+PCX Flag 1 Constant flag\r
+Version 1 PCX version number\r
+Encoding 1 Run-length encoding flag\r
+Bits per Pixel 1 Number of bits per pixel per plane\r
+Window 8 Window dimensions\r
+HDPI 2 Horizontal image resolution\r
+VDPI 2 Vertical image resolution\r
+Color Map 48 Hardware R-G-B color palette\r
+Reserved 1 (Used to contain video mode)\r
+NPlanes 1 Number of color planes\r
+Bytes per Line 2 Number of bytes per scan line\r
+Palette Info 2 Palette interpretation\r
+HScreen Size 2 Horizontal screen size\r
+VScreen Size 2 Vertical screen size\r
+Filler 54 Initialized filler bytes\r
+\r
+Figure 2 - PCX File Header Structure\r
+\r
+\r
+/* Read an encoded scan line (all color planes) from a */\r
+/* PCX-format image file and write the decoded data to a scan */\r
+/* line buffer */\r
+\r
+void pcx_read_line\r
+(\r
+ unsigned char *linep, /* PCX scan line buffer pointer */\r
+ FILE *fp, /* PCX image file pointer */\r
+ int bpline /* # bytes per line (all color planes) */\r
+)\r
+{\r
+ int data; /* Image data byte */\r
+ int count; /* Image data byte repeat count */\r
+ int offset = 0; /* Scan line buffer offset */\r
+\r
+ while (offset < bpline) /* Decode current scan line */\r
+ {\r
+ data = getc(fp); /* Get next byte */\r
+\r
+ /* If top two bits of byte are set, lower six bits show how */\r
+ /* many times to duplicate next byte */\r
+\r
+\r
+\r
+\r
+ p. 13\r
+\f\r
+ if ((data & 0xc0) == 0xc0)\r
+ {\r
+ count = data & 0x3f; /* Mask off repeat count */\r
+ data = getc(fp); /* Get next byte */\r
+ memset(linep, data, count); /* Duplicate byte */\r
+ linep += count;\r
+ offset += count;\r
+ }\r
+ else\r
+ {\r
+ *linep++ = (unsigned char) data; /* Copy byte */\r
+ offset++;\r
+ }\r
+ }\r
+}\r
+\r
+Figure 3 - Decode PCX Image File Scan Line Function\r
+\r
+\r
+/* Encode a scan line and write it to a PCX file (the line is */\r
+/* assumed to contain the color plane scan lines in sequence, */\r
+/* with padding for an even number of bytes and trailing white */\r
+/* data for each line as appropriate) */\r
+\r
+void pcx_write_line\r
+(\r
+ unsigned char *linep, /* Scan line buffer pointer */\r
+ int length, /* Scan line buffer length (in bytes) */\r
+ FILE *fp /* PCX file pointer */\r
+)\r
+{\r
+ int curr_data; /* Current data byte */\r
+ int prev_data; /* Previous data byte */\r
+ int data_count; /* Data repeat count */\r
+ int line_count; /* Scan line byte count */\r
+\r
+ prev_data = *linep++; /* Initialize the previous data byte */\r
+ data_count = 1;\r
+ line_count = 1;\r
+\r
+ while (line_count < length) /* Encode scan line */\r
+ {\r
+ curr_data = *linep++; /* Get the current data byte */\r
+ line_count++; /* Increment line byte count */\r
+\r
+ if (curr_data == prev_data) /* Repeating data bytes ? */\r
+ {\r
+ data_count++; /* Increment data repeat count */\r
+\r
+ if (data_count == 0x3f) /* Max allowable repeat count ? */\r
+ {\r
+ pcx_encode(prev_data, data_count, fp); /* Encode data */\r
+ data_count = 0;\r
+ }\r
+ }\r
+\r
+\r
+\r
+\r
+ p. 14\r
+\f\r
+ else /* End of repeating data bytes */\r
+ {\r
+ if (data_count > 0)\r
+ pcx_encode(prev_data, data_count, fp); /* Encode data */\r
+\r
+ prev_data = curr_data; /* Current data byte now prev */\r
+ data_count = 1;\r
+ }\r
+ }\r
+\r
+ if (data_count > 0) /* Any remaining data ? */\r
+ {\r
+ pcx_encode(prev_data, data_count, fp); /* Encode data */\r
+ }\r
+}\r
+\r
+\r
+/* Write an encoded byte pair (or single byte) to a file */\r
+\r
+void pcx_encode\r
+(\r
+ int data, /* Data byte */\r
+ int count, /* Data byte repeat count */\r
+ FILE *fp /* PCX file pointer */\r
+)\r
+{\r
+ if (((data & 0xc0) == 0xc0) || count > 1)\r
+ {\r
+ putc(0xc0 | count, fp); /* Write count byte */\r
+ }\r
+\r
+ putc(data, fp); /* Write data byte */\r
+}\r
+\r
+Figure 4 - Encode Image Scan Line Functions\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+ p. 15\r
+\r
projects / 16.git / blobdiff