OS/2 Shareware BBS: 10 Tools/10-Tools.zip/gbmos2pm.zip/gbmdlg/gbmdlg.hlp

OS/2 Help File | 1997-01-26 | 27KB | 837 lines

ΓòÉΓòÉΓòÉ 1. Bitmap File dialog ΓòÉΓòÉΓòÉ

This dialog allows you to load a bitmap from a file, or save a bitmap to a
file. Filenames and directories may be selected from the listboxes via the
keyboard or the mouse, just like in any other File dialog.

You can handle bitmap files of a variety of different formats. For example,
OS/2 Bitmaps, CompuServe GIF files, ZSoft PCX files and many others.

To see an extensive list of the level of support for the various bitmap
formats, and the format specific options available in each, see the Bitmap file
format support section of this help.

You can select which files are listed in the files listbox using the Bitmap
filetype filter combo box. You can pick, <All files>, <All GBM supported files>
and various <Format>s.

The program will look at the file extension and determine the format of the
file and use the relevant bitmap file handling code.

The Optional bitmap format specific options field allows you to specify a
string which is used to give hints to the relevant bitmap file handling code.
For example, you can tell the GIF file reader to ignore corrupt data and return
how far it got by giving the "errok" option.


ΓòÉΓòÉΓòÉ 2. Bitmap file format support ΓòÉΓòÉΓòÉ

This program uses the Generalised Bitmap Module. This peice of code can read
and write a variety of bitmap formats. The application program is unaware of
the file format of any bitmaps, and is just presented with the bitmap data in a
single standard way.

Some bitmap formats allow additional options to be supplied and these options
are listed highlighted like this.

This section fully defines the level of support :-

Formats supported are :

      OS/2 / Windows Bitmap

      CompuServe Graphics Interchange Format

      ZSoft PC Paintbrush Image Format

      Microsoft/Aldus Tagged Image File Format

      Truevision Targa/Vista

      Amiga IFF / ILBM Interleaved bitmap format

      YUV12C M-Motion Frame Buffer

      Portable Greyscale-map

      Portable Pixel-map

      IBM KIPS

      IBM Image Access eXecutive

      X Windows bitmap

      RiscOS Sprite

      IBM Printer Page Segment

      GEM Raster

      Portrait

      JPEG

      Others

 The Bitmap File Dialog can handle bitmaps in any of the formats documented
 above.


ΓòÉΓòÉΓòÉ 2.1. OS/2 / Windows bitmap ΓòÉΓòÉΓòÉ

The following file extensions

  .BMP .VGA .BGA .RLE .DIB .RL4 .RL8

are recognised as OS/2 1.1, 1.2, 2.0 or Windows 3.0 bitmaps.

Input

The bitmap support will read any of the above if uncompressed or run-length
compressed.

CCITT G3 MH Fax compressed files, or RLE24 compressed files can't be read.

 index=N
        Can be used if the file is an OS/2 bitmap-array file to specify which
        bitmap in the array to read (default N=0 - the first in the array).
 inv
        Causes the palette to get inverted after reading. Provided to allow for
        inconsistencies between Windows and OS/2 programs in how the palette of
        1bpp files should be interpreted.
 invb
        Causes the bitmap bits to get inverted after reading.

 Output

 The this module can write both OS/2 1.1 and OS/2 2.0 / Windows 3.0 style
 bitmaps.

 By default OS/2 2.0 or Windows 3.0 bitmaps are written.

 The OS/2 2.0 / Windows 3.0 style of bitmaps written are written with a header
 size (cbFix) of 40, which is compatible with both Windows 3.0 and OS/2 2.0.

 1.1
        Causes the bitmap to be written OS/2 1.1 style.
 2.0 or win
        Causes the bitmap to be written OS/2 2.0 / Windows 3.0 style.
 inv
        Causes the palette to get inverted before written. Provided to allow
        for inconsistencies between Windows and OS/2 programs in how the
        palette of 1bpp files should be interpreted.
 invb
        Causes the bitmap bits to get inverted before written.
 darkfg
        This is probably the best option to use when writing 1bpp bitmaps. It
        ensures that the darkest colour is represented in the file as 1's (and
        is therefore the foreground), and when the bitmap is reloaded, this
        will come out black.
 lightfg
        As darkfg, but the lightest colour is stored as 1's.

 The newer MultiMedia Windows bitmap format that allows 16 and 32 bpp support
 is not currently supported.

 The Bitmap file format support help panel lists other supported file formats.


