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