MySQL-Python on MacOSX 10.6 Snow Leopard

GCC was reporting a file not found error for stdarg.h early in the compile of MySQL-Python-1.2.3 on MacOSX 10.6 (Snow Leopard). I was staring right at the file, “/Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h,” so it most certainly did exist. The problem seems to have been caused by the GCC compiler version and architecture I was using with my Python, Apache and MySQL installations.

$ gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
$ mysql --version
mysql Ver 14.14 Distrib 5.1.35, for apple-darwin9.5.0 (i386) using readline 5.1
$ /usr/sbin/httpd -v
Server version: Apache/2.2.17 (Unix)
$ python --version
Python 2.6.2

This was not obvious until I went to the trouble of downloading the MacOSX10.4u.sdk files and still had the same error—but I will spare you the tale of the hours I lost banging my head.

For reasons that don’t matter here, I had previously manually compiled both Apache and MySQL to use 32-bit architecture. As I understand from all the help I looked for online (this site where my issue with stdarg.h was part of the discussion was particularly helpful), all the various libraries, Python, and the GCC compiler need to be using the same architecture. I found two solutions:

MySQL-python-1.2.3 $ sudo CC=/usr/bin/gcc-4.0 python setup.py clean
MySQL-python-1.2.3 $ sudo CC=/usr/bin/gcc-4.0 python setup.py build
MySQL-python-1.2.3 $ sudo CC=/usr/bin/gcc-4.0 python setup.py install
MySQL-python-1.2.3 $ sudo ARCHFLAGS='-arch x86' python setup.py clean
MySQL-python-1.2.3 $ sudo ARCHFLAGS='-arch x86' python setup.py build
MySQL-python-1.2.3 $ sudo ARCHFLAGS='-arch x86' python setup.py install

Everything compiled with either one of these. The latter seems to me to be the better solution. After running it, I could load the library in Python with no errors:

>>> import MySQLdb

I was then able to get Django to talk with MySQL and set up a database. Yay!

Notes: For the compile to work you will also need the Python setuptools module. I installed it using easy_install, which I had evidently installed without installing the full setuptools package.

Django, PYTHONPATH, and iPython

After trying Drupal and finding it needlessly twisted, I have decided to experiment with Django. I’m working my way through Python Web Development with Django®, by Jeff Forcier, Paul Bissex and Wesley Chun, published by Addison-Wesley Professional in 2008. Thing have gone smoothly, so far, though I have not yet set up Apache to work with Python and Django either locally or on my server. My previous experience has been limited using Python for cgi scripting.

I followed the Django installation instructions at http://docs.djangoproject.com/ to install Django 1.2.5 (current version is 1.3), generally without a hitch. Following instructions in Appendix B of the book, I ran the command python setup.py install from the Django directory. Also at the suggestion of the book, I installed iPython. It has some handy features, but also seems to have far more features than I need. I’ve also had a problem with its recognizing my Django directory as part of its search path. The regular Python editor does not have this problem.

To inspect the search path, start python:

$ python
Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path

This should print out a mutable list of paths. The problem is, the list is different if you invoke ipython as the editor. In fact, it’s missing the path that contains the Django library. As a result typing

>>> import django

in iPython will return an error message. It works just fine in the regular old Python editor.

The remedy? For scripts that are run from the Terminal, you need to create or modify the PYTHONPATH environmental variable, which stores the search path returned by sys.path in Python. Even if you haven’t set this variable, the standard Python editor apparently gets all the necessary information from other path variables in Mac OSX, while iPython doesn’t. It seems to be missing one specific path. To add it in, edit your ~/.bash_profile file to contain the following line:

export PYTHONPATH=/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages:$PYTHONPATH

You can add other paths to this later on, as you develop your own modules. Other techniques for adding to the search path involve .pth files or, for apps launched from the finder, creating or modifying ~/.MacOSX/environment.plist.

Surprised Party

A new Voronoi-based computer print by Paul Hertz, Surprised Party. Paul suggests that this print registers his giddy mood upon being welcomed to a surprise birthday party, a plot hatched by his wife, sister, and son and very successfully executed. The party was surprised.

Surprised Party

Surprised Party

The image was generated with multiple passes of Michael Balzer’s code for Capacity-Constrained Voronoi Tesselations. Basically, the CCVT algorithm generates random dot patterns where the dots are evenly distributed. The CCVT algorithm has the particularity of greatly reducing geometric artifacts, such as hexagonal grids,  that may appear in other generation methods. The artifacts can easily be detected just by looking, from which one might deduce that the human visual system is very good at detecting order within randomness.

Detail of Surprised Party

Detail of Surprised Party