ΓòÉΓòÉΓòÉ 2.2. CompuServe Graphics Interchange Format ΓòÉΓòÉΓòÉ

The .GIF file extension is recognised as a GIF file.

Input

1 bpp GIF files are read as 1 bpp data.

2, 3 and 4 bit GIF files are read and returned as 4 bpp data.

5, 6, 7 and 8 bit GIF files are read and returned as 8 bpp data.

GIF files provide no support for 24 bpp images.

Both GIF87a and GIF89a level files may be read.

The code will correctly handle deferred clear-codes in the LZW data stream.
Files with these often break earlier programs that claim to load GIF files.

 index=N
        Can be used to specify which image in the GIF file to read (default
        N=0).
 errok
        If a corrupted or truncated GIF file is encountered, normally an error
        is returned. With this option, as much data as was decoded before the
        error is returned, and no error occurs.

 Output

 The GIF87a style of GIF files are written, and since the GIF standard is
 backwardly compatible, all programs that claim to load GIF files should handle
 the output generated by this program.

 The exception to this is that if the transcol option is used a GIF89a style
 file will be written.

 This program does not generate GIF files with deferred-clear-codes, as these
 have been shown to break many older GIF readers.

 xscreen=N,yscreen=N
        Specifies what values to put in these fields of the GIF file header.
        The default is the image size.
 background=N
        Specifies what background colour index to write in the GIF file header.
        The default is 0.
 xpos=N,ypos=N
        Specifies what values to put in these fields in the GIF file header.
        The defaults are 0 and 0.
 transcol=N
        Specifies that index N designates a transparent colour. This option is
        useful for when you wish to embed GIF files in HTML documents. Using
        this option causes a GIF89a file to be written because the Graphics
        Extension Block holding the transparency information is a part of the
        GIF89a spec., and not the GIF87a.
 transcol=edge
        As above, except transparent colour is the colour of the first pixel in
        the bitmap.
 ilace
        Causes the GIF file to be written interlaced, which can be good for
        those GIF files referenced from HTML documents.

 This code correctly handles 1bpp GIF files. Some programs make incorrect
 assumptions about the initial LZW code table size in the 1bpp case, and so
 fall over. UBU is/was guilty of this.

 This code has been tested on a wide selection of files from a wide variety of
 sources. It has been tested against the output of public domain PPMTOGIF.EXE,
 and tested for compatibility with UNIX X Windows xloadimage and xv.

 The Bitmap file format support help panel lists other supported file formats.

 GIF and 'Graphics Interchange Format' are trademarks (tm) of Compuserve,
 Incorporated, an H&R Block Company.


ΓòÉΓòÉΓòÉ 2.3. ZSoft PC Paintbrush Image Format ΓòÉΓòÉΓòÉ

The .PCX and .PCC file extensions are recognised as a Paintbrush file.

Only a subset of the possible planes/bits-per-plane combinations are supported.

Input

This program reads 1,4,8 and 24 bpp files.

The run-length encoding scheme is supported.

Compressed runs of pixels are not supposed to straddle scan lines. Some other
applications violate this rule. By default, if this code finds that a run of
pixels is longer than the scan line, it will use the leftover pixels on the
next scan line. Some images will not load properly, as they require the loading
program to discard those pixels in the run that extend beyond the end of the
scan line. This behaviour can be enabled using the trunc option.

Output

This program writes 1,4,8 and 24 bpp files, using run-length compression.

It will always ensure run-lengths of pixels do not straddle scan lines.

