Parent Topic: <A href="http://www.pcigeomatics.com/cgi-bin/pcihlp/PMHPACKP">PMHPACKP</a><hr>
<H3>PMHPreferPixmap</H3>
<PRE>
  typedef struct
  {
    int                 nBytesPerPixel;   
    int                 nDepth;           
    int                 nScanlinePad;     

    int                 nRedShift;       
    int                 nGreenShift;
    int                 nBlueShift;

    uchar               abyRedComp[256]; 
    uchar               abyGreenComp[256];
    uchar               abyBlueComp[256];
    uchar               abyGreyComp[256];
    uchar               abyMap8Index[256];

    TBool               bTopToBottom;     
    TBool               bUseCompress;     
    uchar*              paby8to24;
  } PMHPreferPixmap;
</PRE>
<UL>
<LI> nBytesPerPixel: This field gives the total number of bytes used
for each pixel. This is not always the same as the depth since
there may be unused padding (alpha) bits in each pixel. This may
be 1, 2, 4 or 8. If the value is 2 the shift, and colour
compression tables should be ignored and the image packed as
5-6-5 bit packed data. 
</UL>
<UL>
<LI> nDepth: This field gives the number of bits per pixel that give
useful imagery info. Either 8 (PseudoColor) or 24. 
</UL>
<UL>
<LI> nScanlinePad: Each scanline must be a quantum of this number of
bytes. This value is usually 1, 2, or 4. 
</UL>
<UL>
<LI> nRedShift, nGreenShift, nBlueShift: These values give the shift
values to place colour components in the proper locations within
a 32 bit word. Thus on a byte swapped machine a nRedShift value
of zero would indicate that the red byte should be the first (low
order) byte in the 32 bit word while on a non-swapped system an
nRedShift value of 24 would have to be used for the same effect.
At this time only the values 0, 8, 16 and 24 are legal. It is
assumed that the components being shifted into the 32bit word are
bytes. For 24 bit images (nBytesPerPixel == 3) the shifts are
relative to a 32 bit word, and it is assumed that they will
result in the Red, Green and Blue bytes being placed into the
first three bytes of the word such that the fourth byte can be
skipped when packing into 24 bit. 
</UL>
<UL>
<LI> abyRedComp, abyGreenComp, abyBlueComp, abyGreyComp, abyMap8Index:
These arrays are used to convert 24 bit color values into 8 bit
colormap values. The aby[name]Comp arrays compress each component
into an index value. Adding the index values gives a colormap
index. The abyMap8Index array then converts this index into an
actual color pixel value for a particular system. 
</UL>
<UL>
<LI> bTopToBottom indicates the vertical orientation of the data. If
TRUE, means that the lines go from top to bottom order. If FALSE,
the lines go from bottom to top order. 
</UL>
<UL>
<LI> bUseCompress indicates whether or not the compression tables are
used. Note that bUseCompress TRUE with nBytesPerPixel values of
24 or 32 indicates that a DirectColor (in X Parlance) image is
being composed. After composing the 32 bit value the
abyRedComp[], abyGreenComp[] and abyBlueComp[] values &quot;luts&quot;
should be applied, but the result placed back in the original
location rather than being composed into an eight bit
(PseudoColor) value. 
</UL>
<UL>
<LI> paby8to24 is a 768 byte array used to translate 8 bit pseudocolor
values into 24 bit color values. The first 256 bytes are the red
component values for each pseudocolor table entry. The next 256
bytes for blue and the last 256 byte for green. For example, to
find out the RGB values for 56th color map entry (where the
entries are numbered from 0 to 255), it would be red =
paby8To24[55], green = paby8to24[55 + 256], and blue =
paby8to24[55 + 512]; 
</UL>
<hr>
Parent Topic: <A href="http://www.pcigeomatics.com/cgi-bin/pcihlp/PMHPACKP">PMHPACKP</a><br>
<a href="http://www.pcigeomatics.com/dev_corner/pcihlp_gateway.html">About PCI Help Gateway</a>