More HDR

Since my previous post about HDR, I bought a more professional camera with both a larger, less noisy sensor, and a more advanced bracketing function. The camera is a Panasonic Lumix DMC-GX1 with the standard ‘pancake’ powered zoom lens. I still mostly follow the steps explained in my article about Luminance HDR, but with this camera the preprocessing step is almost always unnecessary. Here are some results, enjoy…

Sinds mijn vorige post over HDR heb ik een meer professionele camera gekocht met een grotere, minder ruizige sensor, en een meer geavanceerde bracketing-functie. De camera is een Panasonic Lumix DMC-GX1 met de standaard ‘pannenkoek’ power-zoomlens. Ik gebruik nog steeds grotendeels de workflow die ik uitgelegd heb in mijn artikel over Luminance HDR, maar met deze camera is de preprocessing-stap bijna altijd overbodig. Hier zijn een paar resultaten, geniet ervan…

Photography 101: avoid taking a photo with the sun shining into the lens. Puh!

Fotografie voor beginners: vermijd het nemen van foto's waarbij de zon in de lens schijnt. Puh!

The Arenberg castle near Leuven. Mind the crane, soon it will be impossible to take a photo like this without the new IMEC aquarium office building sticking out behind it like a sore thumb, courtesy of the great Flemish spatial planning and a certain mayor's delusions of grandeur.

Het Arenbergkasteel nabij Leuven. Let op de kraan, dankzij de fantastische ruimtelijke planning in Vlaanderen, en de grootheidswaanzin van een zekere burgemeester, zal het binnenkort onmogelijk zijn om een foto zoals deze te nemen zonder het nieuwe IMEC kantooraquarium dat de achtergrond verpest.

 I predict that if I will be taking a photo at this exact same location in ten years, it will be filled with asphalt roads and multiple specimens of the typical fake rustic villas that are prevalent in Belgium, as well as some of the newer-style shoeboxes.

Mijn voorspelling is dat als ik over tien jaar een foto neem op exact deze zelfde plek, hij gevuld zal zijn met asfaltwegen en meerdere specimens van de typisch Belgische faux-rustieke villa's en de recentere stijl van bewoonbare schoendozen.

 This was a royal pain due to the animated ‘raindrop’ lights hanging from the trees, which caused significant differences between the three differently exposed photos. These differences became ugly artifacts when creating the HDR image the straightforward way. The only solution was to manually erase all differences such that the lights were consistent between the three different exposures. I shortly tried Luminance's “Anti-ghosting” tool for this, but I could not get it to work, so I used the good old GIMP.

Dit liep niet van een leien dakje door de geanimeerde ‘regendruppel’-lichten in de bomen. Deze veroorzaakten grote verschillen tussen de drie foto's met verschillende belichting, wat dan tot lelijke artefacten leidde in de HDR-foto. De enige oplossing was deze verschillen manueel uit te vegen zodat de lichten consistent waren tussen de drie belichtingen. Ik had even geprobeerd de “Anti-ghosting” functie van Luminance hiervoor te gebruiken, maar ik kreeg het niet aan de praat dus ik heb de goeie oude GIMP gebruikt.

GIMP 2.8 gripes

I have used Photoshop since one of the early versions when it came as a freebie with a UMAX flatbed scanner (yes, a time when Photoshop was given away for free, I am that old). When the price of Photoshop started rising to astronomical levels and when I started using Linux more often, I tried GIMP and gradually became accustomed to its unusual interface. It did most of what I required, except higher bit-depth editing. Eventually I almost completely ditched Photoshop and do pretty much everything in GIMP.

Now I have been using GIMP for years, and I have seen it evolve. This evolution was always gradual and most of the time it was subtle between versions. With version 2.8 however, there are some not so subtle changes and some of those rub me in a pretty wrong way:

