Luminance HDR 2.0.2

Luminance HDR is growing, improving and leaving behind some of its historic problem: memory hungriness and unexpected faults. I am trying to sort out as many problem I can and, at the same time, I am getting a lot of patches from really smart guys that I will never thank enough. Most of the work in this new version has been made “under the hood”, so you will not see any drastic change in the UI (which is good… and bad!).

Changes [compared with 2.0.1, while some of them were already present in the 2.0.2-pre1]:

  • LibRAW is now in charge to convert RAW files, removing the dependency from dcraw as an external tool (Thanks to Franco Comida)
  • New Batch Tonemapping Engine
  • Smaller memory footprint during the TM process
  • Better acquisition/release of the memory
  • [Windows only] improved responsiveness of the UI
  • [Windows only] update of some of the dependencies
  • [Mac only] Luminance HDR 2.0.2 works on Mac OS X 10.5.X (64 bits version for Snow Leopard also planned, but not yet released)
  • [Mac only] Better UI in Mac OS X (looks cleaner and closer to the Mac style)
  • Huge memory leak during the HDR creation process has been sorted out. The overall procedure is now much faster and uses less memory
  • Huge clean of compilation errors and wrong memory allocation/release (Thanks to Elizabeth Oldham)
  • [Linux only] Multithread support is active again and improved (using OpenMP)
  • [FreeBSD] Cleaner compilation (Thanks to Joao Rocha Braga Filho, Maintainer of Luminance HDR for FreeBSD)

I would also thank a great Luminance’s user, Ron Todd, who made available for all of us his experiments with the new LibRAW engine and blowing highlights (I strongly suggest you to read it!).

My current “To Do” list is too long to fit in here, but while I am releasing this version, I am playing with the Intel TBB library (Threading Building Blocks) and I am probably going to introduce a new dependency in the next version. At the same time, as I am already discussing in a previous blog post, the project will most likely switch to CMake, leaving QMake.

You can download Luminance 2.0.2 using one of these links:

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

If you appreciate Luminance, please consider a donation (there is no minimum amount!):

If you want to share with other users your results, you can use our FlickR group and Facebook group.

[Update, April 30th, 2011] Thank to one of our user, Alessandro Lorenzi, we have a package for Fedora Core 14. You can download it here.

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!

Donations

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,
Davide

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 ]