[hugin-ptx] Re: building libpano on windows using cmake
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 edition 2008 and whatever is the
default compiler for that.
In fftn.c, the following line of code produced 'not found' errors
# include __FILE__
How is it possible, that _FILE_ does not expand to a valid path on your
system?
I don't know, but it seems to be a more common problem given the
commented line of code there
This Debug-folder was new to me. Somehow I start to think, that even cmake is
very platform independent.
Don't have here appropiate windows machine, so cannot help much.
You may try add this library in tools/CMakeLists.txt
line 18++:
if(WIN32)
list(APPEND commands panoinfo)
list(APPEND _common_libs ../Debug/pano13.lib)
endif()
I think this problem has already been solved in 1098 so this is no
longer necessary
Here I would add tools/compat_win32/getopt.c to the list of sources ov pano13
lib
like (from line 46 on):
IF(WIN32)
SET(wxWidgets_ROOT_DIR ${SOURCE_BASE_DIR}/wxWidgets-2.8.10)
ADD_DEFINITIONS(-D__Win__)
FIND_PACKAGE(wxWidgets REQUIRED)
SET(win_c tools/compat_win32/getopt.c)
ENDIF(WIN32)
That works! Thanks, allard
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[hugin-ptx] Re: building libpano on windows using cmake
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... allard PS, not building with Java support. Would that complicate things further? On Oct 17, 12:14 am, allard a...@allardkatan.net wrote: Hi Tom, ThanksI didn't seem to have that lib anywhere, now installing a platform SDK to get it. Where is the 'list of libraries given to the linker'? Allard On Oct 15, 7:06 am, Tom Sharpless tksharpl...@gmail.com wrote: Hi Allard _ht...@4 is an entry point in the Windows socket library DLL; wsock32.lib should be included in the list of libraries given to the linker. Are you building on Windows with or without Java support? Regards, Tom On Oct 13, 11:34 am, allard a...@allardkatan.net wrote: Hi all, I've fixed most of the problems I had building libpano (SVN1093 a.k.a. beta3) with CMake on windows, but there's one little thing I still can't get right. First the solved problems: I had to replace ADD_DEFINITIONS(-D__Win__) in Cmakelists.txt with ADD_DEFINITIONS(-D__Ansi__) to get rid of some unresolved symbol errors (thanks for the tip Jim Watters) In fftn.c, the following line of code produced 'not found' errors # include __FILE__ so I replaced it by # include fftn.c Then, there is apparently some confusion about where the pano13.lib is supposed to be located. When building the debug version, it is created in the folder 'Debug', which is created under the build directory. But subsequent tools sometimes expect it to be in the 'tools' folder. Copying pano13.lib there eliminates the errors. edit upgrading to svn1098 also After this, a lot of unresolved symbol errors related to getopt kept showing up. Copying the compat_win32 folder all over the place didn't help. Finally, I managed to get rid of them by adding the following line to PTCommon.c: #include tools/compat_win32/getopt.c Only the .h file was included, apparently this was not enough. I don't know if all of these solutions I found by trial and error are good practice, but they seem to have worked. Suggestions for how to do it better are welcome. All tools build now, except for PTBlender. This gives an error that says: pano13.lib(ColourBrightness.obj) : error LNK2019: unresolved external symbol _ht...@4 referenced in function _OutputPhotoshopCurve Any idea what could cause that? Allard --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Enblend/Enfuse 4.0 and Hugin
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 with -w -f3000x1500. yes, there are some changes in howenblend/ enfuse is called in 4.0 we will need to adapt this in Hugin - ideally with anenblend--version to find out if we're using a legacyenblend-enfuse; and with the Makefile adapted to theenblend-enfuse generation found on the machine. I think it could have been done more backward compatible way inenblend. Yes of course it should be done backward compatible, actually I can not see why there is a new command. Why not make Enblend working properly with the current command for both ways. I can not see any reason for having 2 commands. As far as I know the -w command is the only command built in in any stitcher, PTGui PTMac or Hugin. It has to be backward compatible or you loose 90% of the users. Hans --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: building libpano on windows using cmake
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 to ${_common_libs}
CMakeLists.txt:68
set(_common_libs ${TIFF_LIBRARIES} ${ZLIB_LIBRARIES} ${JPEG_LIBRARIES}
${PNG_LIBRARIES})
if(WIN32)
find_library(WXSOCK32 wsock32)
if(NOT ${WXSOCK32} MATCHES -NOTFOUND)
list(APPEND _common_libs ${WXSOCK32})
endif()
endif(WIN32)
...
Allard
Kornel
--
Kornel Benko
kornel.be...@berlin.de
signature.asc
Description: This is a digitally signed message part.
[hugin-ptx] Re: Help\Question setting up dev instance
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 installer. In Linux flavors all of these are taken care by the package manager that defines build and runtime dependencies and that keeps track of which files are intalled where. In Windows the user is on their own, and this can be a frustrating experience. On the wiki page you want to describe how to diagnose such a break and a generic way to fix it. Then you want to list all the specific fixes for each and every SDK package. Together they will end up being an instruction to build the SDK from scratch, though ideally users only need small fixes for their existing SDK and the first user that bumps into a break fixes it and contributes back to the project by updating the fix into the wiki; and a zipped binary package too. The zipped binary package can be used by other users to overwrite / update their SDK without having to download a full SDK or going through the whole fix as described in the wiki. When there are enough fixes to make the SDK outdated (as it is now), a new version of the SDK can be packaged and put up for download. I'm sorry I can't do much more. Windows is no longer my main platform. I'm currently very much behind on emails of this group, and have to prioritize my limited time. I'm in Quebec-City until Monday and won't have access to Windows until I'm back in the office. And I have a bad surprise waiting for me there. I have not been able to access my server remotely. It may just be a missed update of the dynamic DNS (the VoIP infrastructure seems to be OK) but it could as well be a failed system drive or a failed router. Whatever it is, I have a couple of very busy days ahead. For Hugin, and in the short term, this means: - release RC2 (this weekend, from my dyno-book) - take the time to read all the interesting things that have been brought up in the GUI threads (likely one of next week quiet nights, if there is any) - understand what is wrong with my gettext implementation and fix it (thanks Thomas Modes for the feedback) - test (and possibly re-fix) a configuration error with the enblend Mercurial repository (notifications are not yet 100% functional) - last but not least, I am playing with SVN-Hg and back. My goal is to piggy-back on the existing SVN infrastructure and use Hg locally. This shall make developers life easy without disrupting anything downstream (in my vision SVN will stay as-is for integration and release processes). - oh, and I also have the coding style document, resulting from the discussion amongst developers back in August, that is at 80% completition. But first: it's 4h30 AM and its time for me to start my day. Yuv Nicolas Pelletier wrote: I'll try to update the wiki to at least redirect to the thread, if not mention what should be done until the SDK is update. If it can make life simpler for other people. nick On Fri, Oct 16, 2009 at 1:28 PM, J. Schneider j-schn...@gmx.de wrote: Thanks, This is not the thread I had found and will follow that this weekend. Fine, then we are two. Thanks! nick regards Joachim --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Fwd: Re: [hugin-ptx] Re: possible memory leak in enblend enfuse?
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 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 br...@postle.net 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 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
-~--~~~~--~~--~--~---
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 '.;
@@
[hugin-ptx] Re: building libpano on windows using cmake
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.
This lib should be added to ${_common_libs}
CMakeLists.txt:68
set(_common_libs ${TIFF_LIBRARIES} ${ZLIB_LIBRARIES} ${JPEG_LIBRARIES}
${PNG_LIBRARIES})
if(WIN32)
find_library(WXSOCK32 wsock32)
if(NOT ${WXSOCK32} MATCHES -NOTFOUND)
list(APPEND _common_libs ${WXSOCK32})
endif()
endif(WIN32)
...
Allard
Kornel
Panotools already has ENDIAN aware file i/o functions in filter.h
These should have been used instead of using another package for this
one function.
--
Jim Watters
http://photocreations.ca
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Fwd: Re: [hugin-ptx] Re: possible memory leak in enblend enfuse?
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 seam and have only one or two vertices. This is likely to happen when the distance transform result has many small, fragmented patches. For each seam we should compute an appropriate MaskVectorizeDistance heuristically. The condition that leads to the error message mask is entirely black, but the white image was not identified as redundant also needs to be examined. If the seam optimization is allowed to remove snakes entirely, either because the vectorization decides the contour is too small or because the annealer collapses the contour, then this condition should not be an error. The white image does have pixels to contribute (according to the distance transform), but the optimization decided that it was not worthwhile to blend them in. Currently the optimization does not consider the contour area as a constraint. I think this requires more thought. Should the optimization be allowed to collapse contours or is this a bug? Andrew On Sat, Oct 17, 2009 at 5:23 AM, cspiel csp...@freenet.de 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 exposure stack. What do you suggest Enblend should do? Should it detect an almost complete overlap of a pair of images and report the problem to the user? This would be very helpful in the case we discuss here, but lead us to the problem of how to identify these pairs of images. Furthermore, how can we code this efficiently? It is a funny situation that only crashes enblend in weird circumstances, but it is still a bug in enblend that is good to have fixed. So even though the original test-data is a bit nonsensical, it did allow us to find and fix a bug. You are totally right. Enblend must behave even with nonsensical data. Right now the Distance Transform routine goes ballistic when two images almost completely overlap. I have some ideas, but I'm also curious of your suggestions. /Chris --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Fwd: Re: Re: possible memory leak in enblend enfuse?
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 different approach to seam line finding would avoid these problems, and also leads to better seams. One possibility are the graph cut based segmentation algorithms. Here the masks are generated directly and there is no need for going from masks to vectors and back to masks. I'm also quite sure that the generated seams would be better than with the current snake algorithm. ciao Pablo --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: GSoC2009_layout with XYZ for Windows - please test
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 in bug: 2881036 with screenshots) Any suggestions? Cheers /O --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Fwd: Re: Fwd: Re: [hugin-ptx] Re: possible memory leak in enblend enfuse?
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 exposure stack. What do you suggest Enblend should do? Should it detect an almost complete overlap of a pair of images and report the problem to the user? This would be very helpful in the case we discuss here, but lead us to the problem of how to identify these pairs of images. Furthermore, how can we code this efficiently? The problem is more complex. The normal mode-of-operation of enblend is: that images are added incrementally. So such an almost overlapping image could very well be completely inside the already assembled pixels, which enblend detects, but also, as is probably now the case, only just outside the currently being-stitched area. Enblend already detects the case where all pixels are already accounted for. We could instead of just checking black-or-white wheter /any/ pixels are new, just count the number of pixels being new. If this count is very low, it is a hint there is something going on. Of course, if I take say 3x3 shots (non-bracketed) and overlap them almost 50%, the center one will have only a small amount of only-defined-by-this-image pixels, but still be essential for the end result. Enblend (by default, I haven't tried the option that changes this behaviour) adds each image as it goes. It could make a map of how many images do I have for this pixel, next for each (non-transparent) pixel in image X if the count is not equal to one, there are other images defining this pixel. An image where ALL pixels are marked not-one, is redundant. Again, it's easy to count the pixels to get a measure of how redundant each image is. Just printing this info, will allow hugin to read it and present it to the user, and this info can be interpreted by a human to do the right thing. For example, I am working on a .7Gpixel panorama. I took the first 8 images with auto-focus on before I noticed this. I then reshot those images. Of course I didn't remember this when I started stitching (*). I would've been warned of this situation if enblend had warned me: Images 0-15 are redundant. pixels of the source image that overlap other images. example output: --- overlap image percentage name 100% p2516.tif // At least ONE of these images can p25160001.tif // be removed without affecting the p25160002.tif // number of pixels in the final image. p25160003.tif // It could be that removing one p25160004.tif // makes another image non-redundant. p25160005.tif p25160006.tif p25160007.tif p25160008.tif 98% p25160034.tif 95% p25160038.tif 92% p25160039.tif 65% p25160021.tif 64% p25160022.tif 63% p25160056.tif 63% p25160023.tif 62% p25160018.tif 62% p25160026.tif --- In the case at hand, the unique pixels from one image are a small narrow line of pixels. These are delimited by the edge of the image. The overlapping region is MUCH larger. This is an obvious warning sign. It is a funny situation that only crashes enblend in weird circumstances, but it is still a bug in enblend that is good to have fixed. So even though the original test-data is a bit nonsensical, it did allow us to find and fix a bug. You are totally right. Enblend must behave even with nonsensical data. Right now the Distance Transform routine goes ballistic when two images almost completely overlap. I have some ideas, but I'm also curious of your suggestions. /Chris OK. Roger. (*) Of course you look at the images before stitching starts. However, they are easily recognized as belonging together and then lumped into one directory to be stitched. Then later on I start stiching that directory I just let the keypoint finder look at them... -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ --~--~-~--~~~---~--~~ 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] Re: Next GUI - take 2
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 projections later. I agree with this completely. The only other point I was trying to make is that converting to other projections should not involve one project file per projection IMHO. Thanks, nick I don't like this. It adds unnecessary step to panorama creation. Usually I select the projection in fast preview by trying all of them and comparing them how nice they are immediately. Now it would mean that I've to stitch complete panorama (sometimes I crop it quite a lot) and then reprojecting it somewhere. What would be better that when someone specifies more projections (this would need also some work on GUI) it would _internally_ use cube faces/equirect otherwise it would work the same. What I had in mind is indeed like the fast preview window, with many projections and cropping, except it is a fast postview window, that shows you an already stitched pano at high resolution, and lets you format a view interactively, with instant switching between projections. As I have learned from writing Panini, that kind of display is quite feasible with OpenGL technology. It works especially well if the pano is in cubic format. I believe (but have not yet seen) that would be possible to render final high resolution reprojections quite fast using the video hardware via OpenGL. But even if the final rendering had to be done in software, I would prefer this way of composing my images, as it is pretty hard to get just the right view while looking at a low resolution preview. And if I want to keep several views it will probably save time, because reprojecting a large image is a lot faster than stitching it from small ones (no blending needed). Regards, Tom Lukas On Thu, Oct 15, 2009 at 12:43 PM, Tom Sharpless tksharpl...@gmail.com wrote: As seems to be usual, I agree with Bruno. The job of a stitcher is to prepare, match up, line up, and combine images on the panosphere. Generating some flat projection of the panosphere is a necessary part of that job, but generating all possible projections is not. Creating printable views involves so many possibilities, and so many aesthetic considerations, that it is a speciality all its own. And repeating the entire process from source images to get each view is a big waste of time: things like lens correction, photometric correction and, especially, blending really need to be done only once. 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 projections later. I include equirectangular only for the sake of tradition. Cube faces have several advantages. You can display them almost immediately with QuickTime or Flash technology. Because they are rectilinear images, they are easy to judge, and to retouch. And they even let you stitch faster, because to map from a radially symmetric projection (e.g. almost any photo) to a radially symmetric projection, you only have to implement a nonlinear function in one dimension, along the radius. That one dimensional mapping can be a lookup table; whereas to stitch to equirectangular requires a full 2-D nonlinear mapping (I use this trick in autopano-sift-c to generate stereographic images faster than is possible with libpano). For composing just the right view you need an interactive program, that can custom fit the projection to the subject to some extent (think of a view camera on steroids). Both my Panini, and Max Lyons' PTAssembler preview window, come close (from different directions) to what I would ideally want. Maybe the new Hugin suite should incorporate such a program; but it ought not to be configured as a set of sub-options on stitching. Regards, Tom On Oct 14, 4:44 pm, Bruno Postle br...@postle.net wrote: On Wed 14-Oct-2009 at 16:09 -0400, Nicolas Pelletier wrote: I'm not convinced it is a post processing step. I think it depends on where we draw the what should hugin do boundary. I guess that where I'm coming from is that Hugin and the Stitcher tab are complex enough as it is. I'm currently working with the exact workflow you mentioned, create a 360 180 equi and then use this as the first element in the chain. But if the other steps were only post processing, then why should we have other projections and other import method? Mainly because we can, but also because partial panoramas are legitimate targets, and because people have a use for stitching partial equirectangular and cylindrical input. Also, from this equirectangular, if we had many output, we could have a nice
[hugin-ptx] Re: building libpano on windows using cmake
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? If it is a standard
package of some kind, then creating a local version could create more
problems than it solves. If it is something that is already local to
libpano, then by all means rewrite it.
-- Tom
On Oct 17, 11:00 am, Jim Watters jwatt...@photocreations.ca wrote:
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.
This lib should be added to ${_common_libs}
CMakeLists.txt:68
set(_common_libs ${TIFF_LIBRARIES} ${ZLIB_LIBRARIES} ${JPEG_LIBRARIES}
${PNG_LIBRARIES})
if(WIN32)
find_library(WXSOCK32 wsock32)
if(NOT ${WXSOCK32} MATCHES -NOTFOUND)
list(APPEND _common_libs ${WXSOCK32})
endif()
endif(WIN32)
...
Allard
Kornel
Panotools already has ENDIAN aware file i/o functions in filter.h
These should have been used instead of using another package for this
one function.
--
Jim Wattershttp://photocreations.ca
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
