It is a shame format 3 was never given a fair chance. The 16 byte header made it unnecessarily awkward to read any file that contained it because you could not use the same code and data structure to read it. You had to read part of the header and then determine if it was a 16 byte header or a 32 byte header, switch gears and then read the rest.
The 16 byte header made no sense because it contained only the "ILDA" and binary "0003" followed by two 32 bit integers; one for the size of the data that follows in bytes and one for the quantity of elements. That might seem OK, but storing the size and the quantity is redundant. If you know one, you know the other. And using a 32 bit integer for quantity could cause a big problem. All the other sections use a 16 bit unsigned integer that can only count up to 65535 elements. A 32 bit number can count up to 4.3 billion elements. This number would be used for dynamic memory allocation to make room for the data that follows. If the number was an error your code might allocate up to 12GB of RAM. Not good.
Like I have said many times before, format 3 was the proper answer for exactly what ILDA had been advertising on their website for many months before the release of the proposal in 2004. It was designed to extend the utility of the previous three section types. Format 3 works with formats 0 and 1.
If an ILDA file reader that came before it had been written to skip over unrecognized stuff (as it is written in the spec) by looking for "ILDA" 000[0, 1 or 2] then it would skip format 3 and find the format 0 or 1 vector image that sits just beyond it.
There is also another interesting side effect of using format 3 with 0 and 1. Formats 0 and 1 have palette indices in them. So every frame in a file could be 24 bit color (format 3) and palette color (format 2) and monochrome (by reading only the blanking byte).
This would have been particularly useful for stand-alone projectors that read from fixed media like a CD ROM, SD card or EPROM. Some projectors might be fully analog modulated RGB capable of using the 24 bit color tables. Some projectors might have only 2 or 3 bits for each color (8 bits in total can define a palette of 256 colors). Some might be TTL (only 7 colors) and some might be monochrome.
It would have been possible to create frames with 24 bit color and a well designed palette to produce exactly the colors that the artist wanted on all systems, all in the same file.
Formats 4 & 5 do not work with 0 & 1. They are mutually exclusive. Although you might be able to store a mix of 0, 1, 4 & 5 in the same file, you cannot store a single frame that is both 0 or 1 and 4 or 5 at the same time. Skipping 4 or 5 will get you nothing. And using the same 32 byte header for 4 & 5 means that it suffers from the same defect as 0, 1 & 2. There is no way to know how big the section is without knowing what it contains.
When I spoke to the top 3 executives of ILDA back in 2010 about all of this (Patrick Murphy, Dan Kohn, Tim Walsh) they all agreed that format 3 was a perfectly valid format for the reasons I stated above. They also saw no sense in the 16 byte header and they also thought that it should be fixed and added back into the specification.
What happened to that idea?
I hope this thread doesn't just dry up and blow away. Inquisitive minds want to know, while Dean sits there munching his popcorn.
James.