Like a perfect gray tone, CCVT-generated dot patterns seem to have a aesthetic appeal that has a statistical correlate. Using them to produce art seems rather natural, in the tradition of “all-over” abstract painting. Their lack of order has the somewhat paradoxical effect of enabling one to see all sorts of orders–trails and swirls of dots where the fundamental rules are, roughly, for dots to keep their distance and avoid regimentation.

The Fibonacci Series and some shuffling were instrumental in selecting and assigning the colors. I leave it to the curious to decipher the numerical game. It should not be difficult. Like a good friend, you can count on the Fibonacci series.

/**
* Shuffles an array of integers into random order
* @param intArray   an array of ints
*/
public void shuffle(int[] intArray) {
  for (int lastPlace = intArray.length - 1; lastPlace > 0; lastPlace--) {
    // Choose a random location from 0..lastPlace
    int randLoc = (int)( randGenerator().nextInt(lastPlace + 1) );
    // Swap items in locations randLoc and lastPlace
    int temp = intArray[randLoc];
    intArray[randLoc] = intArray[lastPlace];
    intArray[lastPlace] = temp;
  }
}

Lens Distortion and Perspective Correction

A review of PTLens, lens distortion correction software for Windows and Mac OS, with further notes on correction in Photoshop and Bridge CS4.

PTLens uses a database of lens characteristics for correcting barrel, pincushion, and complex distortion caused by lenses. It also provides tools for correcting perspective distortion and chromatic aberration. The lens distortion correction, in my brief test, proved markedly better than what I could achieve with Photoshop. I used the Photoshop plug-in (the software also provides a standalone application and a plug-in for shift lenses): it identified my lens and focal length and applied an automatic correction. Although I could have tweaked the correction, it turned out to be as close to spot-on as I could detect.

PTLens does have one drawback: it presents as a preview a scaled-down image in its dialog box. Photoshop does the same–neither tool lets you preview in the image itself–but Photoshop’s Lens Correction tool permits you to zoom in over a comparatively large image. PTLens can zoom, though only for chromatic aberration, apparently, and it provides a small area to preview. This makes PTLens decidedly awkward to work with if you need to see zoomed in views. PTLens does provide a grid, which facilitates distortion, perspective, and rotation corrections, but even for these more global corrections, a larger zoomable image than PTLens provides can be handy. For its modest price, PTLens provides some excellent functionality, from what I can tell on first impression, but its limitations mean that you will still use Photoshop’s tools for some corrections.

Comparing PTLens with Photoshop

Photoshop correction on the left, PTLens on right

The above images were corrected for lens distortion. The PS example used the Filter > Distort > Lens Correction tool, with distortion, perspective and rotation corrections. For the PTLens example, distortion was corrected with PTLens and perspective, rotation, and warping corrections were applied in Photoshop. The image was shot at 18mm with a Nikon 18-200mm f/3/5-5.6 zoom lens, Nikon D300 body.

In Photoshop, it proved very difficult to get the precise correction, and I think this shows in the comparison. Quite possibly, the distortion had both barrel and pincushion distortion–common in wide angle lenses, according to the PTLens web site. Photoshop can’t correct such “complex” distortion; PTLens can. The combination of corrections in Photoshop also warped the image considerably, more than occurred with PTLens. I cropped the Photoshop image to remove warped edges. The PTLens image, after minor perspective and rotation correction, was easy to correct with the Edit > Transform > Warp tool. The Perspective correction had scaled the image down in the lower portion. Applying the warp transformation only on the lower portion distorted only the garden. Because the garden has no straight lines, the distortion isn’t even noticeable.

By the way, for chromatic aberration correction, if you are using RAW images, the best tool in my pack is Adobe Bridge. Photoshop’s correction is less fine-tuned. It’s a good idea to correct chromatic aberration before you even begin working in Photoshop.

Update: Much of the functionality offered by PTLens is now built into Adobe Bridge CS5, and I assume by extension to other Adobe Products.

Emigre Type Foundry: Historia

I have in my hands the most recent specimen book from Emigre Type Foundry and I am delighted. Emigre’s type books become collector’s items, and its not hard to see why–in small format, they extend to the printed document the quirky, fun and righteously well-defined aesthetic that permeates their typeface design.

This current offering, Historia, is something else. It’s not just a “greeked” specimen book, but a photographer Rudy VanderLan‘s journal of battlefield locations in the Mexican-American war of 1846–1848, with a recounting of that history, panoramic photos, and stylized, typeset “labels” for each location.

You can order the next specimen book free from Emigre, or buy a small collection for the modest price of $3. I did not see the current one online, though I expect it’s still available. Just don’t ask to borrow mine ;^}.

