Laser Projector (Red, Green, Purple) "Laser 3D Party Light" from Spencer's

[swamidog]

that could also be a color blanking delay issue.

without a way to control the blanking rise and fall time of the lasers, i would expect to see issues like that.

do you also see issues with yellow lines having a little red on one end and a little green on the other?

So, after poking at this thing for quite a while, I think there is a bug in the show card's interpretation of the ILDA format 0 data.

James will attest that I'd been trying to get to the bottom of why my laserboy-generated figures were missing vectors, sometimes quite a few. I suspected an off-by-one error somewhere in the chain, and I think it's in the Spencer projector showcard.

The bug is this: The color and blanking status of a vector is taken from a LATER vector instead of the vector it belongs to. This means lines change color before they should, or blank before they should, and in general make messes of some portions of some graphics. In some graphics, the effect is not noticeable, I think because it occurs within a dwell time period.

Here is one example that comes from a frameset that ships with the projector and is otherwise available on the 'net, abst-new.ild. This is frame 498 as rendered in LaserBoy, but zILDA shows the same coloration:


The 'walls' of the tunnel are cyan (blue+ green) up until the green ring, and then green outside of it.

Now look at how this image is rendered by my copy of the Spencer projector:


If you consider the order of the vertices as described by laserboy, the cyan line stops 'early.' This line is drawn from top-right to bottom-left of the image. I verified that the Spencer projector draws the points in the same order by creating a very large circle and scanning it very slowly to see which way the circle was drawn. The projector does draw the points in ascending order as indicated by laserboy.

I have other samples as well; some are posted over at the LB forum, some are just lying around on my camera. In my mind, there's no question that the showcard is prematurely adjusting the lasers when reading vertex information and sending it to the DAC. I haven't determined if it's a fixed offet error than can be corrected simply by shifting all of the color information one vertex forward in the ILDA file or if it's more a complicated timing issue that will vary based on the scan speed.

I have noticed that the magnitude of the error is larger for higher scan speeds, but I think this is just due to the fact that at high scan speeds the scanners are just more physically 'behind' the current command than at low scan speeds. I have to say at scan speeds of 5 and below, you can really see the 8-bit-ness of the DAC come through in the art.

Anyhow, I just wanted to get the group's opinion on what they have seen and how easy they think this may be to correct with a "SpencerProjector" filter we could pass ILD files through.

Best,
tribble

[tribble]

that could also be a color blanking delay issue.

It's possible. But, I've seen it in so many different figures, so closely linked to the positions of the vertices, I don't think that's it. Look at these pictures; this is one color, direct drive red, at a fairly slow scan speed.




... and on this one, an entire side is missing! It's not like it 'fades out' either; it's a sharp division between lit and blank, which makes me think the laser timing is much much faster than the scanner speed in these particular images, just occurring at the wrong time. By exactly one vertex definition.




I understand that there are sync issues with scanner waveform generation and laser modulation waveform generation, but things seem to correlate so well with vertex position and order and not so much with scanner speed, my money is on the bug in chinese code. Probably the only way I will ever know for sure is to program the suggested shift in color assignments and see what happens (unless someone more familiar with ild writing code volunteers to do it first.)

[james]

If this is in fact a error in the way the internal DAC decodes ILDA files, then there might be an easy fix for it. It would be pretty simple to add an effect to LaserBoy to correct it. If we can rule out the effect of improper timing between the scanner and the color signals, then this is probably a consistent problem that can be corrected in an every-case scenario.

While we're at it, we could add promoting all 2D format 1 frames into 3D format 0 frames in the same effect. We'll just call it the Chinese effect!

BTW LaserBoy lets you export bitmaps of the art. One of these days I should put a switch in there to capture the whole screen with the extra artifacts intact. Everything you see inside the LaserBoy window is actually a memory image of a bitmap anyway!

James.

[tribble]

As an aside about our galvo amp discussion... ragerlazer has posted a giant photo of the "25k" scanner amp board from goldenstar, and I recognize a few of the improvements we were discussing. Yet, there are some components missing, perhaps required only for the 40K board? I thought y'all would be interested in seeing it if you haven't already:

http://www.photonlexicon.com/forums/...464#post249464

[tribble]

If this is in fact a error in the way the internal DAC decodes ILDA files, then there might be an easy fix for it. It would be pretty simple to add an effect to LaserBoy to correct it. If we can rule out the effect of improper timing between the scanner and the color signals, then this is probably a consistent problem that can be corrected in an every-case scenario.

I'm interested in pursuing this... I'll let you know if I get time to set up the development environment prerequisites for building LB on my windows box. If there's a simple option we can toggle to apply some sort of correction to the output of all the frame effects and the optimization function, I think it would greatly enhance the image quality by eliminating a lot of 'tails' that are actually 'lead-ins' in processed art.

While we're at it, we could add promoting all 2D format 1 frames into 3D format 0 frames in the same effect. We'll just call it the Chinese effect!

You know what's interesting? I've found a pantload of .ild files on the web, and zILDA reports some of them as type 1, and they STILL PLAY FINE. Whoa! Not sure what the difference between 0, 1, and 2 is, but 2 seems to be a killer, and 1 sometimes but not always.

