Thoughts on Systems

Emil Sit

Nov 7, 2008 - 3 minute read - Photography flash neil van niekerk Photography

Flash photography with Neil van Niekerk

Shooting with natural light can produce a beautiful portrait, but in many real life shooting conditions photographer-added light can improve the quality of the result. In his flash photography workshops, such as the one I took last week in Boston, Neil van Niekerk explains the technical knowledge you need to produce the artistic look you may be seeking and then works hands-on with you to put that knowledge into practice. The techniques that he teaches grew from his experiences working in studios, applied to on-the-go wedding photography: practical, fast, effective. {% img left 333 500 ‘Melissa: indoor bounce flash, camera right.’ %}

Neil favors soft directional light that ideally looks as if flash was not used (motivated light). To achieve this, Neil teaches you to deliberately control the ambient light by setting your exposure manually and then to bring in directional light, either by bouncing an on-camera flash off a nearby surface or by using off-camera lights. He reviews the theory of controlling flash exposure manually (aperture, ISO, power, distance) and automatically (flash exposure compensation, leaving shutter speed, aperture and ISO transparent). With diagrams and live demonstrations, he explains flash technicalities like second curtain sync, high speed sync and the magic of the maximum sync speed.

In the afternoon, we worked with two extremely patient models Tanja and Melissa and went through a number of practical exercises including using the histogram to meter, bounced fill flash and FEC to control contrast, off-camera lighting in bright sunlight, use of gels to control color temperature, indoor bounce flash with modifiers, and a few more. In warmer climates, Neil takes the class downtown to work but things were a bit chilly in Boston so we spent the evening shooting in-doors, working more with off-camera manual flash.

One technical note: Neil recommended that we use evaluative (or matrix) metering instead of spot. He recommends this in order to be sure that the TTL flash metering will correctly set the power for the desired exposure of the subject; he suggests zooming in to a white patch (e.g., of the wedding dress) to correctly set the ambient exposure based on the histogram. Since I use primes mostly, I would prefer to be able to leave the camera in spot metering. Fortunately, the Photonotes Flash Photography with Canon guide seems to suggest that I can: > E-TTL II […] examines each evaluative metering zone before and after the E-TTL preflash. It then calculates the weighting for each zone independently, biasing against those zones with high reflectivity in the preflash. This means that E-TTL II does not have a flash metering pattern as such, since it’s calculated dynamically.

This seems consistent with my usage on the 30D so I will stick with spot metering for now. (Nikon users, pipe up in the comments.)

Neil’s work is meeting a growing demand to incorporate sophisticated flash techniques into photography for better results. He encourages an understanding of the full manual approach and off-camera aspects (a la strobist), but doesn’t shy away from using the intelligence programmed into today’s TTL flashes. He’s willing to answer questions from complete beginners, but the workshop is best (I think) for people comfortable with their camera controls and basic flash usage, and wanting a taste of the more sophisticated. Neil’s workshop is definitely recommended: I came away more confident in my ability to get results using flash having better internalized the fundamentals and gotten some great practical tips. For more pictures from the shoot, check out my photostream on Flickr.

Sep 2, 2008 - 1 minute read - Technology Thoughts

Securing the web browser.

Google is soon going to demonstrate Google Chrome: a ground-up re-written browser designed with security in mind. Wow, render each tab in a separate process (and more). Compare that to what we saw at SOSP 2007: MSR presented some improvements to deal with IFRAME within MSIE (MashupOS (PDF)) and how to track Ajax performance in a distributed way (Ajaxscope), and researchers at Cornell described a new programming language that allows for static partitioning of data (Swift (PDF)).

Aug 20, 2008 - 1 minute read - Research Thoughts


Pierre-Evariste Dagand developed Opis, an OCaml-based framework for developing distributed systems. It includes yet another Chord implementation, tested in ModelNet against Macedon and MIT Chord. While I still think OCaml is kind of ugly, it appeals to me more than P2 or Macedon did. (via Anarchaia)

Aug 15, 2008 - 3 minute read - Technology git mercurial tools usability workflow

Experiences with Mercurial and Git

I have been a big fan of the Mercurial version control system since migrating the Chord project from CVS almost two years ago. Mercurial offers a comfortable command-line experience, good performance and a module based architecture for expansion. Since graduating, I have had to interface with Subversion and Perforce servers at work and used that as an opportunity to learn how to use Git, the other big player in the distributed version control world.

Learning Git can be a bit daunting—concepts like the index, the abstract model of Git repositories as a directed acyclic graph, and commands like git-reset and git-rebase are hard to wrap your head around. Coming from CVS or Subversion, it is easy to think that Git is just weird, much like Lisp macros might confuse the average programmer. However, last year, Ted Ts’o wrote > […] I see its potential as being greater than hg, and so while it definitely has some ease-of-use and documentation shortcomings, in the long run I think it has “more legs” than hg, […]

Having gotten comfortable with Git, I definitely agree with this statement.

Compared to Mercurial, branching with Git is much easier. When developing features for Chord, I would use Mercurial’s patch queue extension to develop features piece-meal until they were ready to commit. I would edit the series file manually to rearrange commits, in particular to push out small bug-fixes. It is much easier to use topic branches or git-stash to arrange (and re-arrange) commits and do small fixes. Git’s view of branch heads as simply pointers to some commit on a commit graph and its constant tracking of your commit history with reflogs around allows you to develop without fear of losing your work, even when arranging things so that your published history is pretty. In Mercurial, last I checked (around version 0.9.4), branches in a single working tree were still somewhat confusing and hard to use.

Git also has excellent Subversion and Perforce front-ends. With git-svn and git-p4, you can mirror an existing repository (say, the official version control system at the office) into Git, develop using all of Git’s tools, then push changes neatly back into Subversion and Perforce. Mercurial has hgsvn but I haven’t used it and its documentation suggests that it can’t push changes back into Subversion; I don’t know of any Perforce front-ends for Mercurial.

Mercurial makes it extremely easy to serve up a repository, without requiring starting a daemon on any special ports. hg serve is all you need and you can efficiently clone a Mercurial repository over HTTP; Git uses a special protocol that runs over a dedicate port, making it somewhat less firewall friendly. Mercurial also better allows differences between the HEAD branch (aka tip) and your current working directory state—you can push into a repository with a working directory without confusing Mercurial; not so with Git. This means collaboration in Git requires a third copy of the repository for collecting commits (or requires that repositories be updated only by pull).

For most uses, Mercurial and Git are more-or-less interchangeable, especially with the usability improvements in versions 1.5 of Git and later. The most basic commands like status, diff, commit, and log behave very similarly (at first glance). Commands execute quickly, even for large trees. Both systems are very flexible with modules and scripts that bring most features to parity. For myself, having learned how to work with Git, I prefer the power Git offers with fast branches and powerful tools like reflogs and rebase. For the undecided, fortunately there are tools that convert repositories from Git to Mercurial and vice-versa, so other than mental switching costs, there is little to fear in choosing one or the other. I won’t be using Subversion or CVS any more if I can help it.