frame optimization through ballistic precomputation

[drlava]

Doc, please send me a email so I can send you a small attachment you might find interesting.

I also have the equation of state for a galvo scanner, I will scan it in for you as a JPeg this evening. I would caution all of you that your neglecting hysteresis in the bearing friction, and that DSP scanner amps have only made the civilian market in the last 3 years.

true, DSP scanner amps could do all of this internally, negating the need for the software to do it. That technology will likely take a while to become affordable, no?

Another technique is to accelerate the scanner to a position P, then apply a precise timed pulse of 1/2 the magnitude and the opposite phase at a time Tau later, thus slamming on the brakes so to speak and eliminating the need for damping.

Isn't this close to what damping already does, but in a linear way not a pulsed way

[Pangolin]

Frankly I'm suprised this hasn't already been implemented in everything, including a section for parameters in the ILDA format. Either there aren't enough engineers in the laser show industry or we are overlooking a fundamental flaw.. ?

Hehe. We have done a bit of work in this area ourselves, and if you take a look in some articles I wrote for The Laserist magazine around 15 years ago, you will see a discussion vaguely along these lines and how to do it pretty easily.

The "fundamental flaw" you are looking for is the assumption that the impulse response of all 30K scanners is the same, but this is not the case.

Think of it this way. Lets say you had a lot of people, all with 30K "filters", but each person implemented their filter with a different number of stages, and with different rail voltages at each stage. The analogy hopefully paints the picture that yes, for very tiny signals, perhaps of a few degrees, the impulse response is the same. But outside of that realm, it becomes more and more of a crap shoot as to whether or not scanners will actually be able to draw the images that are intended. With the wide variety of scanners out there, all claiming to be "30K" but being drastically different in nature, well, it is not possible to provide a meaningful improvement and also at the same time be compatible with the meriad of scanners that are in the field right now. There are other implications to this as well, but to discuss them would seem to take this off-topic...

But anyway, if you want to explore this go right ahead. We have already done the work in this area and we already have our own conclusions. But a good professor of mine used to say "student teach thyself"! Sometimes the best way to learn about a problem is by doing work on it. Who knows, maybe you will find some magical solution that will solve what I see as "compatibility" problems, and also the "other implications" that I aluded to above.

Bill

[mixedgas]

[QUOTE=Pangolin;66347]Hehe. We have done a bit of work in this area ourselves, and if you take a look in some articles I wrote for The Laserist magazine around 15 years ago, you will see a discussion vaguely along these lines and how to do it pretty easily.

The "fundamental flaw" you are looking for is the assumption that the impulse response of all 30K scanners is the same, but this is not the case.

Ah, the pe....
I'll save you the trouble of looking that up when James gets us together this week, I'll bring a copy.

Steve

[drlava]

Ok, cool. As we stated earlier, scanners all won't be the same so some tuning will be needed, the parameters of which can be stored. But it sounds like they were just TOO different for Bill to think this technique was justified in a general sense. Although, this line of thinking has brought up some other ideas which hopefully will be implemented in some upcoming sofware soon...

[Pangolin]

Hi guys,

Just a few more points:

Agreed. I would like to someday get away from having to specify images as a set of points and only as a series of segments, beziers, and shapes and then let the software figure out how to draw it based on the characteristics of your scanners.

This part is already working in our relatively new software like LC-MAX, LC-FLASH, LC-4D, and a few others, the user really doesn't need to specify points and such. The input is there, and the software automatically figures out how to control the scanner to achieve, at least what we believe is optimal results. There is some adjustability available to the user, but the default parameters we have chosen work really well.

Ok, cool. As we stated earlier, scanners all won't be the same so some tuning will be needed, the parameters of which can be stored. But it sounds like they were just TOO different for Bill to think this technique was justified in a general sense.

Well, it is really a matter of:
1. Exactly how much faster could you get the scanning, and;
2. Exactly how much variability is there.

Regarding the first point, within my article years ago, I stated that you could only get around a 50% increase in scanning speed. Then a few years after I wrote that article Bruce Rohr said the same thing in a speach at ILDA. And more recently, I have seen this same 50% estimate in servo books. Now, 50% might seem like a lot, but it really isn't that much... Also, this 50% was a whole lot easier to get with the G-120 which (because of common servo topologies used) executed all steps in roughly the same amount of time. This is no longer the case with 6800 and more recent scanners.

And lastly, once you accomplish this, you will see other "artifacts" that I won't mention here. (You'll just have to spend your time doing it, and then you will see them.) These are "artifacts" of the solution, not "problems" that could be solved with more work.

With regards to the second point, we have found that, in the field, there is HUGE variability between what all of our users have (despite the fact that everyone thinks they have 30K scanners), so we purposely make sacrifices in certain areas of *absolute performance* so that ordinary users with ordinary equipment will be able to display good looking imagery.