This code has been tested on some PC Paintbrush originated .PCX files.

The Bitmap file format support help panel lists other supported file formats.


ΓòÉΓòÉΓòÉ 2.4. Microsoft/Aldus Tagged Image File Format ΓòÉΓòÉΓòÉ

The .TIF and .TIFF file extensions are recognised as TIFF files.

There is support to handle 1,4,8 and 24 bpp files.

Input

This program reads uncompressed, Packbits and LZW compressed files.

This code will read all Baseline TIFF 6.0 files, except CCITT Modified Huffman
encoded bi-level files.

 index=N
        Can be used if the file contains more than one image to specify which
        image to read (default N=0 - the first).

 Output

 This program usually writes uncompressed data.

 Data are written in a single large strip.

 Files written by this code are Baseline TIFF 6.0 compliant.

 artist=TEXT
        Causes an Artist tag to be added with text TEXT.
 lzw
        Asks GBM to use LZW compression.
 software=TEXT
        Causes the Software tag to be added with text TEXT.
 make=TEXT
        Causes the Make tag to be added with text TEXT.
 model=TEXT
        Causes the Model tag to be added with text TEXT.
 host=TEXT
        Causes the Host tag to be added with text TEXT.
 documentname=TEXT
        Causes the DocumentName tag to be added with text TEXT.
 pagename=TEXT
        Causes the PageName tag to be added with text TEXT.
 imagedescription=TEXT
        Causes the ImageDescription tag to be added with text TEXT.
 pal1bpp
        Causes 1 bpp data to be written as a palettised file, with 2 palette
        entries. Technically this is not TIFF 6.0 Baseline compliant. The
        default is to write out a bi-level file with the brightest colour as
        white. This is Baseline compliant.

 The TEXT should not include spaces.

 There are 2 well known corruptions of the TIFF format.

 Some TIFF writers write the ColorMap tags length to be 2^N, whereas it should
 be 3*2^N. This code will detect this tag having a bad length, and correct for
 it transparently. UBU is/was guilty of this.

 Some TIFF readers/writers believe that ColorMap entrys are bytes. In fact they
 are words. When reading TIFF files, if this code finds that all the palette
 entrys are in the range 0-255, as opposed to 0-65535, then it multiplys them
 all by 256, thus transparently overcoming the problem. When writing TIFF
 files, this code writes the 8 bit palette entry in both the low and high bytes
 of the tag. Thus programs that look at the high byte work fine. Programs that
 use the full word work fine (the colours get 0.5% brighter). Programs that
 incorrectly look at the bottom byte work fine too. At least one version of
 Image Support is/was guilty of this.

 JPEG compressed data, and data in the Y-Cb-Cr colour space is not supported.

 CCITT G3 Modified Huffman / Facsimile compressed data is not supported.

 The Bitmap file format support help panel lists other supported file formats.


ΓòÉΓòÉΓòÉ 2.5. Truevision Targa/Vista bitmap ΓòÉΓòÉΓòÉ

The following file extensions

  .TGA .VST .AFI

are recognised as Targa/Vista files.

This code can read the uncompressed or run-length compressed Targa/Vista
formats. It will write uncompressed files.

This code only supports 8 bpp and 24 bpp images.

Input

This code will read files with both top-left-origin and bottom-left-origin. Not
all Targa readers correctly handle bottom-left-origin files.

When reading 16 bpp files (which are 5 red + 5 green + 5 blue + 1 alpha), they
are loaded and presented as 24 bpp bitmaps with only the top 5 bits of each of
the 8 bit bytes valid. The bottom 3 bits are zero.

When reading 32 bpp files (which are 8 red + 8 green + 8 blue + 8 alpha), the
alpha channel is ignored.

