2009/5/21 Kunlun121 <jannes.bol...@gmail.com> > > From a near-simultaneous thread on this forum I gather that the > problem with my image is the 2GB barrier that is somehow related to > libtiff and the way it is built. Can anyone confirm this? > > In that thread there was a reference to a Gmane forum which states: > > > ----------------------------------------------------------------------------------------------------------------------- > Some time ago I had the same problem. Enblend produced tiff slightly > bigger than 2GB and no application could read it. Problem is that > when > file is opened in libtiff for reading it is mmaped by default. Mmap() > on > such large file fails. But it can be produced by enblend because mmap > () > isn't used when file is created. I built my own libtiff without mmap > support (attached patch disables mmap usage). Then I was able to read > the file using this: > > LD_LIBRARY_PATH=/opt/mylibtiff/lib:$LD_LIBRARY_PATH application > > Of course this works only if application is linked against libtiff > dynamically. > > ------------------------------------------------------------------------------------------------------------------------ > > Then I remembered that Andrew Mihal quite some time ago answered this > very same question in an email mentioning the need to turn on "large > file support" in my libtiff. > > Regardless, I don't know whether the Enblend that's part of Hugin is a > static or a dynamic build. The problem with the latter is that without > quite explicit instructions from a skilled person, I don't know how to > independently patch the libtiff on my system. If on the other hand the > build is static, would it be possible that a next version is built > using the patched libtiff? > > Thanks, > Jannes >
The enblend and enfuse that are "shipped with" hugin are dynamic builds. Occasionally a static build slips in. I compile tiff with with "--enable-largefile" (among others) but configure simply mentions: checking for _FILE_OFFSET_BITS value needed for large files... no checking for _LARGE_FILES value needed for large files... no . All enblends built so far by me are without largefile support simply because OSX doesn't allow me to. I'm on Leopard (64bit) on an Intel core duo (64bit), meaning that it's a complete 64bit system. The message above seems to show that Apple doesn't use 64bit file offsets even on 64bit hardware in 64bit Leopard and even when trying to compile for 64bit (arch=x86_64). You mention an attached patch, but you didn't attach a patch (or it got lost). Can you resend this patch or point me to it? I will certainly give it a try. Harry --~--~---------~--~----~------------~-------~--~----~ 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~---
