LWN.net Weekly Edition for November 29, 2012

Open source High Dynamic Range photography in 2012

Back in 2010, we looked at Luminance HDR, a standalone application for creating and editing high dynamic range (HDR) images on Linux systems. At that time, Luminance was a technically capable tool with a byzantine user interface that often got in the user's way. In the intervening two years, the program has made strides, although it has yet to break through the easy-to-grok barrier. But it still remains one of the best applications in a small set of open source options.

In 2010, Luminance was at version 2.0.1. Today, the latest release is 2.3.0, which was released in July 2012. The intervening releases introduced cross-platform support (including Mac OS X, which is a popular request among photographers), 64-bit processor support, and significant speed improvements through harnessing multiple CPU cores. The core of the application has been reworked as well, and it now uses LibRaw for raw photo conversion, Lcms2 for color management, and has separated the user interface out — which allows for a new command line front-end.

The feature set is essentially the same as in earlier versions, however. Users can import a stack of images taken at different exposure levels and blend them into one; the combined image covers a far wider range of light-to-dark than a camera sensor can grab in a single shot. The "exposure-blended" output can be exported either as an HDR image (in OpenEXR or TIFF format), or tone-mapped into a more pedestrian low dynamic range (LDR) format. There is one new tone-mapping algorithm in the latest builds, a size-independent version of the Fattal method, and there is an alignment tool which is supposed to support aligning raw images. The other big news on the feature front is support for batch processing, for those who create a significant number of HDR images.

Underexposed	Exposed	Overexposed

Luminance put to the test

The most visible changes in Luminance 2.3.0 are in the user interface, however. Most notably, the application confines itself to a single window — the old interface popped-up multiple windows and windows-embedded-within-windows, which quickly leads to clutter. There is a "wizard" to guide the user through the process of importing and aligning images. Once the image stack is aligned, the user can click through previews of the output using all of the application's available algorithms, and adjust the settings of each to gauge how they affect the output. This is a big improvement over the old interface, which required generating each output option separately, then eyeballing them side-by-side in preview windows. Toggling back-and-forth between the options brings out the often subtle differences between the various effects.

On the other hand, the application has done little to de-math-nerd-ify the settings and preferences. In 2010, I speculated that there may be a limit to how much simplification can be done — the algorithms are complex equations with a host of esoteric variables, after all. But Luminance still fails to offer the user any real clues, presenting instead a list of preset profiles with the utterly opaque names "Profile 1, Profile 2, Profile 3, Profile 4," (and so on) on the last screen of the project wizard. I could not even find an option to rename the profiles. Being able to tweak each algorithm's settings is important, and seeing the changes applied instantly is a boon, but the generic names create a usability barrier.

For example, one of the algorithms always produces desaturated output, and another produces a significant "black outline" effect. Renaming the profiles "Desaturated" and "Outlined" might not be technically correct, but it might help users learn to work with the available options. Sure, user-assigned profile names will be non-standard, but so are the generic "Profile N" monikers. Does anyone know which of the numbered profiles represents the algorithms used in other tone-mapping programs, like Enfuse?

2.3.0 is easier to navigate than the older releases, but it still has is its share of bugs. In particular, the alignment tool failed completely in all of my tests. The interface allows manual, fine-grained adjustment of the imported images, but the adjustment is immediately lost on the next step. Initially, I thought I had forgotten to click "Apply" or some other such button, but that was not the case. Even if one crops the images after the alignment is perfected, the changes are lost immediately. There are other minor irritations, such as the file-open dialog not remembering the last directory, and Exif rotation not being picked up in the project wizard, but a non-functional alignment tool means Luminance is effectively useless without near-pixel-perfect aligned images.

There are two possibilities for getting there. The "correct" thing to do is probably to take all of one's photos from a sturdy tripod with a cable release, thus eliminating awkward misalignments from the outset. But even then, wind and camera shake will frequently cause small misalignments, which necessitates the other option: aligning the images first using a separate application. Fortunately, there is a good option available.

Hugin

The panorama-generation toolkit Hugin has collected an assortment of valuable accessories over the years, including lens-calibration functions, cloud-detection routines, and more. One of the handiest is the ability to automatically align multiple photographs of the same scene. This is a critical step for stitching multiple images into a panorama, but it can also be used to align a stack of images. Hugin will also correct geometric distortion, which is not mandatory for HDR work, but certainly does not hurt.

