Add to Google Reader or Homepage |
~ pjvenda / blog
$home . blog . photography

28 January 2008

Tried a (new) VW Golf 1.6 FSI

Hi everyone,

Yes, besides being a geek, I am also a car nut. Sorry about that.

I had the chance to try a VW Golf 1.6 FSI (Mk V, 2007) over a weekend in the middle of December and thought I should share my opinion about it.

Picture of a 5 door VW Golf Mark V taken from wikipedia. Click on the image above for a larger version.

The Golf has been around for some decades now, improving with its every iteration. It has always been some kind of landmark of build quality - at a price, of course - that other manufacturers try to achieve with their own equivalents.

Its build quality shows both on the inside and on the outside. Things feel solid and well put together. The car is confortable and has all the mininum gadgetry one might want (cd player, air conditioning, cruise control, on board computer, ...). I am not fond of the blue dials but that's a VW tradition...

The engine is a 4 cylinder (straight), 1.6 litre, with direct stratified injection (FSI). It offers 115bhp and is coupled with a 6 speed manual gearbox. It is joyful to drive and powerful enough but seems a bit lazy under 3000 rpm at higher speeds. Not unexpected but not an issue either.
Overall it was pretty fun to drive. Felt like it wanted to be abused a bit, but public roads don't not let me enjoy my deserved fun!

Fuel consumption was higher than I expected. It took 30 litres of petrol to do about 240 miles in motorways (at or below 70mph). That yields some 30 mpg or 8 l/100 km. Bad Golf, bad!

Considering only its reliability, building quality, driving and aesthetic point of view, would I have it? Yes, please!

Now considering everything that there is to consider about this Golf, would I buy it? Erm... No. It implies a considerably higher initial cost when compared with its close competitors and its fuel consumption is worse that what I would tolerate for a car with a commuter/family hatch soul.

Just to clarify, the fuel issue would not apply to the R32, for example. That is obviously allowed to drink whatever amounts of fuel it needs.

Cheers, PJ.

16 January 2008

Focal length histogram

A warning first: this is highly geek stuff! Walk away if you don't have the stomach... or patience.

I was having a hard time in deciding what lens to buy next, I decided to rationalise things:

  1. I need a better lens;
  2. Better lens also means less flexible (less compromised);
  3. Being less flexible, my new lens should provide the focal range that I prefer;
Right, but what focal range is that?? It's not something that I can say from the top of my head like "My preferred focal range is exactly between 35 and 39mm!"...

So, after picking the idea from Tadeusz, I decided to do something similar

Knowing that my photo database has a little over 10000 shots, I wrote a small(ish) ruby program that goes over every picture file, extracts the focal length at which they were shot from EXIF metadata and produces a nice histogram with the help of gnuplot. Hopefully, by analysing the peaks of the histogram, I would be able to assess what is my preferred focal length range.

I will release the script on my website (in the "Programming - Ruby" section) after I fix a couple of annoying bugs in it.

The resulting graph run at 08 January 2008 looks as follows:

Focal length histogram of about 8000 pictures ranging between 18 and 125mm - Click on the screenshot to enlarge.

Roughly 8000 images were analysed and I only included the focal length range of my lens on the histogram. All focal lengths were adjusted to a 1.6x crop factor, but since the 18-125mm already takes that into account, focal lengths don't shift place on the histogram. By discarding the extreme ends of the above focal range (18 and 125mm), I got the following histogram:

Refined focal length histogram by discarding the extreme ends of the focal range in question - Click on the screenshot to enlarge.

Some extra notes before extracting results from the graph:
  • Instead of having a large number of histogram bars placed at the whole range of focal lengths, some discreet spikes show at about 17 different focal lengths. This seems to suggest either the lens is sending rough estimates of the focal length in use to the camera or the camera itself is aggressively rounding that information before writing the EXIF data;
  • The extreme ends of the assessed focal range were discarded because when using the ends of the lens, I would probably prefer to use lower or higher focal lengths respectively when using the minimum or maximum available focal length of the lens;