Is there a document somewhere that describes, at a byte-by-byte level, the standard for the different formats? I googled around and found a draft standard for format 5, but it was a bit thin on the earlier specifics.

[james]

In a nutshell, Formats 0 and 1 are vector art sections, 3D and 2D, with no included color definitions. Format 2 is not vectors. It's a palette. It is also RARELY supported by any ILDA file reader / writers. Formats 4 and 5 are vectors 3D and 2D with RGB color definitions added to the vectors.

James.

[DogP]

The bug is this: The color and blanking status of a vector is taken from a LATER vector instead of the vector it belongs to. This means lines change color before they should, or blank before they should, and in general make messes of some portions of some graphics. In some graphics, the effect is not noticeable, I think because it occurs within a dwell time period.

I've noticed this on some things as well. My assumption was either that they adjust DAC/laser timing on ILD frame samples, or that they don't and we need to. I never really investigated it, but on a system with a fixed sample rate, there could be several samples between the desired point, and the galvo actually getting to that position... so there has to be a delay for the lasers (which are much quicker). I had a discussion with James about this a while ago. The problem here is that if they do adjust for it, they probably adjusted for speed 10 or 15. If you're running at speed 20, their fixed offset is probably gonna be wrong. If they don't adjust for it at all, then the faster the beam is moving, and the more obvious this difference is gonna be.

Laserboy supports this timing shift on wave files, but not on ild files (AFAIK). I was thinking about adding that support to ild files, but haven't gotten to it (or maybe just trying to tweak timing by outputting a wave file with an offset, re-importing without offset and outputting ild... no idea if that'd work). I figured I'll probably get better results from the sound card DAC, and the timing shift is already supported on that, so my time would be better spent doing that.

The other thing I've seen is a dwell at color changes. James was strongly against this, but I've seen programs that do this, and it does make the image look better if you're not able to adjust laser timing. Of course it's adding extra points, which are just wasted, and kinda makes brighter dots at ends of lines, but it avoids stray lines. You can see the brighter dots on the top lines of the Nintendo logo at 1:35 ( http://www.youtube.com/watch?v=Drd8kk51vmM ), where I added points to get rid of the gaps/tails. At 2:10, you can see the Atari logo still has the one tail at the top that I didn't fix... and related to this discussion, note that the color changes happen at different vertical positions, even though the points in the ild file are actually supposed to change color at the same vertical positions. If I added a few points at each transition, it would have stalled enough to change at the correct spot, at the cost of more points and bright spots.

I'll try to get an answer for this though... when I'm probing around with my scope, I'll try a file that has a bunch of blanking points at zero deflection, and turns on the lasers at one non-zero point. If the laser turns on at the same time as the DAC goes non-zero, then there's no time shift (purposeful or not, at least with these test parameters)... if not, I'll try to determine the delay (fixed time, samples, etc).

DogP

[james]

LaserBoy does not support time shifting in ILDA files because there is no such thing!

ILDA files have no information in them at all related to time!

The idea of that format is to be able to exchange art between different systems. It is nothing but consecutive frames of vectors with or without color definitions.

To that end, it works just fine!

That implies that whatever system is used to decode them and display them is responsible for optimizing them.

One only needs to consider the idea of 3D art. Think about it. What is the point of 3D art? ~To show it (in 2D) in different rotations. Every different rotation will have all kinds of different angles. There is no way to put dwell into a 3D ILDA frame in any meaningful way.

That needs to be done within the system that displays it.

If anything, I was trying to convince DogP that building a LaserBoy DAC would give him much better and more controllable results.

Waves are fully cooked and ALL ABOUT time! They have a fixed sample rate from the first sample to the last. The time shifts between the scanner and color signals are constant from beginning to end, based on the fixed rate.

James.

[mixedgas]

I'll try that next time I have it open... what effect will I be looking for as improvement?


I tested the scanner speed via the low-fi way; with an .ild with 250,000 points and a stopwatch. Mine turns out to be about 15Kpps at Spencer Speed 20. So, does that mean the test images are about 15Kpps at 16 degrees?

Your getting it. Although that sounds a little too good to be true. Go back and try it at 8 deg. I'd also bet that your card removed a lot of points. It seems to look for changes and skip some redundant anchor points etc. I'd also bet it turns updates off during interrupts to handle the SD card buffering etc.

When you install the caps at the leds, you should see improvement on de-acceleration and positioning accuracy after long jumps. Any "swimming" or other motion in a complex still frame should be reduced.

Steve

[tribble]

I figured I'll probably get better results from the sound card DAC, and the timing shift is already supported on that, so my time would be better spent doing that.

I suspect you are right on the money, there. Don't worry about digging after this color-shifting-blanking-weirdness if it doesn't support your work on the soundcard DAC project. I will get there as I have time. I think the first thing I will do is cobble together an ILDA file reader, leveraging James' code if possible, to see what's really being fed to the showcard. Then I can be absolutely sure what it's getting when I feed it some random file or other.

The stopwatch method is not good for determining actual peak scanning speed as you said, but at least it tells me roughly how many points per second I should have if I want to do long-term synchronization with music.