Now, whenever I eroded with my e-structuring element, I was left (usually accurately) with a dot (pixel = on) marking all the occurences of 'e.' By dilating this image using one of the original 'e' sub-images, I generated an image which looked like the original, but the areas not covered by e's were zeroed out. Finally, I superimposed this on the originally thresholded image using a colorful entry in the colortable - making the e's stand out.
I then proceeded to apply this same methodology to the other vowels. I succeeded (for the most part), but only after some significant enhancements. The most substantial improvement came when I had the script locate and zero-out all letters [g, l, m, f]. Without these changes, the sript would identify g's as two e's. It would also "find" i's in the l's and f's (and d's), while the m's just caused general confusion, depending on which letters it was neighboring. A further improvement in the vowel-detector's accuracy came when I zero's out all known letters as they were identified. This way, each section of the script left the image in question with fewer active pixels to identify (or confuse).
The last sections of the program deal with cases where the letters are rotated. I look for vowels here by rotating the structuring element by various degree-increments (determined experimentally as optimal), and otherwise processing the images and subimages in the same manner as before.
Figure 1: Simplest Case: Perfect results for all vowels. Each vowel marked with different color.
Figure 2: Same algorithm, but some errors occurred due to variations in letters' appearcance due to thresholding of aliasing and the quality of the scanned original. "tr" combo was mistakenly recognized as 'u', and and some smudged m's were partially tagged as o's.
Figure 3: Rotated vowels were recognized - but very inaccurately. Order of processing (for each vowel) is significant here because rotated letters look like other non-rotated letters. "i" is particularly unlocatable.