View the pictures here (for free)

Buy the book here (for just the cost of printing)

Since this blog is supposed to be about technique, not just pimping my projects, I thought I’d share with you the process I used to make 41 portraits in 2 weeks.

Each of the 41 portraits is a macro shot of an eye, with a classical head and shoulders portrait of a the eye’s owner behind the pupil.

The project

When I look at a portrait I first see the expression on the subject’s face, and after a few moments of appreciation I find my gaze inevitably drawn to the eyes. The eyes reveal the personality of the subject, confirming the expression of the face or contradicting it. The eyes are the most important part of the portrait, yet the smallest. This is a pity because eyes contain beautiful details that are lost in most portraits.

This project consists of inside-out portraits. The intention is that after the first few moments regarding the eye, your gaze is inevitably drawn inwards to the subject’s face:

Yup, that’s natural colour. The colour and texture comes from using a strong flash from the side to illuminate the iris, removing all the reflections you’d see if you took the photo in a well lit room. Click through to the flickr page and have a look at the large size.

This is how the photos were taken:

The Macro shot

As a macro shot, the depth of field was very shallow. Normally I advise people not to close the aperture more than f/11 to prevent softness due to diffraction. I tried f/11 at first, but found that the focus errors this caused were a far worse problem than a bit of diffraction so I stopped down to f/22 to increase the depth of field. As always for macro photography, a still subject is important so I had my subjects lean into a chair back and rest their chin on their hands. My lens was a standard 70-300 zoom with a Canon 500D close-up attachment on the front which reduces the lens focussing distance allowing you to get close for a high magnification.

The eye is side-lit by a single flash. Normally this would produce a harsh light unsuitable for a portrait. However, for the macro shot this was exactly what I wanted. The light reveals all the texture in the skin and iris.

The main lesson I learned from the macro shot was that I got far better results by shooting a bit too much of each eye then cropping down. I left myself more room for error, increased the depth of field, and used my lens at 200mm where it is sharper than at 300mm.

Manually focussing with an f/5.6 lens in dim indoor lighting is hard, so I placed a bare lightbulb behind me and twisted the focus ring until the reflection of the bulb in the eye was a single pinprick of light. This would work for any shiny surface. Using a shutter speed of 1/250 and an f/22 aperture a bright flash is required, meaning that all illumination in the photo comes from the flash and the focussing bulb is not visible in the photo.

The portrait

The portraits were harder than the macro shot because I’m not a portrait photographer. With a bit of practice however, and a lot of wine, I found myself reassuring subjects and coaxing some good poses out of them.

The Flash was bounced into a silver umbrella which creates a soft light on the subject’s face that is much more flattering than a direct flash. The black curtain in the background means that you can’t see the join between the portrait and the black pupil in the macro shot when they are combined.

The main lesson I learned is that taking portraits takes practice. You’ll never get a good shot of someone who is nervous, and you can stop people from being nervous by being confident (and by serving wine). Before I started I didn’t feel comfortable taking photos of people. After 41 portraits I feel like I can get good shots of most (say 75%) of the people I meet.

Editing and post-production

Apart from the obvious changes of superimposing the portrait and and converting everything but the iris to black and white, the only processing I did was sharpening. The skin was treated to a Photoshop unsharp mask at strength 200% and radius 2px. This is a strong effect that looks too much on screen, but will be perfect for the printed work since printing softens the photo slightly. The inner portrait was sharpened with a radius of 1 pixel since 2px messed up the fine detail too much. Finally, the iris got a strength of 40% and a radius of 30px. This effect is completely different to standard sharpening, and has the effect of enhancing the patterns in the iris.

In this photo, the rightmost section has no treatment, the middle section has the 2 pixel sharpen, and the left section has the 30 pixel sharpen on top of the 2 pixel one:

Bernie’s Better Guide to Depth of Field for Geeks Who Want to be Digital Artists

By the way, if you’re not sure what an f/1.8 aperture, 85mm focal length, or 1.6x crop factor camera body are, I suggest you have a look at last month’s beginner’s guide.

P.S.: SoPhoBoMo

Paul Butzi over at the Photo Musings blog has an idea that’s just perfect for beginner and advanced photographers alike to improve their skills. The goal of Solo Photo Book Month is to produce a professional PDF photo book with 35 images over the month of April. Afterwards you can post it online, keep it to yourself and feel smug, or even send it to a print-on-demand site like blurb.com and start selling it.

