Archive for the 'Development' Category

Sourceforge Project of the Month May 2012

It is a big pleasure for me to announce that Luminance HDR won the award as May 2012 Sourceforge Project of the Month. It is  an honour for us to win this award, that has been given to absolutely brilliant projects for the last 10 years. And it is also a good occasion to talk a bit more in detail on what is going on in Luminance HDR.

I would like to start by saying my appreciation for the work made by Daniel and Franco: they are both seriously skilled developers and they compensate my lack of time by carrying on the development. It is all thanks to their work that we have a new beta version to play with after such a short time from the release of the 2.2.1: if you are curious to test the latest progress, we will appreciate any kind of feedback.

However, a lot of work needs to be done to bring Luminance HDR were I would love it to be. When I took it from the hands of the former founder, nearly two years ago, Luminance HDR was facing a really bad moment, and it was really close to be abandon [1][2]. Not much development was going on, so  it was given to me, a person that had no clue of the internal structure of the project. But I didn’t have a build for Mac OS X and I need a copy of Luminance HDR for my pictures. So I started compiling everything on Mac. And it worked. Sort of.

Without telling you the all story (I don’t want to bug you!), since that day, I’ve started working more and more on Luminance HDR. I’ve fixed several heavy memory leaks, merged the Main Window with the Tonemapping Window and started using tabs instead of MDI containers, just to name a few. At the same time, I’ve moved the building system to CMake and the source control repository to Git (and now that I’m forced to use SVN for other projects, I cannot tell you how much I love Git!). It’s probably thanks to my first efforts that Franco and Daniel started to work again on the project, pushing myself to do even better.

But the greatest thing that happens to Luminance HDR in these two years is you. Yes, you! I’ve started a Facebook group and in a few weeks we were 100. Now, almost 300. And you are all active users, sharing pictures, suggestions, tricks and proposing ideas. Without your support and feedback, we couldn’t understand whether our work was appreciated or not (something really important when you work for free!).

And now? I think this award is not the finish  line, but more the start. While the current code is being maintained and improved, many thing are happening to prepare the next generation. It’s a complex work, that involves rewriting a large part of the underlying processing engine, but it is a challenging task that will completely change our baby. I would love to have near real-time processing, and more improved and advanced post-processing features, in order to speed up the entire workflow. The GUI needs to be polished and improved as well. And much more. So, stay tuned…

Luminance, 64 bits and Macs (Lion?)

I have been working on Mac OS X since I have taken the lead of the Luminance HDR project. Mac OS X is a nice platform, supported well by Qt, with several good quality external tool available (mainly coming from the Linux world). I did a lot of work to shape a nice interface on OS X and I will do more work later on this aspect.
To make my life easier, I decided to release a 32 bit only version of Luminance HDR (both for Windows and Mac OS X). Luminance however can be compiled in 64 bit without any drawback and this has several advantages. And in fact Daniel Kaneider’s work on a Win64 and my experiment with Universal compilation prove that.
So, since I started the development line that will bring to Luminance HDR 2.1.0 (still don’t know when!), I worked with the idea to release 64 bit builds at the end.

But obviously Apple decided that my plan to make an Universal build was too easy. I don’t know how many of you still use a 32 bit machine with OS X, but surely they are still a lot of people that did not upgrade to Snow Leopard from Leopard (and they will probably not upgrade to Lion): so now I am facing my personal dilemma about Luminance HDR’s development. In fact the new XCode 4 supports only OS X 10.6 and later, but not 10.5 (which means cutting out all the Leopard’s users). At the same time, Qt made its move and decided to support officially only 64 bit build, unless you do not compile Qt on your own.

Currently I’m working on Snow Leopard, using Qt 4.7.3 and supporting OS X Leopard (and 32 bit builds), but if I will upgrade my machine to Lion (not sure I will do that anyway), I will be forced to cut off all Leopard users and, as a consequence, drop the 32 bit build (Snow Leopard surely supports 64 bit applications, so it would not make sense to make a 32 bit build).

Luminance HDR on Windows 64

Daniel Kaneider, a long collaborator of the Luminance HDR project (even when the name was Qtpfsgui), made a 64 bit build of Luminance HDR for Windows.
It is a great thing to see Luminance running in 64 bit on Windows, but unfortunately this build is to be considered really unstable. However, we need your help to spread it around a learn when it crashes and why, so we can make it better, more stable and faster.
You can download the build on the link below. We are particularly interested in:

  • crashes
  • UI behaviour
  • visual artifacts
  • memory footprint (hdr creation and tonemapping in particular)
  • RAW handling

[ Windows (64-bit) SVN 918 ]

CMake or not CMake?

I’ve been struggling since I’ve taken the head of the development with the difficulties of debugging the project properly: makefiles, gcc and gdb are really bad tools when you are used to work inside a graphical IDE (in my personal case, Xcode). This seems to be a big problem also for other users: KDevelop project does not seem to work correctly (never used that, but that is what I have been told), which is a big problem when you work on a Qt project and you expect at least to be able to work with the developing suite provided by Qt itself!
A few days ago I meet CMake while I was working on something else: CMake seems to be a great tool, able to generate Makefiles and project files for more or less every IDE and every platform you may think. Even KDE uses it! So I think I’m probably moving to CMake pretty soon, in order to help myself and all those who want to contribute to the project in debugging the code easily.
Do you think it makes sense?