1. The sliders: there are many, many people complaining about these. They are completely non-intuitive. Apparently the sliders are invisibly divided in different regions that cause different behaviour, which has to be guessed from the cryptic changing arrow cursors. I refuse to follow a tutorial or read a manual just to use something essential as a slider. And what's up with stuffing the text display inside the slider? These things violate the KISS principle in a way that makes me hurl and would make Steve Jobs cry. I simply gave up and now always enter the numbers manually, which also requires quite a bit of skill because of the risk of grabbing the sliders instead of clicking the editable text.
2. Brush size: previously, absolute brush size depended on two factors: their actual size (radius or bitmap size) in the preset, and a scale factor in the brush settings. The upside of this was that it was possible to create presets for commonly used brush sizes. Simply click a brush and off you go, if you wanted a custom size then adjust with the scale slider. What they now did is decouple the radius from the presets: each brush shape is normalised to one-pixel radius. Defining three circles at radii of 5, 10, and 20, is almost pointless because those three brushes will behave identically. The size must be set manually with — yes indeed — the awkward sliders, each and every time a different brush size is required. What used to be as simple as clicking one preset in the palette has now become: a) clicking the desired shape in the palette, b) having a go at the horrible sliders and giving up, c) trying the up/down buttons and giving up because they use ridiculous 0.01 size increments, c) having a fight with the slider to obtain access to the size edit field, d) typing the desired size. After some experimenting I found out that for brush shapes that do not fit in a square, the radius is determined by their largest dimension. For instance, to paint a brush shape defined at 24×35 pixels at its original size, the size must be set to 35. Now, the radius or bitmap size in the preset has not become entirely useless. There is a small obscure button to the right of the size field that will set the brush to its ‘native’ radius. Hence the old behaviour can be mimicked with two clicks. This may not seem like a big deal but I heavily rely on pixel-accurate brush presets for a lot of my editing. I am already annoyed by the amount of clicking around I need to do in GIMP, therefore every additional click is an added nuisance. My suggestion: clicking a brush preset while holding some modifier key (shift, alt, …) should both select the brush and set it to its native size.
3. The default brush is the clipboard brush: I almost never use the clipboard brush and if nothing was copied, nothing is brushed. And of course, if something is in the clipboard it is rescaled to the default size of 20 pixels thanks to what I described above! Doesn't it make a lot more sense to select the plain circular brush upon starting GIMP?
4. Separate save and export: the ‘save’ dialog now only allows to save in GIMP-specific formats. For all the rest, a different dialog called ‘export’ is needed. The point is, this dialog is identical in design and function to the save dialog, only it needs to be accessed from a different menu item. What is the point of this? Hidden propaganda for the XCF format?
5. Brush dynamics: to replicate the old “fade out” feature, I had to take a journey through many unintuitive windows. Eventually I arrived at something that behaves like the old fade, only it felt like I had to configure things backwards to make it work. I guess the new dynamics controls are an improvement if I would actually have something with pressure sensitive input, but was it too much asked to add a simple ready-to-use preset that mimics the simple old “fade out”?
6. Weird tool behaviour: sometimes the ‘move’ tool suddenly switches to path mode, which makes me wonder why I cannot move anything until I look at the tool window, or the ‘select’ tool switches to subtract mode for reasons unknown. There are other weird things like the arrow keys suddenly acting as “zoom in/out” even when the move tool is active. It seems like there are hidden key bindings and hidden states. One of the things I dislike about GIMP compared to Photoshop is that I often have to mash my keyboard and mouse just to do a few simple things that required one keypress and one mouse click in Photoshop, because in GIMP keys behave differently depending on what window in the interface has focus. With this version, this dependency on contexts only seems to have got worse.
7. Fuzzy select: I have always found the ability to adjust the threshold on-the-fly of the magic wand (fuzzy select) or similar colour tools to be one of the greatest features that sets GIMP apart from other editors. The way in which the selected regions are highlighted has now changed however, with two consequences: one, unless when zoomed in single-pixel regions are not visible in the selection. This is very annoying because I often use these tools to detect and remove single-pixel noise. Second, the updating of the selected area when changing the threshold has become horribly slow. I cannot tell whether this is inherent to the new system or due to the slow display update bug in the OS X version, but it has made working with these tools a hassle.

The whole redesign gives me the impression that a few newcomers have joined the project and imposed their specific ideas of image editing upon everyone. My impression is corroborated by reports from other people who say that the developers, apparently in a bout of arrogance, feel that GIMP 2.8 is perfect and everyone who dislikes the new design is a noobish amateur. I guess I must also be a n00b with my more than eighteen years of graphics editing experience.