It has been eloquently argued that the most important development for the artist is arriving at a personal style. Technique - the stuff of my articles - is important because a lack of technical skill can prevent you from being able to express your personal vision. However if you don’t know what your personal vision is, you’ll never take photos that you consider to be art.

SoPhoBoMo is great because it may well help you define your personal style; that’s certainly what I’m hoping. I haven’t decided what my project is going to be, but I imagine my new-found love of macro photography will feature pretty heavily. 35 photos may seem a lot for one month, so pick a project that you can do along with your daily routine.

If you decide to go ahead, pledge your entry here. If I haven’t sold you on it, read this.

While I prepare the next big article, here’s a useful tip for Flash and Flex programmers. ActionScript 3.0 is great, but has no Singletons.

Samuel Agesilas has a solution that successfully prevents subclasses from calling the constructor using super(), but it doesn’t prevent other code from creating new instances of a class with new

Therefore I present to you a crafty hack to make a constructor truly private: add a required argument to the constructor, which must be set to a secret value that is only known to the class:

class Singleton {
    private static var _instance:Singleton = null;

    // secret known only to this class
    private static const secret:Number = Math.random();

    /**
     * @private
     */
    public function Singleton(enforcer:Number) {
        if (enforcer != secret) {
            throw new Error("This class can't be instantiated directly");
        }
    }

    /**
     * Global single instance
     */
    public static function get instance():Singleton {
        if (_instance == null) {
            _instance = new Singleton(secret);
        }
        return _instance;
    }
}

This method also has the advantage that it is very fast, and offers a level of compiler protection: new Singleton() will fail at compile time. A user could make the compilation work by passing in, for example new Singleton(42), but there is a very high* chance of that failing at runtime.

Use this technique whenever a constructor should only be called from within a class, to save your users from the all too easy mistake of of creating a second instance of a singleton.

* Geeky aside: the change of guessing the result of Math.random() is 1 to 2^52 against, or 1/4,503,599,627,370,496. This is because 64 bit floating point numbers have a 52 bit mantissa.

Update: Grant Skinner has another way of doing the same thing. His is probably more elegant, but less amusing, and amusingness is a trait I value in language hacks. Also, his solution is not checked at compile time. Andrew Trice had a go too. His version requires an extra argument so provides compile time checking, but can be defeated by calling new Singleton(Singleton.getInstance). Thanks for the links shaun.

Update 2: Ho hum, Eric J Feminella has a solution that is better than mine, since it is properly checked at compile time, i.e. you can’t fool it by passing in any int, and falling back on runtime checking (though null would work). I still contend that my solution is more amusing though :o)

After much head-scratching I have dragged myself through the beginner phase of the initially bewildering world of photography, and can now present to you Bernie’s Better Beginner’s Guide to Photography for Computer Geeks Who Want to be Digital Artists: the guide that I wish someone had written for me 4 months ago.

As of now, this is a blog about web development and photography. If you only want one, try these feeds for web development only or for photography only.

When I built Animator.js, I got some flack for suggesting that inheritance is not a Good Thing. Keen to avoid a holy war I restated my position to ‘inheritance is often useful, but more often overused.’ Over the last few months I’ve been trying to figure out exactly when it should be used, and have concluded - at least for the kind of systems GUI developers build - never. There are better techniques that accomplish the same thing.

In this article I justify my dislike of inheritance as a prelude to my next article introducing an open source animation toolkit that is built without inheritance.

Read the article here.

Edit: Eric Herman wrote in with a link to a good article he wrote giving a more detailed example of the same problem from a Java point of view.

Edit 2: OK, I couldn’t make this stuff up. This is a verbatim quote from the Java API documentation for the Properties class that reads configuration from a file:

Because Properties inherits from Hashtable, the put and putAll methods can be applied to a Properties object. Their use is strongly discouraged as they allow the caller to insert entries whose keys or values are not Strings. The setProperty method should be used instead. If the store or save method is called on a “compromised” Properties object that contains a non-String key or value, the call will fail.

This is what inheritance does to your system! In all fairness, the Java API team introduced the generic collections API to get around this kind of problem, but it’s still funny.

Specifically, he says:

The eval function (and its relatives, Function, setTimeout, and setInterval) provide access to the JavaScript compiler. This is sometimes useful for parsing JSON text, but in virtually all other cases it indicates the presences of extremely bad coding. The eval function is the most misused feature of JavaScript.

Well I’m tired of my favourite function being badmouthed just because some people can’t program properly. In this article I show how to use eval to generate optimised code based on information only available at run time. The resulting code is 5 times faster than the non-generated version.