Update [2011.06.07]: I’ve been working with CMake for quite a while, trying its functionalities with small projects first. I finally made the CMake file for Luminance and it seems to be working quite well on Linux and Mac OS X. I’m working on the Windows versione and once I’m sure it works correctly, I will drop the QMake project file (which is currently still part of the repository).

Luminance 2.0.2: Under Development

It’s been a while since the last update. After all, it was Xmas for us as well!
Development of the final release of Luminance 2.0.2 is going on and we have taken every single bug report really seriously: we are trying to fix them, or eventually take them like milestones of the next release.

Currently I’m working on the memory issues of Mantiuk06 (which seems to be the most used operator and the one with some problems, especially when using big images), trying to avoid memory allocations and copies when not strictly required. Moreover, I’m trying to rewrite some functions to help out the compiler to produce better code (increasing the throughput). When I’ve done with this, I would like to have a look at the false colors produced during the HDR Creation process: this one seems to be another major problem. Let’s what I can do!

Huge Commit!

Just a few minutes ago I made an huge commit changing 75 files! Most of these changes were trivial, but others were really deep and interesting. Let me summarize:

  • Qtpfsgui was born merging different tools in an unique solution. For this reason, some code is duplicated. The first modification was to get rid of pfstmo::Array2D. This class was a duplicate of pfs:Array2D, and infact I’m using this class now. Moreover, pfs::ChannelImpl was another duplicate of pfs::Array2D, so I got rid of this duplication too, removing the old implementation and implementing this class as a composition of Array2D. So, in a shot, I removed two duplications. And this is very most of the modifications came from.
  • Working on images, Luminance works mostly on vectors. So I added a new set of functions to Luminance, tailored to work on vectors using Intel SSE Intrinsics (fully supported by any modern compiler). This modification made a huge different in the processing time of Mantiuk06 (which is the first that I did implement with this new architecture). Unfortunately, being a new set of functions, they are not still free of bugs. So, if you spot any, let me know!
  • Colorspace conversion functions are now friend of pfs::Array2D. This allows to access directly the private data of the class and allows to use the vectorized functions even on these operations, highly increasing the performances. Similar optimizations were made on other functions (copy, cut, rotate), but not yet completed (they will be in the coming commits).
  • I’ve also started a clean up of the code: some files don’t own an header file, forcing a pre-declaration of the function explicitly. Not really a “normal” way of coding effectively.

I’m going to work using these techniques, trying to improve also the HDR creation process, which seems to be a weak point (probably due to the increase in mpixel of the current cameras) and the align function. Eventually, I will work on the GUI too…

OpenMP vs. SSE

Let me say a thing: I’m not against OpenMP! I think it’s a wonderful tool and I did use it in the past for several reasons, but I simply didn’t like how it was used in the Mantiuk06 implementation. In fact, most of the OpenMP directives in the code where just basic stuff, throw in the play just to see what happens. I don’t say that it was useless: there is a reasonable speed up in using OpenMP against a plain implementation, but it was the wrong technology to respond to the demand of better performance. Why? Because OpenMP was used on vectors, where SSE instructions are a tailored solution for this kind of problem and can achieve an higher speed up. So I decided to prove myself this idea and I took a piece of code from Mantiuk06 and I’ve tried to implement it in a couple of different why:

  • Plain implementation: let the compiler achieve the best it can!
  • OpenMP: more or less the plain implementation, but with an omp parallel for (exactly as it was found in Mantiuk06);
  • SSE: vectorized implementation using Intel SSE Intrinsics;
  • Apple Accelerate: basically an SSE implementation made by Apple for Apple Hardware.

The result confirmed my intuition and the SSE implementation was the faster in 3 different scenarios: only simulation running; one other high demanding process competing for the processor; two others high demanding processes competing with the simulation. This is why I disabled OpenMP in Luminance 2.0.1 (removing also annoying faults during Mantiuk06) and why the next version will use SSE. Graphs can be found here.


For a reason that I didn’t really understand clearly, I’m now one of the administrator of the Luminance HDR Project.
Let’s start from the beginning: a few weeks ago I was trying Luminance HDR 2.0.0. It has been released in July so I though it was interesting to give it a go. It was even more interesting because I had to compile the code from scratch using my Mac OS X.
I have to say: it wasn’t as hard as I imagined. Using MacPorts and a bit of patience, I had my working copy of Luminance HDR.
My first question was: why is it a newer software worse than the previous older one!? I know, I lot of people out there had the same thought and I agree with them, Luminance HDR is worse than QTpfsgui for these reasons:

  • The tonemapping process does not produce the same result of QTpfsgui;
  • The UI interface is somewhat not-coherent, because probably it has been touched but too many people with different ideas about how it should be and how it should be changed;
  • Luminance HDR crashes for unknown reasons, expecially using Mantiuk 06.

I am still learning the code and trying to find out where the sources of these problems are, but I’m confident that I will eventually come out with something interesting. So, if anybody wants to collaborate, just let me know.