Raster Scan (Electron Microscope) Rotation Algorithm?

[John Larkin]

On Mon, 04 Apr 2005 22:22:12 GMT, Jeff Miller
<cornheadorama@hotmail.com> wrote:

Hi,

I haven't made a whole lot of progress on my electron microscope
digitizing project this month, but I hope to finish in the next 6-8
weeks. Perhaps sooner. The last decision is whether to use an MCU or DSP
in the project, or to stick with discrete logic as I'd originally planned.

To recap and give some background, the heart (arguably) of a scanning
electron microscope consists of a pair of X and Y scanning coils which
are driven in a raster-scan pattern not too unlike a television
deflection yolk. In fact NTSC scan rates, interlace and all, are
sometimes used so that the output can be displayed on a TV monitor.

As it turns out, scan/image rotation is a fairly common feature of high
end scopes. I'm wondering what it would take for me to incorporate such
a feature into my project. I'm not sure whether or not this feature is
limited to digitally controlled scopes: I'd very much like to know.

I'll be driving my coils with 16 bit D/A converters: I want to
experiment with ultra-high resolution images blown up to poster size.

Of course rotating the scan in multiples of 90 degress is trivial, but
ultimately I'd like arbitrary rotation or at least in 45 degree
increments. I could probably get an idea of the algorithm I'm looking
for by drawing some superimposed squares, mapping point to point and
finding the pattern. For example: if the baseline (non-rotated) image is
generated using 0,0 as the upper-left origin and proceeds right and down
as it does with traditional TV, then for a 45 degree counter-clockwise
rotation I'd load 0,32K in for the origin.

I see a shift problem looming. I think I see the solution, though.
Although I'm using 16 bit D/A, software limitations will limit my image
to 32K by 32K pixels. In the example above, then, for the baseline image
I'd load 16K,16K in as the upper-left origin and 48K,48K as the
lower-right end of frame. For 45 degree counter-clockwise I'd load
approximately 11K,32K in for the origin: that's 16K divided by 1.414 for
X and center of range for Y.

But perhaps you're familiar with this algorithm? Are sin, cos, or tan a
necessary part of the algorithm for arbitrary rotation? Do I really need
more that 16 bits of D/A resolution to do this right? If the rotation
angle is very small, for example such that the origin of the first line
is at ~16K,16001K and the end of the first scan line is at ~48K,16K it
seems like I might need as much as 30 or 32 bits of resolution to slowly
jack up the Y value by one pixel over the course of the scan line.

I should probably be using signed notation in these examples to make
them more clear.

Is there a way to do this in the analog domain? In actuall fact I'll
probably have 4 D/A converters total, two MDACS for the scanning and two
more driving the reference of the MDACS to set gain. Normally the gain
dacs would be loaded with the same values to give equal magnification in
x and y: in fact a single DAC could be used to set both gains but I want
to be able calibrate them. At some level it seems like I'm just changing
the "slope" of the scan lines and that perhaps only a pair of analog
multiplications is needed: perhaps the output of the X DAC is simply
multiplied by a term that varies with the degree of rotation and then
multiplied by the Y term. And vice versa?

I can't quite get my head around it, though I think I'm almost there.

Anyone know how this type of thing is done in practice, or have any
comments?

-Jeff

If the deflection coils are symmetric and can be driven with arbitrary
waveforms, and you have a pair of scan sawtooth waveforms or whatever,
you can do arbitrary rotation with four multiplying DACs and two
summing amps.

D1 = k1 * saw1 + k2 * saw2

D2 = k3 * saw1 + k4 * saw2

where D1 and D2 are the analog deflection amp inputs

Saw1 and saw2 are the old analog x, y sweep sawtooths (sawteeth?)

K1..K4 are digital vals you load from your PC into the multiplying
DACs, with the usual sin/cos triggish stuff.

This is cool because K1..K4 do rotation and zooming, too. You can even
sort of un-bend trapezoidal distortion, like if you're not hitting a
surface straight-on. A little dynamic focussing helps here.

There are more digital ways to do this, too, but quantization issues
can get nasty.

Linear Technology has some nice fast 4Q 16-bit mdacs.

John

 

[Jeff Miller]

John Larkin wrote:

If the deflection coils are symmetric and can be driven with arbitrary
waveforms, and you have a pair of scan sawtooth waveforms or whatever,
you can do arbitrary rotation with four multiplying DACs and two
summing amps.

D1 = k1 * saw1 + k2 * saw2

D2 = k3 * saw1 + k4 * saw2

where D1 and D2 are the analog deflection amp inputs

Saw1 and saw2 are the old analog x, y sweep sawtooths (sawteeth?)

Mmmm hmmmm. That's about where I was headed.

K1..K4 are digital vals you load from your PC into the multiplying
DACs, with the usual sin/cos triggish stuff.

Screeeeech.... what usual sin/cos stuff? Dynamically? Or statically, ie:
knowing desired angle of rotation you calculate a pair of sin/cos values
and load them into the appropriate (static) K's and then "go".


Screech? Staticly of course, except if you want the image to spin.

Ah, OK no problem.

This is cool because K1..K4 do rotation and zooming, too. You can even
sort of un-bend trapezoidal distortion, like if you're not hitting a
surface straight-on. A little dynamic focussing helps here.

Mmmm hmmm, dynamic focus is next on the agenda: I might try dynamic
astigmatism correction as well. I'm even considering "zoned" or
pixel-by-pixel (ie: digital dynamic) focus: auto-tuned by FFT'ing the
samples and optimizing for the higher frequencies, of course


I was thinking once of making the saws with two more dacs, so then you
could know the addresses at all times, so then you could have a focus
lookup table. Not per pixel, but in a reasonably-sized checkerboard.

Exactly what I had in mind. Definiteley something to think about "for
later" as most imaging at high mags deson't benefit from dynamic focus.

Yeah per pixel would take a ridiculous amount of memory.

-Jeff