Clearly I am a wide-angle kind of photographer. The ranges I have used most often are between 18 and about 40mm with a little spike around 55mm.
Now that I have a scientific answer to the question: "What focal lenghts do I use more often?" maybe I can now decide which lens to buy? Well, I have decided and I have already bought it. Oddly it does not fit to the peaks of the histogram as well as I would like due to a number of reasons:
  1. I still want some degree of flexibility - or else I would be buying one or more prime lenses;
  2. I want excellent optical quality for the lower focal lengths - fast, sharp and with low distortion;
  3. The Canon 24-70mm f/2.8 L is absolutely out of the question for financial reasons;
Stand by for the result.

Cheers, PJ.

07 January 2008

Software toolkit for photography post processing: from Linux to Mac OS X

I've been getting used to Mac OS X Tiger and I must repeat the obvious: It's bloody great!!

One of my current time sinks is the post-processing of digital photos ranging from trivial sharpenings to time consuming panorama builds and HDR experiments. Of course, being a Linux geek, my toolkit is all Linux-based and reasonably optimised with tens of shell and ruby scripts to automate the boring repetitive stuff. The main software components are currently composed by exiftool, ufraw, digiKam, hugin, qtpfsgui and The Gimp.

Now if only I could use all those tools on OS X...

  • exiftool - A tool for reading, writing and editing meta information of images and other types of media.
Easy and done. There are binary versions of this command line tool ready to be installed on to the system from the home page of the project.
  • ufraw - A utility to read and manipulate raw images from digital cameras.
Easy and done. I compiled v0.13 from sources with a basic set of dependencies supplied by fink. Pierre Andrews went through the trouble of creating a nice .app package himself and made it available here: Thanks Pierre. It runs on X11.
  • qtpfsgui - An open source graphical user interface application that aims to provide a workflow for HDR imaging.
Seems easy but not quite done yet. The main website has a very nice .app binary build of version 1.8.12. The only thing missing is support for hugin's align_image_stack, but Mandus ( together with Ippei Ukai ( are working on getting it added. If I recall correctly, this is linked to carbon or cocoa i.e. it does not run on X11.
  • digiKam - An advanced digital photo management application.
Or headache #1. The main problem with getting this to work in OS X is its close integration with the KDE desktop environment. It has tons of dependencies like libkipi, kipi-plugins, libkexiv2, libkdcraw, libgphoto2, liblcms, libpng, libtiff, libjpeg, ... and it is damn hard to get everything working and working together. Fink has one decent build of digiKam 0.9.3 which compiles and installs fine, but the final result could be better - it does not process all the EXIF/IPTC that the native Linux version does and the GPS locator function (a kipi plugin) does not seem to work. Both of these are functions that I use extensively.
How wonderful it would be to have digiKam properly packaged into one .app (just like qtpfsgui) and linked to qt4-mac instead of running on X11... I'll just keep working on getting it running - compiling dependencies and dependencies of dependencies until eventually I get it right.
Or headache #2. Again tons of dependencies prevent me from cleanly building a snapshot of the SVN trunk. The building system even attempts to create a nice .app package but then it does not work. Unlike digiKam, though, there seem to be alternatives. Some good-hearted people who are able to build these snapshots successfully and package them nicely into .app packages, cutting the number of external dependencies as much as possible (ideally there should not be any dependency in .app packages other than OS X's system libraries).
Both Ippei Ukai and Harry van der Wolf have HuginOSX .app builds available on their websites. Harry's seem to be the most recently updated: These snapshots run natively on cocoa, although there are some important dependencies that must be interpreted by the mono framework.
  • The Gimp - the GNU Image Manipulation Program. It is a freely distributed piece of software for such tasks as photo retouching, image composition and image authoring. Functionally analogous to Photoshop.
Easy and done. An .app binary build of version 2.4.0rc3 may be downloaded here: It runs on X11, though.

Once I get all these working properly, I think I will be both happy and sad at the same time. Happy because I had been able to port my post-processing photography software kit to Mac OS X, which is great. But sad because by then, I will have no good reason for going back to Linux...

Cheers, PJ.

My website is back online!

It's a shame that it is so out of date... but it has physically moved about 1000 miles ( recently and went offline for a few days because of a number of reasons.

Finally it is running again on the "new" server.

All I have left to do is... update it, of course. I have lots and lots of stuff to put there and I hope I'll start updating it again soon. Meanwhile, check it here:

Cheers, PJ.