Output

 yup and ydown
        Causes the data to be written in bottom-left-origin or top-left-origin
        form. The default is bottom-left-origin.
 16
        If the data is 24 bpp, then the 16 flag causes only the most
        significant 5 bits of the red, green and blue to be written in a 16 bit
        pixel.
 24
        Has no effect, as this is the default.
 32
        If the data is 24 bpp, then the 32 flag causes the data to be padded
        with 8 zero bits of alpha channel to make a 32 bit pixel.

 The Bitmap file format support help panel lists other supported file formats.


ΓòÉΓòÉΓòÉ 2.6. Amiga IFF / ILBM Interleaved bitmap format ΓòÉΓòÉΓòÉ

The following file extensions

  .IFF .LBM

are recognised as interleaved bitmap files.

Normally ILBM files are 1,2,3,4 or 5 bpp, because the early Amigas supported
upto 32 colours at once. 6,7, 8 and 24 bpp files are also found nowadays too.

Extra-HalfBrite, or EHB is a mode where N colours have palette entries, but the
file may contain 2*N colours. The second set of N colours are half the
brightness of the first half. In this way, for example, 64 colours may be
displayed on an early Amiga.

Hold-And-Modify, or HAM is a type of screen format where each pixel is either
one of a small number of colours in a palette, or is held the same as the pixel
to its left except that either the red, green or blue is modified. In this way
a much larger range of colours can be displayed.

HAM modes sometimes have fringes down the vertical edges of shapes in the
picture, as sometimes it is necessary to modify the lefthand pixel several
times to get to the desired colour, if a suitable entry is not in the palette.

HAM6 is a HAM mode where there are 16 base palette entries and a possible
maximum of 4096 colours. This is found on early Amigas.

HAM8 is a HAM mode where there are 64 base palette entries and a full 24 bit
range of colours. Also because of the larger palette, fringing is less than in
HAM6. This mode is present on later Amigas.

Sliced-Hold-And-Modify, or SHAM is a mode where the palette is changed on every
(or every other) scan line. This also helps reduce fringing compared to normal
HAM6. SHAM is actually sliced HAM6, and might really be called SHAM6, and SHAM8
is not known to exist.

Input

This code can read files that contain uncompressed or RLE compressed data.

1 bpp files can be read ok.

2,3 and 4 bpp files are read and returned as 4 bpp data.

5,6,7 and 8 bpp files are read and returned as 8 bpp data.

24 bpp files are read and returned as 24 bpp data.

EHB images can be read and are returned as 8 bpp data.

HAM6, HAM8 and SHAM files can be read and are returned as 24 bpp data.

Only the BMHD, CMAP, CAMG and BODY chunks are used when reading the file.

Output

This code can write 1, 4, 8 and 24 bpp files.

24 bpp files can also be written in HAM6 form. This loses quality, but, is
still better than a normal 8 bpp file.

This code writes RLE compressed data, as this usually results in much smaller
files.

Only the BMHD, CMAP and BODY chunks are written to the file. When writing HAM
data, a CAMG chunk is written also.

You can optionally override parts of the BMHD header.

 ham6
        Means write 24 bpp data in HAM6 format, rather than as a true 24 bpp
        file.
 xpos=N,ypos=N
        Overrides the origin information in the file. Defaults are 0,0.
 transcol=N
        Overrides the transparent colour field. Default is 0.
 xaspect=N,yaspect=N
        Overrides the aspect ratio information. Defaults are 1,1. This header
        information is not always honored by ILBM readers.
 xscreen=N,yscreen=N
        Overrides the screen size information. This is not often used by ILBM
        readers. The default is the image size.

 Note that when some early programs try to load an >5 bpp ILBM file, they can
 switch to a 32 colour (5 bpp mode) and only read the 5 least significant
 planes of the file. This generally looks bad.

 This support has been tested using a large range of sample files. But, some
 sample files supplied to the author have yet to be loaded. In particular some
 (24bpp?) DCTV originated files are not yet understood.

 The Bitmap file format support help panel lists other supported file formats.


ΓòÉΓòÉΓòÉ 2.7. YUV12C M-Motion Frame Buffer ΓòÉΓòÉΓòÉ

The .VID file extension is recognised as a YUV12C file.

