From: "A. Sinan Unur" <sinan DOT unur AT cornell DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Header of PCX files
Date: Mon, 08 Dec 1997 08:03:24 -0500
Organization: Cornell University (http://www.cornell.edu/)
Lines: 107
Sender: asu1 AT cornell DOT edu (Verified)
Message-ID: <348BF01C.E1B09BE3@cornell.edu>
References: <347D2F73 DOT 5761 AT esiee DOT fr> <66firo$fcq AT bgtnsc01 DOT worldnet DOT att DOT net>
NNTP-Posting-Host: cu-dialup-0015.cit.cornell.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

Alex Barsamian wrote:
> 
> >I'm looking for the exact description of the header of PCX image 
> >files. I know it is 128 bytes long, I know the title of the 
> > differents parts which are containing in the header.
> >But which values should I put in them ???
> 
> Here is what the PCX 5.0 spec looks like:
> 
> typedef struct pcx_header {
>     char manufacturer;  // the manufacturer: this is useless
>     char version;            // file format version
>     char encoding;        // type of compression, RLE or none
>     char bits_per_pixel;
>     int x,y;                       // starting location of image in x/y
> space
>     int width,height;       // size of image, units in pixels
>     int horz_res, vert_res;    // dots per inch, for printing
>     char ega_pallete[48]    // the old 16 color pallete
>     char reserved;            // ?
>     char num_color_planes;    // don't care if using 256 color PCXs
>     int bytes_per_line;
>     int pallete_typ;        // 1 for color, 2 for greyscale
>     char padding[58];    // seems fairly obvious...
> }
> 
> The pallete is found 768 characters before EOF.

do the specs assume those ints are 16 bit? if so, you will have a
problem if you try to read data straight into that struct. _IF_ the ints
are supposed to be 16-bit in that header (which i think they probably
are), you might want to use

typedef unsigned char UINT8;
typedef unsigned short UINT16;
typedef unsigned int UINT32;

typedef struct PCX_HEADER {
    UINT8   manufacturer;
    UINT8   version;
    UINT8   encoding;
    UINT8   bits_per_pixel;
    UINT16  x,y;
    UINT16  width,height;
    UINT16  horz_res, vert_res;
    UINT8   ega_pallete[48];
    UINT8   reserved;
    UINT8   num_color_planes;
    UINT16  bytes_per_line;
    UINT16  pallete_typ;
    UINT8  padding[58];
} __attribute__((packed)) PCX_HEADER;

a somewhat more roundabout approach that i sometimes use involves
treating structs like this involves using an array for the struct, and
an enum for the offsets of the various fields and accessor functions for
each field. for example, suppose some binary info is supposed to be laid
out as:

 UINT16 field_1
 UINT16 field_2
 UINT8  field_3

the size of this is 5 bytes. so,

unsigned char HEADER[5] would be the array to store the info in.

typedef enum HEADER_OFFSET
{
  HO_FIELD1 = 0,
  HO_FIELD2 = 2,
  HO_FIELD3 = 4
} HEADER_OFFSET;

since, in this case, all values would fit fine in an unsigned int, i
prefer to specify the return value of each accessor as such:

typedef unsigned int HEADER_VALUE;

HEADER_VALUE hv_field1(const char* h)
{
  h += HO_FIELD1;
  return *((const unsigned short *)h);
}

HEADER_VALUE hv_field2(const char *h)
{
  h += HO_FIELD2;
  return *((const unsigned short *)h);
}

HEADER_VALUE hv_field3(const char *h)
{
  h += HO_FIELD3;
  return *((const unsigned char *) h));
}

whatever you decide to use, the important thing is to get the field
widths right.
-- 
----------------------------------------------------------------------
A. Sinan Unur
Department of Policy Analysis and Management, College of Human Ecology,
Cornell University, Ithaca, NY 14853, USA

mailto:sinan DOT unur AT cornell DOT edu
http://www.people.cornell.edu/pages/asu1/