Bramz’ warehouse

When viewing my gallery from another PC, I noticed that the images showed a bit too dark, especially the black and white ones. This was of course due to a badly calibrated monitor. I started looking for some resources on monitor calibration, and this is what I came up with:

black point

The black point is all about how dark are your darkest greys. What is the darkest gray that you will not perceive as black? There are two checks that I found useful, on dry creek photo and simplefilter. You should be able to get this straight using the brightness knob on your monitor.

If you’re on a really bad monitor like I was, and you happen to run on an nVidia graphics card, you might turn to the software settings of that card. Right-click on your desktop and select properties. Go to the settings tab, and click on advanced. Now you should be able to select the tab with the nVidia settings, you can recognize it by the logo. Now gets a bit tricky. Set the color mode in advanced mode. Above it, you’ll see a graph with three nodes: a black, grey and white point. Drag the black point up until you have fixed your settings.

white point

Using the white point test pattern on simplefilter, you can check your monitor’s whitepoint. You should be able to read all figures. If you cannot, you can usually fix this with the contrast knob on your monitor. Adjust it so that you can just read the figure one.

gamma correction

The most commonly used color space for computer images is the standard sRGB space. It is designed to match typical home and office viewing conditions, and uses primaries that match the phosphors of a typical CRT display, and the D65 white point with a colour temperature of 6500K. The color space also is specified to use a gamma correction of 2.2, which also agrees with a typical CRT display. However, not all displays are calibrated for this.

The calibrate your gamma correction, you first need a good test pattern. The best I could find is from photoscienta.co.uk. Select the Gamma 2.2 target test pattern (direct link). Now adjust your monitor settings the patterns look even (squeeze your eye a bit and look from a little distance to get the best result). But how to do that? There are several ways, depending on your set up.

• on monitor: if you’re very lucky, you can set the gamma correction on your monitor itself.
• If you have Adobe Photoshop installed, you probably will have Adobe Gamma too. You’ll find it in the Windows Control Panel. Say that you want the gamma control panel (_not_ the step by step wizard!). Here you’ll find a little slider you can use.
• nVidia control panel. If you have an nVidia graphics card, you can use their control panel too. Right-click on your desktop and select properties. Go to the settings tab, and click on advanced. Now you should be able to select the tab with the nVidia settings. Here too, you’ll find a slider to fix the gamma correction. If you have your using the advanced mode here, you can fix the gamma correction by dragging up or down the middle node of the graph.

colour temperature

If you have a way to set the color temperature of your monitor, you probably should set it to 6500K, as this is the white point sRGB was designed for. Anything more, and your whites will be too blue, anything less and they will be too yellow. If you cannot do this on your monitor, you might be able to fix this using the control panel of your graphics card. However, this is tricky since there’s no test pattern you can use to check this. What you need to aim at is a white that neither has a blue nor a yellow cast.

To get this really right, you actually need some hardware calibration tool like or GretagMacbeth Eye-One Display 2, Pantone Huey, or ColorVision Spyder2. But of course, this are rather expensive products if you only need it once or twice.

Wow, this post has become much longer than I’ve anticipated =)

My first experiment in HDR (High Dynamic Range) photo editing. I’m a bit reluctant to use the term HDR, because technically, none of the images were ever stored in a HDR file format. Unless you count Canon’s RAW CS2 format as HDR, which I don’t. Not really anyway. I also do not count the use of 16 bit channels in Photoshop as HDR, as I didn’t use the extra 8 bits to extend my range, but merely to bump up the numerical precision of the editing.

Anyway, for you who know nothing about HDR, normal images like the one below that are stored in the JPEG format, have what is called a Low Dynamic Range (LDR). That’s because they use only 8 bits per colour channel, and that’s no where near enough to fit the typical range of an outdoor scene. If you want to grass look alright. you often will end up with an blown-out sky. If you aim for the sky, you end up with an underexposed ground. That’s where exposure bracketing comes in. It means that you take the same picture with different exposure settings, and then you merge them into one. You can either use HDRshop or Photomatix to get a single HDR picture that can represent colors beyond the limited 8 bit range, and tonemap it back into a regulare JPEG afterwards (because your screen can’t properly display HDR images, it’s an LDR device after all). Or, alternatively, you can fire up photoshop and try to merge the different exposures manually. That’s what I did.