Fonts and the Visual Design of Web Pages

HTML was not made for visual designers–certainly not in the beginning. It was built on markup languages that were intended to capture the organization and functionality of documents and document elements, not their appearance. It was intended to be flexible in its presentation, independent of visual layout and style. Database designers understood this. Visual designers hated it. They have been striving ever since to twist it to their purposes.

In many ways they have succeeded. Netscape’s introduction of the now-deprecated <font> tag in 1995 was the first crack in the facade. Tables were used early on to create layout, though HTML advocates objected: “Tables are for tabular data!” Invisible GIF “shims” provided indents and line spacing that markup balked at. It was a mess, though it provided a nice market for the the specialized knowledge that HTML tweakers and twisters acquired. Mercifully, the WWW Consortium introduced new markup standards and eventually CSS. Using tables and shims today is a not just anachronistic, it’s counter-productive. It will frustrate good design, because always was just a workaround.

Font display is the one element that is still not under the designer’s control. Designers tend to rely a handful of “web-safe” fonts that “most” computers will have installed. To circumvent the quirks of different browser in displaying these common fonts, markup libraries like YUI can level the ground with CSS that zaps the quirks and then lets you build up CSS specifications that will provide uniform font display on all browsers. Cascades (font-family: “Lucida Grande”, “Verdana”, sans-serif) provide a measure of fallback safety, but you still have no way of really assuring uniform appearance of fonts on web pages. PDFs or Flash are poor substitutes for standards. Creating font graphics is fine for a smattering of display type, but it won’t do for body text.

There have been a number of font embedding schemes. The W3C is working on a standard for Embedded Open Type, but there are quite few legal and technical problems to overcome.  At the moment, embedded fonts (via the @font-face CSS declaration) are mostly supported through font servers that operate on a fee-for-service basis. Not all type foundries permit their fonts to be embedded. Meanwhile, the Google Font API provides some 16 open source fonts that are designed to work on all current browsers. It’s a step in the right direction, and supported by a company many of have come to rely on (with varying enthusiasm).

A Dangerous Size

Printing an 11 x 14 inch sheet on the Epson 9900 involves a ticklish problem: the paper jams against the roll cover. This crumples it top and probably bottom, where the crumpled paper can hit the print head. This could damage the print head. Collisions can happen both when the paper feeds for the first time, when it moves up and down as the sensors on the head measure and position it, or when you start printing, and it again adjusts up and down.

Fortunately, the solution is simple. You can hover over the printer, gently guiding the top edge of the paper with your hands, though that isn’t the best solution. Holding or taping another piece of paper onto the roll cover behind the sheet works better. You could also leave the cover in raised position, but then you wouldn’t have it to guide and support the sheet.

protected printer

Paper taped to roll cover

Bitmap to Surface to Model

Bitmaps can be used as height fields for a 3D terrain. Typically, the brighter the pixel value, the higher the terrain at the location mapped to the pixel. A 3D grid such as a terrain model can be output as cross-sections and created in any convenient material. The Processing app included with this post will do the whole process for you: open a bitmap, display it as a terrain model, and output cross-section profiles to a PDF file. The profiles include slot marks. Once you cut out the profiles and the slots, you can fit everything together into a model. The model can be used to construct a mold for the surface.

Let me explain this with pictures. First, here’s what the assembled model looks like:

The assembled model

The assembled model

Continue reading ‘Bitmap to Surface to Model’

Mushroom Duotones

Posted a few duotone images of mushrooms to Flickr. Didn’t mean to spend this morning making these images, but when you get the right subject matter, there is an eerie presence to toned images: Maybe it’s the intersection of image qualities that recall old photography and emulsions hand-coated onto paper coupled with high tech display and printing—or maybe the mushrooms (just shitakes) have an effect on me.

This tutorial on duotones over at Luminous Landscape was useful.

Duotone Soft Proof

Can’t soft proof a duotone in Photoshop. Have to convert to RGB to soft proof; however, the color changes in subtle ways.

One way to compare the images is by checking their histograms.

The duotone image is just a little darker on average (mean 106.97 compared to mean 112.53), and it clearly has pixels in the darkest bins, including a spike of 0% black over on the left edge of its histogram. The RGB image has no black pixels until you reach level 11, about a 4% gray.

Comparison of two histograms

Comparison of RGB and duotone image histograms

You can use Curves adjustment layers to compare the dynamic ranges of the two versions of the image. Option-drag on the black point or the white point in the Curves dialog to see where in the image the darkest and lightest values are found. The duotone reveals solid black (0%) in a few places. The RGB version has no solid blacks. In the light tones, the two are practically the same.
Continue reading ‘Duotone Soft Proof’