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!

Luminance HDR 2.0.2-pre1

A pre release of Luminance HDR 2.0.2 is out. It is stable and reliable but could contain undiscovered bugs, that’s why you should download and test it before the official release of 2.0.2.

You can download using these links:

[ Windows (32-bit) ]
[ Mac OS X (32-bit, Intel) ]
[ Source Code ]

I also made available an rpm for Fedora 12 x86_64 and a src.rpm for the same distribution.

Thanks to Davide Anastasia’s work, it is more stable and faster than ever. It has also more options for RAW conversion thanks to libraw which is now used in place of dcraw.

Please download and test it. If you spot a bug, we will appreciate a bug report on the Tracker that indicates version of Luminance, OS and the exact list of steps to replicate the behaviour.

Update (08/Dic/2010): A new Mac OS X build is available. The previous one was not working correctly with Mac OS X Leopard 10.5.x. Enjoy!

Too early for 64 bits {on Mac OS X, obviously!}

Today I download Qt 4.7 for Mac. It includes the 64 bits version build on the Cocoa framework and I was really curious to see how it behaved.
Final result: it’s still too early for 64 bits! I had the GUI completely stucked and completely unexpected crashes. It looked like Windows!!! Nightmare!


This Monday I’ve got the first donation since I’ve started to work on this project. It was such a nice surprise, because I didn’t really expect anything from this work. I really want to thanks those who gave me some money to work on this project: they were really appreciated and they are the proof that there were some interest for this project around. For this reason, I’m going continue to improve the code and make Luminance better every release.

For those who don’t want to give money but own (not more needed) books about C++, Advanced programming or Qt library, I will surely accept them.

Thanks all,

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.

Luminance HDR 2.0.1: Windows Release

Here it is, the Windows Release of Luminance 2.0.1-1. While I was working at this release, I’ve found a bug in the memory management of Mantiuk (Thanks Franco). Hopefully, it should be fine now.

Download the new release and let me know if it works fine for you. If it doesn’t behave in the correct way, fill a bug in the Tracker showing exactly what you do to raise the problem.

[ Download here ]

Luminance HDR 2.0.1

After a long search, I’ve found what the error in LuminanceHDR was. And I fixed it!
Currently, the new 2.0.1 is just a general fix of the TM operators. This will make the output exactly equivalent to the one we used to have with qtpfsgui 1.9.3 (in some cases, even better).
This release includes the first Mac OS X edition of the 2.0.X branch and I expect a lot of feedback on it! A Windows version will be available soon (hopefully Giuseppe will make it for us soon). Obviously, for the Linux huggers, source code is ready for you to be compiled.

My plan for the future releases is:

  • go thru the bugs still open on the Tracker and try to fix as much as I can;
  • improve the Mac OS X build, using Apple libraries wherever it is possible, in order to improve throughput and overall user experience;
  • improve memory management, in order to avoid unneeded swap and crashes;
  • improve the user interface, trying to make it more understandable for the average user.

I would like to say thank you to Axel Voitier (patch on a critical race in the Mantiuk06 operator) and Elizabeth Oldham (patch that enables or disables UI features). Their help made LuminanceHDR better.

[ Download 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.