HDR photography with Luminance HDR and a cheap camera

If your camera has an ‘auto bracketing’ feature, it can take multiple shots of the same scene with different exposure values. Normally people use this to select a single photo with the best exposure afterwards, and throw away the others. However, it is possible to do more with this: by combining the information from all those photos, a single ‘High Dynamic Range’ photo can be created. This allows to capture much larger differences in light intensity within a single photo. There are some commercial packages that can do this, but there is also a great open-source alternative called Luminance HDR (formerly Qtpfsgui).

On my website you can find an article that explains how I use Luminance HDR to create HDR photos with a simple point-and-shoot camera that supports auto bracketing (a Panasonic Lumix DMC-FX37). Below are a few examples of the kind of results I obtained from this.

HDR-foto's maken met Luminance HDR en een goedkope camera

Als uw camera ‘auto bracketing’ toelaat, kan hij meerdere foto's van dezelfde scène nemen met verschillende belichtingen. Normaal gebruiken mensen dit om achteraf de ene foto met de beste belichting uit te kiezen en de rest weg te gooien. Het is echter mogelijk om hier meer mee te doen: door de informatie van al die foto's te combineren kan één enkele foto met hoog dynamisch bereik (High Dynamic Range of HDR) gemaakt worden. Dit laat toe om een veel groter bereik aan lichtintensiteiten weer te geven in één enkele foto. Er zijn hiervoor enkele commerciële pakketen beschikbaar, maar er is ook een uitstekend open-source alternatief, Luminance HDR genaamd (voorheen Qtpfsgui).

Op mijn website kan u (in het Engels) een artikel vinden dat uitlegt hoe ik Luminance HDR gebruik om HDR-foto's te maken met een eenvoudige compacte camera die automatische bracketing ondersteunt (een Panasonic Lumix DMC-FX37). Hieronder vindt u enkele resultaten die ik hiermee behaald heb.

Weak TOSLINK (S/PDIF) output on recent MacBook Pros

I have been using a surround receiver with a 10m optical TOSLINK cable and a 2006 model MacBook Pro without any problems for years. With my early 2011 17" MacBook Pro however, as well as someone else's 13" MacBook Pro from the same era, the receiver started producing frequent bleeping sounds, subtle audio drop-outs, and sometimes even downright refusing to work until it was ‘rebooted’.

I suspected all kinds of causes, including the cable or degrading components in the receiver. However, with a totally different receiver and cable of similar length, occasional drop-outs were also noticeable although this receiver was more robust and able to resume fast enough that it wasn't too jarring. After some more tests it became obvious that the light output from the new MacBook Pro is simply weaker than on older models and many other recent devices with S/PDIF outputs. This is especially visible when simply looking at the end of the cable when first plugging it into the new MacBook Pro and then one of those other devices. The photo shows the output of the MacBook Pro (top) and of a TOSLink repeater (bottom) through identical cables.
The 10m cable causes a considerable attenuation of the signal no matter what (Wikipedia mentions 10m as the limit for cable length). But with the old MacBook Pro, apparently the end result was still strong enough. The data sheet for the detectors in the receiver states that they expect at least -24dBm. My guess is that with the new MacBook Pro + the long cable, the output drops slightly below this, which is why it is just on the edge between working and not working. Some solutions are: a TOSLINK repeater to drive the long cable, a more sensitive detector with coax connection to the receiver, or a USB sound card with a stronger optical output. I settled for a repeater for which I made a USB power cable for extra convenience.
Another example where newer is not always better…

OS X Lion: fixing stuck wallpaper

One of the many small annoying bugs in OS X 10.7 ‘Lion’ that seem of too low priority to get fixed by Apple is that sometimes the desktop wallpaper gets stuck at the same image. When changing it in System Preferences, everything indicates that it has changed but still the same image stays on the desktop. A reboot fixes this and for some people (I suppose especially those used to working with Windows) this seems a satisfactory solution, but the more seasoned Mac users frown upon rebooting for something as trivial as this.

There is a more elegant solution, being only restarting the process that is responsible for the desktop wallpaper. This process is the Dock, and it can be restarted by either typing “killall Dock” in a terminal, or by using Activity Monitor. Mind that this could have some side effects. Eventually you will probably end up rebooting anyway to get everything right, but this fix will work if for some reason you badly need to change the wallpaper.