The shots have been taken at 8 pm in the Gemene Weidebeek nature reserve, a 5 minutes walk from my home. It’s a 40 ha area that consists of common pastures with a creek running through. The name literally means Common Pasture Creek. I did three exposures, each two stops apart. I stacked them as layers in Photoshop, the brightest one on top. I used layer masks to mask block the sky of the top one, uncovering the well exposed sky of the one below. The darkest exposure was used to bring back some detail of the brightest part of the sky. I used levels to lighten up the foreground a bit more, using some dodging and burning to add some contrast.

I hope you like the result =) You can view a larger version in my gallery.

pyvtuneapi is a very simple extension that binds the VTune API to Python. If you have VTune, and you’re using it to profile a Python driven application, you can use pyvtuneapi to pause and resume the analyzer.

As you could read in my previous post, my devenv.exe stopped working since last Patch Tuesday updates. Since rebooting and even reinstalling the entire VS2005 suite didn’t resolve the problem, I’ve tried the only other approach I could think of apart from reformating my laptop: reverting the windows updates. I made an extra backup of my data, and the first update I tried to uninstall was KB936357, a microcode patch for the Intel Core 2 Duo (which my system runs on). Surprisingly, devenv.exe came back alive!

What’s going on here? Does devenv.exe rely on a quirk of the Core 2 Duo that is now patched by that update? Or is it all just coincidence? Yet, the patch seems to be a critical update.

Hopefully to be continued …

update 11th July 2007: I tried to reinstall the patch, and this time, things are still working (knocking on wood). So, perhaps it was just a one-time quirk of the gods?

update 12th July 2007: It seems that other people have experienced the same problems as well. Though they’re reporting the KB928365 update as the culprit, which is a security update for the .NET Framework v2.0. Same symptoms, uninstalling/reinstalling the patch did the trick. It’s quite weird that uninstalling a different patch resolved the problem (I have the KB928365 patch installed as well), and that reinstalling that patch didn’t result in the same problem again. So, maybe the real culprit is still something else?

The Registry is also reporting on problems due to .NET updates of last Patch Tuesday, though their reference is to patch MS07-040 of KB931212 which actually includes KB928365 and KB928366

Today, after a mandatory reboot because of a patch Tuesday windows update, devenv.exe of Visual Studio 2005 no longer wants to start. Well, it tries to start, and sometimes it gives a flash of its main window, but then it dies without a cry.

The first thing one tries to resolve the problem is to reboot … to no avail. Uh-oh … Trying to start devenv.exe from another account? It doesn’t start either. Double Uh-oh …

OK, no panic yet. If rebooting doesn’t help, reinstalling the product will. It’s a bit tedious, but it has to be done. Removing the current installation, installing VS2005 from scratch. Freeing 3 gigs on C: to reinstall SP1, installing SP1, fingers crossed … still doesn’t reboot! Now I’m really scared!

WTF may be causing that much of trouble to devenv.exe? The only thing left to do is to try to reverse the windows updates …

To be continued …

Today, the second étape of the ever legendary Tour de France finished in Ghent, Belgium, the city where I work and live during the week. We got a day off for this event, so what else could I do than to go and watch the tour in real life? I positioned myself on the front line at the 1 km mark before the finish. And of course I also took my photo camera …

Can anyone recognize Gert Steegmans or Tom Boonen on this picture? They all look the same to me =)

update: our local expert identified a whopping four bikers on that picture. In front is Mateo Tossato, followed by Sébastien Rosseler, Gert Steegmans and Tom Boonen. Kudos to Koen!

I’ve finally added an RSS feed to my photogallery. Now, you will be able to easily find the latest additions or updates, without having to browse through all albums. I hope you enjoy it!

From my previous post, you might know about my recent interest in minidumps to debug remote applications. Since then, I’ve been trying to implement an automatic and unattended crash dump facilitiy in Lass. On the Win32 platform, the key functions are SetUnhandledExceptionFilter in kernel32.lib and MiniDumpWriteDump in dbghelp.lib. The former lets you set a function to handle any exceptions that boil up from the application unhandled. The latter is used in that function to actually produce the minidump.

An interesting article on the subject is debugging custom filters for unhandled exceptions, especially the part about patching the SetUnhandledExceptionFilter function once you’ve set your filter, to prevent other modules (and even the runtime library) to set their own exception filters and thereby disabling yours. They do that by dynamically replacing the first instructions of that function by:

