OK Finally I got it compiled!! Not the hole hugin (It still gives me some errors) but at least it has passed the align_image_stack compilation :) It is a 39MB executable!!!

try stripping the debug symbols from it with: strip align_image_stack before the "make install" step, or before moving/copying it to a directory named in the PATH var.

How did you do that? I downloaded hugin from the svn repository, did cmake and make install, but align_image_stack was not compiled in the process. When I navigate to the directory where align_image_stack.cpp is located (hugin/src/hugin1/tools) and do a cmake/make install from here, compilator complains about a missing config.h and compilation fails.

Alright, I managed to compile align_image_stack by de-commenting the "add_subdirectory(tools)" line in the CMakeLists.txt file located in hugin/src/hugin1. I have copied the align_image_stack binary in /usr/local/bin and now Qtpfsgui can find it. However, I now get the following error: "The external process "align_image_stack" crashed..." I guess it's because my images do not have the right format.

Once you have an HDR image loaded up in the workspace you have to tone map it (use the big button, shortcut:CTRL+T) to get an LDR (like Jpeg). Only after the tone mapping step has been performed you can save it as jpeg.

Yes, I have already found it.. Anyway, Thanks for the reply :)

1) if the checkbox is grayed-out and you cannot specify any value manually, it means that Qtpfsgui is using the correct values from the exif data in your image. In that case there is no need to specify the exposure values manually, Qtpfsgui is already using the correct ones automatically. 2) Yes there were several bugs that crept in (especially in the windows version) but with the latest version (1.8.8) all of them have been fixed. 3) Saving a tonemapped LDR in a 16 bit format makes little sense (to me, at least) :) Here's a discussion we had a while back on flickr: http://www.flickr.com/groups/qtpfsgui/discuss/72157594548766502/72157600058641698/

1) if the checkbox is grayed-out and you cannot specify any value manually, it means that Qtpfsgui is using the correct values from the exif data in your image. In that case there is no need to specify the exposure values manually, Qtpfsgui is already using the correct ones automatically. This works only in ideal world... Yes. There is a need to specify values manually because exif values can be incorrect even if the program reads those incorrect values correctly! 2) Yes there were several bugs that crept in (especially in the windows version) but with the latest version (1.8.8) all of them have been fixed. I meant 1.8.7 linux version. 3) Saving a tonemapped LDR in a 16 bit format makes little sense (to me, at least) :) Here's a discussion we had a while back on flickr: http://www.flickr.com/groups/qtpfsgui/discuss/72157594548766502/72157600058641698/ so the operators produce 8 bit output... ok.

1) qtpfsgui provides a one-to-one exif data copying feature, maybe that can help you cope with that problem. I'm curious, how is it possible that the aperture value and the exposure time info in the exif data can end up being wrong?? Another workaround is to use a different application to erase all your exif data (qtpfsgui doesn't have that capability). Just remember that if you are dealing with only one image then you can set the EV value at an arbitrary level, the histogram will only be translated left or right, you can find the mathematical reasoning here (pretty hardcore stuff): http://freenet-homepage.de/hsbosny/HDR_Tutorial/HDR_Tutorial-en.html#Bemerk_1 2) Does it still crash with 1.8.8?

1. Of course it is easy to screw up exif. In my particular example tiff files apparently have wrong exifs after output from raw covertor. Of course I now always have to set in the raw converter to not export exif if I intend use qtpfsgui and after that I always have to set it back as it also affects jpegs output (for jpegs exifs work fine). Very inconvenient. Why not to read the exif and also make comboboxes which set this "alive"? This seems very natural. 2.Thank you! It does not crash anymore.This is great.

crashes with something like this: ::::::resized goes into tone mapping QPaintEngine::setSystemClip: Should not be changed while engine is active

qtpfsgui is crashing if I want to tonemap too. Here is the console Output: ::::::original goes into resize executing resize step executing pregamma step executing tone mapping step Speicherzugriffsfehler I have Suse 10.2 64Bit

Same problem with the tonemapper in OpenSusue 10.2 (32-bit): ::::::original goes into resize executing resize step executing pregamma step executing tone mapping step Segmentation fault I tried RPM and also self compiled package. Any idea for help? best regards candy33

I have also problem with the tonemapper in OpenSusue 10.2 (32-bit): ::::::original goes into resize executing resize step executing pregamma step executing tone mapping step Segmentation fault Urgently need help! Thanks motu

New version 1.8.10 works on SUSE 10.2 you can find it here: ftp://rauchs-home.de/suse/10.2/i586 you need to install libexiv2-0.11 first. if libexiv2-0.11 conflicts with other versions of libexif, install it with "rpm -i --force ...", it doesn't matter to have different version on the same machine. best regards candy33

I didn't know about that. I'll try to remember to give them a holler. They could also help me diminish the memory footprint.

Here is the initial bug report: http://bugs.kde.org/show_bug.cgi?id=125543 Good luck with it :)