Although YUV12C files contain 12 bit YUV encoded colour image data, this code
pretends they contain 24 bit RGB encoded colour data.

Input

The files are converted from YUV to RGB data before the data is presented to
the program.

Output

The RGB data is converted to YUV when it is written to disk.

YUV12C files must be a multiple of 4 pixels wide. When trying to write a bitmap
that is not a multiple of 4 pixels wide, this code truncates the last 1, 2 or 3
pixels left over.

 xpos=N,ypos=N
        Overrides the origin information in the file. Defaults are 0,0.

 This support has been tested using the M-Control Program 2.0, Browser sample
 application.

 The Bitmap file format support help panel lists other supported file formats.


ΓòÉΓòÉΓòÉ 2.8. Portable Greyscale-map ΓòÉΓòÉΓòÉ

The .PGM file extension is recognised as a Greymap file.

Credit for file format to Jef Poskanzer.

Only the Binary P5 form of this format is supported.

These files hold no palette information.

Input

The files are returned as an 8 bit image usually with a greyscale palette.

 r,g,b or k
        Forces the image to be read as shades of red, green, blue or grey (the
        default).

 Output

 Normally 8 bpp image data as the greyscale equivelent of the bitmap data.

 r,g,b or k
        Forces the red,green or blue component of the image to be written, or
        alternatively to write the greyscale equivelent (the default).

 The Bitmap file format support help panel lists other supported file formats.


ΓòÉΓòÉΓòÉ 2.9. Portable Pixel-map ΓòÉΓòÉΓòÉ

The .PPM file extension is recognised as a Pixel-map file.

Credit for file format to Jef Poskanzer.

Only the Binary P6 form of this format is supported.

The Portable Pixel-map format is only capable of holding 24 bpp RGB data, and
this code fully supports this.

The Bitmap file format support help panel lists other supported file formats.


ΓòÉΓòÉΓòÉ 2.10. IBM KIPS ΓòÉΓòÉΓòÉ

The .KPS file extension is recognised as a Pixel-map file.

The .KPS file is not enough to define a KIPS image.

The palette is stored in either an associated .PAL or .KPL file.

Input

 pal or kpl
        Tells this code to look for a .PAL or a .KPL file to find the palette
        (default is .PAL)

 Output

 pal or kpl
        Tells this code to write  a .PAL or a .KPL file containing the palette.
        (default is .PAL)

 The Bitmap file format support help panel lists other supported file formats.


ΓòÉΓòÉΓòÉ 2.11. IBM Image Access eXecutive ΓòÉΓòÉΓòÉ

The .IAX file extension is recognised as a IAX file.

This image format does not include a palette or a file header. In particular,
the image file size cannot be determined from the file! This code assumes an
image width of 512 pixels, and determines the image height by dividing the file
size by the width.

The data is presented as a greyscale.

Input

 r,g,b or k
        Forces the image to be read as shades of red, green, blue or grey (the
        default).
 width=N
        Overrides the default assumption that the image width is 512 pixels.

 Output

 Normally 8 bpp image data as the greyscale equivelent of the bitmap data.

 r,g,b or k
        Forces the red,green or blue component of the image to be written, or
        alternatively to write the greyscale equivelent (the default).

 The Bitmap file format support help panel lists other supported file formats.


ΓòÉΓòÉΓòÉ 2.12. X Windows Bitmap ΓòÉΓòÉΓòÉ

The .XBM file extension is recognised as a X Bitmap file.

X Bitmap files are ASCII text files, that look to be directly source
include-able in C programs.

This program is very generous in its parsing of the files.

This program supports X10 and X11 1bpp bitmaps. Some .XBM files with text
strings inside have been encountered. These looked to be sprites or icons and
are not supported.

When reading X Bitmaps, 1's are returned as black, 0's as white.

When writing X bitmaps, the darkest colour is written as 1's, the lightest as
0's.

This code has been tested on some .XBM files.

The Bitmap file format support help panel lists other supported file formats.


