Check this out:
http://www.photonlexicon.com/forums/showthread.php?t=9559What is it about the ILDA file format that seems to allude so many seemingly good software engineers?
To be fair, the ILDA specification document is poorly written and completely lacks any insight as to how to implement or use the structures that it defines.
But if you implement it in code and work with it for many years, you'll see just how simple it is.
It is nothing more than four data types in a specific arrangement.
a. the section header
b. the 3D coordinate
c. the 2D coordinate
d. the color
Each of these structures is made of nothing but 16-bit integers and 8-bit characters.
The absolute limitations of how many things can be counted with 16-bits or 8-bits apply here, just like they do every other place a binary integers is used.
The section header is uniform. It marks the beginning of a collection of homogenous data elements. It contains the type of data and the number of elements of that type.
a. the section header (indicates section data type and quantity)
The coordinate structures contain signed short integer values that represent either 2D or 3D locations. Each of these coordinate structures also contain an 8-bit character that contains 1-bit that indicates whether this data element is lit or blank and another 8-bit character that may be used as an index into a palette of 256 colors or less.
It is quite possible to ignore the palette index and simply light or blank each coordinate according to the blanking bit. It is also possible to have a lit coordinate with a palette index that points to black.
For this individual data type to be useful, it must be stored as a series of consecutive coordinates. It is not the individual coordinate that makes a useful item of data. It is the distance between every two consecutive coordinates.
b. the 3D coordinate (indicates X, Y, Z, blanking, palette index)
c. the 2D coordinate (indicates X, Y, blanking, palette index)
The color data type is just three 8-bit characters; one for each of red, green, and blue, that make a typical 24-bit color value. A section header is followed by one or more colors to make a palette. The only other intrinsic item of information is the index of the color structure in each palette section.
d. the color (indicates index and RGB)
That's it!
There seems to be a never ending discussion and debate about the original intentions of ILDA when this was designed and how a variety of applications, old and new, deal with these structures.
WHO CARES?
This is nothing more than a simple arrangement of binary numbers! EVERY answer to EVERY question that anyone has ever had about this file format can be found in the structure itself.
It is what it is. It does what it does.
Trying to put artificial limitations or restrictions of use on this arrangement of data is meaningless, futile and wrong.
If an application can not properly read a file that follows the rules of this arrangement of data, then it is wrong.
To be more specific, there is clearly NO WAY to indicate the original intentions of the creator of an ILDA file with regard to points-per-second, frames-per-second or scanning-angle. These are only the most primitive and important things the projectionist needs to know. Furthermore, there is no way to indicate hardware requirements, placement of one or more projectors, viewing angles, geometric corrections, etc... etc... etc... etc... etc...
Since there is no way to convey any of these items of information, we must consider them to be outside of this format and unknowable by its measure.
That means the notion that an ILDA file is supposed to be pre-optimized for a specific pps and viewing angle on a specific grade of projector is WRONG.
It is senseless and impossible.
The fact that there is a 3D data type is proof of that!
There is NO WAY to properly optimize a 3D drawing for 2D scanners!
The ILDA file format has some useless appendages in its section header. So what? There is only one of those for every section and all of the data types that follow are perfectly reasonable in their design.
ANYTHING that can be stored in a manner that follows the rules of this file structure is fair game.
There is a very good reason this file format exists. It defines a very specific level of information that is intrinsically connected to 24-bit color laser vector display.
Yes there are other "true vector" file formats out there. USE THEM! If you want more flexibility to design abstract concepts like circles and splines, then use the file formats that already have those data element types.
Somewhere along the line, you will come to a point where you need to convert those abstract concepts into 16-bit and 8-bit binary numbers to clock out of a DAC. This process might never look exactly like the ILDA file format, but that DAC stream could easily be saved as an ILDA file.
Furthermore, this ILDA file could be stripped of information in various ways to reduce points or colors. Or points may be added or moved to suit the needs of further processing or display on a dissimilar projector.
Clearly, there is value in being able to store color vector art in a variety of stages between totally stripped to fully optimized or even over-optimized information. This kind of flexibility is very useful.
It is exactly what is NOT in the file format that makes it a meaningful type of information storage. It is NOT intrinsically related to time, speed, hardware, abstract concepts, etc... etc... etc...
It is a working data format.
It is literal binary information. It does not require translation or interpretation.
It can store data in various stages of process.
It follows simple rules of connect-the-dots drawing with color, in multiple sequential images within a single file.
Use it to its fullest potential with a good dose of your own applied intelligence.
James.
