|
Originally posted: June, 2010. This is an approximate timeline accounting of my experience with The International Laser Display Association and their ILDA File Format Specification. In late 2003, I was introduced to the art of color vector laser display. I was already an experienced C/C++ programmer with an emphasis on graphics. My immediate focus in the field was on software development. I implemented the ILDA File Format Specification and the ability to read and write files and manipulate 3D color laser vector art in code. Shortly after the new year, in 2004, I met Rob Mudryk and Matt Polak, who both live within less than an hour of me. At Rob's house, both of them saw my work in the form of a 40 minute ADAT tape that was the 2004 New Year's Show for Akron, Ohio USA. Both of them acknowledged it had extraordinary effects and features. I continued contact with Matt Polak after that meeting with several phone conversations. It was only after I had met him in person that I discovered he was then the current chair of The ILDA Technical Standards and Specifications Committee, the very body of people responsible for the open public domain specification document! He told me, in a phone conversation, about an upcoming proposal to add a new section to their file format that would allow for individual RGB color values for every vertex in a frame. He also told me how it would be done. Since I already had the first three sections done and working in code, adding this last section, to be able to break away from palette only art into direct RGB art, was a HUGE welcome change and improvement. At that point the file format had only 3 sections, named 0, 1 and 2. Sections 0 and 1 are arrays of either 3D or 2D vector coordinates. A vector coordinate element contains coordinate values for X, Y (and Z, in the case of 3D), a blanking byte and an index into a palette of RGB values. Sections 0 and 1 are drawings, with blanking, but no local color information. The frame may have no color at all and simply rely on the blanking byte or a color may be assumed to be from an un-provided palette or the color may be found in a palette of RGB values previously defined in the same file. The other section is a palette of RGB values. A palette is also an array of homogenous data elements. All three sections of the file are counted, ordered lists of data elements. Therefore, each section begins with a uniform section header. A list of counted data elements of the appropriate type follows. In 2004, an ILDA file consisted of consecutive sections of types 0, 1 and 2. data types of consecutive bytes
uniform section header
data type 0
data type 1
data type 2 (and 3)
original documented specification
The new section, that Matt told me about, was really a brilliant idea. It was simple and elegant. Using a single byte value to look up a color in a palette limits the possible number of distinguishable colors to no more than 256. Since a frame, (section 0 or 1) is a counted, ordered list of vertices, then it is possible to create a corresponding table of RGB color values that share a one-to-one relationship with the vectors in the frame that follows in the file. Every bit of the functionality this idea provides is in cooperation with the previously existing format. This is the mathematically correct way to extend the utility of sections 0 and 1 to include individual RGB values per vector. This section was given the obvious number 3. proper alignment
I implemented this new concept in my own code. Matt told me that ILDA would be releasing a new version of their file specification soon that would include the proposal for this new section. I waited. They release their new specification document sometime in early to mid 2004. I checked it out very carefully. I was already very familiar with the previous specification document that had been in the public domain for quite a few years. I noted the description of the new section 3 data structures and methodology and it was described exactly as I had been told it would be. I made a public announcement of my experience and capabilities with the new ILDA proposed file format on the USENET news group alt.lasers. I followed that up with several requests to exchange files with anyone else who might be working with the new format. I had to ask several times over a period of several weeks, but finally, I got an email from Matt Polak. It contained two files made by the ILDA technical committee as examples of the new extension of the file format. I could not open them. When I examined them in a hex editor, I found not the uniform 32-byte section header preceding the new section but rather a nonsense, 16-byte, section header. vandalism
obviously wrong
Understand this right now. This has no merit. This is not an accident or a misunderstanding. It is obviously destructive. It is every bit as obviously wrong as it looks in the above illustrations. If you seriously don't understand how or why this is obvious vandalism, seek the advice of any experienced software developer. The most glaringly obvious "error" is the use of a 32-bit number (for quantity) in the place where the stored value can never exceed what can be stored in a 16-bit number. Any bits set in the top 16-bits of this number could cause serious memory allocation errors and crash the application and possibly the whole operating system. This is OFFENSIVE GARBAGE created for no other reason than to destroy this concept. This is not what one would expect to find in a publicly posted file format specification from an "International" committee of dedicated professionals. I immediately checked the online public domain documentation and saw that it had been changed to describe this vandalism instead of the obviously correct way. I talked with Matt Polak in several phone conversations after that. I asked him if he defended the use of the non-uniform section header. He did not. I asked him to do something about it. He refused. He assured me that my position was well known and understood within the committee. I asked if I could meet with him and show him my work as proof that I had a working implementation of the correct form. He said no. He did not want to see my work because if he never saw it then he could pretend that it did not exist and then it would not be an issue. He also told me that even if he could do something about it, he would not because it wouldn't do anything to make himself look good. When I pressed him to answer the question as to why this was done to the format specification, he admitted it was to ruin my work and ruin the format extension. I told him this issue would not simply go away. I would keep working on my code and this is so obviously wrong that it will come back to bite him in the ass. He then passed me off to Peter Jakubek, who, in email, told me that it is a simple matter of data structures. I should get a book on C programming. He didn't have time to explain and didn't feel the need because I am not an ILDA member. Shortly after that, on January 17th, 2005, I published a rebuttal in the form of a web page, well before the expiration date of the public proposal to add the new section. http://laserboy.org/ilda_file_format.html This was completely ignored by ILDA. The very first bullet point of the ILDA mission statement from their own official website says: "ILDA promotes the use of laser displays in the international marketplace through awards programs, publications, technology standards and a code of ethics." http://www.laserist.org/mission.htm The very reason why ILDA exists had just been vandalized and destroyed by themselves. I publicly discussed the issue on alt.lasers and the laserist list. These discussions always diverted away from the question of why-the-non-uniform-header. In 2005, my work was not open source or free. It was a completely viable, competitive concept in the market of ideas and capabilities. Instead of getting any traction what so ever from my success with the new format revision, it was turned around and used as a weapon to destroy my work, my integrity, enthusiasm and reputation. In 2006, photonlexicon.com (PL) came into existence and I was actually invited to join to get away from the harsh environment of alt.lasers and the laserist-list. During this time I discovered that the document that had been public domain ever since its introduction in the early 1990s had been taken away from the public and held as ILDA member's only information. Someone on the PL sent me a copy of the new, member's only, document. It contained descriptions of two more sections to be added to the specification and a statement of deprecation of the use of section 3. I implemented the new sections 4 and 5 in my code. My purpose for writing this account is primarily to tell how ILDA vandalized my work, their own file format and their own stated reason to exist. That happened when they changed the last publicly posted document to what it is now. It is important to note that the correct implementation of the first four file sections, 0, 1, 2 and 3 completed the working set of four types. With that, it became possible to save either 3D or 2D vector art frames with just blanking and no color or color from an assumed palette or color from a defined palette and individual colors per vertex all coexisting in the same file format specification; 3D, 2D, palette, and color table. ILDA had been advertising that their file format was under new development for many months before it finally arrived in the mid 2004 public proposal release. This was exactly what the proposal was supposed to provide. Following the links from "The Wayback Machine" [CLICK] (web.archive.org) from March, 2003, this is the first public announcement of the new revisions to the ILDA File Format Specification that appears on the web. Note: "The committee invites all interested parties to submit comments on the proposals. The standards will continue to be designated as .preliminary. until at least October 1, 2005, giving the committee time to respond to comments and make any needed revisions." "These revisions provide for true 24-bit color table integration. This change will allow true-color RGB data to be saved in the standard ILDA file format, making it easier for newer laser software to exchange data without sacrificing color quality." Since the use of color tables as described had now been destroyed, another way to store unique RGB color values per vertex was conceived in the form of sections 4 and 5. type 4, 3D vector with BGR element
type 5, 2D vector with BGR element
note the use of the uniform 32-byte section header
These arrangements are obviously a complete replacement for all of the previous section types described above. They do not work in cooperation with anything previously existing. Again, ask any competent software developer if these new data types have anything to do with the previously defined file format specification. They do not. They don't even store the RGB in the same order. This could have been a total departure from the original file format, with a different file extension, but it was not. It was published as a "members-only" upgrade to the existing ILDA file format specification which was now a document entirely for use by ILDA members only. The only notion of the previous file format that this new method keeps is the failures and limitations of the original, ill-conceived, but functional 32-byte section header and the extension .ild. The addition of sections 4 and 5 accomplished nothing but to prove that ILDA understands the common sense and utility of the uniform section header. The release of this information to only ILDA members made it clear that this file format specification was intended for ILDA member's use only. It solved absolutely nothing of a technical nature. My persistent position on "Format 3" became the central reason I was always on my own side of an argument I could never win. The general consensus seemed to be that if I truly believed that ILDA would change their file format specification just to vandalize my work then I must be paranoid, delusional, psychotic, in need of mental health care, and lying about the whole thing just to bring attention to myself. I got banned from The Photonlexicon. Sometime in September, after SELEM 2009, I contacted Patrick Murphy, the executive director of ILDA, by phone. Over a period of several months, I spoke on the phone with and exchanged emails with all three of the then current top executives of ILDA, to include Tim Walsh, the elected president and Daniel Kohn, the chair of the ILDA Technical Standards and Specifications Committee. None of these people held these positions at the moment of the original offense in early to mid 2004. Once I explained the situation, all three of them immediately recognized that using the 16-byte header was wrong. They also agreed that there was nothing wrong with the idea of Format 3 with a uniform section header and that it should be included in a near future revision to the official ILDA file format specification.
Tim Walsh put it together instantly. He knows all of the people involved at the ILDA end of the dispute. He commented on how accurately I had represented the personalities involved and how my story completely fit with the ongoing issues, disputes and previously unexplained failure of the addition of RGB color tables to the format spec. He sees its offensive nature just as well as I do and said that something should have been done about this a long time ago. Daniel Kohn also fully understood the technical aspects of the vandalism. He also agreed that using the uniform section header and the concept of section 3 color tables is completely valid and should be included in the current ILDA file format specification document. Unfortunately, he seems to have had his head wrapped up with issues about how any changes to the ILDA file spec might advantage or disadvantage certain professional software packages. He felt the need to include all kinds of written limitations to the use of these simple data structures that just don't make any sense at all. Patrick Murphy sent me a copy of a February, 2009 working draft of the specification document. It is entirely worthless. It contradicts itself multiple times in multiple ways. It is huge and goes on for page after page of pure nonsense. It is a declaration that there is NO STANDARD. It states requirements for compliance that are not described within it or anywhere else. The only information that seems to come out of it is that no one can implement it in any way unless someone within ILDA, with the proper authority, offers the opinion that compliance might have been met. That is not a standard. That is a sick joke. Imagine I walk into a fabric store and I ask for three yards of the finest muslin. The shop keep grabs the wasted end of a random bolt of fabric, shoves it at me and says here you go! I say wait! This isn't muslin and there is no way this is three yards! His answer is take what you have and fold it into thirds. That will be your new measure for a yard! The motive in my analogy is that the shop keep is also a tailor. A carefully measured three yards of muslin is for his use and advantage only. He is not comfortable enough with the quality of his own work to allow it to compete in a fair, open market. This dispute is literally as old as civilization. This is the very reason we have standards and standards keeping associations. They are supposed to be the same for EVERYONE. It is also why ILDA has a mission statement and a code of ethics. . . Now let's get to the funny part of this story. Almost all of my communications with ILDA within the year previous to this writing have been with Patrick Murphy. I must say, he is amazingly easy to speak with on the phone. He understood my position very quickly and sounded very empathetic when I explained the negative impact this issue has had on me personally. He even reiterated many of my concerns, indicating that he truly understood the serious nature of the offense that ILDA had perpetrated. He asked me what I would like to see done about the whole situation. First and foremost, I said, I want him to see this for what it really is! If he truly believed what I was saying, he should know what to do! I literally asked him to DO THE RIGHT THING. I told him that I would like to join ILDA, but I was not going to join unless I knew I had a welcome position on the Technical Standards and Specifications Committee and that my technical experience on this matter would be given genuine consideration. I would like to write at least the section about the use of RGB color tables and how they interoperate with the other three sections. Then I'd like to go over the entire document to make sure it measures up to the quality of every other computer science specification document I've ever implemented or written. I explained to him that being included as one of the developers of the actual document and having the opportunity to set it straight and get my name and company name in the credits of the document would go a very long way toward helping to restore my reputation and credibility. He assured me on several occasions that my non-ILDA-member status had nothing to do with how this matter was being considered by ILDA and had no bearing on the validity of my assertions about their file format standard; and I should not feel compelled in any way to join ILDA just to get my point across. He also noted the only way I could get on the committee would be to become a member of ILDA, indicate my interest in being a committee member and wait and hope to be invited by a vote of the current committee. I spoke to all three of the previously named ILDA executives about this matter. They all fully understood my desire to join ILDA and the committee. All of them expressed their approval as long as normal ILDA procedure was followed. I agreed and asked Daniel Kohn to poll the other committee members to see if I would be welcome, before I paid the membership fees. As I explained, I had no other reason to join ILDA, other than to be on this committee. I never heard back from any one of them about this proposition. Patrick Murphy told me, in conversation, that ILDA had been thinking for some time that all of the names in the credits of the ILDA file format specification should be removed! So, truly no one would be accountable for any part of it! Unfortunately, it took me several months to discover a trend in the phone conversations with Patrick Murphy. Whenever I called him. He was always five minutes late for a super important engagement and had so many other important things to do that he always had to put me off. I just kept calling him back. The number one reason why I wanted to join ILDA and the committee was to be able to show all of them the status of my work. I have extensive experience and practice with their file format. I have also logically extended the utility of it, translated its binary form into my own standard plain ASCII text format and defined a totally new format for extending the utility of the standard Microsoft RIFF WAVE file format for use of storage, transport and direct display of laser art. All of these things might be offered as standards by ILDA and their Technical Standards and Specifications Committee. It is impossible to deny anything, if you are looking right at it. Patrick agreed with my assertion that you don't need to vote on the correctness of math. Eventually, he agreed to set up an online meeting to include me, himself and all of the other relevant ILDA members to give me a platform to present my work. I had scheduled a local laser enthusiast meeting about a month from then and I said great! I'll have something to announce at my LEM! ILDA and I have come to an understanding! He responded in the affirmative. Weeks after that date came and went, I called him once again. He immediately remembered that we should have had an online meeting and admitted that he had done nothing to make that happen. He asked me to call him back at the beginning of next week. I assured him I would. As he was taking his cell phone away from his ear to hang it up and put it in his pocket, I could hear as clearly as every other word he had just spoken... "SHIT!" That pretty much framed up the value of the diplomacy, sincerity and importance of all of our previous conversations. Since we had already established that the file format specification should be redone to include a uniform section 3, that matter seemed to be dispatched. My next obvious concern was about the six years of abuse I had suffered as a result of my detractors using the issue to trash me and my work in open public forums. Patrick recognized that there are two situations that need to be remedied. The first is the contents and quality of the file format specification and the second is the effect this has had on me and my work. My position is very simple. Everyone can see this is vandalism. The proof is the vandalized specification document itself. The conviction is the fact that I publicly posted a rebuttal to do it the right way and it was ignored. All of the people who were directly involved in the development and release of this document are known. One of them made the foul decision and the others agreed to document and publish it. He told me that he was not going to do any investigating. He explained. Sometimes when you look into things you find too many conflicting stories and you end up knowing less than when you started. He explained that the official position of ILDA on this matter is: The release of the mid 2004 document with the proposal for RGB color tables was never changed. It was put out the way it is now and for a solid technical reason. My failing was that I was simply unable to convince the committee to do it MY WAY. He had no interest in urging anyone to come forward with that solid technical reason. So what is so obviously wrong today, is somehow plausibly correct six years prior to this writing and needs no explanation. ILDA had a perfectly good opportunity to change the course of events and come out looking good for having fixed a serious, ongoing violation of itself caused by "the previous administration" but they chose to perpetuate the deception, trivialize the importance of the issue and do ABSOLUTELY NOTHING about it. This translates directly into the fact that the current administration of ILDA must believe there is technical merit in the vandalism of its own file format and its intended purpose of devaluing my work and allowing its members and others to deride me about it in public forums. This is what a new pledge to ILDA's code of ethics is agreeing to. He gave me a couple of homework assignments to do so the onus of progress would be on me. He wanted me to write a detailed explanation of exactly what additions or modifications I would like to see reflected in the new file format specification, followed by another detailed analysis of why it should be done and what effect it would have. Do it the right way. Because it is the right way to do it. Everyone will get a fair chance to write code for a sensible format. The next piece of busy work assignment is my personal favorite. He asked me to pretend that I am ILDA and write a detailed apology to myself! I should deliver this to him personally and we would go over it, word by word, making adjustments as needed. He would then urge the ILDA Board of Directors to vote on whether or not to deploy this apology to myself. I can only hope they spent a lot of money on a suitably lavish frame waiting for that document to materialize. I told him in conversation that I could not believe the obvious, trivial, stupid, nature of this whole thing. It still blows my mind that ILDA would throw away so much for such an obvious bogus act. I told him that I would write this very story that you are reading now and that it would contain all of the details about the file format specification then and now. He warned me to be careful. He said I should not divulge any of the details of the current specification document (that he sent me) as this would violate the members-only status and I might be putting myself into legal jeopardy! So that was it! Patrick Murphy's solution to the issue was to tell me that ILDA had done nothing wrong -- even though everyone who looked at it at that time could see it and agreed that the use of the bogus 16-byte header for Format 3 was obviously vandalism. But somehow, only six years prior to these discussions, it was not just legitimate, but a superior solution to using the standard 32-byte section header found at the top of every other section type in the file format, including the previously non-existent Formats 4 and 5. And, he capped off the conversation with a threat that I might be sued by ILDA for writing (this) a public description of their trade-secret Formats 4 and 5. Did you get that? It's obviously wrong now but perfectly OK in 2004 and deserves no explanation to me or anyone else. I was wrong, not ILDA. This is the official position of ILDA on the matter of Format 3. I have no idea if Patrick Murphy consulted with any other high ranking officials in ILDA to come to this conclusion, but I have heard that he was given the title of Executive Director for life. So I guess whatever Patrick says is ILDA doctrine. So if it was such a great idea in 2004, then why did the proposal to add Format 3 fail? Why was it deprecated and removed from the file spec? Why was it never given a chance to work with the standard 32-byte header that works with every other file section type? I have no way to know this for sure, but from everything I've seen or heard about this issue, I would guess that Peter Jakubek is the individual who busted Format 3. All of the other members of the tech committee at that time went along with it, put their names on it and releaseed it to the general puiblic. When I tried to resolve the matter with Patrick Murphy, he did nothing about it except to willingly add himself to the ethics violation. From the ILDA Code of Ethics:
If you are reading this and thinking "Who cares?" maybe you should read the ILDA mission statement again. Providing and properly maintaining technical standards and specifications is one of the fundamental things ILDA is supposed to do. Another thing they are supposed to do is define and enforce a code of ethics. Do you see the problem here? What would you do if this had happened to you? Would you get knocked on your ass, give up, go home and never be heard from again? Or would you stand up for yourself and try to get other people to see this for what it is? . . Added Notes (2014): I proof read this story a while ago because I was informed that there were some typos. I also took the opportunity to follow some of the links to resources that are not on my own servers and found that some changes have been made on ILDA's end. If you go to the official ILDA website, laserist.org, and follow the link Technical standards under the menu heading For all laserists you will find a list of specification documents. One of them is titled ILDA Image Data Transfer Format and linked to the following document: standards_ilda-image-format_2006_004pt1.pdf The "2006" in the file name indicates that this document was prepared after the failed 2004 proposal. This is the ILDA file format specification they are currently offering to the general public. I'm not exactly sure when this happened. But it was certainly not in 2006. The failed 2004 proposal had been their public offering for many years after its expiration date of October 1st. 2005. If I had to guess, this change probably happened sometime in 2013; definitely well after I posted this story in 2010. As stated in standards_ilda-image-format_2006_004pt1.pdf:
Revision History
* Made a minor correction to the Overview paragraph on page 4,
* Added ILDA's name and website to the cover page.
* Updated copyright date in the footer of each page
This is nothing more than a typo corrected version of the document that preceded the Revision 006, April 2004 proposal to add the ill-fated "Format 3". It offers no statement of deprecation of the use of Format 3. It makes no mention of Revision 006, April 2004 in its "Revision History" and it omits the names of the people who contributed to the specification document that actually preceded it. It also makes no mention of the addition or even the existence of Formats 4 and 5. Apparently, Formats 4 and 5 are reserved for members-only and not to be implemented by developers who are not members of ILDA. So, ILDA failed to keep the promise they made to the public, way back in 2004, of a new revision to the standard file format to add the ability to save 24-bit color frames. It's like none of this ever happened! But it did. . . Added Notes (2019): The current file format specification ILDA_IDTF14_rev011.pdf is now available to the general public on the official ILDA website. It contains a description of Formats 4 and 5. Plus it also features a full definition of the default 63 color palette. It also contains a redacted list of previous versions of the spec. So, which versions are not listed? What is the reason for including an incomplete list of previous versions? For the sake of total disclosure, I should point out that I edited the end of the section of the accounts of 2010 and before. I deleted stuff about my opinion on the matter, which is, more or less, irrelevant. But the whole story is absolutely true from my own personal experiences. You don't have to believe anything that I claim to be true. Anything that was said in an email or on the phone can be thrown out as hearsay. But you can't throw out the real, tangible evidence; statements posted on the ILDA website and a consecutive series of versions of the ILDA file format specification document and the timeline in which they occurred. You can look into the archives of alt.lasers, The Laserist List and The Photonlexicon and see for yourself that I made my position known and that I have never changed my version of the story. You can also see how I was treated by members of ILDA (Bill Benner, in particular) and the sycophants who followed them. You can try to weave your own narrative around these facts, but I really don't see how you could come up with a story that exonerates ILDA from any wrong-doing; or more specifically, by it's members, past and present, anyone in ILDA who knew about the ongoing dispute over Format 3 and did nothing to come forward and set the record straight. No one ever did. You can't expect cancer to cut itself out. . . . James Lehman : VP / CTO
330 762 7137
. . |
