New EYEMAGIC Scanners EMS7000

[JohnYayas]

many people talked of that detailed test that happened at the LEM (notes, photos, tables etc etc etc)
since then, none has managed to post anything more detailed

so until then, i think this discussion is pointless. share the data, pics and test methodology and then we'll talk again

It might be pointless to you but considering that there were several independent witnesses as FLEM who can verify what is being said, I don't think it is pointless at all. At this point, the only course of action is for someone to test and document that they DO perform as advertised. So, if the ones at FLEM were faulty then it should not be hard for Tom to send a set to Buffo for testing. Or he can send them to me. I'll test them. But, I won't send them back.

[White-Light]

QuickShow and the Flashback 3 that it runs on are limited to 45k from what I have been reading, you also can not export to ilda as i understand it. I am not an owner of QuickShow/Flashback 3 so I guess I shouldnt list specs. But again just as I understand it, Pangolin QuickShow and Flashback 3 are pointless in this testing. But I guess we will wait and see how it was tested.

Sorry you're right, Quickshow would be limited to 30kps.

Most probably tested with Beyond or LD2000 an a QM board.

You can get a copy of the ILDA test patterns from the links at the bottom of this page:

http://www.laserfx.com/Backstage.Las...Scanning3.html

[dsli_jon]

Hey Adam -

Request for some further clarity, on what (would-be) a rather important-point:

In the interest of clearing this up...He ran the scanners at 60K and 8 degrees scan angle and showed that the ILDA test pattern looked terrible. Then he reduced the scan speed until the pattern looked normal, and that was when the speed had been reduced to around 45K.

..Can we *confirm* that these were the 5.3mm and not the 6.8 x 12mm mirs at FLEM?...Obviously, that would 'make a bit a difference' in real-world performance... Jus' sayin'..

..Also, we verified that the EMS-4000 scanners that Flecom had did not live up to their advertized performance either

..'as-advertised'...with *Frank's* size-of mirror? Again, an important-factor, please clarify...

Other-question, answered..

..I'm not trying to 'start any riots', here, just calling-for further 'clarity'...

ciao
j

[heroic]

I don't know.

Yep running fast you lose a little brightness but on the other hand you can remove flicker caused by a high point count which can itself (the point count) add brightness back.

There is absolutely no intrinsic reason that high point rates should reduce brightness, as long as your lasers are capable of a fast rise-time. Direct injection diodes are most certainly capable of a fast rise time (some few nanoseconds). The only reason you lose brightness by running fast is the deadtime added by the buffering scheme used on FB3s (and maybe QM cards). Other DACs don't have to work this way.

[MIIKKKLLLL]

Visually, the beam appears to be brighter because the image you see of the beam is longer "printed" into your eye when you set a low KPPS.

And I absolutely don't agree with this (http://www.famous-company.com/pm_nyquist.htm) because when the scanners draw some "dots", when you have faster scanner you loose less time between 2 dots with the laser source "off" and that result in a upper XX% dutycycle time.

So we can say that each kind of frame need to be optimised for a maximum impact and minimal flickering.

[heroic]

Visually, the beam appears to be brighter because the image you see of the beam is longer "printed" into your eye when you set a low KPPS.

This is incorrect. Given the same frame data, the off-time is set by the number of points that the laser is turned off for and the on-time is set by the number of points that the laser is turned on for; absent DAC deadtime and slow DPSS rise time, the point rate is irrelevant since the average power is set by the ratio between on-time and off-time.

The reason the FB3 is dimmer at higher point rates is that it seems to need a little bit of time at the end of a frame scan to get its ducks in a row, during which time the lasers are off. This is common in systems that use double buffering- when you get to the end of buffer 1, you can't start scanning buffer 2 until it's full. This is actually why many video games use triple buffering, since you never have to wait to switch buffers that way.

Etherdream uses a circular buffer with no ends, so it scans continuously and does not suffer from this problem.

[JohnYayas]

This is incorrect. Given the same frame data, the off-time is set by the number of points that the laser is turned off for and the on-time is set by the number of points that the laser is turned on for; absent DAC deadtime and slow DPSS rise time, the point rate is irrelevant since the average power is set by the ratio between on-time and off-time.

The reason the FB3 is dimmer at higher point rates is that it seems to need a little bit of time at the end of a frame scan to get its ducks in a row, during which time the lasers are off. This is common in systems that use double buffering- when you get to the end of buffer 1, you can't start scanning buffer 2 until it's full. This is actually why many video games use triple buffering, since you never have to wait to switch buffers that way.

Etherdream uses a circular buffer with no ends, so it scans continuously and does not suffer from this problem.

Depends on if frames are repeated when they are drawn too fast. Sometimes it isn't possible. If a frame, drawn at 30000 pps takes 0.1 seconds, it will take 0.05 seconds to draw at 60000pps. This means less on time and that frame will indeed appear dimmer than the frame at 30000pps. If the show frame rate is set at 10 frames per seconds, the next frame will be drawn if at 30000 pps. If scanning at 60000pps, there is either .05seconds of darkness or the first frame is repeated. In the case of 30000/60000 it happens that two frames can be drawn in one frame slice and the brightness of a frame will be about the same. Buf, if the pps is increased from 30000 to 45000 then it takes .075 seconds to draw the frame. There isn't enough time to fill in the darkness. So, either the software does nothing for .025 seconds or it draws either the first or second frame which makes the first frame last too long or the second frame come early. This is only one software scheme, though. Another scheme could be to interpolate points so that the frame takes the same time at 60000 as 45000 as 30000. Or, the software can simply adjust the point rate per frame and make it work that way. Regardless, given the exact same frame, if it is drawn once at 30000pps and once at 60000pps it will appear dimmer at 60000pps because the on time is 1/2. You can't argue against that and it has nothing to do with buffering.

[heroic]

Except that this is a solved problem in the AV industry.

[JohnYayas]

Above you said that with the same frame data the frame will appear the same. Now you are saying that it won't but it is possible compensate by changing the frame? Isn't that what I just said?

[heroic]

Above you said that with the same frame data the frame will appear the same. Now you are saying that it won't but it is possible compensate by changing the frame? Isn't that what I just said?

It is not possible to compensate for DAC deadtime by changing the frame.

Moreover, this idea of one frame to a buffer is wrongheaded in the extreme. Frames are not reflected in the hardware of the system in the same way as they would be in a video environment. What you do to eliminate deadtime is to turn your stream of frames into a stream of points. You put as many as you can into the buffer and you start filling the next buffer immediately from the point you left off. If your original source has too few points for your DAC, then you resample the points. Because you do this on a small scale, point by point rather than frame by frame, there is no repeat issue. There is no reason for a frame boundary to be a buffer boundary.

Better still, having decomposed frames into point streams, you ditch the double buffering entirely and use a circular buffer of points. Then there is no buffer switch issue.

When I listen to a 44.1 kHz audio CD on my 96 kHz sound card, I don't get deadtime between CDDA sectors. This has been solved since about 1985, when sample rate converters became a common feature of digital audio systems.