Software > Joint Development
ILDA File Format On-And-On
James:
Check this out:
http://www.photonlexicon.com/forums/showthread.php?t=9559
What 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. :)
Fanny Pack:
Meh, been there, done that. :)
James, I was reading about Windows media today, specifically ASF files that combine audio and video as seperate streams. It seemed like a good way to do laser display instead of putting it all into a WAV file since it allows for independent processing of each stream. You can do the same by ripping the wav file apart I guess. But my point is, if you created such a file you could create custom codecs that play laser streams and that would offer you a lot more flexibility that trying to hodge podge everything into a WAV file. Yea, I know you won't like that idea but thought I would share it anyway.
James:
I'm sure there are plenty of new and perhaps better ways to represent color laser animation.
What I wrote above was in response to the non-engineering nonsense and never-finished-nature of the ILDA file format.
There is another issue that absolutely seals the deal as proof of my claims as stated above.
Consider the fact that each frame in a sequence might need to be repeated an unknown number of times in order for it to appear for a specified length if time before the next frame is shown.
For this to be done correctly and without possible damage to the scanners, a small amount of data needs to be generated and added to the information that is stored in the ILDA file. The scanners need to have a defined path to get from the last point of a frame back to the first point of the same frame AND a path from the last point of one frame to the first point of the next frame.
There is no provision for this information in the ILDA file format. It MUST be calculated outside of the storage limits of the file and intelligently added to the data at some point between reading from the ILDA file and clocking points out the DAC.
In any other field of engineering, math is the answer and the absolute final word.
When someone comes forward with a statement and has a working model that proves it, that is the end of it.
I've been called a jerk, paranoid, delusional, in need of mental health care, and banned from a forum for making a statement and having a working model that proves it.
James. :)
meandean:
Quote from Zoof@PL:
--- Quote ---The ILD file format should be just a raw data storage for direct playback.
--- End quote ---
Good luck with that! :D
Here's the one I appreciate from allthatwhichis:
--- Quote ---I got nothing man; I just put frames on a timeline synched to music...
--- End quote ---
drlava:
That discussion isn't really about what the ilda format should have done or could do, The ilda format is what it is.
The thread is more about exploring the utility of using a true vector format for describing laser frames and animations. If such a format were to be described, whether programmers would use it.
Navigation
[0] Message Index
[#] Next page
Go to full version