|
LaserBoy
Linux Laser Projector
|
|
The ILDA Image Data Transfer Format Is currently undergoing changes to extend the long standing definitions of data structures for storing color vector art data in a non-platform specific binary file.
The purpose of the proposed addition is to allow for every point in a vector image to have its own, possibly unique, 24-bit color definition.
Before any revisions were applied to the file format, it was only possible to have a palette of up to 256 unique colors per frame and depending on the individual interpretation or implementation of the original format, some of those colors might have to be set to black, white, grey, etc.
Most of the ILDA files that are floating around out there now use a default palette, that is not defined in the file. It is assumed that if there is no palette defined in the file, a default palette of 62 colors plus black should be used. The very first image on this page uses this palette.
There are three traditional sections in the ILDA file format.
- 3D vector image with 1 byte color palette indexes
- 2D vector image with 1 byte color palette indexes
- single byte indexed palette (256 colors or less)
Each of these section types is represented in the file as a uniform, 32-byte, section header followed by appropriately formatted data. The amount of data, measured in bytes, that follows is calculated as the number of elements times the number of bytes in each element. Any number of sections can be stored consecutively in the file and they are considered to be in the natural order in which they appear in the file.
There are three different individual elements that make up the data chunks that fallow each section header:
- a single 3D point in a vector image takes 8 bytes
- a single 2D point in a vector image takes 6 bytes
- a single color in a palette takes 3 bytes (RGB)
An unfortunate short-sight exists here. There is no way to know how much data follows a section without knowing exactly how big each element of that data type is. This might not seem important, but it seals the fate of this format as being impossible to write code that can read it that will survive with ANY backward compatibility to ANY new revision to the specification.
There is no way to reliably skip over a section of an unknown kind because there is no way to know how big it is.
It would have been better to store an actual byte count in the headers of each section. That way a file reader could just jump that many bytes past any unrecognized section in a file that contains section types that were added to the file format after the file reader was designed.
As it is, the uniform ILDA section header contains a 16-bit unsigned short integer for "quantity". This number can represent anything from zero to 65,535 elements of arbitrary size.
The logical conclusion is that nothing can be added to the format specification without breaking every program ever written to read the old standard version.
The rational choice here is to either freeze the current ILDA file format as it is and create a totally new 24-bit standard, designed to be more robust and extensible, or to go on with the functionality and structure of the current design, which actually works just fine.
Someone within ILDA realized that a variation on the palette section, that was already part of the file format, could serve as a forth section type; a natural order 24-bit color table. This color table could have any number of colors defined in it such that there would be exactly one color for each point defined in the next section of the file; which, necessisarily, had to be a vector image of 3D or 2D points.
This is a great solution! Now we can have the 24 bits of color we want for each point in the vector drawing.
For some reason, the proposed new ILDA standard describes a new, non-uniform section header. It is not just another 32-byte section header like the other three.
The new section header is only 16 bytes. The first 8 bytes match the same format as the first 8 bytes of the original standard section header. But, this is followed by two 32-bit integers; one for data length in bytes and one for number of colors.
If we know enough about the file we are reading to recognize this different header, then we certainly know that the size of each color in the data that follows is 3 bytes each. So, storing both number of elements and size of data is useless and redundant.
Perhaps this idea is an attempt to blend the concept of the original counted elements of an arbitrary size with the actual size of the data in bytes. It might seem like forward thinking, but unfortunately, it is not possible to fix the deficiencies of this file format with any kind of extension.
This can not possibly solve the problem stated above. An old standard ILDA file reader will choke on this header just as it would on any other non-old-standard additions to the file format.
It only adds a problem of its own. With another section header type in the mix, a file reader can no longer read a uniform 32-byte chunk header and calculate how much data to read after that. The new header type has to be differentiated from the old standard header. So only the first eight bytes can be read before determining which type of header it is. Then the rest of the header can be read. Then, finally, the data can be read. There is no reason for these extra steps. Read the header. Read the data. Move on.
The original three section header types are logically the same structure. Since the only difference between the original file section 'palette' and the new section 'color table' is the maximum number of colors AND the new section is entirely dependant upon and logically bound to either of the original section types of 2D or 3D point vectors, why do we need a non-uniform section header for color tables? There can never be more colors in a color table than there are points in a vector drawing, so we don't need a 32-bit integer to store a number that can never be more than 16 bits and storing the length of the data in bytes is not a traditional concept of this format.
There is nothing to gain by using a non-uniform header with 24-bit color tables.
Why do I care about all of this?
Because, LaserBoy is entirely based upon the ILDA file format! It is nothing less than a very complex, conglomerate C++ memory object that _IS_ the ILDA file format made real and dynamic in memory.
And also, there is only one International Standard. That's the whole point.
The file formatt.ild is an example of the LaserBoy implementation of a possible 24-bit color extension to the ILDA Image Data Transfer Format.
The LaserBoy implementation is different from the ILDA proposed standard in that LaserBoy assumes that all section headers are exactly the same data structure.
class ilda_header
{
// literal string "ILDA\0\0\0" (7 char)
char format ; // 0, 1, 2 or 3
string name ; // exactly 8 char
string owner ; // exactly 8 char
u_short quantity ; // number of points or colors
u_short identity ; // number of this section in file
u_short total ; // total number of sections in file
char scanner ; // scan head this section is for
char future ; // not used
}; // total of 32 bytes
The file
formatt.ild
contains the frames seen in the bitmaps below.
This requires that the file contains the following
sections in the order listed:
|
LaserBoy can maintain palette and true color frames simultaneously in memory and in file. LaserBoy can force bit resolution color reduction and translate true color frames to files that match the traditional ILDA palette format.
Any questions or comments about LaserBoy or my differences with the ILDA format should be directed toward me; james@akrobiz.com
Any questions or comments about the ILDA file format or the proposed changes should be directed toward ILDA and their technical standards committee.
Currently, I am not an ILDA member and I have no immediate plans to become one. I have nothing against ILDA. I just don't have any reason to be a member right now. I'm sorry if anything about this document or my opinion offends anyone.
2D image with default palette
3D image with palette of pure hues
2D image rendered with 24-bit color table
2D image rendered with 8-bit packed pixel palette