Page 355
Quick Nav Bar
<<   Previous Contents
Selection
Op Index
Parent User Notes
Index
Glossary
Next   >>


ELF File Format Information (.elf)

General - Versions 1 and 2

ELF is a highly advanced layered image format designed by Black Belt Systems to support its WinImages products.

Although other layered image file formats exist (e.g., Photoshop ®'s ".PSD" format), they presuppose a number of defined layer mode behaviors, and in some cases do not allow for layers of a size not equal to a base layer. They all define a comparatively limited total number of layer modes. Some formats also require a base layer, or imply one. Additionally, many previously defined layered formats offer very poor image data compression, resulting in overweight filesizes that unnecessarily waste filesystem space.

Note:

Keep this in mind...
Generally speaking, in the image manipulation software community, it is considered "not a good idea" to define a new file format unless you really have a good reason, or reasons. Well, we did: We knew for certain that any combination of the above-described problems would severely cripple the capabilities of WinImages' layered image handling.

So we created a brand new format to ensure that WinImages's layering may be as flexible as possible and may grow and develop completely unfettered by previous application's various design issues and limitations. Since at this time we can show that WinImages' layered image handling is demonstrably superior in almost every way to other high-end image applications, we see the creation of this format as having been completely justified.

We are making many details available on ELF so that software developers may, if they so choose, implement a reasonable level of support for the file format. This is offered freely to the developer community, regardless of shareware, freeware or commercial application implementations.

Note:

Keep this in mind...
Warp layer technology is not available for free use outside of Black Belt Systems at this time, though it may be licensed. Please see this legal notice.

We only require that any person or company publishing an application with ELF support let us know that your application will read and/or write ELF files. We can then make you aware any time the specification is advanced, and you can then make an informed decision about keeping your application up to date. We'll also be very pleased to list your application both in the shipping documentation and the network-level documentation. It is our belief that such cooperation helps everyone.

We will make a sincere effort to keep this information up to date. The latest specification may be viewed at:

http://www.blackbeltsystems.com/bx_elf.html

To let us know that you have implemented support for ELF, email support

Technical Description, ELF Version 2 (ELF-2)

Endian-ness

ELF-2 is "Big Endian". MS byte first, LS byte last, MS word first, MS word last. This means that the HEX number 0x01234567 would be represented in the file by a stream of bytes in this order:

<-- beginning of file  
 0x01 0x23 0x45 0x67
  end of file -->

When reading and writing ELF-2 files, care must be taken to arrange the long (signed 32 bit) variables in the Big-endian order. Byte entities are read one at a time, and are in the correct order, they need no correction on any platform as long as they are read one byte at a time. (char arrays, the CO structs).

General Structure

ELF-2 files are sequences of RGBA image layers, nearest to deepest ordered, which combine to form a master image of the dimensions specified in the elf_header structure. All layers have alpha (not just a place for it, they actually have an alpha mask for each set of R,G, and B layers). Layers may be any size at all, larger, the same as, or smaller than the master image in either or both dimensions. Because layers may be any size, there can be areas where layers do not overlay previous layers. Where layers do not overlap, full transparency is assumed. ELF-2 files do not implement "channels" though channelized software can reconstruct much of an ELF-2 file by developing R, G, B and A channels linked as layers. Similarly, WinImages implements Photoshop ® "blend" channels by turning them into Grey Mask layers - "There's more than one way to skin a file format!"

Channel data is 0-255 R,G,B,A (red, green, blue, alpha). Zero alpha is fully transparent, 255 alpha is fully opaque. String data is zero-delimited. Aspect data is handled as, numerator, denominator. You must convert it to DPI via:

// non_zero(n) returns 1 for zero, otherwise unchanged
// ----------------------------------------------------
x_dpi = x_dpi_num/non_zero(x_dpi_den);
y_dpi = y_dpi_num/non_zero(y_dpi_den);
// ----------------------------------------------------

Because of the defined DPI conversion, it is acceptable to place DPI directly into the numerator variables, and 1, or zero, into the denominator variables. Since zeros are coverted to one's, it's the same thing after correctly reading the file.

File Integrity

A number of mechanisms exist to ensure that reading ELF files goes in a predictable, replicable manner:

Magic Numbers

First, the file format provides magic numbers, and they must be used to ID the file. Extension is not sufficient. Readers must check both the number in the header and the number in each layer structure.

Version Numbering

Second, ELF-2 files (and ELF files) have a version number; 2 for ELF-2 and 1 for ELF. Readers must read this number and match it against their internal capabilities. ELF readers will not be able to read ELF-2 files without additional heuristics.

Format Details

Layer Offsets

Offsets of zero in non-local layers indicate that layers line up with the master image at the upper left hand corner. Positive X and Y offsets indicate offset left and down into the master image, respectively. Local layers develop offsets from the upper left of the base layer in the local stack; the base layer in turn is offset from the master.

Scan Line Ordering

In the publicly documented compression formats, image data is stored top of image to bottom of image, in scanlines of all red, followed by all green, followed by all blue, followed by all alpha.

Pixel ordering within scan lines

In the publicly documented compression formats, image data is stored left to right. Pixels at the left side of the image are encountered first when reading or decompressing image scanline data.

Compression

There are three supported compression modes, and an uncompressed mode. Two modes are public, one is proprietary. WinImages allows the proprietary high compression mode to be turned off so that ELF files may be saved in a format that external applications can read.

The first public format uses ZLIB's INFLATE and DEFLATE compression methods. This compression mode is indicated by a compression flag value of ELF_ZCOMP.

The second public format (and the one that seems to work best) is a type of RLE. This compression uses a single signed byte to flag runs or block copies; this same byte is also a duplicate or copy count. This compression mode is indicated by a compression flag value of ELF_RLECOMP.

The third, proprietary format is undocumented as to method, but is detailed enough so that such blocks can be skipped in a defined manner. This compression mode is indicated by a compression flag value of ELF_TCOMP.

Finally, ELF layers can stored uncompressed. This is indicated by a flag value of ELF_NOCOMP.

ELF_ZCOMP Compression Description
This compression mode is implemented using ZLIB, version 1.1.3, July 9th, 1998. The deflation algorithm used by gzip (also zip and zlib) is a variation of LZ77 called "deflate" along with a matching decompressor called "inflate." Scan lines are stored with a big-endien 4-byte length of the compressed data prior to the compressed data itself, then the compressed data follows. Each of the R,G,B and A chunks has it's own length and data block.

Note:

Keep this in mind...
Some testing (not very extensive, perhaps 25 images) has indicated that not only is DEFLATE/INFLATE definitely quite a bit slower than ELF_RLECOMP compression and decompression, it usually will result in a significantly larger file as well. For this reason, R6 writes RLE compressed ELF files only in the non-high compression mode, though it can read both RLE and DEFLATE types of compression for compatibility's sake.

ELF_RLECOMP Compression Description
If the byte read is positive, then copy that many more bytes verbatim from the incoming byte stream into the channel.

For instance, if an 0x03 is encountered, then the next three bytes are to be read into the channel. Before inserting the data in the channel, check for channel overrun error by count + total bytes generated thus far, and if not overrun, read the three bytes, and increase the channel position. check for end of channel, and if not end of channel, load another flag byte.

If the flag is negative, this indicates that you will be duplicating the next byte.

For example, you read a -4 as the flag byte. To determine how many times to duplicate the byte, negate it (-4 becomes 4) and add one, so that you would now have 5. Be aware that this is not "complement and add one", it is negate and add one. Before inserting the data in the channel, check for channel overrun error by count + total bytes generated thus far, and if not overrun, read the next byte from the file, and insert 5 copies of that byte into the channel. Check for end of channel (x width) and if not reached, read the next flag byte.

No compressed run extends beyond a scan line component, for instance the red could be a single run, but the green will be a new run.

ELF_TCOMP High Compression Mode
This compression mode begins with a 4-byte chunk size, followed by that many bytes of data in a proprietary format. If you encounter an ELF_TCOMP compressed layer, read the four byte chunk size into a SIZE variable, and then discard the next SIZE number of bytes. Fill the layer with white RGB data and 100% transparent (0) alpha information. This layer is not readable outside of WinImages' applications.

ELF_NOCOMP Uncompressed Data Description
Uncompressed layers are just that, completely uncompressed. Channel data for a width of 320 pixels will contain 320 red bytes immediately followed by 320 green bytes, 320 blue bytes, and finally 320 alpha bytes.

Note:

Keep this in mind...
Compression is specified per-layer. It is possible for an .elf file to contain a mix of compressed and non-compressed layers, and that the compression mode types themselves are mixed. Why? Because the compression modes used cannot guarantee to produce a compressed output, especially from "noisy" source data. This allows applications to store uncompressed layers in place of compressed layers when the compression results in output larger than input, and it also allows an application to pick the compression mode that results in the highest data compression. For this reason, readers must always support all implemented public compression modes. If a minimal ELF writer is to be designed, the best single choice for compression is ELF_RLECOMP.

Application behavior of testing compressed results before committing to a compressed representation is optional, but recommended. An additional benefit of this approach is that image loading may also be faster when uncompressed versions of noisy sources are stored.

When reading the image, the morelayers flag will be one as long as there are additional layers to read. A zero morelayers means you're about to read the last layer. So if the first morelayers is zero, there is only one layer in the image.

Mode tells you how to rebuild the composite master image. See the #defines below. If the image contains modes that are not described here, it will have a new version number; that lets your reader know it can't deal with the .ELF file properly. Observe the version number!

Opacity essentially is a second, global, alpha for the layer.

Visible is a switch. 1 means it is visible, 0 means it's not used to display the final image.

Color1 and color2 are RGBA entities that will be used in future layer modes, not yet implemented in version 1.

In ELF, there is no "base" layer; instead, a master view is generated that is created from the layers in the .elf file. In this way, the problems that predefined base layers incur are completely avoided.

There is no gamma component predefined, as that is a local issue for the monitor/room combination, properly decided by the user of the software displaying the file, if indeed such amenities are available. Similarly, there are no chromasticities defined.

The general structure of a 5-layer ELF version 2 file looks like this:

elf_header block (master image defined here - there is no image data)
elf_layer block (topmost layer)
RGBA channel data
elf_layer block...
RGBA channel data
elf_layer block...
RGBA channel data
elf_layer block...
RGBA channel data
elf_layer block (deepest layer)
RGBA channel data



#define ELF_MAGIC 0x1BAB00FE
#define ELF_MAJIC 0x62951413

#define ELF_NOCOMP  0
#define ELF_RLECOMP 1
#define ELF_ZCOMP   2
#define ELF_TCOMP   3

#define LMD_NORM   0   // overlay layer on sublayer composite
#define LMD_ADDN   1   // add layer to sublayers, limit at 255
#define LMD_ADDG   2   // add layer channeldata-127 to sublayer composite, limit at 0 and 255
#define LMD_MULT   3   // layer multiplies sublayer composite
#define LMD_DIFF   4   // subtract layer from sublayer composite, limit at 0
#define LMD_ADIF   5   // subtract layer from sublayer composite, "wrap" around 0 to 255
#define LMD_MASK   6   // use layer alpha channel only as mask
#define LMD_BRIT   7   // 0-255 layer channel is amount of remaining brightness increase
#define LMD_DARK   8   // 0-255 layer channel is amount of remaining darkness increase
#define LMD_COLR   9   // apply layer hue to sublayers
#define LMD_SCOL  10   // apply layer hue & saturation to sublayers
#define LMD_VALU  11   // apply layer value to to sublayers
#define LMD_CNEG  12   // mix color negative of sublayers to themselves using channel amplitude
#define LMD_MNEG  13   // mix monochrome negative of sublayers to themselves using channel amplitude
#define LMD_MONO  14   // mix RGB average of sublayers to themselves using channel amplitude
#define LMD_IMSK  15   // Inverted mask from alpha channel only - RGB ignored
#define LMD_WARP  16   // See Legal Notice Read in, write out. Do not change data!
#define LMD_REDC  17   // Replace red channel with this layer's red channel
#define LMD_GRNC  18   // Replace green channel with this layer's green channel
#define LMD_BLUC  19   // Replace blue channel with this layer's blue channel
#define LMD_MAXC  20   // Replace all channels with the maximum of R, G or B at each pixel
#define LMD_SCRN  21   // Screen mode
#define LMD_OVLY  22   // Overlay mode
#define LMD_HDLT  23   // Hard Light mode
#define LMD_DYE   24   // Dye - doubly saturated colorize
#define LMD_MINI  25   // Minimum of channel or underlying layer composite
#define LMD_MAXI  26   // Maximum of channel or underlying layer composite
#define LMD_ADBR  27   // Adjust brightness - 0=128, 128+ is increase, 127- is decrease
#define LMD_ADCN  28   // Adjust contrast - 0=128, 128+ is increase, 127- is decrease
#define LMD_ADHU  29   // Adjust hue - 0=128, 128+ is increase, 127- is decrease
#define LMD_ADSA  30   // Adjust saturation - 0=128, 128+ is increase, 127- is decrease
#define LMD_LIGH  31   // Lighten mode
#define LMD_GMSK  32   // Grey Mask - layer luma masks underlying layer composite
#define LMD_GMSI  33   // Inverted Grey Mask - invertedd layer luma masks underlying layer composite
#define LMD_GKEY  34   // Grey key - layer data keys to luma of composite as mask
#define LMD_GKYI  35   // Inverted grey key
#define LMD_GKYN  36   // Soft Grey key - transparency is difference from key
#define LMD_GKNI  37   // Inverted Soft Grey key - transparency is difference from key
#define LMD_CKEY  38   // Color key - transparency is non-match of RGB data
#define LMD_CKYI  39   // Inverted Color Key
#define LMD_CKYN  40   // Soft Color Key - transparency is difference from RGB key
#define LMD_CKNI  41   // Inverted soft color key
#define LMD_HKEY  42   // Hue Key - you know the drill
#define LMD_HKYI  43   // Inverted Hue Key
#define LMD_HKYN  44   // Soft Hue Key
#define LMD_HKNI  45   // Inverted soft hue key
#define LMD_SKEY  46   // Hue and Saturation key
#define LMD_SKYI  47   // Inverted hue and saturation key
#define LMD_SKYN  48   // Soft hue and Saturation Key
#define LMD_SKNI  49   // Inverted soft hue and saturation key
#define LMD_MINC  50   // Minimum of R, G or B
#define LMD_SATU  51   // Transfer saturation to underlying layer composite
#define LMD_SFLT  52   // Soft Light mode
#define LMD_DSLV  53   // Dissolve mode - if rdm key is off, transparency is 100%
#define LMD_SDSL  54   // Soft Dissolve - if rdm key is off, transparency is sublayer #define LMD_CYAN  55   // Add as Cyan (subtractive color space mode)
#define LMD_MAGE  56   // Add as Magenta (subtractive color space mode)
#define LMD_YELL  57   // Add as Yellow (subtractive color space mode)
#define LMD_BLAC  58   // Add as Black (subtractive color space mode)
#define LMD_AND   59   // Logical AND
#define LMD_OR    60   // Logical OR
#define LMD_XOR   61   // Logical XOR
#define LMD_NAND  62   // Logical NAND
#define LMD_NOR   63   // Logical NOR
#define LMD_XNOR  64   // Logical XNOR
#define LMD_LUMA    65 // Replace luma information
#define LMD_EXCL    66 // soft absolute subtract
#define LMD_HUE     67 // Replace hue information
#define LMD_DODGE   68 // photographic develop operation emulation
#define LMD_DIVIDE  69 // opposite of mulitply
#define LMD_BEHIND  70 // transfer like matte where layere is transparent
#define LMD_EXPRESS 71 // softer version of dodge
#define LMD_BURN    72 // photographic develop operation emulation

struct CO
{
    unsigned char r,g,b,a;
};

struct elf_header
{
    long        magic;            // magic number # 1 (ELF_MAGIC = 0x1BAB00FE)
    long        version;          // versions 1 & 2 defined; any other number, cannot read
    char        base[256];        // basename of master
    char        anno[256];        // annotation
    char        auth[256];        // author information
    char        copy[256];        // copyright information
    char        soft[256];        // software that wrote the file
    long        xdim;             // width of master view
    long        ydim;             // height of master view
    long        dpixn;            // DPI X numerator (applied only to master view)
    long        dpixd;            // DPI X denominator
    long        dpiyn;            // DPI Y numerator
    long        dpiyd;            // DPI Y denominator
    long        layerordinal;     // total layers generated thus far (used in new layer numbering)
};

struct elf_layer // for version 2
{
    long        majic;            // majic number # 2 (ELF_MAJIC = 0x62951413)
    char        name[256];        // name of layer
    long        xdim;             // width (xmax-1) of layer
    long        ydim;             // height (ymax-1) of layer
    long        xoffset;          // horz layer offset
    long        yoffset;          // vert layer offset
    long        layernumber;      // number of this layer (do not use to order!)
    long        compression;      // Compression type. 0=none, 1=rle, 2=zlib, 3=proprietary
    long        morelayers;       // flag - if 0, this is the last layer to read
    long        mode;             // layer mode 0=normal, 1... are additional recomb. modes
    long        visible;          // layer visibility 0/1 for version 1 files
                                  // for version 2:
// ------------------------------------------------------
#define ELF_F_VISI   1            // layer is enabled
#define ELF_F_LOCL   2            // layer is local stack to layers below
#define ELF_F_GMSK   4            // layer has global mask enabled
#define ELF_F_ZOOM   8            // layer has a zoom integrated into its warp (1 only!)
#define ELF_F_ROTA  16            // layer has a rotation integrated into its warp (1 only!)
#define ELF_F_LOCP  32            // layer is in movement lockstep with layers below it
#define ELF_F_WWRP  64            // MUST BE ZERO
// ------------------------------------------------------
    long        opacity;          // opacity, lower 16 bits for version 2, 0-100
                                  // upper 16 bits is factor from 0 to 30,000 for version 2 only
    struct CO   color1;           // color one for drawing - unused in v1 and v2 files
    struct CO   color2;           // color two for drawing - unused in v1 and v2 files
};




Technical Description, ELF Version 1 (deprecated, superceded)

Note:

Keep this in mind...
ELF, or ELF-1, is a compatible subset of ELF-2. A properly implemented ELF-2 reader can read ELF-1 files with no trouble, and no special casing, because all new field uses are either set to zero with compatible meaning of zero, or values represented in an ELF-1 file mean the same thing in an ELF-2 file. ELF-2 files, however, cannot be read by an ELF-1 reader, as modes exist that will not translate properly without additional flags that do not make it through ELF-1 flag filtering, layer modes and mechanisms exist in an ELF-2 file that cannot be understood by an ELF-1 reader, and layers may be stored in previously unknown compression states.

ELF is "Big Endian". MS byte first, LS byte last, MS word first, MS word last. This means that the HEX number 0x01234567 would be represented in the file by a stream of bytes in this order:

0x01 0x23 0x45 0x67

When reading and writing ELF files, care must be taken to arrange the long (signed 32 bit) variables in the Big-endian order. Byte entities are read one at a time, and are in the correct order, they need no correction on any platform as long as they are read one byte at a time. (char arrays, the CO structs).

ELF files are sequences of image layers, nearest to deepest ordered, which combine to form a master image of the dimensions specified in the elf_header structure. All layers have alpha (not just a place for it, they actually have masks). Layers may be any size at all, larger, the same as, or smaller than the master image in either or both dimensions. Because layers may be any size, there can be areas where layers do not overlay previous layers. Where layers do not overlap, full transparency is assumed.

Channel data is 0-255 R,G,B,A (red, green, blue, alpha). Zero alpha is fully transparent, 255 alpha is fully opaque. String data is zero-delimited. Aspect data is handled as, numerator, denominator. You can convert it to DPI via:

x_dpi=xdpin/non_zero(xdpid); // non_zero returns 1 for zero, otherwise unchanged
y_dpi=ydpin/non_zero(ydpid); // non_zero returns 1 for zero, otherwise unchanged

The file format provides magic numbers, and they must be used to ID the file. Extension is not sufficient.

Offsets of zero indicate that images line up at the upper left hand corner. Positive offsets indicate offset into the image.

Image data is stored top of image to bottom of image, in scanlines of all red, followed by all green, followed by all blue, followed by all alpha.

Compression is a type of RLE. This compression uses a single signed byte to flag runs or block copies; this same byte is also a duplicate or copy count.

If the byte read is positive, then copy that many more bytes verbatim from the incoming byte stream into the channel.

For instance, if an 0x03 is encountered, then the next three bytes are to be read into the channel. Before inserting the data in the channel, check for channel overrun error by count + total bytes generated thus far, and if not overrun, read the three bytes, and increase the channel position. check for end of channel, and if not end of channel, load another flag byte.

If the flag is negative, this indicates that you will be duplicating the next byte.

For example, you read a -4 as the flag byte. To determine how many times to duplicate the byte, negate it (-4 becomes 4) and add one, so that you would now have 5. Be aware that this is not "complement and add one", it is negate and add one. Before inserting the data in the channel, check for channel overrun error by count + total bytes generated thus far, and if not overrun, read the next byte from the file, and insert 5 copies of that byte into the channel. Check for end of channel (x width) and if not reached, read the next flag byte.

No compressed run extends beyond a scan line component, for instance the red could be a single run, but the green will be a new run.

Uncompressed layers are just that, completely uncompressed. Channel data for a width of 320 pixels will contain 320 red bytes immediately followed by 320 green bytes, 320 blue bytes, and finally 320 alpha bytes.

Note:

Keep this in mind...
Compression is specified per-layer. It is possible for an .elf file to contain a mix of compressed and non-compressed layers. Why? Because RLE does not always produce a compressed output, especially from "noisy" source data. This allows applications to store uncompressed layers in place of compressed layers when the RLE compression results in output larger than input.

This application behavior is optional, but recommended. An additional benefit is that image loading is also faster when uncompressed versions of noisy sources are stored.

When reading the image, the morelayers flag will be one as long as there are additional layers to read. A zero morelayers means you're about to read the last layer. So if the first morelayers is zero, there is only one layer in the image.

Mode tells you how to rebuild the composite master image. See the #defines below. If the image contains modes that are not described here, it will have a new version number; that lets your reader know it can't deal with the .ELF file properly. Observe the version number!

Opacity essentially is a second, global, alpha for the layer.

Visible is a switch. 1 means it is visible, 0 means it's not used to display the final image.

Color1 and color2 are RGBA entities that will be used in future layer modes, not yet implemented in version 1.

In ELF, there is no "base" layer; instead, a master view is generated that is created from the layers in the .elf file. In this way, the problems that predefined base layers incur are completely avoided.

There is no gamma component predefined, as that is a local issue for the monitor/room combination, properly decided by the user of the software displaying the file, if indeed such amenities are available. Similarly, there are no chromasticities defined.

The general structure of a 5-layer ELF version 1 file looks like this:

elf_header block (master image defined here - there is no image data)
elf_layer block (topmost layer)
RGBA channel data
elf_layer block...
RGBA channel data
elf_layer block...
RGBA channel data
elf_layer block...
RGBA channel data
elf_layer block (deepest layer)
RGBA channel data



#define ELF_MAGIC 0x1BAB00FE
#define ELF_MAJIC 0x62951413

#define ELF_NOCOMP	0
#define ELF_RLECOMP	1

#define LMD_NORM 0    // overlay layer on sublayer composite
#define LMD_ADDN 1    // add layer to sublayers, limit at 255
#define LMD_ADDG 2    // add layer channeldata-127 to sublayer composite, limit at 0 and 255
#define LMD_MULT 3    // layer multiplies sublayer composite
#define LMD_DIFF 4    // subtract layer from sublayer composite, limit at 0
#define LMD_ADIF 5    // subtract layer from sublayer composite, "wrap" around 0 to 255
#define LMD_MASK 6    // use layer alpha channel only
#define LMD_BRIT 7    // 0-255 layer channel is amount of remaining brightness increase
#define LMD_DARK 8    // 0-255 layer channel is amount of remaining darkness increase
#define LMD_COLR 9    // apply layer hue to sublayers
#define LMD_SCOL 10   // apply layer hue & saturation to sublayers
#define LMD_VALU 11   // apply layer value to to sublayers
#define LMD_CNEG 12   // mix color negative of sublayers to themselves using channel amplitude
#define LMD_MNEG 13   // mix monochrome negative of sublayers to themselves using channel amplitude
#define LMD_MONO 14   // mix RGB average of sublayers to themselves using channel amplitude

struct CO
{
    unsigned char r,g,b,a;
};

struct elf_header
{
    long        magic;            // magic number # 1 (ELF_MAGIC = 0x1BAB00FE)
    long        version;          // versions 1 & 2 defined; any other number, cannot read
    char        base[256];        // basename of master
    char        anno[256];        // annotation
    char        auth[256];        // author information
    char        copy[256];        // copyright information
    char        soft[256];        // software that wrote the file
    long        xdim;             // width of master view
    long        ydim;             // height of master view
    long        dpixn;            // DPI X numerator (applied only to master view)
    long        dpixd;            // DPI X denominator
    long        dpiyn;            // DPI Y numerator
    long        dpiyd;            // DPI Y denominator
    long        layerordinal;     // total layers generated thus far (used in new layer numbering)
};

struct elf_layer // for version 1
{
    long        majic;            // majic number # 2 (ELF_MAJIC = 0x62951413)
    char        name[256];        // name of layer
    long        xdim;             // width (xmax-1) of layer
    long        ydim;             // height (ymax-1) of layer
    long        xoffset;          // horz layer offset
    long        yoffset;          // vert layer offset
    long        layernumber;      // number of this layer (do not use to order!)
    long        compression;      // Compression type. 0=none, 1=rle
    long        morelayers;       // flag - if 0, this is the last layer to read
    long        mode;             // layer mode 0=normal, 1... are additional recomb. modes
    long        visible;          // layer visibility 0/1 for version 1 files
    long        opacity;          // opacity, lower 16 bits for version 1, 0-100
    struct CO   color1;           // color one for drawing - these are unused in v1 and v2 files
    struct CO   color2;           // color two for drawing
};


Quick Nav Bar
<<   Previous Contents
Selection
Op Index
Parent User Notes
Index
Glossary
Next   >>
Page 355

WinImages F/x, WinImages Morph and all associated documentation
Copyright © 1992-2007 Black Belt Systems ALL RIGHTS RESERVED Under the Pan-American Conventions

WinImages F/x Manual Version 7, Revision 5, Level B

HTML Documentation Management System © 1992-2007 Black Belt Systems