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…

4 Responses to “Huge Commit!”


  • So… do you have ideas for the gui?

    Personally I don’t like eye-candy tho I know some users do. The machine before this was rather resource limited and even bouncing progress bars irritated me!

    Can I do anything to help… in that vein I did look at reducing some of the compile time warnings a few weeks ago but got distracted by Life/etc. Would that be useful?

    • Compile warnings are a problem sometimes, so if you can clean a few of them, I would be happy to accept the patches.

      Regarding the GUI, I think that progress bars are important for the user to have the feeling that the program is actually doing something, so I’ll probably work to introduce them in other operation (save, open and this kind of stuff). But, moreover, I have the big idea to remove the awkward tonemapping window, merging it with the main window. This would also save a lot of memory currently wasted to keep open two windows. What do you think? Is it a good idea? Then I’ve already done (in the trunk) some minor cosmetic changes for Mac OS X: http://picasaweb.google.com/davide.anastasia/LuminanceHDR#5535401582886261874

  • Aye, progress bars are useful to know it’s still alive. I’d favour a percentage style progress bar. But thats a big difference to attention grabbing bouncing block on the status bar which is what it does at the moment.

    Good on merging the main and tonemapping windows!

    • Once we have implemented the bouncing block status bar, it’s easy to create a percentage style status bar. But I’m just realizing that even the easier of the status bar does not work properly when it’s programmed by me! :(

Comments are currently closed.