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).