Skip to content

8

I mentioned in an earlier post that I was intending to go to the bottom of certain rumors about Panasonic including lens defect correction data in the EXIF information of RW2 files. A number of commercial photo software programs are known to manipulate the RAW image data to remove geometry distortion, chromatic aberration and vignetting silently, which lead to enthusiastic reviews posted on certain digital photography sites about the quality of the Lumix G1 kit lens. However, I know from developing my RAW files with ufraw and digikam that the kit lense has a significant barrel distortion at short focal lengths.

One way to automatically correct those distortions is collecting correction data in a database like PTLens and Lensfun. The photo software knows what corrections to apply to images taken by a certain camera with a certain lens at a certain focal length. That approach however requires significant effort for maintaining the database plus you will always be playing catch up with the camera manufacturer developing new lenses. Not an issue for independent open source efforts, we've been running after information from vendors ever since, but not a good situation for the camera vendor. Unless he runs after the software companies to update their databases whenever he releases a new lens, images developed from his cameras RAW files will be not optimal. I would not want that, especially not if I wanted to reduce development cost and retail price for new products.

Panasonic most likely went the second way, which is having software makers implement the same correction algorithms they use in their cameras and embedding the necessary correction parameters inside the photos meta data. Doing it that way allows for lesser synchronization effort between Panasonic and software vendors and faster time to market. With some effort it might be possible to use this correction data also in open source software.

That being said, there's now a couple of tasks to be done until the correction data can be used:

  1. find out what information is stored, and where
  2. reverse engineer the format of the correction parameters
  3. understand how it's applied to image data
  4. proof of concept implementation

I believe I've made some progress today on 1.), finding out what information is stored and where. I inspected some of my RW2 files to see what Exif tags they contain and found a couple of tags that are not decoded by exiftool or exiv2. They just contain some data bytes in unspecified format. I noticed that they seem to vary from file to file and decided to find out if I could reproduce the values.

Reverse engineering is a black box approach. In our case the camera is the black box, inputs are the controls like aperture, focal length, exposure program etc, output are the generated RW2 files. You cannot observe the inner workings of the black box other than by observing differences in the output when making modifications to the input. It definitely helps if you can make an educated guess about the inner workings of the black box. For geometry correction, I know a bit about how its corrected, so that is my first target.

I know that geometry distortion depends on the focal length, so I made a couple of shots with the kit lens at 14mm and 45mm, two at each. Then I looked at the Exif data and found one tag, "Exif.PanasonicRaw.0x0119", where the data did not change for images taken at 14mm, but changed significantly when going to 45mm.

14mm:

84 236 201 47 38 0 0 0 43 1 0 0 141 1 1 0 208 14 238 1 86 2 2 252 196 9 226 3 228 72 36 134

45mm:

152 94 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 86 2 0 0 196 9 0 0 35 234 24 155

Looking at the data, you see something interesting - a lot of Zeros appearing at 45mm. Nothing changes from 45mm to 35mm, which looks like this:

35mm:

161 54 43 194 51 0 0 0 0 0 0 0 0 0 1 0 42 0 1 0 86 2 1 0 196 9 245 1 176 16 17 65

Still a lot of Zeros, but lesser. What does this tell us? Now, I know that the geometry of the lens is almost perfect at 45mm, so I expect that there is less correction necessary. It's reasonable to assume that some parameters of the correction formula will become very small, or zero. The data in the Exif tag apparently follows our expectations. I also assume that the data is not encrypted.

The next task is now to find out how the data is formatted. Most likely these parameters are rational numbers. What I don't know yet is the representation. Is it 16, 32 or 64 bit per coefficient? Am I looking at fixed or floating point numbers, little or big endian? Does this tag only contain correction parameters for geometry, or also for chromatic aberration? The tag contains 32 bytes, so it's either 16, 8, or 4 coefficients. I'll have to do some research on geometry correction, maybe Panasonic uses something that is public domain.

It looks like a prominent method of correcting lens geometry is based on Zernike polynomials. The PanoTools lens model uses polynomials as well. One property of polynomials is that you can use as many parameters as you like, it just depends on the order of the polynomial. It's merely a question of computing power available. I could start with a 2nd or 4th order polynomial like the PanoTools model and try to match the tag information with coefficients computed by Hugin.