In fact, Luminance 2.3.0 can call out to Hugin's automatic image alignment tool. In my own tests, however, working directly in Hugin is far simpler. First, in the event that the alignment routine fails to find where the images line up, you can manually fix problems in Hugin itself. A failure in Luminance leaves you with only the Luminance manual-alignment tool (which, in my tests, never worked). Second, Hugin's ability to fix lens distortion is always applied before the alignment step, which greatly increases the odds of success with wide-angle shots (where there is more distortion). Luminance's call to Hugin's alignment routine does not perform distortion correction.

But Hugin can also perform the exposure-blending step itself, too. It uses the Enfuse utility, and it produces excellent results. The only caveat is that Hugin offers no control over the tone-mapping used to create LDR output. Whatever defaults Enfuse uses are applied to the output when generating an LDR file. It attempts to create sane-looking results: no weird color saturation, no "fringing" or other artifacts one might find in the HDR sections of a photo-sharing web site.

The real question is whether there is any reason to head back to Luminance if the output from Hugin is good enough. One certainly can: Hugin can export OpenEXR or HDR TIFF output too; these files can then be opened in Luminance and tone-mapped with any of the included algorithms. Whether that is worth it is a purely artistic decision. For the most part, the output that Hugin gets from Enfuse is straightforward: balanced color, the full range of contrast. If the point of blending multiple images is simply to capture a scene that does not fit into a normal exposure in the camera's viewfinder, Enfuse will likely suffice. Only if the special-effects look is desirable does Luminance offer much extra functionality.

Comparing the two user interfaces is a bit of a toss-up. Both fall well short of making the task at hand simple to understand. Technically, the best results from Hugin are probably found by making as few adjustments to the tools and options as possible — but that fact is far from discoverable. The Optimizer tab, for instance, offers tantalizing options like "Optimize high dynamic range," but they rarely do what the user expects and are difficult to revert. Luminance may throw a screenful of esoteric research-paper terms at the user, but at least it is easy to click between the alternatives.

The rest

Nevertheless, there are still other options to weigh. The Digikam photo-management suite can also blend multiple pictures into an HDR image. It, too, uses Enfuse for this functionality, so its results will be similar, but it is simpler to use. Hugin's UI is an array of potentially-confusing tabs — most of which hold tools and buttons that have no bearing on blending a stack of images together into an HDR format. Avoiding them entirely may be the best way to get started in HDR images on Linux.

On the other hand, Digikam is extremely anxious to take over one's photo collection and manage it, whether one wants it to or not. Running it for the first time launches an import wizard that wants to index the user's entire home folder; the only way to prevent this is to point it at an empty directory instead.

Another approach might be to use Enfuse directly. Enfuse was designed to be executed from another application (namely Hugin, which the Enfuse manual recommends in its workflow section), but it can be called from the command line as well. The caveats are that Enfuse needs pre-aligned images, and it expects certain things from the input image formats. For instance, it expects input images to have an alpha channel — which they do when they are generated by Hugin — and throws warnings when no alpha channel is found.

The final option to consider is exporting an OpenEXR or HDR TIFF file and using one of the various open source raw converters to make adjustments to it. Darktable, RawTherapee, and Rawstudio each support OpenEXR, and they offer the usual slate of adjustment tools. In short, there is not any reason that an HDR photo needs to be filtered through one of Luminance's tone-mapping algorithms. Those techniques can produce intriguing results, but it would be wrong to regard them as the only "HDR" option.

Luminance HDR	Hugin	Digikam

In that sense, perhaps Luminance deserves a pass for keeping its algorithm-adjustment options complex. Ultimately, the majority of users just want a photo that looks good to the eye. The surreal-looking tone-mapping that first captured the public's attention with the term HDR has its place, but it does not have to be the final word, and it probably will not be. The expanding support for OpenEXR and other natively-HDR formats within the usual photo-editing applications probably means we will see other uses for HDR gaining in popularity.

For that matter, the digital camera market is beginning to see hardware that natively blends together stacks of exposures; HDR is one of the main selling points of replacement camera firmware projects like CHDK and Magic Lantern. Add to that mix the high-bit-depth support coming in GIMP 2.10, and two years from now, the HDR editing scene on Linux — and other platforms — could look drastically different.

Comments (9 posted)

Ubuntu on the Nexus 7

Your editor recently related that, thanks to the generosity of the folks at Google, he had come into possession of a second Nexus 7 tablet. There are many advantages to that state of affairs, not the least of which being that one can install questionable software on one tablet without breaking the other; it's possible to have your tablet and hack it too. Never one to turn down such an opportunity, your editor decided to give the recently announced Ubuntu Nexus 7 port a try.

