ILDA file usability

[Zoof]

Previously, this has come up in a number of 'charged' discussions but the coast seems clear right now to post my view and to find out how other see these points. A simple I (dis)agree, my experiences are ..., or any contributing thoughts are all very welcome. This will just represent my view, I’m not going to battle about them. I want to know what you think.

Here is my view: The ilda file contains raw data that should be sent directly to the scanners at the design scanspeed without software changing or adding points to the graphics definition (for exceptions below). This is the only way that the file format makes sense to me. At creation time care should be taken that all points are at the right place, blanking is optimized, enough anchorpoints (dwellpoints) are used to display the graphics correctly when sent to the scanners at the design scanspeed. The tuning of the projector through the ILDA process should ensure proper projection.

Playback software should only alter the graphics to scale, correct for non-orthogonal projection, correct colors for nonlinear laser modulation behavior, and others in this category. The software should not alter, or intelligently correct point placement, insert anchorpoints or whatever. The ILD file format should be just a raw data storage for direct playback.

ILD files store points. The coordinates of these points can be regarded as vector format but IMO, from a graphical point of view, the file format cannot be regarded as true vector format. Curves are approximated by straight line segments, or so we assume. In fact we rely on our scanners to smooth the line segments into curves, so the exact graphics definition is given by ILD point placement and the ILDA tuning of your scanner, i.e., partially in software and partially in hardware. From a usability point of view this is very poor.

In addition, editing graphics point by point is tedious, especially if you have to manually edit each point on a curve to change it's shape. Graphics packages have good ways to deal with curves (spline, Bezier, etc) and even pre-WWII car and aeronautical designers used bezier curves to define the exact shapes of their aerodynamic outlines. (the algorithms were kept strictly secret by the companies until Bezier published about them, and the become known as bezier curves).
These curves define truly scalable vector graphics and vector graphics packages such as Corel Draw are based on them.

Finally, projection is by definition 2D so the 3D ILD formats are complete nonsense – again there are better ways to store 3D shapes. I’m not blaming ILDA, it makes sense how they started but the format, other than for direct playback, has outgrown itself.

Who would like to have the ability to work with real graphics for their laser system?
To whom does it make sense to have a true scalable vector graphics file definition for laser display?
How important is sharing laser graphics for you?
If you are completely content with how current systems are working and see no room for improvement or not on these point, please also say so (politely).

Thanks,
Matthijs

[T0mmm]

I clicked disagree, because every laser has slightly different blanking response so you could never really 'optimise' raw blanking data for every laser.

The scanner bit is more agreeable though, but wouldnt you have a huuuge amount of data for a larger frame?

I think either way its always going to be a challenge to get the balance of size/speed/points right, but it just makes it more rewarding once its perfect

[allthatwhichis]

[mixedgas]

Pangolin did some good tests in the late 90s, 10 bits about the limit for laser graphics resolution as far as the eye is concerned, and we only see about 64 shades max at any given time, and thats IF you have artistic genes. Yes, you use a 16 bit dac to get you flexibility in positioning the image within the field, but some place just north of around 10 bits, the additional position information becomes useless.

So other then for using more modern computer programing libraries that come with tools for handing vector, whats the point... Just do what everyone else is doing, use the vector tools for creating new art and keep backwards compatibility for the rest.

Only other thing I can see is a slightly smaller file structure as a benefit.

This is one place where standardizing bodies do have a purpose, and that is to make sure everyone is on the same page.

Perhaps a better place to work would be getting rid of 8 bit color, the fades are really course on a PCAOM and 10 bit color would give you more headroom in creating compensation curves for the DPSS

Steve

[Zoof]

I clicked disagree, because every laser has slightly different blanking response so you could never really 'optimise' raw blanking data for every laser.

The scanner bit is more agreeable though, but wouldnt you have a huuuge amount of data for a larger frame?

I think either way its always going to be a challenge to get the balance of size/speed/points right, but it just makes it more rewarding once its perfect

Hi Tomm, I need to expand a little on the problem I perceive as I work and program with ild files. Some work fine, others need interpolation and the addition of anchor points. I don't know which programs produce these frames but they miss the point completely IMO. A good ILDA file should be playable by 'dumb' software just sending the point and color data to the scanners, possible after scaling and projection correction, and as you mention color correction to compensate for differences. However, the whole ILDA philosophy was that every projector should behave the same so a ild file will play look the same on each projector. Since the masses have discovered cheap lasers, the ILDA philosphy of tuning each projector (espec. color behaviour) to the exact same performance may be more difficult but is fine with me.
The point really is that the ild file format is being misused as a graphics defintion format with above mentioned drawbacks, I have too many files that cannot be played back without interpolation or extra dwelling. Furthermore I think many ild files I have (downloaded, demo, or other) could be optimized in terms of point placement.