1

I'm happy to report that my hack to the sony-laptop kernel module works. We were able yesterday to make the first UMTS data connection with my wifes' Z21, using HSOconnect on openSUSE 11.1. Her detailed description of installing openSUSE 11.1 on the Z21 can be found here, you can also download the source code of the sony-laptop.ko. It's a very rough first version, don't expect packages or inclusion into mainline kernels soon. Still, it gets you where you want.

Loading the module will generate a new file /sys/devices/platform/sony-laptop/snc_wwanpower, you can switch the modem power with "echo 1" and "echo 0".

I'm still working on the graphic card problem, hopefully I'll have a solution soon.

1

My wife urged me today to work on her new Sony Vaio Z21, which is, as anyone able to use Google will know, not particularly well supported by any recent Linux distribution. This is not exactly due to the completely fancy hardware components, rather by the completely undocumented methods of how to switch them on and off.

As an example, the Z21 has a builtin 3G modem, an Option Globetrotter, which is connected to an internal PCIe slot, which means it should just show up on the USB bus. Unfortunately it does not, not under Linux at least. The reason is that Sony chose to switch the modems power supply through an embedded controller chip on the motherboard. This embedded controller is nonstandard and therefore not managed through standard ACPI methods you would find under /proc/acpi, however there is a small kernel module, sony-laptop.ko, which provides an interface to some of the Sony proprietary device functions. The Z21 is unfortunately not supported yet by this module.

Well, it was not difficult to make the module detect the Z21, but the fun just started at this point: None of the functions provided by this module worked. Nada. Zero. OK. Turned out that while the Z21 contains the same "Sony Notebook Controller" as other Vaios, it did not react to any of the known ACPI method calls. So, I started looking deeper into the DSDT. I had never done that in depth before, but looking at the decompiled DSDT ASL, knowing that the DSDT is really not a table but rather byte code, it wasn't difficult to understand that the "SN07" method of "SNC" device was the key to switching the modem on and off. After traversing several levels of If/Else statements I found that calling "SN07" with 0x9f070803 as argument switches on the 3G modem, while 0x00000803 turns it off again.

Unfortunately this is not the end of the story. While the modem is now accessible via USB and even recognized by the hso.ko driver module, and even while we're able to talk AT commands via ttyHS0, we have yet to make the first data connection.

The biggest challenge will however be to understand the weird inner workings of the graphics adapters. The Z21 has two of them, an Intel GM45, and and some Nvidia with a name that I currently cannot remember. Under Vista you can dynamically switch between them, and unfortunately the BIOS lacks any preset, so when you cold boot into Linux, both of them are active which completey confuses the drivers and disables direct rendering. I know the answer is somewhere inside the DSDT devices and methods, but it's hard to understand this from reading the disassembled bytecode, without comments or sensible variable names.


Ready!
Originally uploaded by thinkfat

Since we got our new digital camera I have been using it quite regularly and I got very much interested again in digital photography and everything around it. I used to shoot lots of photos when I inherited my grandfathers Cosina SLR, despite the tedious act of having the film developed and paying for prints just to throw lots of them away.

I don't quite remember why I never picked up a digital SLR camera when they became fashionable, but they were quite expensive back then and anyway I spent most of my money (and most of my time) on amateur radio equipment. Today the situation has changed. DSLR cameras today are mass market products, not just for photography enthusiasts.

So, I familiarized with the Lumix G1 quickly and today I carry it with me almost constantly. The photo in this blog post links back to my flickr account, you're welcome to have a look at some results of my early ventures into digital photography.

Interestingly, this camera got me back to KDE programming again. Of course I started using various 'K' programs like KPhotoAlbum or DigiKam to keep track of my growing collection. And sure enough, once you start using a 'K' program, you find lots of small annoyances that demand fixing. So I hacked kflickr to upload resized pictures with an adjustable quality instead of some default value, digikam to recognize the lens description of the Lumix G1, the flickr export plugin to allow uploading to the photostream only instead of requiring a set and I'm now trying to automatize lens defect correction using information embedded in the RW2 files this camera generates when shooting 'RAW'.


p1020151.jpeg
Originally uploaded by thinkfat