OS X Lion: oplossing voor vastgelopen bureaubladafbeelding

Een van de vervelende kleine bugs in OS X 10.7 ‘Lion’ dat blijkbaar van te lage prioriteit is om door Apple opgelost te worden, is dat de bureaubladafbeelding soms blijft steken. Als deze veranderd wordt in de systeemvoorkeuren wijst alles erop dat er een andere afbeelding moet verschijnen, maar de oude blijft staan op het bureaublad. Het ganse systeem herstarten is een ‘oplossing’ maar voor wie dit niet gewend is vanuit Windows lijkt het overkill voor zo'n triviaal probleem.

Er is een elegantere oplossing, namelijk enkel het proces herstarten dat verantwoordelijk is voor de bureaubladafbeelding. Dit process is Dock, en het kan herstart worden door ofwel “killall Dock” te typen in een terminal, ofwel door Activiteitenweergave (Activity Monitor) te gebruiken. Het is mogelijk dat dit wat neveneffecten geeft, maar deze oplossing is bruikbaar als u om een of andere reden dringend de afbeelding wil veranderen.

Why do ‘Recent files’ show recently closed, not opened files?

Something that has annoyed me ever since the feature of “recently used files” has started to appear in software, is that it most often shows the wrong files. The easiest way for a programmer to implement this feature is to update the list of recent files whenever the user opens a file or saves a new file. This however does not make sense from a user point of view.
When I open a file, I have no desire to look it up in the list of recent files because the file is already open. Now if I work on this file during a long time and I open a lot of other files in the meantime, it will be pushed off the list of recent files. If I then close that file and think “ow, I should add one more thing” and I look in the “recent files” menu, the file is not there even though I worked on it only a few seconds ago!
When I wrote a simple HTML editor long ago I implemented the recent files menu such that it updated the list upon closing files. It was slightly more involved to get this working correctly, but it felt much more intuitive during use.
Edit 2012/05/18: the most recent versions of TextEdit in Mac OS X ‘Lion’ finally implement the ‘update-menu-upon-closing’. I hope this is a sign for things to come.

Waarom toont “recente bestanden” recent geopende i.p.v. gesloten bestanden?

Iets dat mij altijd gestoord heeft sinds het concept van “recent gebruikte bestanden” zijn intrede heeft gevonden in software, is dat het meestal de verkeerde bestanden toont. Voor een programmeur is het het makkelijkst om dit te implementeren door de lijst van recente bestanden te updaten elke keer de gebruiker een bestand opent of bewaart. Dat houdt echter geen steek vanuit het standpunt van de gebruiker.
Wanneer ik een bestand open heb ik geen nood aan het op te gaan zoeken in de lijst van recente bestanden aangezien het bestand al open staat. Stel nu dat ik gedurende lange tijd aan dat bestand werk en ik open intussen een hoop andere bestanden. Dan wordt dat eerste bestand uit de lijst geduwd. Als ik het dan sluit en denk “oei, ik moest nog iets toevoegen”, en ik kijk in de lijst van recente bestanden, dan staat het er niet tussen. Ik had er nochtans enkele seconden geleden nog aan gewerkt!
Toen ik lang geleden zelf een simpele HTML editor schreef, had ik het menu van recente bestanden zo geimplementeerd dat het bijgewerkt werd tijdens het sluiten van bestanden. Dit was iets ingewikkelder om correct te programmeren maar veel intuïtiever in het gebruik.
Update 20112/05/18: de meest recente versies van TextEdit in Mac OS X ‘Lion’ gebruiken eindelijk deze ‘update-bij-sluiten’. Ik hoop dat dit een teken aan de wand is.

Apple XCode 4.2 & SetFile command

A little-known fact is that Apple's XCode ships with two command-line utilities called GetFileInfo and SetFile. They allow to query and set various file attributes. Many of these are obsolete properties from the Classic Mac OS days but some are still relevant and pretty handy, like creation date (which cannot be changed with ‘touch’ AFAIK). An even lesser-known fact is that since OS X Lion, there was a bug in the SetFile command that caused it to set incorrect dates when used with the -d or -m arguments. The date was always set one hour before the specified date. This bug has been fixed in XCode 4.2.