As one example of this, we do not supply any raster frames that do bi-directional raster, only uni-directional. You could get bi-directional to work, but it won't look good UNLESS everything is really perfect, and I mean everything. The linarity, acceleration and deceleration characteristics, and a lot of other factors have got to be the same in both directions, and also the color shift really has got to be tuned perfectly for a bi-directional raster to look right. Otherwise you get what looks like a "comb" effect in some parts, or all parts of the image. LOBO uses bi-directional rasters, but they have control over every part of the process. They make their own software, their own scanner amps, their own mirrors, etc. And yet, you can even see flaws in their rasters in their rasters if you look closely enough. So we only supply uni-directional rasters with our stock imagery because because almost nothing needs to be working correctly for you to get half-way-decent looking imagery. About the worst that can happen is that the entire image is shifted, but it still looks OK with no "comb" effect.

So, since we have a large user base and we want to have a good "out of the box experience", we sacrifice *absolute performance* in some respects, in favor of the darn thing just working pretty well for most people.

So sure, it is possible to make a system with a wizard that figures out this and that about the scanners, and then can adjust the output in some way to get a more optimal scanning. But our experience shows that the increase would not be "meaningful". And that, even if everyone was using exactly the same equipment, the "artifacts" that result from strongly applying the approach are not worth it.

It's easier to get a speed increase with different scanners or a different servo technique, and this also gives none of the "artifacts" of the point-pulling.

Although, this line of thinking has brought up some other ideas which hopefully will be implemented in some upcoming sofware soon...

Great! That's what learning is all about!

Bill

[carmangary]

Bill, why don't you describe what the artifacts were and help with the problem? We already know that Pangolin has already done everything we are doing many years ago. So why not help us out?

[buffo]

Bill, why don't you describe what the artifacts were and help with the problem? We already know that Pangolin has already done everything we are doing many years ago. So why not help us out?

If you're going to continue with the "chip on your shoulder" attitude, why should he bother helping you?

Seriously - you ask Bill for information, he gives it to you, then you find some reason to thumb your nose at him. This pattern has repeated itself more than a few times. If I were Bill, at this point I'd have to seriously question your motives. Sure, he likes to help the community, but when you're openly hostile, why in the world would he feel obligated to deal with you?

If you had bothered to attend one of the laser enthusiast meetings, you could have seen the raster images in person. It would have been a simple matter to adjust the color shift to show you how that can alter the image, and you would then understand why a bi-directional raster would give you comb distortion. (For that matter, if you had visited the Pangolin office when you were in Florida, Bill could have shown you this in person and in much greater detail.)

Likewise, if you had seen one of the scanner tuning seminars, you'd understand some of the other problems that can crop up when you assume that both scanners will always be running at the same speed (which they often aren't when you get close to their performance limits). I don't claim to understand the entire problem, but I know that I've got a better understanding of scanners as a result of being there.

But that's right... You decided that you didn't want anything to do with Pangolin... I quote:

Yea, you were helpful with the ILDA format stuff and I thought you were a stand up guy for helping me out. But, since then, other stuff has happened, which lead me to canceling my trip to visit Pangolin when I was out in Florida or ever having any of your products in my possession.

So why, again, are you asking for his help? Especially when you find him so repulsive that you've proclaimed in public that you'll never allow yourself to posses any of his products?

Your decision to cancel your trip seems rather foolish, given everything you stood to gain from it. And here you are, demanding more help from the very person you claim to dislike.

I just don't get it...

Adam

[carmangary]

I was seriously not asking for help. You kind of missed the point. I'm not going to get into it publicly, though.

[Zoof]

Agreed. I would like to someday get away from having to specify images as a set of points and only as a series of segments, beziers, and shapes and then let the software figure out how to draw it based on the characteristics of your scanners..

Exactly how I like to do it - actually it was one of my first goals when I started coding. All the `art' in Laseroids, Lasertennis and even the 3D grid are all defined in SVG, thus in beziers. I never touched the point data manually although I stored the graphics in ILDA format in order to safe the work of the conversion algorithm after tweaking the parameters.
Taking the next step will prove to be a lot of work and seems Utopian from what I learned about current laser scanning systems. To do it properly one would need the feedback signal from the scanners.

Mixedgas:
I actually tried the "braking peak method" you describe when I was still toying with homebuilt openloop scanners.
It worked for a large part but getting it right proved near impossible due to severe riming issues with the parallel port and windows. Implementing this with modern DACs seems not feasible either because the Tau cannot be chosen as there is a fixed timing between the points.
I got started with it because my scanners had severe damping issues.
Some of the results I got are in this gallery (second half): http://picasaweb.google.com/DrZoof/HowItStarted#
You can find a drawing showing the idea and then results with and without the compensation.

[carmangary]

I think that if the characteristics of the scanners are known well enough, you can do either or or both of the following:

(1) Be able slow the galvos down enough by speed control, anchor points, etc so that things are drawn correctly.
(2) Be able to compute "pulled" paths that in reality are displayed as you want tem to be. (ie the circle in the ILDA square trick).

#2 is too much for my brain so I plan on just going after #1. After that I'll probably change Spaghetti to also support a new format of laser drawings (non-ILDA) that either I will create alone or with anyone who is interested. They already do exist, though. Moncha creates this type of drawing in their drawing program. Once you are done with it you export it to ILDA. I want to just bypass the ILDA file step. This is one reason that I don't think that WAV files will be useful in the future as James predicts. They are still point based and have no notions of curves, circles, etc.