If the motorbike virus has you, somehow it's not a question of convenience any more to go for a quick ride or not. So right after lunch today we took out our bikes for the first time this year. It was sure a bit chilly still at 5°C but with the right clothing it was bearable. We drove up to Neunkirchen, had a coffee and apple pie and went back home again.

I also took the opportunity to see if the camera setup I envisioned for our summer vacations would work out, and I'm happy to report that the Lumix G1 fits nicely into the tank pack as planned and is easy enough to operate while on the bike.

I also experimented with the geotagging feature of digikam, which worked quite nicely. I downloaded the trip log from my GPS after the ride and told digikam to correlate the images I had taken. It added a set of tags to the EXIF information that show the location where the photo was taken - well, to be precise, the location where the GPS receiver was when the photo was taken, but since it's mounted on the bike, that's not going to be too far off.

Now if I only could get flickr to consistenly import the location data. It's working only sometimes and I don't know why.

Of course the weather did not improve over the weekend and there wasn't much point in going outside "hunting". But this night the temperature fell below freezing point and today morning everything outside had a nice glaze of frost. I did a quick walk through the garden to take a few pictures. This rose came out particuarly nice. I didn't play around with the program, probably I could have achieved a more blurred background with a wider aperture:

Another nice shot, some latent Hibiscus buds:


I'm hoping for nicer weather now ...

So eventually, after a one-day intermezzo with the D40 (which is definitely a very nice camera!) we settled on the Panasonic Lumix G1. I didn't have much time to play with it yet, but it's really quite a nice camera. It's tiny, and solidly built. It's a huge difference to the D40, which feels a lot more plastic-y. But that's somewhat expected, after all the D40 costs about half of the G1.

I've shot a few test photos indoors and it's not a bad performer there. The view finder is a bit noisy in low light but it doesn't influence usability much. Still, if it gets really dark the frame rate of the view finder decreases a lot. Not sure why, I guess the camera then averages across several frames to keep the noise down.

The auto focus is fast. I have no comparison to DSLR cameras in the same price range, but it's easily as fast as the D40 (which probably doesn't say much).

The flashlight seems a bit weak. Where the D40 tended to overexpose, the G1 is more into underexposing images shot with the flash. Might be a configuration issue, I haven't figured out all the settings yet.

I'm very pleased. I'll try to make a few outdoor shots during the weekend. Hope the weather improves over night, it just started raining again.

As Christmas approaches quickly, my wife and I are trying to figure out what presents to give to friends and family, and to ourselves. We figured it'd be time to bite the bullet and get ourselves a new digital camera. We own a rather old Casio 3 MP compact DSC that has served us well for a couple of years but now the case is seriously starting to fall apart. The latch of the battery housing lost its lock and now it doesn't want to keep shut and can only be held in place with some duct tape. Anyway it's a pretty old camera, slow and with very limited features, its only advantage being, well, it's compact.

Now, while we could just get a similar DSC to replace it, unfortunately we both are a bit gadget crazy. Also, my wife owns an old Minolta SLR that makes awesome pictures but could be replaced by something more fancy. It's quite battered, the case is cracked a bit so she put some black insulating tape over the crack to keep light from coming in. And now we've got to decide what we want to get.

The options are close to infinite. Should we go for a real DSLR or is a "bridge" camera with a 20x Megazoom the better choice? And since we also love travelling with our motorbikes and taking pictures on the road, wouldn't a point-and-shoot compact camera be a much better idea? This weekend I've looked at a lot of reviews and narrowed down the options to only a few, but it's still tough.

For a compact DSC, the Canon PowerShot G10 could be a good choice. But it's got a too small sensor with way to many pixels (14.7MP) and quite consequently it suffers from noise a lot. Looking at the sample pictures the reviewer took, already at ISO 200 you can see the effect of noise filtering done by the camera, taking away sharpness and details. However, there's the predecessor G9 with a slightly "smaller" sensor at 12.1MP which has better noise figures. The G9 or G10 would be the ideal travel companion on the motorbike. Still, it's not an adequate replacement for the Minolta.

We know from experience that a small SLR camera can be handled easy enough even while sitting on the motorbike, balancing the bike with one foot on the ground and the other foot on the brake pedal, even with the helmet on. You just use a wide angle lens and point the camera to the approximate direction and press the trigger. A life preview like on compact DSCs helps but is not strictly mandatory. Changing lenses to go from wide angle to zoom is out of question, however.

