Hi Kornel, thanks for the tips. I got it running now even after
rolling back the insertions in the ptcommon and ptblender files.
Just the _FILE_ thing still needs my manual fiddling.
See also below
What is your compiler, maybe we could do it compiler-dependent
I work with Visual C++ express
OK, I got the lib and found a way to manually tell MSVC to include it
in the PTBlender project by setting it in the properties of the
project.
Build successful! But it would be nice if I knew where to change this
properly.
Next project: building the mosaic version of hugin with this
libpano...
On Sep 7, 10:25 pm, Zoran Zorkic zo...@gmx.net wrote:
On Sep 7, 10:11 pm, Yuval Levy goo...@levy.ch wrote:
Zoran Zorkic wrote:
Got this after trying to blend a 360x180 from Hugin 2009.1.0.4263:
enblend: unrecognized wrap-around mode -f3000x1500
Probably becauseenblendwas called
Am Samstag 17 Oktober 2009 schrieb allard:
OK, I got the lib and found a way to manually tell MSVC to include it
in the PTBlender project by setting it in the properties of the
project.
Build successful! But it would be nice if I knew where to change this
properly.
This lib should be added
Please do update the wiki. the thread is transient but there are some
learnings that should be made permanent in it.
Next time one dependency upgrades, the sync between the mercurial
repository and the SDK is likely to break again.
And changes to both repository and SDK can break the
2009/10/17 grow george...@gmail.com:
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
Kornel Benko wrote:
Am Samstag 17 Oktober 2009 schrieb allard:
OK, I got the lib and found a way to manually tell MSVC to include it
in the PTBlender project by setting it in the properties of the
project.
Build successful! But it would be nice if I knew where to change this
properly.
Hi,
I suspect a problem in the vectorization of the seam lines. There
is currently no checking that the MaskVectorizeDistance parameter is
suitable for the number of actual pixels on the seam (the points
visited by the CrackContourCirculator). Thus we can construct snakes
that undersample the
Hi Andrew,
Andrew Mihal schrieb:
Hi,
I suspect a problem in the vectorization of the seam lines.
Actually, the approach of using vectorized seam lines is a relatively
complicated process. Additionally, snakes are not particularly well
known to find good global solutions. I think a
I have now tested with a bit bigger project, and get a very strange result,
I need some help to see If I am doing something wrong, or it's a bug.
Iseems like there are phantom CP's in optimization that stuffs up the
result. These are visible in the layout-view but not in the CP-list.
(reported
On Sat, Oct 17, 2009 at 05:23:40AM -0700, cspiel wrote:
Roger -
On Oct 16, 11:53 am, Rogier Wolff rew-googlegro...@bitwizard.nl
wrote:
Most people are not this familiar
with the code, and simply fire up a GUI. The hugin-0.7.0 gui, I
suspect simply blended all the images from an
Hi Lukas,
On Oct 16, 9:19 am, Lukáš Jirkovský l.jirkov...@gmail.com wrote:
Hi
2009/10/16 Nicolas Pelletier nicolas.pellet...@gmail.com:
I think a new Hugin should provide only two direct stitching
targets: cube faces and equirectangular, and let you convert either of
those to other
Hi Jim,
Are you saying that some source line that calls htons() should be
rewritten to call something declared in filter.h instead? That sounds
right -- it seems stupid to make a program that does not use network I/
O depend on a sockets library.
But what source file has this silly call in it?
13 matches
Mail list logo