ΓòÉΓòÉΓòÉ 2.13. RiscOS Sprite ΓòÉΓòÉΓòÉ

The .SPR and .SPRITE file extensions are recognised as a RiscOS sprite file.
Technically, due to the way the RiscOS works, files don't have extensions. But
for convenience, I have arbitrarily said .SPR, to allow sprites to fit in with
all the other image formats.

Input

This code will read 1,2,4 and 8 bpp files. 2bpp files will be expanded to 4bpp
on reading.

Sprite files can contain an image, or an image and a mask plane. This code will
ignore the mask plane.

If no palette is present in the file, GBM will assume a default palette similar
to that used by the RiscOS Wimp.

There is a limitation in that the first-bit field of the sprite header must be
a multiple of 8 (highly likely).

 index=N
        Can be used if the file contains more than one sprite to specify which
        sprite in the file to read (default N=0 - the first in the file).

 Output

 This code will write 1,4 and 8bpp files.

 A palette will be written into the file.

 Only the image plane is written, ie: no mask plane.

 When outputting 8bpp bitmaps, the usual wierd Archimedes palette is written
 and the bitmap data is mapped to this palette. This is because the Archimedes
 cannot support arbitrary 256 colour palettes. The VIDC chip only has 16
 palette registers, with 16 fixed overrides on (or shades of) each.

 GBM writes 16 palette entries to the file. Sprite files can be found with 64
 palette entries (with 4 overrides on each). However, it is seen that these 64
 palette entries are actually just 16 entries with the 4 overrides on each.
 Hence this is equivelent to 16 entries with 16 overrides, except some of the
 overrides are explicitly stored in the file.

 Tested reading 4bpp sprites with no palette.

 Tested reading 8bpp sprites with no palette and with 64 entry palette.

 Sprites generated by GBM have been loaded on RiscOS. Remember: Use SetType to
 change type of file from PC-file to Sprite, by SetType option of filer menu or
 "*SetType <filename> Sprite".

 The Bitmap file format support help panel lists other supported file formats.


ΓòÉΓòÉΓòÉ 2.14. IBM Printer Page Segment ΓòÉΓòÉΓòÉ

The following file extensions

  .PSE .PSEG .PSEG38PP .PSEG3820

are recognised as PSEG files.

PSEG files are used as a way to include image data in SCRIPT documents.

PSEG files only contain 1bpp data, which is always ink on paper, ie: black on
white.

Input

PSEG files should be downloaded from the host in binary mode. No EBCDIC/ASCII
conversion should be used in the download process.

The palette is always returned as black 1's on white 0's, because PSEG files do
not include any palette.

 fixrec
        Some PSEG files have been observed to have shorter records than
        specified in the length field (2nd and 3rd bytes) of a record. Although
        this doesn't matter when on VM, it can confuse non-VM readers, such as
        GBM. GBM can be told to attempt to compensate for this corrupt record
        structure using the fixrec option.

 Output

 When writing PSEG files, any colour palette is lost.

 The resulting file is a binary file and should be uploaded to a VM machine as
 such. No EBCDIC/ASCII conversion should be used. However, on a VM host, the
 record structure of a PSEG is necessary for it to be correctly interpreted by
 the VM tools. On non VM systems, files do not have a record structure.
 Therefore after uploading, the PSEG files must be 'fixed'. You need a tool,
 like FIXL3820 EXEC to do this. Basically, each PSEG files record starts with a
 0x5a character, and this can be used to delineate records.

 PSEG files are a multiple of 8 pixels wide, so this code writes a file with
 the width the next multiple of 8 pixels wide. The right edge is padded with
 white pixels.

 double
        There is a scale factor in the PSEG header. By specifying this option,
        the scale factor is written as double the usual value.

 The Bitmap file format support help panel lists other supported file formats.


ΓòÉΓòÉΓòÉ 2.15. GEM Raster ΓòÉΓòÉΓòÉ

Files with the .IMG extension are recognised as GEM Raster files.

