The documents below describe the current, official ILDA Technical Standards for laser displays. Click on any underlined link to view that standard.
This document covers 30k scanner tuning, DB-25 connector and signal specifications, DMX-512 Effects Control, Effects Specifications, and ADAT Tape Playback and Track Assignments.
This technical standard describes ILDA's official Image Data Transfer Format for exchanging laser show frames between systems. The resulting frames and files are often called "ILDA frames" or "ILDA files." However, since there may be other ILDA-format files, it is best to call these IDTF or "ILDA IDTF" frames and files.
You can obtain frames from any program that correctly writes IDTF-format files, and transparently load them directly into any system that can load IDTF-format files. Similarly, you can save frames in IDTF format, to sell or trade with users of other systems that read IDTF format.
The IDTF format is intended for frame exchange purposes only. A laser system is free to read and write its own proprietary format that best meets its features and requirements. It is not optimized for space or speed, and it is not currently concerned with display issues such as point output rate. Also, the format does not include show information such as timing of frames.
Generally, the highest function the IDTF format can provide is a sequence of frames which play back to form an animation.
The ILDA Test Pattern very accurately defines mechanical laser scanner response. The test pattern's primary use is in alignment and calibration of galvanometer based laser vector graphic projection systems.
This known response is crucial to proper reproduction of interchanged imagery. Use this test pattern to calibrate programming and playback equipment prior to the commencement of image creation.
The point output rate associated with this ILDA Standard defines only the rate which must be used during scanner adjustment. This standard does not affect the point rate at which subsequent images may be generated or reproduced.
The ILDA Glossary was done in the early 1990s, at a time when different laser show companies used different words to describe identical concepts. For example, what is now called a “frame” was also called a “cel” or an “image.”
The goal of the Glossary was to standardize terms used in the laser display field. Over time, most of the terms in the Glossary either became commonly used, or were superseded by an improved device (e.g., PCAOMs). For this reason, the Glossary is included here mostly for historical interest.
The Glossary was produced by the Terminology Standardization Committee, which was separate from the Technical Committee. But since the Glossary lists technical terms, we have put it on this tech standards webpage.
The IDN-Stream standard describes the encoding of laser show artwork into digital data streams. This can be from single laser projector data sent across a network connection up to entire laser shows including multimedia content, stored in data files for playing back in a target environment.
The goal of IDN-Stream is to set a new direction in laser projection data handling. It is to add meta information and timing to content and thereby making artwork describe itself instead of being bound to specific environments.
IDN-Stream wants to unify digital connections by moving the projector interface from an electrical level to a protocol level and wants to offer a new universal exchange format for movie-like artwork. It again ensures the compatibility and interchangeability of hardware, software and artware in order that the results are predictable and that the artwork is faithfully reproduced from system to system like the ILDA Standard Projector did when it was defined.
Information from ILDA Technical Committee chair Dirk Apitz, February 2017
Let's start with the IDN message. Before I decided to go with a new protocol, I studied existing protocols, file formats, concepts etc. After a dozen or so - I gave up. Too complicated, too limited, too hard to synchronize, not adaptable, too expensive, in need of special hardware.
I figured out that it had to be modular and it had to be versatile since the laser business is a rather small market and implementing different protocols and formats would just raise development cost. Further, it had to be somehow packetized to allow for multiplexing, storage and transport across switched networks - and - it had to cover everything from hobbyist to professional, show to industrial applications.
Together with the Technical Committee, we ended up in what ILDA standardized as the IDN Message. In particular the IDN Channel Message that is defined in the IDN-Stream standard. With the generic IDN Message, there has been some space reserved that will be needed in other related standards. So, for now, let's focus on the IDN Channel Message.
Sometimes, people say that IDN is not finished. Well - I would say that this is a question of angle of view. Sure, network and file standards are in draft or under development - but the main part is there. It's the part that describes the codec. The description of how to put laser content into little, handy data packets that can travel across networks or be stored in files. While the rest is important too - essentially - it's 'just' about how these packets are dealt with. As long as IDN Channel Messages are handled nicely and kept in order - the (laser or media) content stays intact no matter of where these messages are stored or how they are transported.
That said, the planned formats are essentially just a standardized way of communicating - but IDN Channel Messages could live everywhere from database or proprietary file to cloud to cable. Plain or encrypted, secure or obfuscated.
The most important concept of the IDN Channel Messages is the timestamp. Every channel message has one. This timestamp has a resolution of 1 microsecond and is 32 bit wide, covering more than one hour. It is defined to be relative though, meaning that only the difference between the timestamps of consecutive channel messages is taken into account. This has the advantage of an arbitrary start point (especially useful in case of lost communication) and infinite playback (wraps get irrelevant).
With this concept of timestamps, another large problem is solved very nicely too. Synchronization across multiple distinct data streams, eventually carrying different media types like Laser, Effects, DMX512, Audio, MIDI or Video since all that has to be done is processing the messages in ascending order of their timestamps.
Other key concepts include packetizing and multiple simultaneous channels. Packetizing is useful just about everywhere since just about all scenarios use multiplexing, switched networks, frames, blocks or sectors. Essentially, in case you wanted to store or transfer a continuous waveform, it has to be packetized unless you have LP's, tape, dedicated links or such in mind. So - going for packets (or messages in IDN wording) makes the protocol very versatile. Further, the support for multiple simultaneous channels on protocol level makes IDN Channel Messages powerful and future proof.
Regarding laser projection content, the challenge was to define a data representation that covers all professional use cases but stays with moderate complexity - keeping simple implementations in mind. The outcome is a representation that is superior to all other formats as it arbitrarily scales in frequency, precision and signal count (sample size). 16, 24 or 32 Bit on your X/Y - no problem. 16 Bit on your colors - no problem. Frequency of 100 kHz or 250 kHz or 1 MHz - no problem. Stereoscopy - no problem. Further signals like BeamBrush - no problem. Sample-Synchronized output for multi head projectors - no problem.
Information from ILDA Technical Committee chair Dirk Apitz, February 2017
IDN is an open standard. There is a publicly available document describing it. It was developed in the ILDA technical committee - and voted on and adopted by the ILDA membership in Dubai 2015. Opposed to an open standard like this there are proprietary implementations. These are usually secrets of people or companies. Best you can get there is access by signing NDAs (Non-Disclosure Agreements).
This might not bother you as long as everything works fine, you're satisfied, features are sufficient and your relationship to the manufacturer is good. It turns into a headache, once something breaks though. You might find yourself in dreaming of other solutions, searching for workarounds or fooling yourself by glossing over the situation.
Even worse - how about a company closing down or being taken over or discontinuing a product? How about operating system upgrades/changes? How about changed business that leaves you in need of some special features that your setup doesn't provide? Or - how about you wanting to watch your old shows on future hardware - in - say 20 years from now?
But - stop - isn't it your time and inspiration that you put into your artwork, shows and programming? You're the owner - right? So - why is it that you can't just access it with different products to reach your goals and expectations?
Open standards allow for that. As an example - think of OpenOffice or pdf - or the Internet Protocol. There is more than one editor, viewer - or program in general being able to use these formats.
Information from ILDA Technical Committee chair Dirk Apitz, February 2017
One concern expressed about IDN is “My work is unprotected and can be stolen.”
Well - there is a slight difference between security and obfuscation... - and I'd like to quote here from Bruce Schneier's book about applied cryptography:
If I take a letter, lock it in a safe, hide the safe somewhere in New York, then tell you to read the letter, that's not security. That's obscurity. On the other hand, if I take a letter and lock it in a safe, and then give you the safe along with the design specifications of the safe and a hundred identical safes with their combinations so that you and the world's best safecrackers can study the locking mechanism - and you still can't open the safe and read the letter - that's security.
Coming back to the IDN Channel Message, it's a strewn myth that IDN-encoded content can't be encrypted. Support for this has been put into it on several levels - just that there is no specification of how to actually do it. Why not? - well - why should it? There hasn't been anyone showing up with skills, time or funds to put it in. It's that easy.
The most straightforward solution would be to wrap the plain messages into an encrypted stream like for example https does for http. Setting up a VPN could be another approach. In addition to that, IDN Channel Messages could live inside the obfuscated containers of current software systems. These systems and containers could provide the locking and allow for import and export of the IDN streams.
ILDA has a webpage with resources about the IDN. As of March 2021 it contains the following sections:
You can use these proposed standards for guidance such as understanding ILDA's technical goals, or for preliminary product development. But be aware there may be differences between draft versions and any final, official version approved by the Technical Committee and the ILDA Board. Also, ILDA is not responsible if a proposed standard is voted down, becomes outdated or unused, or in other ways never becomes a final, official standard.
See the "Source Code and Libraries" section of the ILDA-Digital.com webpage
The proposed IDN-Hello standard describes the protocol for the detection, enumeration and query of IDN-enabled devices. By a requestor, it can be used to discover the topology and configuration of an IDN segment and map services like laser display, DMX512 or audio to devices. Since the protocol introduces an abstraction layer, these devices can be located locally or remotely.
The protocol further defines a realtime access to the default IDN session which can be used to process IDN-Stream messages in realtime. This is the easiest and most direct way of passing IDN-Stream messages between systems.
Although, preliminary implementations exist, the standard is currently under development and testing. While the core part of discovery and processing of IDN-Stream messages is pretty much finished, mapping of services and handling of service/unit/link properties are work in progress. Please contact the Technical Committee for the most recent status.
Information from ILDA Technical Committee chair Dirk Apitz, December 2016
With older analog ILDA ISP cables, everything is pretty clear. You run an ILDA cable (DB-25 parallel port style) for each projector, individually or daisy chained, connect them, and run them. Essentially, what you're doing this way is assigning an address by hand-wiring the projectors.
With digital networking, everything runs across a single cable. You very likely saved much time in wiring, but your addressing scheme is gone. Now - how to get it back?
At this point, let's make a distinction between the network hardware (OSI 1, 2) and the data that travels on the line (OSI 3++). Don't get confused with the OSI layers; I've just mentioned those for completeness. For now, the distinction between the network and the data should be sufficient.
There are many types of networks out there. Some are for historic reasons, some are because of specific properties. The one most widely used by end users is Ethernet — that little 8 way RJ45 connector that was never designed for stage use - and always breaks. Thankfully Neutrik found a solution, but this is another story.
Along with the network type there comes an addressing scheme. Think of this as an address on the letter. On Ethernet, this is the MAC address. Every network adapter has a unique one. All connected devices form a network and you could think of this network as a city or country.
Cities may want to get connected to each other and there may be different options. I mentioned different network types. It could be a wireless link, a dedicated cable or a channel on a phone line where a 'virtual cable' gets multiplexed with others.
Now, let's move on to the data. A letter shall be sent from one city to another. This means, the data packet is transported inside city A to a bridge and over to city B where it gets dispatched.
Unfortunately, since multiple types of networks may be involved, our addressing scheme is kind of in trouble. Let's therefore introduce a global addressing scheme that can translate into any local scheme. This is the IP address - or with the example above it could be the GPS coordinates.
Too complicated? Well maybe a bit — but what I like to point out here is that two levels of addressing is not generally bad. It gives a degree of abstraction and with that arbitrary flexibility. Anyway, nothing you want to worry about when setting up a show. Neither the hardware (MAC/EUI48) nor any IP address (that may even change). And — honestly — computer scientists don't like it too. That's why they assigned names. Hostnames, domain names, and so on.
Now, how does IDN deal with this?
IDN was designed to use standard components and run on minimal infrastructure as well as on dedicated networks. Requiring a name translation service in the network would have been wrong because of complexity. Instead, IDN comes with a simple network scan mechanism found in embedded devices.
Running on minimal infrastructure kind of implies little/zero configuration as well. While you might want to care about the device name or service name like "LightShark 4000 Pro" or "Left-2", you may not really be interested in the IP address (unless for special setups) or the MAC address which is just needed for delivery. Or, as with the example above, you may just want to send a letter to your friend and not care about how the postman does his job.
With IDN, your application broadcasts a scan message on the network and all devices answer with their information. Then, the application knows of who is there. It knows this by the (current) address that can be retrieved from the response data packet. Regarding IDN, the information in the reply packet contains a unique ident code and a user-given name. The ident code can be used for housekeeping and merging subsequent scans and the name can be presented to the user. This way, when the user choses a name, the application exactly knows whom and where to talk to.
Well, you got your addressing scheme back. Assign names to your projectors and label them. Set everything up, start your application, hit “Scan’ and you get a list of all projectors by name. Depending on the application, arrange them like they are on stage, assign tracks or outputs — and that's it.
Information from ILDA Technical Committee chair Dirk Apitz, April 2021
DN-Hello is actually IDN-Hello (discovery) and IDN-RT (read time transfer). Both protocols relate in versioning, header fields, commands - but are independent! Means, a server can implement either one or the other or both (which makes most sense). There is a special case of broadcasting and multicasting where an implementation of just IDN-BRT (a subsection of IDN-RT) is needed.
January 15 2021 draft
The proposed IDN-File standard describes the format for storage of IDN-Stream messages persistently in files. These files start with a main header structure describing origin and format which is followed by a linked list of anchor message structures describing interfaces (based on a service map which essentially defines a virtual IDN device) for the streams in the data sections. A file can contain multiple streams. Locator tables can be used to navigate inside the streams.
Although implementations exist, the standard is under development and testing. While the core part of storage and positioning is pretty much finished, handling of calibration/reproduction and standard service assignment are work in progress. Please contact the Technical Committee for the most recent status.
The proposed IDN-Session standard describes the protocol to maintain a session on a remote IDN device. Sessions receive IDN-Stream messages, maintain buffers, keep a clock, manage resources and schedule message for output processing.
Generally, a session is independent from the link on which messages are transmitted. The standard for sophisticated systems that are able to handle buffer management and to do ahead of time streaming are reliable data connections which this standard defines. Realtime streaming on the other hand can be done through the IDN-Hello protocol by talking to a default session.
The standard is currently under development. While the core part of the session functionality is finished and proven to be consistent, the protocol for the reliable data connection, application buffer management and clock maintenance are work in progress. Please contact the Technical Committee for the most recent status.
These files are explanatory and are not "standards". Some may be no longer used or relevant, and are here for historical purposes.
This is an older version of the IDTF; the latest version 11 from 2014 is higher up on this page. Since version 5.1 was in use for many years, we are keeping it here for reference.
This standard was proposed to the ILDA Technical Committee in November 1992. It was not voted on or adopted, possibly because a practical, affordable, usable variable-width beam device was not developed until November 2019.
"The laser beam becomes a more useful brush if its width can vary while drawing a graphic. To create a "Beam Brush", the beam size is changed, usually by focusing and defocusing the beam. It takes both software and hardware to accomplish this task fast enough so a single image can use different line widths. The [proposed, never-adopted] ILDA Beam Brush Standard makes beam sizing operate the same regardless of computer or projector. A laserist can be assured that his or her images will have the same appearance on any ILDA-compliant system."
The ILDA Standard Palette assigns RGB values to the previously arbitrary color numbers in the ILDA File Format.
For example, ILDA Color 1 is now defined as: red=255, green=255, blue=255. This color is, of course, white. (Values are expressed on a 0 to 255 scale: 0 is off [0 volts] while 255 is full on [+5 volts].)
The ILDA Standard Palette allows systems to know what color to read and write, so that the 256 closest-matching colors are transferred.
The ADAT is an SVHS cartridge-based 8-track digital audio recorder. The ADAT is a very economical, portable unit that quickly become the defacto-standard for laser graphic recording and playback after its introduction in 1992.
The ADAT must be modified to allow it, an AC coupled audio recorder, to record DC coupled laser graphic signals properly.
The data in this document applies to the modification of Alesis and Fostex brand ADATs. This information is not intended to be a step-by-step guide. Modifications should be performed by those with reasonable technical knowledge and experience.
The modifications are however, quite simple, they consist of jumpering the signal input AC coupling capacitors. The capacitors are typically small electrolytic or tantalum types. Not all channels of the ADAT need be modified. Modify only those channels used for storing laser graphic data. This will typically be ADAT channels 1-6. However, the modified channels can be used for recording audio signals without problems.
One of the first ILDA standards, for a huge multi-pin connector. No longer in use.
This Laser Projector Interface Standard provides the cable, mechanical and electrical requirements for interfacing with laser projection systems.
The primary objective of this standard is to define a mechanical and electrical interface for laser projection devices so as to provide laser graphic playback systems, within a certain class of laser projectors, with device independence.
A secondary objective is to allow for remote projector operation over a single cable at distances of several hundred feet. Thus, laser projectors with either single or dual scanner sets, full-color or monocolor outputs, differential or single-ended wiring, local or remote operation can all be easily accommodated by this standard.
This paper by Malcolm Hignett of Thames Valley University was presented at the 2009 ILDA Conference in Amsterdam.
Abstract: Thames Valley University in London has been running laser display courses for undergraduate students and interested members of the public since 1996.
This presentation will evaluate some of the successes and pitfalls of running courses in laser display and show examples of animation and beam shows arising from the final year animation degree students.
A SWOT analysis of existing experience within TVU will offer a pointer to the future design, development and updating of courses, both within the higher educational sector and for industry.
The follow up to this paper will also seek to revisit and identify within a seminar context with ILDA members, the aesthetic essence of using laser beams and animation for audience entertainment, avoiding ‘sameness’ in beam shows and maintaining the excitement that we all feel when watching an imaginative, well-designed show.
Other ILDA websites: ILDAmember.com for membership database and event management (including joining ILDA), and LasershowSafety.info for safety information.
No reproduction of the text or images on this website is allowed without written permission of ILDA or other copyright holders. "ILDA" and the ILDA logo are trademarks of the International Laser Display Association.
Photo credit: iStockphoto