LaserBoy
Software => Laser Software => LavaSoft => Topic started by: drlava on September 06, 2009, 08:36:40 pm
-
Hey guys, this has been brewing for a while, but has only been discussed briefly here until now. That is, what is the appropriate way to send frames to the DAC driver, and what is the appropriate way for the DAC driver to send these frames on to the hardware in terms of blanking timing.
I have noticed a trend with Spaghetti in that a lot of the shows that are available expect the lasers to have fast modulation speed in order to be displayed properly. But, what happens when one tries to play one of these shows with galvo blanking? The frames have heads or tails on the lines unless blanking timing is adjusted by the laser controller, to make the galvo blanking signal slightly lead the xy signals. What's wrong with that? you say.. well, nothing, until you realize that if you display the ilda test frame with these blanking adjustments it won't look right. It will only look right with 0 controller blanking adjustment on galvo blanking setup. So, to display the test frame correctly you need one controller setup, to display the currently available shows correctly you need another setup. Something's not right.
Similarly, there is an issue with projectors with fast blanking such as our dpss and AOM modulated units. When one displays the ilda test frame in spaghetti with 0 modulation delay, it doesn't look right, it looks like this:
(http://hacylon.case.edu/laser/EzAudDac/ilda_off.jpg)
This can be fixed now by adding in R, G, and B offset delays in the EzAudDac.ini file to simulate the slower galvo blanking.
(http://hacylon.case.edu/laser/EzAudDac/ilda_on.jpg)
This was as close as I could get it, one 48000th of a second sooner blanking looked worse.
However after tuning up the system to make the test frame look as right as possible, when one goes to play a spaghetti show, there are often tails and or heads.
So, what's right?
There are frames available that are meant to be displayed just as the ilda test frame is displayed.
There are some frames out there that are meant to be displayed with no galvo blanking simulation.
Pangolin loads frames assuming they are tuned to be displayed with galvo blanking.
Spaghetti loads frames assuming they are to be displayed with fast blanking (thus normally the blanking on the ilda test frame doesn't look right.)
Personally I lean toward making the ilda test frame look right with the controller/driver blanking delay if necessary, and then the other content should look right also. The reason this is important is that if we are going to be sharing frames, this should be hammered out. Also, it's important because EzAudDac 1.08 now has individual r,g,b,i blanking delay adjustments to make the ilda test frame (and most other frames) look right when it is fed directly to the driver.
What are your opinions?
-
Please explain how you get the ILDA test pattern to clock out properly on a 48KHz, fixed-frequency DAC!
James. :)
-
Spaghetti doesn't use a constant scan speed when displaying files and it doesn't employ blanking and color shifting in its optimizations. So, what you are trying to achieve with Spaghetti isn't possible in the manner that you are doing it.
You can force a constant frame rate and you can apply your own blank optimization by making all of your frames have the same number of points and turning off blanking optimizations. The number of points in your frames will also have to be equal to the max scan rate / frame rate. For example, if you set the max scan rate to 48000 and frame rate to 30 then each frame should contain 1600 points. If you do that than I think you will achieve the results you are looking for.
-
Please explain how you get the ILDA test pattern to clock out properly on a 48KHz, fixed-frequency DAC!
James. :)
It's simple, really. You just slow down the laser modulation control signals to simulate galvo blanking with the laser controller. Download EzAudDac 1.08 here. (http://hacylon.case.edu/laser/EzAudDac/EzAudDac_108.zip) This basically equates to a delay in the modulation signals, determined by the BlankDelay settings in the ini file. After this is set up, every file that conforms to the ILDA standard with respect to galvo speed and blanking should look right.
Gary, what I am proposing is to take care of this completely in the laser controller (many do this already) and it has nothing to do with Spaghetti except for how a few of the currently available shows are timed with regards to blanking. The spaghetti example was illustrative of the point I am trying to make.. which is:
when the laser display system (controller, blanking, galvos) is tuned up to display the ILDA test pattern correctly (from any software) then, in my opinion the shows and other frames coming from the software to the DAC should also display properly.
-
This could turn out to be a very interesting conversation!
I think we all have our own ideas about how this stuff works out.
I figured out my math with the idea that my DAC would be a fixed frequency; most likely the highest I could get out of a given sound card ~ which seems to be 48KHz, although the echo Layla will do 96KHz.
As far as I can figure, the only way to accurately clock out the ILDA test signal is at precisely integer divisions of the DAC frequency.
LaserBoy corrects for the scanner delay by shifting the color channels back a settable number of samples in time.
I'm quite sure it works. I have been very happy with the way LaserBoy waves look when projected.
I think it is also important to note that the ILDA test pattern is for tuning your scanners! It is meant to be very difficult for your scanners to reproduce! It is probably not the best thing to use for color to scanner time alignment; certainly not in the world of a fixed-frequency DAC.
As far as I know... If you are using scanners to draw and a scanner to blank, then you don't need to make any time difference between the signals. Galvos is galvos! They should all be in about the same time domain.
James. :)
-
Exactly right. The higher the audio DAC frequency, the finer timing tuning capability you have to make the frame display properly. While you do this with waves, EzAudDac can do the shifts in real time on incoming data.
I ran into this with ILD SOS development. I tuned up a frame so it looked perfect on my system and then sent it to a member with a different software setup. They loaded it and found the blanking looked all wrong! What was happening was the software loaded the frame and displayed it in the same way it loaded the ilda test frame and displayed it, except the ilda test frame displayed correctly. SO the solution was to tune up my laser controller so the ilda test frame looked correct, then load the frame I was working on and tune that till it looked correct. Then when I sent the frame it finally looked good on the others users system.
It makes perfect sense, really but it was never really spelled out this way.
-
I think it is also important to note that the ILDA test pattern is for tuning your scanners! It is meant to be very difficult for your scanners to reproduce! It is probably not the best thing to use for color to scanner time alignment; certainly not in the world of a fixed-frequency DAC.
James. :)
The ilda test frame is for tuning your scanner and your blanking galvo, so it is also an important reference for color to scanner time alignment.
Yes, galvos are galvos, in basically the same time domain. This is why we need the controller (and/or something like DZs timing board) to compensate for fast blanking if we use dpss and AOM modulation.
-
The ILDA test pattern is for tuning AND DETUNING your galvos so that they bahave the same as everyone elses. It's the same as how the DZ color board dumbs down all of the laser modulation to the same level.
If you want 100% accurate frame reproduction from system to system, PROPER use of the ILDA pattern to tune your system is the way to go. What you end up with is a bunch of frames that are tuned for your system. When you give them to the next guy, if his scanners are tuned the same as yours, then that means that the frames will also be tuned to his scanners and that they will look right. But that is only if he displays the frames at the same speed and angle that he used to tune his scanners which in most cases is 30K at 8 degrees. Scanners are not linear devices so if you both tune your scanners to 30K@8 but you create your frames at 30K@ 20 that will not mean they will look good at 30K at 20 on the next guys system. In fact, there is no guarantee that they will look good on his systems at any combination. It only works if you design them at 30K @8 and he displays them at 30k@8.
People that run their scanners in small rooms (ie most hobbyists) will want a scan angle greater than 8 degrees or else their image is tiny. So, they jack up their angle and run their scanners in a detuned state. Also, some of these people may only have 20K scanners (or some other speed) which make it impossible for their systems to ever be tuned the same as a 30K set. These reasons are why I designed Spaghetti's optmizer as it is. It will compensate for the wide angles and slow speeds as best as it can and give decent results on cheap scanners. Spaghetti is made for the low man.
-
Gary, I think you might be missing my point here.. This isn't about scanner tuning really it's about standardization. What I am saying is that there are two standards I see emerging in 'common man' work: 1) ilda frames (and shows) that are blanked assuming dpss blanking. 2) ilda frames and shows that are blanked assuming galvo blanking (like the ilda test frame).
We should either 1) standardize on the traditional method of releasing frames blanked assuming galvo blanking, with the ilda test frame as the standard, or 2) throw the ilda test frame out the window except for x/y tuning and standardize on releasing frames that assume dpss/AOM blanking (this requires that a tuning/blanking standard be developed for this mode).
-
I'd prefer them to be released with computer screen blanking so that they look correct on a computer screen. You can then apply whatever optimizations to them that you want to make them look good on your scanners.
-
I think Gary is (sort-of) right on this one.
A set of frames is just that. It's a set of frames. It does imply some characteristics about how it gets optimized for scanning; but that implication is only a matter of the total number of points it has.
Obviously, without omitting points, it will take a certain amount of time just to get through all of the points present at some rate of points-per-second.
Other than that, one of the more complex tasks I had to accomplish with my code was to figure out how to make a set of frames look good, at or about a specified frame rate, on any given projector.
That is why there are so many parameters for optimization AND it is why those parameters are stored in the resulting wave; so that the optimization can be understood at a later date, undone and redone for a different system.
I think you are looking for The Golden Fleece!
There is no commonality between all of the laser projectors that are out there.
That is just another reason why the ILDA file format is so important!
It is the art without any concept of time.
James. :)
PS. Sorry Gary. I just can't aggree with you completely. What fun would that be? %)
-
Ok, but you are basically agreeing that they should be in galvo blanking format, which I also agree with. And we know that these can't be sent right to the DAC (if it doesn't have point shifting) on a dpss system and expect them to look right. Gary adds lit and or blanked points at the transitions to compensate. What I'm suggesting is that is won't be necessary to add so many points when we let the controller (EzAudDac or RIYA in this case) do its thing with blanking shifting.
-
ILDA is ILDA!
There are no "modes".
ILDA is not intended to be shoved into a projector as-is.
The idea of optimizing vector art and saving that as ILDA so that it can be fed into a program that has poor or no optimization capabilities of its own is WEAK.
If you're using a program that is written to display ILDA frames and it has no means of optimizing them, GET ANOTHER PROGRAM!
I can think of at least one good one that is free! ;) ;D
James. :)
PS. The stream of data that flows from a laser signal generating application to the DAC (of any kind) is not ILDA!
It need not, should not, and can not be standardized!
-
There are many frames out there, the best hand-done and most popular frames ARE pre optimized, and if you try to run those through an optimizer again, generally you get crap! The only thing that needs to be done to these frames for proper display is the blanking shift! no more points added! This is not a weak idea dude, it's been around for a long time and has been used by the best with success.
-
That is a good and valid point.
It's also why you can turn off the optimizations in LaserBoy.
There are some GREAT examples of ILDA frames that are point ready.
Dean's program produces waves, that, when converted point-for-point into ILDA are point ready AND LaserBoy would wreck them if they were optimized before they were converted back to wave.
Similarly, there are some unbelievable frames out there that were hand drawn, a point at a time, to take full advantage of the inertia of the galvos. The frames look really weird on a computer screen. But that's not what the artist was looking at when the frame was drawn!
James. :)
-
Yes, ok. So now that that's straight, let's get back to the subject of in what state a frame should be sent to a controller driver, and what a controller driver should do with that frame. If the frame is known to be pre-optimized such as the dolphins sequence, it should sent to the controller driver as-is. The controller driver then takes it and applies the neessary blanking delay because it has been set up previously to work with the DPSS rig that it is driving. What you get out, whether it is the dolphins frame or the ilda test frame, is a proper-looking frame.
-
I think the issue is where you find the intelligence that can, if necessary, make two distinctly different modifications to the stream of data that eventually gets clocked out the DAC to become a set of analog signals.
1. points optimization
2. color to scanner time alignment
If you do it in the driver, then you need to know how to tell your driver what to do, when.
If you do it in the preparation of a wave, then it might be well noted in the header of the wave.
You can't expect to set standards on how this is done!
This is the very art of it!
It is what makes one system better than others.
It is also what leaves it open to infinite future possibilities!
James. :)
-
Yes, I was only suggesting that #2 be done in the driver/controller, as it is well suited for it. It doesn't need to be told what to do, it will do the alignment all of the time. The alignment tuning could be done with a set-up program (using the ilda test frame) just for the driver itself. Once it's set, it can be forgotten!
-
Absolutely! ;D
Once I figured out that my PCAOM is about 7 samples @ 48KHz ahead of my galvos, that has remained a constant in my universe!
However, your universe may vary; hence the ability to adjust for such an anomaly.
James. :)
-
There is a related issue that I saw at SELEM.
300Evil's RGB was weird on the green.
I think the rise time was just too long.
It was really strange. Sometimes the green was there and you could see white (not magenta!) and other times it looked like there was no green there at all.
I think that is something that could be compensated for in software, but should probably be corrected with a better laser diode driver.
Sample shifting won't fix this issue.
This is a matter of rise time, and how hot the diode is when it is asked to come on again. This is a much more complex issue of thermal hysteresis (I think).
James. :)
-
I was only suggesting that #2 be done in the driver/controller
Eeeiiiiiiwwww !!!
James. :)
-
if you have downloaded 1.08, download it again as there has been a bugfix fir the single frame writing function.