Pcx format file

Using the run-length data compression scheme, a run of pixels several bytes in length may be converted to a run code only two bytes in length.

The encoded data is read one byte at a time. If the two most significant bits MSB of the first byte read are set to 1, then this byte is the first byte of a 2-byte run code. The first byte in a 2-byte run code always contains the run count in its lower six bits, which is the length of the pixel run. Therefore, a pixel run may be 1 to 63 pixels in length. Using the two most significant bits to indicate a 2-byte code rather than just one, MSB is a holdover from the early CGA days of Paintbrush.

The second byte of a 2-byte run code is the value of the pixel run itself. This value may be in the range 0 to and is written to the output a number of times equal to the run count. If a run-count byte is read and the two MSBs are both 0, then this byte is a run-value byte, and the run count is considered to be 1. This 1-byte run code is used to prevent a 1-pixel run from encoding into a 2-byte run code. A 1-byte run code can contain a run value only in the range 0 to If the pixel run value is in the range 64 to , a 2-byte run code must be used instead.

If an image contains many single pixel runs of color values greater than 63, an increase of image data size can occur after PCX encoding. Such an increase in data size typically occurs only in very noisy or grainy images. It is also necessary to determine if the image data has been encoded across scan lines.

If the two MSBs are set to 1, then mask off the run count. Read next byte. Write the byte a number of times equal to the run count. Else, if the two MSBs are set to 0, then mask off the run value. Write the byte once. Repeat steps 1 through 6 until the buffer is full. This means that when a run of data is being encoded, and the end of the scan line is reached, the run should stop and not continue across to the next scan line, if it is possible to stop it. Decoding can be complicated by PCX files that have been encoded ignoring this rule.

Encoding across scan lines gains a few extra bytes of compression, but the process of decoding a single scan line is made much more difficult. Raw data is read one byte at a time. The only information needed is the number of bytes in a scan line. The following is the procedure for encoding image data using the PCX compression algorithm: Read a byte of pixel data, and store the value.

Set counter to 1. Read the next byte, and check if it is the same as the stored value. If it is the same, increment the counter. If it is not the same and the count is greater than one, or the count is 63, or if the end of the scan line has been reached, then mask on the two MSBs, and output the count value. Output the data value. Repeat steps 1 though 6 until all scan lines have been read.

Knowing the data format of a scan line is necessary so you can parse the pixel data from a scan line for display of the image or conversion of the image file from one format to another. All scan lines in a PCX file always have the same format.

Scan-line pixel data is stored in one of two ways--either pixel-oriented or plane-oriented. Pixel-oriented data is stored with all the pixel data either real data or indexes into a color palette in a contiguous line. Plane-oriented data unrolls the pixel data into its red, green, and blue components and groups them by color across the scan line. Single-plane data is stored pixel by pixel in one long plane that runs the length of the scan line.

The data in the scan line is not the actual image data itself but is instead a series of index values into either the EGA or VGA color palettes. The exception for single-plane data is the 1-bit monochrome image, where each bit in a scan line maps directly as a pixel value. How much of the scan-line data a single pixel occupies is determined from the BitsPerPixel value.

For example, with one bit per pixel, every byte of scan-line data contains eight pixel values. With eight bits per pixel, every byte of scan-line data contains one pixel value. Some sources seem to indicate that there are formats where even the smaller palettes are added behind the image, so it is best to always check for it there.

To determine if this is the case, check if the decompressed image data is followed by a 0C byte, and if there is enough data left in the file behind that for the palette data. As a general rule, the palettes are lists of 3-byte blocks. These blocks normally contain 8-bit RGB data, but even if they are used differently as is the case for CGA palettes , they will still retain the 3-byte block structure. It is difficult to correctly determine the palette for 1-bit and 2-bit images, since they can be stored either as CGA or as EGA, and there is no real way to identify which method to use.

Some sources suggest checking for x dimensions on 1-bit images, or x on 2-bit, since those are standard CGA sizes for respectively its monochrome and 4-colour mode, but x is a very common size for non-CGA images as well, and there has most likely never been anything preventing people on CGA hardware from saving PCX images in different sizes than a full screen.

It is also suggested, for two bit per pixel images, that those with a single 2-bit plane would use a CGA palette, while those with two 1-bit planes would use EGA [2].

All of this makes fully automatic identification for these image types very difficult. CGA palette handling is a bit peculiar. As with other colour palettes, the data is seen as blocks of three bytes.

The first triplet contains a specifically-defined colour. Only the highest four bits of the first byte are used, meaning the actual colour value can be found by taking that byte and shifting it four bits to the right. The result is a value from For monochrome CGA images, this colour is put on index 1 on the palette, and index 0 is filled in with black EGA palette entry 0.

For actual 4-colour palettes, this colour becomes the background colour at index 0. For the full explanation on which colours this produces, see the CGA Palette article. However, the way these three bits are determined changed in PC Paintbrush version IV, and this change is not reflected in a change in the Version value in the header.

The only decent way to distinguish the files from before and after version IV is to check the PaletteInfo byte in the header, which is 0 on files using the old method, and filled in with 1 or 2 on files using the new method. In the original way the status bits were saved, the second palette entry's first byte byte 3 contains the three status bits. For the newer files, with the PaletteInfo byte filled in, the following [4] [5] should be done to determine the palette:.

The new method seemed to have been intended to convert a fully-saved colour palette back to CGA status bits. Sadly, it seems people figured out exactly what it checked, and started writing PCX files which contained only exactly enough data to derive those bits instead of saving an actual full palette.

They can also be converted to more user-friendly formats. Actively scan device characteristics for identification. Use precise geolocation data. Select personalised content. Create a personalised content profile.

Measure ad performance. Select basic ads. Create a personalised ads profile. Select personalised ads. Apply market research to generate audience insights. Measure content performance. But you can change it to any program at your pleasure.

In the pop-up windows, choose a program as the PCX file opener. If you decide to always open PCX files with the program, only check the option ' Always use the selected program to open this kind of file '. How to Open. Windows OS Default. Linux OS Default. Android OS Best. Apple iOS Best. Other apps to open.