This is where we enter the domain of Megazoom bridge cameras. I looked at two models, the Nikon Coolpix P80 and the Canon PowerShot SX10IS. The fixed lense ranges from wide angle to extreme zoom and their sizes are similar to compact SLR cameras. But again, a small sensor and high pixel count drive up the noise figures. The SX10IS is much better than the P80 there, but its image quality is just about par to the compact PowerShot G10, this leaves the long zoom as the main advantage. But again, on a motorbike its very difficult to use a long zoom even in good light.

The Panasonic Lumix G1 is an interesting candidate. It's a so called "Micro FourThirds" camera with a big 4-by-3 sensor at 12.1MP. It's not a real DSLR, because there is no mirror box and hence no optical view finder. But leaving out the mirror box and using a electronic view finder allows to make a very compact case. Not that compact however. It's not much smaller than compact DSLRs, but it's got a twist-able live preview display which is an advantage over regular DSLRs. The image quality is stunning! Due to the big sensor the noise figures are much better than of any of the MegaZoom or 10+ MP compact cameras and the quality of the lense is much better as well. The lenses are however also the weak spot: They are exchangeable and currently there is just two options, a variable 14-45 mm and a 45-200 mm. I already stated that changing lenses on a motorbike is a no-go. But I also said that a long zoom is difficult to handle anyway and looking at our trusty Minolta, we find that it also has a vario lense with 28-70 mm focal length, which is about equivalent to the 14-45 of the G1. And we know from experience that a compact SLR works well with the bikes.

Enters another contender, the Nikon D40. This entry level DSLR has a 6.1MP Nikon DX sensor(crop factor 1.5) and is amazingly cheap to have. The noise figure of this camera is really, really good. It doesn't even feature any ISO below 200, it's just not necessary! You can expect it taking very good pictures especially under low light conditions, think sightseeing and not needing to carry a flash for photographing in churches, crypts or in fading daylight. It's also quite well established and has a wide range of lenses to chose from. It's currently sold as a kit of body and 18-55 mm plus 55-200 mm vario lenses. Cons: it's larger than the Lumix G1 and doesn't have a life view display. On the positive side there's the image quality and the wide variety of lenses, making it the perfect replacement for the old Minolta.

It's still a tough choice. On one side compact cameras can be carried wherever you go and taking out the camera to shoot is quick and easy. But then, my wife also owns a Nokia N95 with a built-in 5MP autofocus camera, we have used it on our last summer holiday trip with good results. So is there really a need for another compact DSC? MegaZoom cameras are very versatile due to the wide zoom range. However the image quality appears to suffer from the technical constraints and the long zoom is no advantage while on the motorbike. Still, in the coming days we'll also look at new model, the Canon PowerShot SX1, but it's hard to tell if the use of a CMOS sensor can do anything about the image quality. The Micro FourThird Panasonic Lumix G1 is quite a cool device. The electronic view finder is stunning, image noise figures are not so bad and the quality of the lenses is very good. But will it survive as a concept so that more lense options will be available eventually? Experts seem to be undecided. And since it's not really small, why not go all the way and buy a real DSLR like the Nikon D40?

1

Kubuntu just shipped an update to their Linux kernel to 2.6.27-9. It didn't help about the U100 webcam problem but at the same time disabled the driver I had hacked up earlier. To make my life easier I extracted the uvc video driver from the kernel sources into a standalone package. This way I can recompile the driver with a simple make whenever a new update comes along.

I figure it could by useful for others as well, so it's up here for download. Compiling and installing should be fairly straight forward, just unpack the sources and type make in the extracted directory. For Intrepid you'll probably need to install a number of packages with essential build tools and at least the kernel header files. There are some HowTo's about compiling kernel modules without installing the full kernel source, however I think it should be enough to just

apt-get install build-essential linux-headers

Once compiled, just install the module as follows:

# cp uvcvideo.ko /lib/modules/$(uname -r)/updates
# depmod -a

This should be all. You can now test the webcam driver with for example xawtv. If you don't succeed, it may be that the old driver module is still loaded. Remove it with rmmod, or if you're entirely lost by now, just reboot.