Why play with Ubuntu on such a device? Even the most ardent Android supporters have sometimes been heard to complain that it's not really very Linux-like above the kernel level. There has been a constant level of interest in more "pure" alternatives like webOS, MeeGo, Nemo, etc., but, so far, none of those alternatives have found any great success in the market. So the availability of Ubuntu 12.10 for a tablet device caught your editor's eye. Might this be a reasonable path to get "real" Linux in a mobile setting?

Like all "Nexus" devices, the Nexus 7 is open from the outset; there is no need to root it via some sort of exploitable vulnerability first. It's a simple matter of plugging the device into the computer and using "fastboot" to unlock it. The unlock operation wipes all the data on the tablet, so, obviously, any needed backups should be made first. The next step is to use fastboot again to flash the "ClockworkMod" recovery image. ClockworkMod allows all kinds of low-level manipulation of the device including backups, operating system installations, and more; it really should be a standard feature of all Nexus devices.

Installation of the Ubuntu port is a straightforward task — assuming one has an Ubuntu desktop system handy. It is just a matter of installing and running the ubuntu-nexus7-installer package. Some rough edges show through quickly enough; the installer cannot figure out the storage capacity of the device and must ask the user to supply that information. More frightening, perhaps, are the scary warnings about not having any other devices attached to the system during the installation; there is, it seems, no way to tell the installer which device to overwrite.

There is another discouraging note during the installation process: the release as a whole is made available under a noncommercial-use license. The reason given in the license notice is proprietary drivers and codecs from Broadcom and NVIDIA. Such restrictions have the potential to raise all kinds of licensing issues. The problem is not created by Ubuntu, though: they are simply using a rebuilt Android kernel and the drivers that came with it. Be that as it may; your editor came to the conclusion that writing a review constituted fair use rather than commercial use.

The use of the Android kernel raises some other interesting questions, since Ubuntu's user space is designed for mainline kernels. Some quick looking around suggests that Ubuntu is not using the Android-specific interfaces; wakelocks have been configured out, for example. Battery life under Ubuntu is claimed to be comparable to what is obtained with Android, but it's being done with Linux-style power management instead of opportunistic suspend. The Nexus 7 thus provides an ideal platform for comparison of the two approaches to power management; this is an area that bears watching.

Once the installation is complete, the tablet reboots and presents the classic Ubuntu screen with the Unity icon bar on the left; there is no login screen. It looks like an interface that was designed for tablets, until one tries to use the tiny icons in the upper right corner. Then, at least for the fat-fingered among us, life starts to get harder. And it doesn't stop there. The simple truth of the matter is that Ubuntu on the Nexus 7 is a painful system to use; it is really only of interest to developers and other masochists at this time.

In fairness, nobody ever claimed otherwise; it is described as an experimental release for those who want to help find and fix problems. So, sure enough, problems do exist. Many of them derive from the fact that the traditional Linux desktop (and Unity remains close enough to "traditional" for the purposes of this discussion) is just not designed around touch-oriented interfaces. Others are simply glitches in the tablet port.

So, for example, one cannot scroll windows with the standard drag gesture; instead, one ends up trying to hit scrollbars in just the right spot. Anything involving a middle or right mouse button requires a complicated dance with the "Onboard" on-screen keyboard. Autocompletion popups swallow keystrokes, so trying to type a URL into Firefox is an exercise in extended pain. The tablet often freezes or goes into a weird unresponsive mode, requiring a reboot — there is a reason that the first entry in the Ubuntu Nexus 7 FAQ is "How do you reset the device when it locks up?". The screen does not auto-rotate (but one can rotate it manually with the xrotate command). Neither Bluetooth nor the camera work. The device often runs out of memory; the known issues page describes the process for configuring zram (an in-memory compression system formerly known as Compcache), which helps a lot. And so on.

On the other hand, there's something refreshing about being able to run multiple windows on a tablet display; as these devices grow in both size and resolution, there really is no justification for forcing every application to run in full-screen mode. It is nice to have a true Linux user space with a complete package repository behind it.

The Unity "dash" is meant to be the way users find applications on the tablet. It remains rather painful to use in the touch environment, though; it is slow and the scrolling is difficult to use. Searching for applications in the main screen quickly turns up unwanted things — the opportunity to buy stuff from Amazon, for example. The interaction between the dash and the onscreen keyboard is problematic; it is often not possible to get both onto the screen at once, and, when that does work out, the keyboard tends to cover the part of the window one is trying to use.

