Creating HDR images in Ubuntu with Luminance (QTPFSGUI)

For those who are not (yet) posession one of the latest generation digital cameras with build-in HDR capailities and the more experimental folks, there is a fantastic tool to create HDR images by combining multiple shots of the same scene: Its called qtpfsgui.

That is, it used to be called that and is still avaiable in Ubuntu under this name (sudo apt-get install qtpfsgui). However, qtpfsgui is discontinued since mid 2009 and has been replaced by the Luminance HDR project.

Since qtpfsgui crashed under ubuntu 9.10 when attempting to save any HDR image, I downloaded the latest luminance version, compiled and installed it like so:

  1. Download the luminance source and unpack the folder.
  2. Install the dependencies required to compile luminance:
    sudo apt-get install qt4-qmake libexiv2-dev libopenexr-dev fftw3-dev libtiff4-dev libqt4-dev g++ libgsl0-dev
  3. Compile luminance (takes a few minues) and install it. Change to the unpacked luminance folder and do:
    qmake
    make
    sudo make install

That´s it! you now have luminance installed and it should be in your main menu under applications>graphics.
It works perfectly under Karmic.
One of the best things about luminance is that you can play a lot with the algorithms and parameters used to tonemap the HDR into a LDR image. In contrast to many other (commercial) tools, you actually get to know which algorithms are used, who created them and can read a little more on how they work (if you are not to opposed to mathematics) by googling up the corresponding papers on scholar or so. This way, experienced users are able to “squeeze” a lot more out of their HDR’s with this tool than with many commercial ones.

Per-assembly filtering with the maven-assembly-plugin

The maven assembly plugin is an extremely powerful tool when it comes to creating custom distributions (aka assemblies) of your artifacts for individual platforms etc. However, the ability to create multiple variants of an artifact within a single build conflicts with the standard maven approach of using multiple build profiles and executing a single build for each profile to generate artifact variants.

This also means that mavens resource filtering is not very useful for individual assemblies, since you can only replace placeholders such as ${someValue} with the same value for all assemblies (since resources are only filtered once, using the active profile(s), for all assemblies).

You can, however, configure the maven assembly plugin to use individual filter property files for each assembly using the <execution> section of the plugin configuration, like so:

<plugin>
  <artifactId>maven-assembly-plugin</artifactId>
  <version>2.2-beta-5</version>
  <executions>
    <execution>
      <id>production</id>
      <goals>
        <goal>single</goal>
      </goals>
      <configuration>
        <filters>
          <filter>${project.basedir}/src/main/assembly/production.properties</filter>
        </filters>
        <finalName>${artifactId}-production-${version}</finalName>
        <ignoreDirFormatExtensions>true</ignoreDirFormatExtensions>
        <descriptors>
          <descriptor>src/main/assembly/assembly.xml</descriptor>
        </descriptors>
      </configuration>
      <phase>package</phase>
    </execution>
    <execution>
      <id>integration</id>
      <goals>
        <goal>single</goal>
      </goals>
      <configuration>
        <filters>
          <filter>${project.basedir}/src/main/assembly/integration.properties</filter>
        </filters>
        <finalName>${artifactId}-integration-${version}</finalName>
        <ignoreDirFormatExtensions>true</ignoreDirFormatExtensions>
        <descriptors>
          <descriptor>src/main/assembly/assembly.xml</descriptor>
        </descriptors>
      </configuration>
      <phase>package</phase>
    </execution>
  </executions>
</plugin>

This snippet uses the same assembly descriptor (you can use any assembly descriptor, actually) to build individual artifacts for production and integration. Note that the ${project.basedir}/ prefix is a workaround for MASSEMBLY-150 and is nedded to avoid a nasty Failed to create assembly: Error filtering file ... Error loading property file 'src/main/...' error when executing the mojo from outside the module directory (say, for instance, in a mvn release:prepare…).

Filtering must be enabled in the assembly descriptor, like so:

<?xml version="1.0" encoding="UTF-8"?>
<assembly xmlns="http://maven.apache.org/xsd/assembly"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/xsd/assembly http://maven.apache.org/xsd/assembly-1.1.1.xsd">
  ...
  <fileSets>
    <fileSet>
      <filtered>true</filtered>
      ...
    </fileSet>
  </fileSets>
</assembly>

Thanks to John Casey for suggesting this in MASSEMBLY-430!

Blog relaunched

I just relaunched this blog, based on the latest 2.9 release of Wordpress.

The new design uses significantly less CSS and markup and increases the accessibility of the content. The design is also making use of the wider screen resolutions that became sort of a standard in the last years.

The image at the top is a scaled-up photograph of the Alps as seen from Bern, Switzerland.

Enjoy!
Olaf

Obtaining the default charset (aka platform encoding) in JAVA

… is really simple since JDK 1.5:

java.nio.charset.Charset.defaultCharset()

So please don’t use messy, old workarounds such as this:

byte [] byteArray = {'a'};
InputStream inputStream = new ByteArrayInputStream(byteArray);
InputStreamReader reader = new InputStreamReader(inputStream);
String defaultEncoding = reader.getEncoding();

Which, unfortunately, is one of the first things you stumble upon when searching for this topic.

Intel linux drivers and new kernel gfx support reach mature state