Thus my view is two-fold:
1) ILD files should be used for direct playback only, they are poor for graphics definition.
2) A better graphics definition file format for laser graphics should be used. The point placement should largely an automated process, and let the designer focus on the art. And decrease filesize at the same time.

Since I regard this community as the online heart of laserists, what we want should be able to happen, and a lot is still waiting to be improved IMO.

[Zoof]

Steve, I agree with you points on hardware improvement. I'm just trying to see if people see the point in separating graphics definition (scalable vector graphics) and raw hardware dependent data (ild file).

Here is the main point:

I believe that laser display QUALITY in general can increase dramatically when the differences between true graphics definition and raw scanner data are respected. I have done a great deal privately to optimize the output of my projector, my proggies (laseroids, laser tennis, especially OLA) are the result of my trials.
On my projector my software creates a cleaner and better output than what are accepted as the main commercial laser systems, after tuning all settings! I believe this result can be generalized to all similar (solid state) systems. The key is point placement derived from a true graphics definition.

[DMills]

Even things like geometry correction can screw up ILDA playback because scanners have finite dv/dt so correcting for geometry can completely screw up the image (Try running the ILDA test frame with some heavy geometry correction on sometime!).

Now there are ways to take an ILDA frame and convert it into something which resembles what the scanners will actually do, which you can then use as a frame for software that is written to handle something more sophisticated - Graphics Gems has some good spline fitting code, add some lowpass filtering to emulate the mass and finite torque).

It seems to me that for most applications, designing the graphics in some suitable vector graphics package (or even in something like 3DStudio) and having the rendering be handled by the playout code is likely more useful, but it does impose a LOT of additional complexity on the playout code (This is not something that is ammenable to running on a small microcontroller for example).

Thinking about it, ILDA is probably fine as a format for simple playback of a show, but it falls down as a format for transport of frames that may be subsequently post processed to produce composite imagery, for which you want a true vector format ideally with vertex and edge data, and with sensible constraints (Polygons chould be convex for example).

ILDA is good because it is a **SIMPLE** standard, and there is much to be said for that. For a format to be used to just play a sequence of frames at a defined scan angle and rate, it is fine, but it is seriously simple minded as a format for transporting artwork (as oposed to scanner data) between systems.

SVG (at least a subset of - lasers don't do gradient fills real well!), could work for 2D material, but I would also like a way to handle 3D pointsets so that show editors can apply meaningful 3D transforms to the data.

Note that we would still need ILDA to provide a simple format for transport of complete shows, this would be a distinct way to transport artwork that may only make up part of a projected scene.

Just my thoughts.

Regards, Dan.

[tocket]

As I see it, the ILDA file formats are a failure in standardization. I don't know if it's because they were poorly designed or if the programmers implementing it just didn't read the documentation properly.

Why do I say this? Simply put, I don't expect an .ild file to work when I open it.

To me, a true vector format for laser graphics makes perfect sense. Let it be up to the software or even scanner amps to make it look good.

[DMills]

I can usually open the things ok, but why don't they include the bloody scan rate as part of the file?

I mean my code knows how to convert a 12k pointset to a 30K one, but if the file does not specify what speed it is supposed to be projected at....

IMHO, a vector format with a value for how long in ms to dwell would be the way to go, leave the details of what voltages to send to the scanners and colour control to the software rendering the scene.

This would allow for compositing images and doing things like hidden line removal before rendering the scene to the output device.

Regards. Dan.

[weartronics]

The ILDA format has always claimed to be an "image data transfer" format, used to exchange frames between systems. Of course, way back when it was defined, there was no distinction between artwork representation and DAC output points, so it got used for both purposes. But with so much new technology since then, these concepts have diverged a lot. As you have shown with OLA, artwork is much more conveniently edited in object-oriented formats, and DAC output points can be generated in real-time according to the desired scanner parameters and any perspective corrections.

ILDA doesn't seem to have caught up with this, and in my opinion the ILDA format no longer serves its stated purpose very well. This is not a criticism of the standard - technology evolution is a fact of life, and the ILDA format has survived in essentially the same form for more than a decade. I don't think that any simple update to the ILDA format will make it suitable for representing editable laser artwork again, but I don't think there's any need to have a separate format for editable laser artwork any more either.

I think you are on the right track using SVG as a laser artwork format.

Of course, the ILDA format is still necessary to import frames into traditional sequencing applications. It's still good for this purpose because modern software interpolates the points as high-resolution geometry anyway (it doesn't simply reuse them as DAC output points). This means that as long as you're not pulling points or trying to create test frames, the scanner parameters aren't important at all.

If you want to document and publish some recommendations for using SVG as a laser artwork format (i.e. which elements should be supported, which attributes represent laser colour, how to store frame-sequential animations in a single file) please contact me because I'm working on similar projects and I would like to contribute.