Of course there are some plus points as well to the new version, like a native Mac OS X build, the text editing system, and layer groups. If only there was an option to switch back to plain sliders, and to instantly set brush size to the native radius when choosing a preset, then I would happily adapt to the few other minor things that bug me — if the obvious bugs would get solved too.

I also experience very slow canvas redraws for large images and when using the magic wand tool, but I suspect this to be a bug in the OS X build.

Schrödinger's tarball (or ZIP file)

Ever so often I download a piece of software or source code packaged in a .tar.gz, .tgz or .zip file and unwittingly unpackage it inside a directory that already has a lot of other stuff in it. What I expect if I untar a file called CoolSourceCode.tgz, is that it will contain a directory CoolSourceCode with everything else inside it, for instance:

CoolSourceCode.tgz contents:
CoolSourceCode/
CoolSourceCode/Makefile
CoolSourceCode/cool.h
CoolSourceCode/main.cpp
CoolSourceCode/stuff.cpp

What I often get however, is a load of loose files at the root of the archive, like this:

CoolSourceCode.tgz contents:
Makefile
cool.h
main.cpp
stuff.cpp

The result is that all these files are then spewed and littered across the other files in my directory, with a risk of overwriting existing files that happen to have identical names.
Of course I can avoid this by first looking at the contents of the archive or always unpacking it in a new empty directory. Now, it seems to me that every time I take those precautions, the archive has been properly packaged with a main directory. If I am too lazy to do it however, boom! I am mercilessly punished. I therefore believe the contents of each tarball I download are in a quantum state of having both a top-level directory, and not having it. When I observe the contents or prepare for the worst, it collapses to the first state, if I fail to observe it, it collapses to the second state.
The bottom line is: before tarring, zipping or whatever-ing an archive, please avoid tampering with quantum mechanics. Put your files in a single main directory and compress that directory as a whole.

Schrödingers tarball (of ZIP-archief)

Regelmatig download ik een softwareprogramma of broncode die verpakt zit in een .tar.gz, .tgz, .zip of een ander gecomprimeerd bestand. Zonder nadenken pak ik dit ding dan uit in een folder waar al een hoop andere bestanden inzitten. Wat ik verwacht als ik een archief getiteld CoolSourceCode.tgz uitpak, is dat het een folder CoolSourceCode bevat waar al de rest in zit, bijvoorbeeld:

Inhoud van CoolSourceCode.tgz:
CoolSourceCode/
CoolSourceCode/Makefile
CoolSourceCode/cool.h
CoolSourceCode/main.cpp
CoolSourceCode/stuff.cpp

Wat ik vaak krijg echter is een hoop losse bestanden in de ‘root’ van het archief, zoals:

Inhoud van CoolSourceCode.tgz:
Makefile
cool.h
main.cpp
stuff.cpp

Het gevolg is dat al die bestanden dan uitgespuwd en rondgeslingerd worden tussen de bestaande bestanden in mijn folder, met een risico op overschrijven van bestaande bestanden die toevallig dezelfde naam hadden.
Natuurlijk kan ik dit vermijden door eerst de inhoud van het archief te inspecteren of het altijd uit te pakken in een nieuwe lege folder. Nu, het lijkt mij dat telkens ik zulke voorzorgen neem, het archief mooi verpakt is met een hoofdfolder. Als ik echter te lui ben om dit te doen, boem! Ik word meedogenloos afgestraft. Daarom geloof ik dat de inhoud van elke ‘tarball’ die ik download in een kwantumtoestand verkeert van zowel een top-level folder te hebben, en ze niet te hebben. Als ik de inhoud observeer of mij voorbereid op het erste, vervalt de toestand naar zijn eerste mogelijkheid, bij het onvoorbereid uitpakken vervalt ze naar de tweede mogelijkheid.
Wat ik natuurlijk gewoon wil zeggen is: alvorens u een hoop bestanden samenpakt in een ZIP, TAR of ander archief, vermijd a.u.b. deze kwantummechanische problemen. Maak eerst een hoofdfolder, steek al de rest daarin, en comprimeer de hoofdfolder als één geheel.

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.