Those difficulties notwithstanding, the onscreen keyboard is, it must be said, one of the best your editor has encountered — at least, for the task of typing at terminal emulators and related applications.

Ubuntu's keyboard lacks the word completion and correction features found on the Android keyboard, but it offers other amenities: easy access to special characters, "control" and "alt" keys, arrow keys, function keys, macros, configurable layouts, themes, and more. Your editor has not attempted to use it with Emacs, but the idea is only mildly irrational.

Some concluding thoughts

In the end, while Ubuntu on tablets is essentially unusable now, that could change in the future. Whether it will change in time to be relevant is not clear, though. Beyond the fundamental issues of making the distribution work on this hardware (and, in particular, within the tablet's memory constraints), there needs to be a set of applications that work well with touchscreens. So it is a little discouraging that Ubuntu has no plans to support Android applications; doing so would help to jump-start the distribution on mobile devices. There is also, according to Mark Shuttleworth (as quoted in this OMG! Ubuntu! article), no plan to improve the interface for the upcoming 13.04 release. So a version of Ubuntu that is actually usable on tablets is, at a bare minimum, a full year away; it may, in fact, take rather longer than that.

The situation isn't helped by Canonical's apparent determination to go it alone in this quest. Rather than pick up a system which has a lot of the basics working now (Nemo or Plasma Active, say), Canonical is trying to build up its own "Unity" shell, and it seems to lack a story altogether when it comes to the development of touch-friendly applications. So it's going to take a while, and that is unfortunate: a year or three in the future may well be too late. There are other tablet-oriented systems out there, mostly of the non-free variety, that are ready and grabbing market share now. By the time Ubuntu gets to be a serious contender, there may be no space for another offering, no matter how nice. Linux on the tablet may repeat the history of Linux on the desktop.

So Ubuntu on the tablet has the look of a cool toy that most of us may never play with. But, then, your editor is highly gifted when it comes to being wrong on the Internet. This distribution is certainly a cool hack, fun to play with, and it might just attract contributors and develop quickly into something people want to use. For now, though, your editor will be putting Android back onto this particular device.

Comments (59 posted)

2012 Linux and free software timeline - Q1

Here is LWN's fifteenth annual timeline of significant events in the Linux and free software world.

2012 has largely been business as usual. Software and distributions continue to be released at an astonishing rate; some distributions have risen in popularity as others fall. Linux continues to appear in more and more places, from embedded to high-performance computing. And, though Linux still has not conquered the desktop, it (in the form of Android) seems to have conquered the phone market and to be well established on tablets. The usual threats to free software continue to lurk: patents and technological measures such as UEFI secure boot. Nevertheless, it has been another good year for Linux, and the prospects for the coming year(s) seem bright.

We will be breaking the timeline up into quarters, and this is our report on January-March 2012. Over the next month, we will be putting out timelines of the other three quarters of the year.

---

This is version 0.8 of the 2012 timeline. There are almost certainly some errors or omissions; if you find any, please send them to timeline@lwn.net.

LWN subscribers have paid for the development of this timeline, along with previous timelines and the weekly editions. If you like what you see here, or elsewhere on the site, please consider subscribing to LWN.

If you'd like to look further back in time, our timeline index page has links to the previous timelines and some other retrospective articles going all the way back to 1998.

January

Linux 3.2 is released (announcement, KernelNewbies summary, LWN merge window summaries: part 1 and part 2).

The Apache Software Foundation releases Hadoop 1.0 (announcement, LWN article).

Microsoft confirms earlier fears about UEFI secure boot by requiring vendors to lock down ARM devices (LWN blurb).

Scribus 1.4 is released (announcement, LWN article).

After nearly two years' work, the Mozilla Project releases the Mozilla Public License 2.0 (announcement, license text).

The Tizen project releases a set of source repositories and an alpha SDK (LWN article).

systemd v38 is released; this is the first release containing "the journal" (announce,ment).

NSA releases security-enhanced Android (LWN blurb).

linux.conf.au is held in Ballarat, Australia, January 16-21 (LWN coverage: A Samba 4 update; Addressing the failure of open source; The past, present, and future of Ubuntu on ARM; Jacob Appelbaum on surveillance and censorship; An LCA 2012 summary; videos).

Southern California Linux Expo (SCALE) 10x is held in Los Angeles, January 20-22 (LWN coverage: Robots rampage; The trickiness of the education market; The road ahead for automotive Linux and open source).

FreeBSD 9.0 is released (announcement, release notes).

An X.Org Server flaw that allows screen-lock programs to be bypassed is disclosed; the bug is quickly fixed (LWN coverage).

GDB 7.4 is released (release announcement).

The KDE project releases KDE Plasma Workspaces, KDE Applications, and KDE Platform 4.8 (LWN blurb, announcement).

HP announces a roadmap to make webOS open source by September (LWN blurb, announcement).

Cinnamon 1.2 is released; this is the first stable release of Linux Mint's fork of the GNOME Shell (LWN article).

February

Greg Kroah-Hartman moves to the Linux Foundation (LWN blurb).

ownCloud 3 is released; LWN looked at this personal cloud system in January.

Linaro Connect Q1.12 is held in Redwood City, California, February 6-10 (LWN coverage of the scheduling minisummit).

FOSDEM '12 is held in Brussels, Belgium, February 4-5 (LWN coverage: Multiarch on Debian and Ubuntu; The Wayland display server).

The Document Foundation announces that it will be based in Berlin (announcement).

Canonical ceases sponsoring one of their employees to work full-time on the Kubuntu project (announcement).

The book Open Advice is published under a CC-BY-SA license; the book consists of a set of essays with advice on contributing to FOSS projects (LWN review).

SUSE, the oldest of the current commercial Linux distributions, turns 20 this year (IT World article, TechWeek Europe article).

Robyn Bergeron becomes the new leader of the Fedora Project, succeeding Jared Smith (LWN interview with Robyn).

LibreOffice 3.5 makes its third stable release, with the project starting to settle into a 6-month release cycle (announcement; LWN article).

Wayland protocol and Weston compositor 0.85.0 are released (announcement, LWN article; The H article).

The Android Builders Summit is held in Redwood Shores, California, February 13-14 (LWN coverage: Android and the kernel mainline).

Canonical announces Ubuntu for Android (LWN article).

VLC 2.0 is released (LWN blurb).

Adobe ends separate distribution of its proprietary Linux Flash plugin used by the Firefox browser (LWN blurb and later article on Flash support on Linux).

Mozilla announces a deal to start shipping HTML5-driven smartphones by the end of 2012 (announcement, LWN article).

The proposed /usr unification causes gnashing of teeth in some quarters (LWN article).

MINIX 3.2.0 is released (LWN article).

March

PHP 5.4.0 is released (LWN blurb; announcement).

The GitHub repository site is compromised (LWN blurb).

Wine 1.4 is released (announcement).

Vagrant 1.0 is released (LWN article).

X.Org Server 1.12 is released (LWN article on the XInput multitouch extension in that release).

The Open Invention Network announces an expansion of the range of software that is covered by the group's patent license agreement. (LWN article).

Google releases the LinSched scheduler-testing framework (release announcement, LWN article).

bzr 2.5.0 is released (announcement).

Gnuplot 4.6 is released (announcement).

Cinnamon 1.4 is released (LWN blurb).

Crossroads I/O 1.0.0 is released (LWN article on this ZeroMQ fork).

The Mozilla project decides to support the H.264 video codec (LWN blurb and article).

Linux 3.3 is released (announcement; KernelNewbies summary; LWN merge window summaries part 1 and part 2; LWN development statistics article).

GCC 4.7.0 is released; the project is now 25 years old (announcement).

LTTng 2.0 "stable" is released (LWN coverage: part 1 and part 2).

The GNU C library steering committee dissolves itself, one of several events that signal a change in the governance of the project (LWN blurb and article).

Version 1 of the Go programming language is released (LWN blurb).

GNOME 3.4 is released; this is the second major update of GNOME 3 (announcement).

Comments (none posted)

Page editor: Jonathan Corbet

Inside this week's LWN.net Weekly Edition

• Security: Security implications for UI changes?; New vulnerabilities in Firefox, Hyper-V, Mantis, Tomcat, ...
• Kernel: Uninitialized blocks and unexpected flags; Loadable security modules; 3.7 development cycle statistics.
• Distributions: Haiku edges toward general release; Fedora, GNU Guix, ...
• Development: Wikimedia's HTML5 video player; Koha; GStreamer SDK; high-DPI text rendering; ...
• Announcements: Ask OpenOffice, events.

Next page: Security>>