PrevTable of Contents Index Glossary Op Index Next 

§ 29 - ELF File Format Information (.elf)

§ 29.1 - 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:

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 have made 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.

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.

§ 29.2 - Technical Description, ELF Version 2 (ELF-2)

§ 29.2.1 - 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).

§ 29.2.2 - 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.

§ 29.2.3 - File Integrity

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

§ 29.2.3.1 - 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.

§ 29.2.3.2 - 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.

§ 29.2.4 - Format Details

§ 29.2.4.1 - 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.

§ 29.2.4.2 - 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.

§ 29.2.4.3 - 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.

§ 29.2.4.4 - 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 its own length and data block.

 Note:

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:

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 - inverted 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 (visible) #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 };

§ 29.3 - Technical Description, ELF Version 1 (deprecated, superceded)

 Note:

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), in that order. 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:

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 };
Keyboard Navigation
, Previous Page . Next Page t TOC i Index o Operators g Glossary
 PrevTable of Contents Index Glossary Op Index Next 
WinImages F/x, 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 6, Level A

Valid HTML 4.01 Loose
 

This manual was generated with wtfm
wtfm uses aa_macro and SqLite
aa_macro uses python 2.7
Page 411
box