Author Archive for Davide Anastasia

Page 2 of 3

Update on the next release

This blog post is a little update on the status of Luminance HDR.

We have been working on a new version of Luminance HDR since the release of the current version, trying to improve functionalities and add a few more, with the aim of giving you a better software. Our core development team now counts a new member (Bruce), that has been a patch supplier for a long time before joining our team. However, we didn’t plan yet when and how the next release will be (maybe christmas?), so it might take long. Be patient!

In the meanwhile, I (Davide) started a new side project: I am trying to make a library out of Luminance’s engine, in order to offer similar functionalities to other software of the open source community. It is a really big project, that will keep me busy for a long period. However, it is my personal commitment to not leave Luminance HDR, which I’ve been cuddling for more than a year and I am proud of!

Mailing Lists

We decided to open 3 new mailing lists with the aim of a closer relationship with users, translators and potential developers. These mailing lists can be found here:

Feel free to join one or more that our mailing list: we are looking forward for you!

P.S. This blog will not allow comments anymore: use our Users Mailing List instead.

Luminance HDR 2.1.0

We are pleased to announce a new version of Luminance HDR. We are changing Luminance HDR deeply, re-factoring a lot of the legacy code. We are trying to add new features and at the same time take out the maximum from new multicore machines using new development techniques. This version is absolutely a big improvement for Windows users, which will experience a more stable and faster software. I do not want to list all the changes we made for this version, it will be too long, but we are definitely waiting for your comments in order to bring out a version 2.1.1 really quickly with all the improvements and the bug fix that Luminance HDR may require.

You can download Luminance 2.1.0 using one of these links:

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

Users of Fedora 14 and Fedora 15 can find pre compiled binaries for i386:

luminance-hdr-2.1.0-1.fc14.i386.rpm ]
luminance-hdr-2.1.0-1.fc15.i386.rpm ]
LibRaw-0.13.8-1.fc15.i386.rpm ]

64 bits packages can be easily built from the src.rpm provided.

Users of Ubuntu 11.04 can find pre compiled binaries for i386.

luminance-hdr_2.1.0-2_i386.deb ]
libraw_0.13.8-2_i386.deb ]

They must also install the package libtiff_3.9.4-2_i386.deb provided.

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.

Note [Mac Users]: This version of Luminance HDR runs only with Mac OS X 10.6 Snow Leopard and Mac OS X 10.7 Lion, in 64-bit native. We do not think to release a 32-bit version anymore, so Mac OS X 10.5 users should stick to the old version.

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 ]


What do you think if Luminance HDR moves to Git?

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!

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!