The Linux Kernel and the XORG video rendering have been undergoing some significant improvements in the last year, with Intel’s linux open source team bringing in a lot of refactorings an architectural improvements.

I myself suffered from the lack of support for recent integrated intel gfx cards in notebooks and thus followed the excellent Intel Linux graphics performance guide using the bleeding-edge configuration, i.e. with the latest (non-stable) builds of the xorg / intel gfx drivers and the most recent kernels. However, this configuration was (not quite unexpected) somewhat unstable and had a lot of issues.

This phase is now over. I am happy to say that after upgrading to Kernel version 2.6.32 and the xserver-xorg-video-intel driver 2:2.9.0-1ubuntu2~xup~3 the graphics support is now fast, reliable and stable. Desktop effects are back working like a charm, also in a multi-monitor setup and with sending the computer to hibernation and so forth.

I am quite optimistic that this state might make it into the upcoming Ubuntu release (Karmic), thus eliminating a lot of frustration laptop users have been experiencing with their intel gfx cards.

Using RPC-style, encoded Axis 1 webservices with spring-remoting

Preamble

When working with enterprise integration you will quite often deal with legacy systems integration.

I recently had the case where integration of webservices was requested, and much to my surprise there are huge issues when attempting to integrate old webservices (as in pre axis2 and pre jax-ws).

These webservices use outdated or unsupported methods, such as rpc-style/encoded communication, or even worce, outdated elements in the XML messages, for instance <multiref>’s. Having to integrate such services does of course imply that you cannot change anything on the server side, and thus such an outdated format must still be consumed.
This is a huge problem, since current WS implementations, such as the popular axis2 framework, do simply not support these formats.

What surprised me the most about this is that webservices are designed to make systems independent by defining a common communication and data format, which is the exact opposite of what is going on here – and these formats are not that old, we are probably talking 4-5 years.

Developers facing these problems are taking rather desperate measures to work around these problems, such as using on-the-fly XSLT transformation to convert incoming and outgoing WS messages. However, this binds your application even stronger to the outdated format and specific service data.

In my case I wanted to use Spring-remoting. Since the service was RPC-style, I wanted to use the JaxRpcPortProxyFactoryBean to create an on-the-fly proxy implementing the service interface. What I did not want to do is having to write any additional code to consume the service. Furthermore, I wanted the complex objects transferred by the services to be represented by standard JAVA beans, and not be generated using the wsdl2java axis1 tools. Here is how I got this to work.
Read the rest of “Using RPC-style, encoded Axis 1 webservices with spring-remoting”

Using apache to redirect from the root “/” context to a webapp context

Just a short note:

The best way of doing this avoiding endless recursion is to use apaches RedirectMatch rule, like this:


RedirectMatch ^/$ http://targethost/mywebapp

Easy, agreed. But i’ve seen (and done it wrong my self) quite often…

Sorry guys, server crash…

Folks,

There was a hardware crash at the hosting center that has caused a complete exchange and re-installation of this server.
I’ve got older backups running now, recent posts are not up yet but will be within the next week.
Posts may still look crappy and outtakes may occur, but for now, a least the older stuff is back online…

Greetings
Olaf

Running mvn:release with Subversion 1.5.x

When attempting to prepare a release using maven and the maven-release-plugin, you are currently very likely to see your build fail with a message such as:


[INFO] Executing: svn --non-interactive copy --file /tmp/...commit . https://subversion..../tags/...
[INFO] Working directory: ...
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Unable to tag SCM
Provider message:
The svn tag command failed.
Command output:
svn: Commit failed (details follow):
svn: File '...' already exists

If you do, you are using subversion 1.5.x which no longer supports tagging from a local working copy, thus causing the unfortunately very misleading error message.

This is a known issue of the subversion sourcecode management (SCM) and there is a simple workaround:
Read the rest of “Running mvn:release with Subversion 1.5.x”

Modular development with OSGI about to be very, very popular – finally.

It’s quite exciting to see the tremendous progress in development tools, patterns, frameworks and libraries since the release of JAVA 1.0 in 1996.
Within just thirteen years, development improved from the first applets, from the dark ages of the first EJB standardization attempts and a lack of suitable development processes into an age where aspect oriented programming, dependency injection and a freely available range of lightweight yet extremely powerful frameworks, libraries and API’s finally permitted the humble programmer to do what he always wanted to do – analyze problems, and elegantly write them down without spending all of his precious time on the syntax.

I would even go as far as saying that there was no object orientation before programming crosscutting concerns and using dependency injection became established mechanisms.
Think about it: The original goal of OO is not to use inheritance, encapsulation, identity and polymorphism, but to express the real world of things – our reality – using an abstract world of things, while preserving most of the properties and relationships we observe in reality.

Before AOP, before being able to separate the description of things from creating, configurating and connecting concrete instances through dependency injection frameworks, this goal was hard to achieve.

Modules larger than classes with OSGI

Now however, we are about to reach a new stage in development of object orientation in JAVA: Developing modules that are larger than classes, modules which can, once properly identified, be developed independently using all the wonderful technology described beforehand. The technology used to achieve this has a name: OSGI. This technology has quite a long history of development, but a certain lack of elegance and light-weightiness barred this component model from becoming a real hit in the worldwide development community. This is about to change.
Read the rest of “Modular development with OSGI about to be very, very popular – finally.”

Older Entries