Since I bought the U100 about one week ago I have been using it in a quite regular fashion. It currently replaces the Archos 5 as the main gadget I spend time with, which was somewhat expected due to a netbook being a much more versatile companion than a portable media player. That doesn't mean I've given up on the "5". It's strong multimedia and internet capabilities (it's even got a decent email client) make it a nice leisure companion, but I cannot use it for hacking and writing blog entries, while doable, is also nothing it really excels in.

Back to the U100 and Kubuntu. I've managed to get almost every bit of built-in peripherals working by now, except for Bluetooth, which I will come to later.

The hardest part so far was getting the camera going. It's an "Asus BisonCam" with USB VID:PID 5986:0203. On first sight it looked like this camera was supported by the Kubuntu linux kernel (2.6.27) because it was instantly recognized by the standard uvcvideo driver, however it did not work at all with either Skype, VLC or even Xawtv. I found that the driver had been moved to LinuxTv so I went and grabbed the latest snapshot from the v4l tree. However, while compiling the snapshot was not much of a problem, the resulting kernel module uvcvideo.ko could not be loaded due to symbol version differences. After several (fruitless) attempts to compile a driver matching the installed kubuntu kernel I looked at the source and found that the linuxtv people were following their habit of breaking compatibility with the mainline linux kernel, making sure that their drivers only work with their very own V4L API.

While it would have been possible to solve this by installing all modules of the v4l tree into the system I didn't feel like butchering my freshly installed system. But, no reason for distress. It took about one hour of tinkering with "kompare" to merge the few relevant changes from the LinuxTv driver into the existing Kubuntu kernel (including compile time). Had Kubuntu provided kdiff3 packages (which they don't), the whole affair could have been even easier. Kompare is not a bad tool, but kdiff3 is a magnitude more versatile.

Adding the office printer was a bit of a challenge, too. There actually is a printing framework in Kubuntu, but it seems to be just a frontend to CUPS and entirely relies on a local CUPS server being running on the system. KDE 3 used to have excellent printer support, but I guess nobody bothered yet to port this code forward to KDE 4, that's a real pity.
For some reason the local CUPS didn't pick up the printers exported by the CUPS instance on our office server and so I had to add them manually with konqueror via localhost:631 and using the web interface, and even then it only worked well after manually installing the printers PPD file. I also tried with the "HPLIP Toolbox" Kubuntu supplies but that only seems to work with HP printers (as the name suggests). Our office printer is a Ricoh iR3170C.

Bluetooth is not working yet. While the hardware is supported - I can switch it on with Fn-F11 and then use hcitool to scan for peers - it does not work at all with KDE. Searching in Launchpads bug tracker I found that this is a well known problem. Apparently there was a rather hasty switch to kernel version 2.6.27 which brought in a new BlueZ version with a completely reworked D-BUS interface. The incompatibility broke KDE's bluetooth support entirely and due to some communication breakdown between Kubuntu and upstream KDE developers the issue wasn't fixed in time. I can only hope that happens soon. I used to use my mobile phone as a modem when in a train or staying at hotels without WiFi. It'd be a real pity losing this. However, the Gnome side of things doesn't look too brilliant either. I installed the gnome bluetooth applet and tried to get modem dialing working but it wasn't possible either. It just wouldn't detect my mobile phone and then it only seemed to support OBEX and some audio profiles. KNetworkManager also doesn't offer any modem support. I wonder why because it definitely works on openSUSE 10.3.

There are some stupid power management bugs, too. For example, DPMS doesn't seem to work, the display just doesn't want to shut down. Also, coming out of suspend the display brightness isn't adjusted when you're on battery power. Also, hibernation sometimes hangs and only forcing an emergency shutdown (long-press on power button) gets you back in control.

I also found that reboot and shutdown from the KDE desktop don't work. It just exits to KDM and from there the system sometimes hangs when you try to shutdown or reboot.

All in all Kubuntu 8.10 looks a bit unpolished. There are no major problems apart from the broken Bluetooth but at the same time there are a lot of small nevertheless annoying malfunctions. Not annoying enough to ditch Kubuntu yet, provided they get their distribution fixed soon enough. I'll re-evaluate when openSUSE 11.1 comes out around Christmas.