Some background: users of Visual Studio have long known that it comes with an awesome debugger, probably the best JavaScript debugger there is (though Firebug is catching up fast). Whenever you get a JavaScript error, Visual Studio can connect to the Internet Explorer process and start debugging. You can pause the execution of the code, rewind and fast-forward execution, modify data held in variables and get notified when specific variables change in value. Once you’re used to it, coding without a debugger makes you feel like a blind man in a dark room looking for a black cat that isn’t there*.

The only problem is that it costs upwards of £500. Microsoft have released an excellent free edition of Visual Studio for web development called Visual Web Developer, but among the features reserved for the professional edition is the ability to connect to a process. Hence when you get a JavaScript error in a web page, VWD won’t appear in the list of possible debuggers.

The work-around is to get VWD to launch IE for you, so that it owns the process and doesn’t have to explicitly connect to it:

1		First enable debugging in IE: go to Tools > Internet Options > Advanced, and make sure “Disable Script Debugging (Internet Explorer)” is unchecked and “Display a notification about every script error” is checked.
2		Then Download and install VWD
3		Create a new empty website
4		Click the “Start Debugging” button. You will be prompted to enable debugging for this website - do so. VWD will then launch IE in debugging mode.Since your website is empty you will see a 404; ignore it and navigate to the actual page or website you want to debug. A tip from Fraser in the comments below: If you like, you can create a home page for the new site, and add this code to the head section:  <meta http-equiv=”refresh” content=”0;url=http://yoursite.com”>. This will redirect you automatically to your chosen site.
5		Any script errors will cause IE to pause execution and transfer control to VWD.The screenshot to the left shows me changing the value of a variable as the script is paused.

If any Firefox users have probelms getting VWD to launch IE, see James Wiltshire’s comment below.
A few debugging tips:

• Learn these shortcuts: Step Over (F10) executes the current line of code and moves to the next one. If the current line of code contains a function call, Step Into (F11) moves the debugger into that function call. Step Out (Shift+F11) executes the rest of the current function and pauses again after it returns. Continue (F5) resumes the script until the next error or breakpoint.
• Debugging is easier if you write code with one function call per line, so that the debugger knows which function you want to step in to.
• You can type any expression in the Watch window, and when its value changes it will turn red.
• If you want to open the debugger when there is no error, click in the left-hand margin to set a break point or place the ‘debugger’ keyword in your code (this works in Firebug too).
• The Script Explorer window is an extremely useful list of open JavaScript and HTML files that you can use to find code in order to set a breakpoint. It is not shown by default but you can enable it in Debug > Windows > Script Explorer.

Happy coding!

* joke stolen from Rowan Atkinson

Highlights are:

• You can now specify the start and end states of an animation using CSS class names: no more style information in your JavaScript code! IMHO this makes it twice as useful as the last version.
• AnimatorChain class makes it easy to chain several animations together (thanks Lachlan Donald and Colin Snover for the idea)
• No more dependency on Prototype.js, so users of other toolkits can use it freely.
• Useful new transitions: elastic, bouncy and Attack Decay Sustain Release.
• Bug fixes - styles can now have negative or fractional values

Thanks to all the people who wrote to me with suggestions and example of work you’ve done with Animator, keep them coming!

The most requested feature was “Can I port it to MochiKit/jQuery/Dojo/mootools”. Which got me thinking – Animator.js is built on Prototype because I didn’t want to rewrite code for function delegation and element manipulation myself, but it doesn’t use any of Prototype’s advanced functionality. I could remove the dependency on prototype quite easily and then it would work with any toolkit. I estimate this would add about 1K to the file size.

Having a class that can be used in any toolkit would be much better than a number of independently maintained forks.

Two questions:

1. What changes should I make to ensure that it can plug in to your favourite toolkit?
2. If someone can make a product usable for more people by re-implementing basic functionality again, is it worth it? Or is the world standardising on Prototype to do all that for them?

I’ll be making another release in a couple of weeks so let me know your thoughts, and any other feature requests.

With that in mind here are my intentions:

• Content over opinion: nobody needs yet another developer weighing in on why Web2.0 is so awesome/despicable (delete as appropriate)
• Experimental over practical: I already spend 8 hours a day building reliable things with stable components and well understood techniques. Here I get to have more fun.
• Conversation over broadcast: I’m not even sure if I’ll have many readers, but any that I do have I invite to email me with any points, technical questions, suggestions, praise, damnation… Really, I love getting emails from people I don’t know and I’m not sure the novelty will ever wear off. I’ll reply to all emails and all blog comments.

Bernie :o)