xor eax, eax
ret 0x4

Crude, but effective.

Once I’ve got it working on Win32, I started looking around for ways to deal with crashes in a similar way on the Linux platform. This has lead me to the discovery of Google-Breakpad (formely known as Airbag). It is a small open-source library that does exactly what I need: cross platform generation of minidumps on windows, mac and linux. It includes client and server parts, the client existing of a handler and sender. The handler is the actual exception handler that generates the minidump, the sender can be attached to the handler as a callback, in order to submit the minidump to a (public) server. Breakpad does not include an complete functional server, but it includes an minidump processor that converts the minidumps in human-readable stack walk, using local (local to the server) available symbol information. The benefit of doing this conversion on a server, in contrast to GNOME’s Bug-Buddy and Apple’s CrashReporter, is that the symbol files do not have to be shipped to the customer.

Breakpad surely looks like a promising tool that could be used in many (open-source) projects. Currently, there’s a mutual effort to include Breakpad in the next Firefox, replacing the closed source Talkback. This will certainly be a good test case, tremendously improving the library with experiences from a large scale project. For me, I certainly will try to include Breakpad in our software as well. There’s one part missing though: how to set up a public server that can receive the minidumps, automatically process them and inform me of the result. A few hints about deploying such a server may be found on the Mozilla wiki.

Yesterday, I had some fun playing around with remote debugging and examining crash dumps. In the lab, we’re currently running a lot of noise map simulations for a project we’re involved in. These simulations are distributed over all available computers in the lab, a mixture of old and new, often actively used by other people as desktop. The fun part starts when things do not run as smoothly as planned, which is unfortunately often the case. What else to expect expected from software that is simultaneously developed and used in production. We’re a research lab, after all.

Our current noise mapper is pretty young and only supports full multi-threading since recently. Since we use this to squeeze out that extra bit of performance on machines that have more than one core, we started noticing – not surprisingly – inconsistent and hard-to-reproduce crashes. Reproducing the crashes on the development box was not feasible as you could just spend hours waiting for the crash to happen. Debugging the crashed programs locally wasn’t an option either, as most of them didn’t have any debugging tools installed whatsoever.

Last week, I’ve found some time to investigate the problem further, and I first started poking around with remote debugging in Visual Studio 2005, but it wasn’t really helpful. Normal use requires that you have identical accounts on both PCs. In the heterogeneous environment of our lab, without central user management and where everyone admins his own desktop PC, this is not a easy thing. However, it also has a no-authorization mode (who needs security anyway =), and after disabling the firewall (the rule automatically created by the remote debugger somehow wasn’t enough) and modifying some obscure security setting, I finally was able to connect to it from my dev box. Unfortunately, I only got corrupted call stacks, so it wasn’t of any help at all.

But that’s when I noticed something really wonderful: minidumps. When your program crashes the hard way on WinXP and later, it pops up a dialog box asking if you want to send debug information to Microsoft. You of course don’t want to do that, but at that moment, a minidump already has been created. You just need to secure it before you click away the dialog box. Then you copy it to your dev box, open it in visual studio and press F5. Et voila, you get an instant reproduction of the crash, ready to be debugged. Then it was almost a breeze to solve the problem.

Why have I never noticed this before? It’s so helpful to investigate problems that happen on machines other than yours. It’s plain magic. I’m thinking of building it in in our software so that the crash dumps are automatically send to me. If I also can avoid the dialog box, I can run the simulations unattended, and still be reported of any issue. When a crash happens, the program simply sends me the crash dump and tries to run the next job. I already have something similar for problems that arise in the Python code of the simulations, but this would make it complete.

Perhaps to be continued =)

I’ve bought myself a Canon EOS 400D recently. It’s a digital single-lens reflex camera what means it uses a mirror to show the image in a optical viewfinder instead of showing them on an LCD, and that you can also replace the lens. I’m pretty happy with it, it’s a nice machine that gives you total control of the image you want to shoot. I only have the standard kit lens on it now, which is of somewhat minor quality. But good lenses are expensive, so I’ll learn to take better pictures first =)

Anyway, I decided to set up a photogallery because taking pictures without showing anyone is a bit … well … senseless. I’ve also made an LiAR album where I’ll upload some high definition renders made using my own renderer LiAR isn’t a raytracer. Unfortunately, I seem to have lost many of them =(