2009/10/17 grow <[email protected]>:
>
> Roger, Chris, Bruno,
> If I understand correctly the images that Roger has identified as the
> cause of the crash are:
> t3_exposure_layers_0024.tif
> t3_exposure_layers_0025.tif
> and these are the images that would come out of the Nona phase of my
> original project with the same numerical suffixes. The suffixes run
> from 0 to 26 for my 27x image, 9x stack project with 3x bracketed
> images in each stack. So these are the first and second image in the
> 9th stack!
>
> (I had misunderstood earlier and assumed that the problematic pair
> bridged the 8th and 9th stacks but if Roger's suffix-numbering matches
> the numbering in the original project they are both in the 9th
> stack.
>
> Bruno,
> My 8th and 9th stacks are applying exactly the method that you
> mentioned for removing the photographers shadow and feet. My
> misunderstanding of the numbering earlier had me thinking that that
> was a problem.)
>
> So if I correctly understand Bruno's explanation of how Hugin decides
> on which images to stack/blend and which to layer/fuse ... then the
> question for me is ... why was Hugin TRYING to apply Enblend these two
> images?
>
> I originally entered them with a Yaw of 0 ... but after Optimization
> they were each placed as follows:
> Yaw: -1.775 Pitch: -82.729 Roll: 39.543
> Yaw: -1.836 Pitch: -82.735 Roll: 39.621
>
> This is nothing like Bruno's 10% angle threshold ... So why would
> Hugin apply Enblend to them?
>
> all the best
>
> George
>
> On 16 Oct, 21:00, Bruno Postle <[email protected]> wrote:
>> On Fri 16-Oct-2009 at 10:15 -0700, grow wrote:
>>
>>
>>
>> >Something that has always puzzled me in the Hugin GUI is how images
>> >are selected to be part of a stack (that gets enfused) or part of a
>> >layer (that get enblended together)
>> >How does it decide?
>>
>> Hugin checks the yaw and pitch of all photos, and any where these
>> angles vary less than 10% of the photo's angle of view are
>> considered 'stacks' (with Fused and Blended output).
>>
>> This can obviously fail for nadir/zenith situations, really the
>> absolute angular distance should be checked, but this has never been
>> reported as a bug so probably the way we do it is 'good enough'
>> (patches welcome though).
>>
>> Similarly any photos with less than 0.5EV exposure difference are
>> considered 'exposure layers' (with Blended and Fused output)'.
>>
>> What is wrong is that although these decisions get written to the
>> .pto.mk files, there is nothing in the GUI to tell the user which
>> photos are being grouped like this - You have to run the stitch to
>> find out.
>>
>> >Is there some way that I can better indicate to Hugin how to handle
>> >images that overlap except for masked areas? Or should I just give up
>> >and merge these images in a separate pass.
>>
>> I think enblend is still the right tool. This is how I shoot two
>> shots to get rid of my own shadow, but I give them a different 'yaw'
>> to force a vertical seam. i.e. this panorama doesn't have a
>> retouched nadir, it is more-or-less how it came out of Hugin:
>>
>> http://www.flickr.com/photos/36383...@n00/2893620038
>>
>> ..I should do a tutorial.
>>
>> --
>> Bruno
> >
>
Hi all,
after reading the entire thread it seems that there are more different
causes for the crash. Rogier fixed one of them.
The second one is problem with writing (and maybe reading) files which
mmaps entire file. Let me guess. All of you use tiff files (as input
and maybe also output). I've got similar problem with Gimp several
times in past when it was not able to save tiff data when memory was
full (with error insufficient memory I think).
So let's take a look at libtiff first. After some searching I've found
out that mmaping entire file is default behavior of libTiff and we are
not the first ones for whom this causes huge memory allocations. So
what to do? I read the man page of TIFFOpen and the fix seems quite
easy. Patch is attached. It may be a bit slower but it should reduce
memory usage.
have a nice day,
Lukas
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
diff -r 1f34bd7a13f0 src/vigra_impex/tiff.cxx
--- a/src/vigra_impex/tiff.cxx Thu Oct 15 08:10:46 2009 +0200
+++ b/src/vigra_impex/tiff.cxx Sat Oct 17 11:43:48 2009 +0200
@@ -255,7 +255,7 @@
{
const FilenameLayerPair file_layer = split_filename(filename);
- tiff = TIFFOpen( file_layer.first.c_str(), "r" );
+ tiff = TIFFOpen( file_layer.first.c_str(), "rCm" );
if ( !tiff ) {
std::ostringstream oss;
oss << "Unable to open file '" << file_layer.first << "'.";
@@ -725,7 +725,7 @@
TIFFEncoderImpl( const std::string & filename )
: tiffcomp(COMPRESSION_NONE), finalized(false)
{
- tiff = TIFFOpen( filename.c_str(), "w" );
+ tiff = TIFFOpen( filename.c_str(), "wCm" );
if (!tiff)
{
std::string msg("Unable to open file '");
