Differential Geometry

General — Alex @ 5:32 pm

I have a couple of weeks left before my internship begins on June 23, and I’ve been trying to bone up on differential geometry. Supposedly the Advanced Multivariate Calculus class I took last semester prepared me for this, but we didn’t spend nearly enough time on the two theorems most important for grasping the fundamentals of dif geo: the implicit function theorem, and the inverse function theorem. None of the d.g. books I’ve located in UH’s library seem to grasp that you might be approaching the subject without having mastered those two theorems, able to see when they apply. But I haven’t, and I can’t. So back I go.

Possibly relevant posts:

Project: Automated Curve-Fitting for Font Design

General — Alex @ 8:26 pm

Since I discovered the world of TeX, and a little later, that of MetaFONT, I’ve been interested in font design. Particularly, I’ve been intrigued by the problem of creating high-quality outline fonts. It seems to me that the quality of the programs that produce the Computer Modern fonts are just a little(?) beyond the dedication and skill levels of amateurs like me. Since the only other way of producing outline fonts is to directly create the outlines, I’ve been interested in the problems involved in turning physical sketches of characters into their mathematical representations. All of this feeding back into my interest in math and curves, of course :). Here are the results of my preliminary research:

The Problem Defined

The main problem encountered in turning physical sketches into fonts is that of fitting the various functions used (splines, bezier curves, quadratic curves, etc.) to the bitmap images. In turn, the primary problem involved in fitting these curves is determining the edges of the bitmaps.

Edge-finding

Originally, this was my stumbling block: how to determine the edges of the individual glyphs, without human guidance. There are algorithms, like Hough Transforms, convolution filtering, and others, but these require too much mathematical sophistication, and essentially are only capable of transforming one image into another image, albeit the second image is a monochrome image, and has ‘less’ information than the first. But, what we want ideally, is a method that not only finds edges, but also determines the connectivity of these edges. In other words, we want to determine not just edges, but also contours. This makes sense, considering the problem: it is important that the counters of the font, for example, are closed contours. General algorithms exist for this also, but all IMO are ad hoc, and require even more mathematical sophistication. But, we don’t want a general solution, we want one that will work under the conditions we assume the characters will be scanned: the input will be grayscale bitmaps, with high contrast, and there will be no gaps in the characters that the algorithm will need to bridge.

Considered from this light, we can find the edges and contours in one fell-swoop, if we make the reasonable assumption that all edges occur at a given level of gray; anything above this threshold value is within the character, and anything below it is outside of the character. Essentially, the question of edge finding is reduced to determing transition points around this threshold. Here is the basic algorithm for identifying the contours:

1. Locate an adjacent pair of pixels, where one has a value above, and one below, this threshold value. Mark the location of these pixels in a ‘visited matrix’

2. Use the inverse function G’ to determine where between the two pixels the edge lies.

3. Proceed in a clockwise fashion along the edge, using a pair of pixels with high contrast adjacent to, and possibly sharing one pixel with the current pair. Mark this pair in the visited matrix.

4. When you return to pixels already visited, the contour has been closed.

5. Repeat this process until all pair of high contrast pixels have been visited, ensuring all contours have been located

Curve-fitting

The first step in the process of fitting curves to each contour is to generate a polygonal frame for the contour. Basically, a tolerance is chosen for the fitting, and a line is extended from the current point to the last such subsequent point such that the distance from the line to the true edge is less than the tolerance. This eliminates unnecessary points from the fitting process, and makes it easier to fit the character with less curves.

Fitting the actual curves is done in an analogous process: depending on the type of curve being fitted, a cost function and a tolerance are chosen (e.g., in the case of the quadratic curves, a squared error cost function is chosen so least-error optimization can be used). Each curve is fitted to as many lines as it can without exceeding the threshold.

Later

As is, the algorithm described doesn’t account for sharp corners, but later I will describe the method used for determining the presence of corners, then recap the entire algorithm. When I have finished writing a program illustrating the algorithm, I will post it.

Possibly relevant posts:

NSCS Responsibilities

General — Alex @ 12:37 pm

I have the honor of being a cowebmaster of the University of Houston’s National Society of Collegiate scholars. This summer, my partner and I are to redesign the website, to make it more competitive with the other chapters’. Since I’m going to be out of town starting Jun. 23, I would like to get all this done before I leave. So far, we’ve decided that the site needs a facelift, and we shall add a database backend that will allow our members or officers to track their participation in events, among other things. I am a little stymied with how to set about this– Miriam, my partner, is doing the visual design part, while I’m doing the backend. This troubles me somewhat, as I don’t know how we’ll handle the necessary integration when the time comes. However, I trust her skills, and mine, so we’ll work it out somehow.

BTW, I bought a USB flash drive w/ 128Mb of memory– a JungSoft Nexdisk– which I used to painlessly transfer a whole bunch of information off of an old computer: most importantly, the entire 2+ years of blogs I made on my previous websites. So I shall import those today.

Possibly relevant posts:

computer Business

General — Alex @ 7:53 pm

Surprisingly— usually I do nothing when I’m on vacation— today has been a busy day for me. I helped my sister to clean the house of a lady that goes to church with us, who had a stroke. Then we went out to eat with her at a Caribbean restaurant (she’s also from the Caribbean). After we dropped her back home, on the way home, we passed by a place that was selling discount computers. Since I’ve been drafted to help my cousin back in Barbados to get a computer, I stopped to look-see.

I ended up buying a pretty good system. The only problems are cosmetic, so far: the chassis is white and scuffed, neither of which is good; the mouse and keyboard supplied are white and a sparkly gray, respectively; and the speakers I got are black. So I’m going to Fry’s right now, to see how much it would cost to buy: a black printer, a black mouse, a black keyboard, a black monitor, and maybe also a black cdrom and floppy drive. My budget right now is $335, so I’ll be cutting it close, if it’s even possible to meet at Fry’s. We shall see.

Possibly relevant posts:

Revidivus

General — Alex @ 7:52 pm

I’m back– previously nucoder.l33t.ca– after several months of downtime. My never-ending todo lists have been wiped, so I will start from scratch, and hopefully make a better job of it this time around. Especially considering I’m paying for this hosting now…

This summer, I will be interning at Lawrence Livermore National Labs in California, so I figured it would behoove me to set up an easily accessible recording system, as I won’t have ready access to a personal computer there. Hence the use of MT. I eventually, *if* I can find them, will upload the 2+ years of entries I had previously accumulated, if only for my benefit– it’s a neat way to see how much and how little I’ve changed over time.

Today, I discovered Linearized PDFs: have you ever wondered why PDFs that you read over a dial-up line tend to take so long to become viewable? That’s not memory or any of the other usual culprits, it’s because regular PDF files are meant to be read from EOF, so the viewer must download the entire file before it knows how to render *any* of the pages. Linearized PDFs are an attempt to help optimize PDFs for viewing over networks. To date, I can’t recall having encountered any files that use Linearized PDF technology, but then, I just found about it today.

Possibly relevant posts:

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
(c) 2008 ChapterZero | powered by WordPress with Barecity