Hi All,
Looking at getting into doing astro panoramas (mainly milky way arch) and
wondering if anyone knew of any guides/tutorials for getting the best out
of Hugin for this specific use case? I've tried creating a few panoramas
and have been finding I get a few stitching and exposure blending err
Windows 10, not familiar with PHP, but can probably work it out if needed,
The high overlap % was to deal with wind, the mount I shot it all on was a
big flimsy when 25Kmph gusts showed up,
On Thursday, 8 April 2021 at 10:35:50 pm UTC+10 Monkey wrote:
> What OS are you using? Are you au fait
Here is the whole image set so you can pick and choose (may still be
uploading for a while), this is 123 rows x 66 columns ordered left to
right, the focus was not perfect in all shots, expecially the trees on the
right hand side of the bottom few rows, a lens like this has a depth of
feild of
Monkey, its 0.44x0.67 degree per image, or about 0.3 square degrees. the
total image is going to be roughly 180x90 or 270x60, though I will have
some margin on the sides, the goal is to exceed 1 Terapixel
GnomeNomad, Thanks I'll check that out,
On Wednesday, 7 April 2021 at 3:22:08 am UTC+10
Would any of you know any good software (free or otherwise), to put
together my small scale trial pano of 8118 photos, (Full scale is hoped to
be 70,000-110,000) shot on a 1900mm lens with a crop factor of 1.62 for
those interested
Hugin seems to crash on trying to open that many files, and see
stitching TIFFs (as those are the only type I had
tried), but tonight I tried simple JPGs, same issue.
Ryan
--
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups
"hugin
Is there some way to install it to my user so I can actually use it?
Thanks
Ryan
--
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic softw
there created with Hugin and
documentation on how to create HDR panoramas with Hugin. I would be
very pleased if you felt it worthwhile to put a link to my page in the
links section of the Huign website.
Cheers
Ryan
--
You received this message because you are subscribed to the Google Groups
rd to do once a branch escapes into the wild.
For the mailing list, there's probably a way to make the messages
include the branch which was affected -- it's all just a bunch of hook
scripts anyway -- but I don't know right off how to go about doing
it.
Hope that helps!
Ryan
On J
> On Jul 1, 5:25 pm, "Ryan Sleevi" wrote:
> > Sorry, I should have reviewed what I sent :)
> >
> > As of 4.0, Enblend/Enfuse transitioned to a CMake build system. So
> the
> > patches should no longer be necessary, you should be able to just
> CMake it.
g/Hugin_SDK_%28MSVC_2010%29
>
> except for the final stages to compile Hugin, because there's not a
> spot. I'll make one...
>
> I've used the pre-compiled version of Enblend 4.0, so it's win32. One
> of the recurring requests on the list is for x64 builds, b
re-compiled version of Enblend 4.0, so it's win32. One
> of the recurring requests on the list is for x64 builds, but the last
> ones I see, from Ryan Sleevi:
> http://groups.google.com/group/hugin-
> ptx/browse_thread/thread/4d19acdfdce90731/f14270cf01284a8d
> and download-ab
the .tar.gz? I
> guess because the README.windows file says to build it with mingw, and
> makes no mention of MSVC.
>
> I also didn't have to install or point to the Java SDK. Does that
> sound correct to you?
> Aron
>
> On Jun 30, 2:45 pm, "Ryan Sleevi&
They're all there in SVN. Perhaps the .tar.gz you downloaded excluded them?
See
http://panotools.svn.sourceforge.net/viewvc/panotools/trunk/libpano/tools/ ,
I see all the tools referenced by the .sln. The patch may be out of date -
though it was just a patch to update the projects for VS2008, IIRC
d up deleting all control points more than about 100
px apart, resetting image parameters, and reoptimizing. That, or just
choosing CP manually.
Of course, support for region-selecting won't really help if the image
is a cubist's dream.
Ryan
--
You received this message because you are s
> -Original Message-
> From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On
> Behalf Of Tom Glastonbury
> Sent: Monday, May 17, 2010 6:26 AM
> To: hugin-ptx@googlegroups.com
> Subject: Re: [hugin-ptx] Re: Windows 64-bit Build
>
> Hi Ryan,
>
Hey Tom,
I'm commenting out of order here, but hopefully it makes sense this
way :)
>
> The other issue that I've mentioned before is that of producing x64 and
> Win32 builds from one source tree/SDK. It seems to me that the hugin
> CMake stuff will differentiate between debug and relea
On Apr 12, 4:28 pm, Felix Hagemann wrote:
> On 7 April 2010 21:09, Ryan Johnson wrote:
> > "Error: no overlapping points found. Photometric optimization aborted"
>
> > Any ideas what to do? There was no difficulty adding control points (the
> > horizon is plen
On Apr 7, 10:49 pm, "John McAllister" wrote:
> Why are you trying to exposure optimise a scene series that probably doesn't
> need it?
Well, in the preview window it looked like it *did* need it, but the
stitched result actually does look fine as you predict. This leaves
some questions, though:
rol points (the
horizon is plenty "interesting")
Thanks!
Ryan
--
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/Hu
e the
stitching takes longer (from being hastily shot) and eats into dinner
or bedtime.
Oh well... she usually likes the result, at least.
Ryan
--
You received this message because you are subscribed to the Google Groups
"hugin and other free panoramic software" group.
A list of fr
versions came well after I was back home. I
figured it was "worth a shot" so to speak, and wanted to share the
results.
--- end soap box ---
Regards,
Ryan
[1] http://www.ece.cmu.edu/~ryanjohn/barcelona-pigeons.jpg (I had just
handed the camera to my wife to give the girls some bi
tend to be inverted, contrast-wise, which completely
confuses automatic cp gen
In summary, this is mostly a report on how to stack day/night photos,
with something of a bug report for the exposure optimization issue.
Enjoy!
Ryan
--
You received this message because you are subscribed to the
Lukas,
Check PreferencesDialog.cpp. On my (slightly out of date) branch, its
around lines 907, which has
cfg->Write(wxT("/ImageCache/UpperBound"),
MY_G_SPIN_VAL("prefs_cache_UpperBound") << 20);
MY_G_SPIN_VAL is a macro to read back the wxSpinCtrls value via
GetValue(
Unfortunately, the error you pasted is about as meaningful as 'an error has
occurred'. The error message indicates that the expected project/library
'huginbase' wasn't built. This is generally caused by one or more
compilation errors earlier on.
Scan 'up' in your log (eg: earlier), and you should
position them in order to find those control points...) and inflexible
(you can't move them separately any more after they are joined).
Ryan
--
You received this message because you are subscribed to the Google Groups
"hugin and other free panoramic software" group.
A list of fre
> "LINK : fatal error LNK1181: Eingabedatei 'libxmi.lib' kann nicht
> geöffnet werden."
> (... "Input file 'libxmi.lib' can't be opened")
There are several sets of paths you want to make sure are correct. In the
solution properties (right click the solution, properties), you want to make
sure for
> well I'd be thrilled to contribute and I do use windows. actually I've
> been going off it lately but I imagine it's cyclical.
> What I would require is a crude explanation what is and how works C
> and what is C ++ how is the same name for program language different
> in windows and unix. I wou
nt steps, the precompiled
> SDK likewise. However, I did, with your help, (thanks!) get enblend to
> build.
>
> I'll go over the process again and take notes so I can try to fill in
> the blanks on the wiki.
>
> Hugin (4719) built with only one hitch, a couple of missing
You forgot to include libxmi with the linker.
My guess is you added libxmi folder to the include directory (like the
default MSVC proj has). You actually have to compile libxmi and make sure to
include it with the linker.
The patch files previously mentioned several times do address this.
I woul
roblems. First there was an error about "slist" which I fixed by
> building STLport. Now I'm stuck at:
>
> 1>c:\huginbase\enblend\src\mask.h(190) : error C3861: 'rint':
> identifier not found
>
> On Nov 15, 6:24 pm, "Ryan Sleevi" wrote:
>
This is caused when PACKAGE_NAME_B is defined, as it expects automake to
have replaced the symbolic @UINT8_T@ with the actual type. However, on
Windows, you don't have Automake, so this doesn't work.
If you visit the Wiki page, you can see the instructions for how to do this
- http://wiki.panotool
See
http://sourceforge.net/tracker/?func=detail&aid=2789320&group_id=77506&atid=
550443
Look at the diff files for libxmi-1.2 and lcms-1.18
tiff.h can be found in wxWidgets, unless you're specifically linking against
a newer version for the larger file support (note: if doing so, make sure
you're
on handling extras
which gcc outputs are significantly more verbose than MSVC, with the
result that binaries are bigger. Either that, or the MS installer is
really good at compressing...
[0]
http://hugin.panotools.org/testing/hugin/hugin-2009.4.0_rc2-win32-cygming-build.tar.gz
Regards,
Ryan
--~
developed is a first step
toward automated building/testing/packaging
Unfortunately, I don't have time or means to carry it any further...
hugin's a great tool, though, so I hope somebody can.
$0.02
Ryan
--~--~-~--~~~---~--~~
You received this message
to delete some files and try again.
Given that GPU blending also works on Allard's build it might be best
to stick with it for now.
Regards,
Ryan
On Nov 3, 12:37 pm, RueiKe wrote:
> Hi Ryan,
>
> I have run this test project with Allard's build of 2009.2 SVN4461 and
>
I moved the definition of EVT_CPEVENT to the .cpp file where it
actually gets used to avoid some linker issues. Any hope of that sort
of change making it into trunk?
Regards,
Ryan
On Nov 2, 5:19 pm, Yuval Levy wrote:
> T. Modes wrote:
> > Hi Yuv
>
> > some weeks again, you wrote
Hmm... definitely try the official windows build of enblend-3.2. I
just checked my libtiff, which claims to have GPU support baked in,
and it doesn't depend on any graphics-related dlls either.
Ryan
On Nov 2, 3:22 pm, Ryan wrote:
> Hi Rick,
>
> Re: i18n: It sounds like wxW
Meanwhile, just to be sure, perhaps you could download the official
win32 enblend/enfuse from Sourceforge and see what happens with a GPU
stitch.
Regards,
Ryan
On Nov 2, 2:37 pm, RueiKe wrote:
> Hi Yuv,
>
> Yes, that is the option I used for the test case that gave the out of
> memor
o I'm pretty sure unicode is really there.
Regards,
Ryan
On Nov 1, 5:34 am, RueiKe wrote:
> Hi Ryan,
>
> I have finished running the first test case for hugin-2009.4.0_rc2-
> win32-cygming-bin.zip.
>
> Platform: Windows Vista 64bit on an i7 with 12GB memory and an ATI
>
ming systems (in addition to
cygwin and mingw32), and I used a prebuilt glut32.dll.
Thanks!
Ryan
On Nov 1, 5:34 am, RueiKe wrote:
> Hi Ryan,
>
> I have finished running the first test case for hugin-2009.4.0_rc2-
> win32-cygming-bin.zip.
>
> Platform: Windows Vista 64bit on an i
On Nov 1, 12:08 am, Bruno Postle wrote:
> On Sat 31-Oct-2009 at 13:05 -0700, Ryan wrote:
> >1. 2009.4 leaves all the temp files laying around after a stitch
> >completes, where the old version used to delete them afterwards. Is
> >this new behavior a bug or a feature?
sent. This can be a major
pain when sending the final image to a (slow) shared filesystem; I
really want the temp files to go to local storage, and the stitched
image to go in the image archive where it belongs.
Thoughts?
Ryan
--~--~-~--~~~---~--~~
You received this
Correction to the URLs:
http://hugin.panotools.org/testing/hugin/hugin-2009.4.0_rc2-win32-cygming-bin.zip
http://hugin.panotools.org/testing/hugin/autopano-sift-C-2.5.1_rc2-win32-cygming-bin.zip
http://hugin.panotools.org/testing/hugin/hugin-2009.4.0_rc2-win32-cygming-build.tar.gz
Thanks,
Ryan
On Oct 31, 1:14 pm, Henk Tijdink wrote:
> Hello Ryan
> As a regular reader of this groupI tried to download your version and
> autopano SIFT, but I don't have access to the FTP server.
> Need a user name and password for getting access?
> How can I get that?
That's a ve
r somebody with a decent GPU to verify that GPU stitching
works.
GPU-assisted preview seems to work fine for me -- enabling
photometrics in 0.8 overwhelms my machine, and other than a brief
spike to get it started, 2009.4 doesn't use any CPU as I drag the
image around and change crop settings.
, but wanted to close
the loop first (in particular, enblend-4.0 sounds like it needs some
integration work still).
Regards,
Ryan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"hugin and other free panoramic so
On Oct 24, 12:46 am, Yuval Levy wrote:
> Ryan wrote:
> > 1. Is anyone interested in playing with the build I have?
>
> I would like to hear from users comparing your cygwin build with an MSVC
> build. Not in terms of size (disk space is cheap nowadays) but in terms
> of
e (I got PM asking for a copy). I also
want to rebuild with proper versions of enblend, etc.
Any suggestions where to host it? The group's file area has a 10MB
limit, and I don't really have a web page handy.
Thanks!
Ryan
--~--~-~--~~~---~--~~
You recei
effort -- I didn't have much
internet access this week and wasn't following the list.
Regards,
Ryan
Package versions:
- exiv2-0.18.2 (source)
- openexr-1.6.1 (source)
- libpano13-2.9.14 (source)
- lcms-1.18 (source)
- jpeg-7 (source)
- glut-3.7.6-bin (binaries by Nate Robins)
- enblend
> -Original Message-
> From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On
> Behalf Of Yuval Levy
> Sent: Tuesday, September 22, 2009 8:20 AM
> To: hugin-ptx@googlegroups.com
> Subject: [hugin-ptx] Re: Enblend: CMake (Windows) broken
>
>
> makes sense - I'm on MSVC
> -Original Message-
> From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On
> Behalf Of Kornel Benko
> Sent: Tuesday, September 15, 2009 6:21 AM
> To: hugin-ptx@googlegroups.com
> Subject: [hugin-ptx] Re: Enblend + cmake + FindBoost
> And we could make it configurable.
> -Original Message-
> From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On
> Behalf Of Yuval Levy
> Sent: Tuesday, September 15, 2009 9:12 AM
> To: hugin-ptx@googlegroups.com
> Subject: [hugin-ptx] Re: Enblend + cmake + FindBoost
> how do the stock FindLibraries on th
: [hugin-ptx] Enblend + cmake + FindBoost
>
> Hi all,
> currently we are using our own FindBoost.cmake. I was unable to make it
> work on OpenSuSE. That is, though I have Boost installed (the standard
> way, add needed packages with yast), this version of FindBoost does not
> find
ugin-ptx@googlegroups.com
> Subject: [hugin-ptx] Windows Hugin SDK and documentation
>
>
> Hi Ryan and other Windows developers
>
> I'm moving this piece of information to the main mailing list.
>
>
> Ryan Sleevi wrote:
> >> -Original Message-
&g
Kornel,
At the lowest level, you can always MESSAGE(STATUS "Message")
so
IF(${SOME_FLAG})
MESSAGE(STATUS "Project will be built with
some_flag disabled. If you prefer to build without some_flag support, you
arch for some way to
exchage changes only.
The version here is mostly your modified version with corrections from me.
Should we really be forced to send
each time all the data? What do you think Ryan?
I'm not Ryan, but Harry ;-)
We (at least one of us) need access to the repository. I
FindLibraryWithDebug is "safe" for Release calls. It's just a special handler
for Windows platforms that tend to have libraries with debug file suffices (and
with my modifications, also handles situations where x86 and x64 libs are
"side-by-side", sharing 1 include dir, but having their own uniq
Re: cmake compilation of enblend [was: Enblend bug tracker
and developer mailing list]
Am Mittwoch 09 September 2009 schrieb Ryan Sleevi:
> > > I try to correct
> > > Kornel
>
> The flag OpenMP_FOUND doesn't really matter as much, at least not in the
> code.
> -Original Message-
> From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On
> Behalf Of Kornel Benko
> Sent: Wednesday, September 09, 2009 9:02 AM
> To: hugin-ptx@googlegroups.com
> Subject: [hugin-ptx] Re: cmake compilation of enblend [was: Enblend bug
> tracker and dev
miNewGC is from libxmi. I'm guessing that cmake isn't quite finding it.
Presumably, libxmi (and lcms) need to be set to REQUIRED in the find_library
calls, as they are necessary. That should allow CMake to bubble the error up if
it's having trouble resolving where you put it.
From: hug
> -Original Message-
> From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On
> Behalf Of Zoran Zorkic
> Sent: Monday, September 07, 2009 4:25 PM
> To: hugin and other free panoramic software
> Subject: [hugin-ptx] Re: Enblend/Enfuse 4.0 and Hugin
>
> Is there a reason i
I'm not sure if many people are aware, but there has been a lot of ongoing
development lately over in the repository for enblend/enfuse. Perhaps most
importantly, Christoph Spiel's staging branch has been fully merged in,
which introduces support for OpenMP on platforms that support it, as well as
You could use Hugin to create the control points to align the images 'as
best as possible'. Presumably, the images won't be taken with the exact
focal length, angles, etc, so this will cause distortion between the images,
but you can control the level by choosing your control points.
You then use
>
> mhh... is yours 64bit? or 32bit?
>
64-bit through and through. Using a DLL version of Glut, rather than a
static library, simply because it was convenient at the time. However, the
error seemed to suggest to me it was a GPU allocation error and not a system
allocation error. The memory usag
Granted, I'm not committing (yet?), but that doesn't keep me from voicing an
opinion, right? :)
> 1.2. VARIABLE NAMES
>
> some variables are named with the CamelCase convention - capitalizing
> the beginning of the word. Other use the word_separated_by_underscore
> convention. Are there other co
> Ryan is so far the only one who has reported success, with his
> self-built version. I wonder if one of the pre-compiled (from Guido or
> from me) yield the same result. This would exclude building errors.
>
> His video card is a GeForce 8800 GTS (256 mb) - anybody else with th
Compiled my own x64 version (using the Glut For Win32 sources -
http://www.xmission.com/~nate/glut.html ), as I wanted to see if there was
going to be any headache on Windows. Some wonky macros, but nothing fatal.
In order to get CMake to find Glut, I had to touch my FindGLUT macro, but I
imagine
> completely unrelated, but what is vc90.pdb? I suddenly see enormous
> numbers of this same warning:
>
The Program Database Filename. If you look at a solution configuration,
you'll see it is configured under Configuration Properties -> C/C++ ->
Output Files. I'm guessing you probably cleaned y
For what it's worth, I tested 4007 and 4012 on my 64-bit Windows install,
and both crashed at launch when launched after setup. 3975 launched fine.
However, 4012 not working seems to be intermittent - I've successfully
launched it several times, with no discernable differences (launching it
severa
> > Anyway I shouldn't have brought up the subject, this is way off
> > topic.
>
> I don't think so - how we organize ourselves is very much on topic.
For what it's worth, I'd weigh in that what Yuval's proposing for the layout
seems to make sense to me. The layout I'm accustomed to is akin to:
As of SVN 1.5, there is a set of merge tracking designed to (somewhat)
facilitate what you describe. You can find details (and more information) in
the 1.5 release notes -
http://subversion.tigris.org/svn_1.5_releasenotes.html#merge-tracking
However, as noted, it's fairly basic and not ideally
By all means, please do. There's definitely a need for someone to provide
64-bit builds. I've refrained from it myself, though I provided the 64-bit
steps, because I'm only able to offer a patent-free installer. As I haven't
had a chance to test through different scenarios with a mixed 32-bit CP
ge
> So does there actually exist an
> installer for 64-bit, or am I going to have to compile this myself?
> The former would be more convenient, but the latter I don't mind doing
> excessively.
The latter. 64-bit compilation is available only through a set of patches.
You'll find instructions for
Hard to tell exactly what it might be, but the error is stemming from the
fact that you have at least two instances of the JPEG/zlib libraries loaded
(wxjpeg.lib and jpeg.lib via jpeg64.dll, wxzlib.lib z.lib via zlib1.dll).
The latter for each of those is probably coming from one of the other
libr
> Thanks for the info.
> Out of curiosity, is there a reason why it is not a single branch with 2
> build targets, but one branch 32, and patches for 64?
>
> Thanks,
>
> nick
That's definitely my goal and on my todo in the coming weeks. The big
reason for it not being yet resolved is that the ini
> So hugin works in 64.
> What about APSC, enblend and enfuse?
>
> Thanks,
>
> nick
>
With the patches, they all work. Getting enblend/enfuse on 64-bit was the
most onerous part, because a number of GNU dependencies are only
distributed in 32-bit form. However, the wiki page details the steps
nec
Nick,
No one's stepped up to the role of being the binary builder. I haven't
volunteered myself just because I wouldn't be able to compile
"everything" - needing to leave off those tools affected by
SIFT/SURF/other patents and the like (which should just be the CP
generators, but still, an imp
> I know of no case in which such a failure has been replicated by a
> second observer. I have not yet been able to get APSCpp to exhaust
> memory on either Windows or Linux. And when I run it under a leak-
> checking debugger (MSVC on Windows, valgrind on Linux) I see no sign
> of memory leaks
> My experiences with profile-optimized code have been far less
> positive. For me the speed-up varied from several percent (Enblend,
> Enfuse, UFRaw) to actually slowing down the code (gcc).
>
> One explanation for my findings could be that I ran all of my tests on
> very fast machines,
Finally got a dump and had a chance to inspect.
The DEP crash itself is being caused by atioglxx.dll, which is ATI's OpenGL
driver. I don't have symbol files for it, so I can't trace, but the path
that Hugin takes that causes this crash:
> hugin.exe!GLRenderer::Redraw() Line 110C+
Message-
> From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On
> Behalf Of hbl
> Sent: Thursday, July 09, 2009 5:09 PM
> To: hugin and other free panoramic software
> Subject: [hugin-ptx] Re: More on hugin vs DEP
>
>
> Ryan,
>
> Thanks for the i
Where were the absolute module references to? Hugin.exe, rsaench, or other
modules?
RSAENH is just the Microsoft RSA Enhanced Cryptographic Service Provider,
which is the crypto core of Windows. I'm surprised DEP is flowing through
there, as nothing in Hugin or the tools is going to pull in that
Hugin requires wxWidgets 2.8.10 as of SVN 3842, according to the CMakeLists.
Is it possible you've got an older version?
The build steps on the SDK reference using wxWidgets 2.8.10, and there is a
more recent SDK package posted from May also up on the wiki. Might be time
to update :)
> -Orig
> Hi Ryan,
>
> interesting stuff. do you do this kind of things for a living?
To a degree. I work on a commercial project where three of the main demands
are "small, fast, and portable," so these sorts of things come up often -
OpenMP, Intel VTune/IPP/C++ Compiler, and x64 al
I couldn't find anything in the archives discussing this, so I apologize if
it's been discussed before.
For my own personal use, I've been building Hugin with profile-guided
optimization. It's a compiler technique that can best be described as the
compiler taking a recording of everything the pro
> and with you and your expertise around I allowed myself to note that
> 64bit Windows is now supported.
Well, it's only supported if those two patch sets get merged upstream prior
to 0.8 (your prior e-mail asking for thoughts). My belief is they should be
very minor (the patches to Hugin itself,
09 7:08 PM
> To: hugin and other free panoramic software
> Subject: [hugin-ptx] Re: Results for Ryan Sleevi SVN 0,8,0,3980
>
>
> Ryan,
>
> It appears the exception is occurring in atioglxx.dll. It's
> associated with the ATi Radeon video driver. The purported so
7;ll see about looking in to it further as well as
posting the stack trace back to the list for those more "in the know".
Either of the methods described in the KB are the preferred method, rather
than sending the diagnostics created by the 'stock' Windows dump tool (more
i
ase/enblend-3.1/. The hugin install script expects this directory.)
2009/7/6 Ryan Sleevi
Enblend/Enfuse don't use the CMAKE-based system that Autopano-sift-c and
Hugin use.
As a result, binaries are not deployed into an INSTALLDIR location. Instead,
once compiled, they are typically loca
Enblend/Enfuse don't use the CMAKE-based system that Autopano-sift-c and
Hugin use.
As a result, binaries are not deployed into an INSTALLDIR location. Instead,
once compiled, they are typically located in
enblend-enfuse-3.2-dir\src\Debug and enblend-enfuse-3.2-dir\src\Release ,
where enblend-enf
be considered a
'block' in any means.
Cheers,
Ryan
> -Original Message-
> From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On
> Behalf Of Yuval Levy
> Sent: Thursday, July 02, 2009 4:01 PM
> To: hugin-ptx@googlegroups.com
> Subject: [
ge, which AFAIK is how Ad is building
his, so we'll see. Hopefully Howard will have more information using the
build I provided him, and we'll be able to get to the bottom of this.
>
> Hi again, Ryan,
>
> Ryan Sleevi wrote:
> > I went ahead and built a binary based on
and debugging their software, it may be helpful for some of
the weird bugs that remain post-release (as I recall, there are a few
mystery ones out there affecting Windows users)
Ryan
> -Original Message-
> From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On
&g
robably not a 1:1 mapping of
your problem, but hopefully if it is some bug in Hugin, it'll surface there
as well.
Thanks,
Ryan
> -Original Message-
> From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On
> Behalf Of hbl
> Sent: Wednesday, July 01
>
> b) this particular project makes such demands for masking that they
> can only be serviced in a 64 bit environment
>
> c) there is a bug that triggers in a 32 bit environment that does not
> trigger in a 64 bit environment
>
> (The fact that it worked for Ryan o
> package content".
> > - Move down into "Contents -> MacOS".
> > Copy the downloaded 64bit enblend over that existing enblend.
> > *Note: Again, only within Leopard and only on G5 or Intel Core2 (or
> newer)
> > 64bit applications will run as 64bit*
&
Guido,
I did update the documentation per your request. You should see a
clean separation wherever possible about the x32 v x64 differences using
parallel tables. Short of breaking it into it's own page, I'm not sure what
ideas you're thinking layout. Breaking it into its own page seems a
Nice work Guido, you beat me too it. I've been working for the past week on
documenting directions for compiling the Hugin SDK in x64, and had already
adopted the new versions. I just updated the wiki page with the directions,
and hopefully I didn't clobber any of your changes along the way. I did
99 matches
Mail list logo