Weinig mensen schijnen te weten dat Apple's XCode ook twee handige terminalcommando's installeert, namelijk GetFileInfo en SetFile. Deze laten toe om allerlei bestandsattributen op te vragen en te veranderen. Veel van deze attributen zijn relieken uit de tijd van Classic Mac OS, maar sommige zijn nog steeds relevant en nuttig, zoals de aanmaakdatum (die voor zover ik weet niet veranderd kan worden met ‘touch’). Nog minder bekend is dat sinds OS X ‘Lion’ er een bug zat in SetFile waardoor deze verkeerde datums instelde met de -d of -m opties. De datums die het bestand uiteindelijk kreeg waren altijd een uur vroeger dan gespecificeerd. Deze bug is opgelost in XCode 4.2.

Mac OS X Lion: showing file path in Spotlight / pad tonen in Spotlight

In versions prior to Mac OS X 10.7 “Lion”, when hovering over a file in Spotlight's results for a while, the file's path would appear. It could also be shown instantly by holding down the Command key. In Lion this has changed. The path will not appear no matter how long you hover over the file name. When holding down Command, a small pop-up at the bottom of the preview window will first show you where your search term matched (the file name or contents), and only ±four seconds later you will be shown the file path. That is pretty annoying if you quickly want to skim through the results for file paths!
Luckily someone on the Apple discussion forums has discovered that if you press Option (alt) together with Command, the file path will be shown instantly. Phew.

In versies van Mac OS X vóór 10.7 “Lion” kon het bestandspad zichtbaar gemaakt worden voor zoekresultaten in Spotlight door er ofwel een tijdje boven te blijven staan met de cursor, of Command in te duwen. Dit is veranderd in Lion: het pad zal niet verschijnen hoe lang u er ook op blijft staan. En als u Command induwt, wordt eerst getoond waar uw zoekterm overeenkwam (inhoud of bestandsnaam), en pas na een viertal seconden zal het pad tevoorschijn komen. Zeer vervelend als je snel de locaties van een hoop zoekresultaten wil weten.
Gelukkig heeft iemand op de Apple-discussiefora ontdekt dat als je Option (alt) tegelijk met Command induwt, het bestandspad ogenblikkelijk verschijnt. Oef.

Magic Mouse battery management

If you have a wireless Mighty Mouse and you're tired of the scroll ball getting clogged with gunk, you may consider buying a new fancy Magic Mouse. In many aspects it will be a step forward, except one.
The battery management of the Mighty Mouse was very good: it could run on a single cell, which means that when it told you its batteries were empty they were both guaranteed to be empty. The mouse would always keep drawing power from whatever battery still had some juice left. This made it possible to run for weeks even on a set of old worn-out rechargeable cells.
The battery management of the new Magic Mouse is not so mighty, nor is it magical. In fact it is absent. The people at Softpedia have already discovered this but they did not explain the root cause of the problem. I do not believe the Magic mouse draws much more current than the Mighty Mouse. The problem is that it treats the two cells in series like any primitive battery-powered device. It expects a total voltage of more than about 2 Volts. This means that if one battery is still going strong at 1.2V and the other one is dead at 0.8V, the mouse will shut off. The Mighty Mouse would still be going at that point because it would ignore the empty battery and draw current from the other one.
Especially with Apple now selling their own NiMH batteries and charger, their decision to drop the advanced battery management is puzzling. If there is any type of battery that benefits enormously from the separate treatment it is rechargeable ones. Contrary to alkaline batteries, NiMH batteries will maintain a quite steady voltage until they're empty, at which point they exhibit a very quick voltage drop. If one battery has less capacity than the other, this leaves no margin for the higher-capacity battery to further discharge because the series voltage plummets below the threshold. With alkalines the steadily dropping voltage provides more spring-action between the two cells.
I tried using 2300mAh cells in a Magic Mouse and they lasted less than two weeks of non-intensive usage. The scenario was as described above: at the end of the run one cell was empty and the other one still had quite a lot of juice left.
If you have multiple pairs of rechargeable batteries and a means to measure their actual capacity (e.g. with an advanced charger), try to match the batteries in pairs of equal capacity. They will give you more mileage. This does not only apply to the Magic Mouse but to any device that connects its cells in series (i.e. practically every device).
P.S.: Anyone who had a wireless Mighty Mouse might remember reading the mysterious notice “3Vdc Agency approvals inside” on its underside. Whatever it meant (I never found any ‘approvals’ while disassembling the mouse), I think the 3Vdc Agency would not approve of the Magic Mouse.