Converting the images (and the code that uses them) to be POT compatible is out of the question.[/quote]

While reading the NPOT textures from file, you could resample them to the nearest POT dimensions in software. If you don't want to lose detail, you might want to resample up only, rather than nearest.

After buffering the resulting POT textures to GL, use a texture matrix to scale the bound textures to the correct aspect ratio on the geometry.

Converting the images (and the code that uses them) to be POT compatible is out of the question.

While reading the NPOT textures from file, you could resample them to the nearest POT dimensions in software. If you don't want to lose detail, you might want to resample up only, rather than nearest.

After buffering the resulting POT textures to GL, use a texture matrix to scale the bound textures to the correct aspect ratio on the geometry.
[/quote]

Resampling AND altering the texture coordinates at the same time will screw the rendering. Either resampling or modifying the texture coordinates.

The old gluBuild2DMipmaps will do the resize automatically for you, in exchange for you losing all control over how the resizing is done. You'll likely want to replace this with your own resample function for production/release, but it remains a means of finding out how well (or not so well) this is going to work out, and that doesn't require a huge amount of code work on your part.

It's actually slower than just resizing and loading yourself, so be aware of that up-front and don't be put off by the fact that your textures now take X times as long to load as they previously used to.

An alternative, for images that don't need to repeat, is to pad the image to the nearest powers of two, then do the texture matrix trick mentioned above.

I'd recommend modifying the texture matrix as the best solution, this means no loss in detail, although large textures might give you quite a bit of overhead(i.e a 1025x1025 would result in a 2048x2048 padded texture).