The GEM Raster file format is an old format, found primarily on the Atari
platform.

It has a basic flavor in which :-

      1 bpp bitmaps can only be black and white.

      4 bpp bitmaps can only use a fixed 'standard' palette, or be greyscale.

      2,3,5,6,7 and 8 bpp bitmaps can only be greyscale.

      24 bpp bitmaps are not supported.

 In addition there are XIMG extensions to the format :-

      1-8 bpp bitmaps can contain a palette.

      24 bpp bitmaps are now allowed.

 Input

 This code can read all of the above, with the usual proviso that 2 and 3 bpp
 are rounded up to 4 bpp, and 5,6 and 7 bpp are rounded up to 8.

 Output

 GBM will write all the above formats, and where there are choices, the
 following options can be used :-

 grey
        GBM writes 4 bpp files by mapping them to the standard palette by
        default. The non default behaviour of mapping to a grayscale can be
        enabled by this flag.
 pal
        When writing 4 or 8 bpp files, this option tells GBM to write an XIMG
        format file with the palette included.
 pixw=N,pixh=N
        This overrides the default pixel dimensions in the header. The default
        is 85 by 85 microns.

 Note that Image Alchemy 17 appears to assume a different standard 16 colour
 palette when converting to GEM Raster format. This disagrees with all the
 testcase images currently encountered.

 The Bitmap file format support help panel lists other supported file formats.


ΓòÉΓòÉΓòÉ 2.16. Portrait ΓòÉΓòÉΓòÉ

Files with the .CVP extension are recognised as Portrait files.

These files hold a single 512x512 24bpp RGB image. Some photographers in
Germany hand you a disk containing a .CVP file when you get your passport
pictures taken. You can return later with the disk and get further prints made.

Now with GBM supporting this format, you can convert to and from other file
formats and use paintbox programs to remove those ugly pimples...

Pixels are not square in this file format, so images when loaded appear
horizontally stretched. GBM leaves it up to the user to rescale the image to
look nice. Scaling horizontally by a factor somewhere between 0.75 and 0.8
gives a pleasing effect.

Of course, it is important to remember that Portrait files only hold 512x512
images, and if you take an image from elsewhere and convert to Portrait, the
image will be printed thinner at the photographers due to this non-square-pixel
problem.

The Bitmap file format support help panel lists other supported file formats.


ΓòÉΓòÉΓòÉ 2.17. JPEG ΓòÉΓòÉΓòÉ

The following file extensions

  .JPG .JPEG .JPE

are recognised as JPEG files.

Technically it is the JFIF type of JPEG files which are supported.

8 bpp (greyscale) and 24 bpp files may be read.

Only 24 bpp data may be written.

Output

Bitmaps can be written with varying degrees of quality (ie: degrees of
lossyness of the compression). They can also be written in a simple progressive
manner.

 quality=Q
        Causes the file to be written at quality Q, where Q is a rather
        arbitrary measure. Q can be in the range 0 to 100, with a reasonable
        default of 75.
 prog
        Causes the file to be written as a progressive JPEG.

 GBM can be compiled up either with or without support for JPEG. If you don't
 see JPEG amongst the list of supported file formats on the File Open dialog
 box, then you are using a GBM.DLL without support.

 The JPEG support for GBM is provided by the Independant JPEG Groups JPEGLIB
 library, version 6a. It may be freely used provided the IJG are credited
 (hence its use in GBM, and this paragraph in the online help).

 The code to interface GBM to IJG 6a was written by Mark Lisowski
 <[e-mail]>. I have made a couple of minor
 modifications.

 The Bitmap file format support help panel lists other supported file formats.


ΓòÉΓòÉΓòÉ 2.18. Others ΓòÉΓòÉΓòÉ

Support for all the bitmap file formats may be added at any time, without
application writers being aware of it.

Any new formats will be listed in the dialog filetype combobox, although the
help may not (yet) have an entry for them.

The Bitmap file format support help panel lists other supported file formats.