[hugin-ptx] Re: GSoC patch ideas
Although I'm not really into this code, shouldn't a divide by zero result in NAN instead of INF? Of course the limit of 1/n with n-0 is INF, but only for n0. For n0 (a very small negative value), 1/n actually goes to -INF. At exactly n=0, 1/n is not defined. It's a small detail, but NAN is more accurate here than INF, if we're going to use that. Best, Bart --~--~-~--~~~---~--~~ 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: GSoC patch ideas
On 21 apr, 15:27, paul womack pwom...@papermule.co.uk wrote: IEEE floating-point standard, supported by almost all modern processors, specifies that every floating point arithmetic operation, including division by zero, has a well-defined result. In IEEE 754 arithmetic, a ÷ 0 is positive infinity when a is positive, negative infinity when a is negative, and NaN (not a number) when a = 0. The infinity signs change when dividing by -0 instead. This is possible because in IEEE 754 there are two zero values, plus zero and minus zero, and thus no ambiguity. Ah yes, I see, I hadn't considered it that way. Then the question is, is a check for a=0 necessary? Doesn't the arithmetic take this into account automatically (as in, it computes the result as +INF or -INF, depending on the value of Aux_1)? Best, Bart --~--~-~--~~~---~--~~ 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: Big hugin project.
On 20 apr, 18:27, r.e.wolff r.e.wo...@harddisk-recovery.nl wrote: On Apr 20, 6:22 pm, Bart.van.Andel bavanan...@gmail.com wrote: My first thought about images rendered black was that somehow you are (well, Hugin is) using a wrong value for the EV. Normally you can tweak the EV value (in the preview window, for instance) to alter the brightness of the image. If the EV is set to a very low value, the image will be rendered completely white, and if set to a very high value, it will be rendered completely black. Is this the case maybe? Ah! checked the PTO, and it's set to zero. This is a very low value, so you are expecting a completely white image, but it's black. Weird Depends. What is really important is the difference between the EV from the input images and the EV as set in the preview window, maybe we are referring to different values (I didn't dive into any PTO files really)... Regarding the final image. I don't know if the zoomed in images cover the entire low res panorama, but if it does, the simplest solution is to remove this image from rendering by clicking the image number once in the preview window. If all positions were already correct, this will leave you with a high resolution panorama with all the data coming from the zoomed in images. No, the zoomed images cover only the 10 percent interesting areas. The rest is grass and sky. Hmm... Well, I can think of a workaround. 1. Render the panorama image, excluding the low res panorama as a source. Use a low resolution and no interpolation, to speed things up. Save as TIFF. 2. Use the inverted alpha channel of the generated panorama to generate a mask for the low resolution panorama. Using some convolution (thickening/thinning) to make the gaps a little smaller. 3. Finally, render the panorama at full resolution, including the now masked low resolution panorama. This is just theory, I haven't tried any of this in practice, but I'm pretty sure it will work. Best, Bart --~--~-~--~~~---~--~~ 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: fov computation from exifless data
Can anyone be bothered to check the source to end this question? As I mentioned earlier: calculation is done in the SrcPanoImage::calcHFOV(...) function, see http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/src/hugin_base/panodata/SrcPanoImage.cpp?view=markup. It takes 4 parameters: - type of projection (e.g., rectangular) - focal length - crop factor - image size These parameters are exactly what is needed to compute the hfov. Check the source to see how it's done. Best, Bart --~--~-~--~~~---~--~~ 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: hugin 0.80 beta for windows
Where can I get pre-compiled version of hugin 0.8 for windows xp. If you had bothered to try the search function using hugin 0.8 beta as keywords (even without the quotes) [1], you'd have found the answer in the very first post of the very first search result [2]. But okay, to answer your question: go to http://panospace.wordpress.com/downloads/ to find the installers. [1] http://groups.google.com/group/hugin-ptx/search?group=hugin-ptxq=hugin+0.8+beta [2] http://groups.google.com/group/hugin-ptx/browse_thread/thread/4db69067e6ac15ea/081e1645bfffea28?lnk=gstq=hugin+0.8+beta#081e1645bfffea28 --~--~-~--~~~---~--~~ 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: fov computation from exifless data
Yuval Levy wrote: paul womack wrote: Pixel count and focal length is NOT enough information to calculate a FOV. I think what would be missing to the above information is pixel pitch or another relationship of the pixel dimensions to the sensor dimensions. sensor size would give a good enough approximation. Correct me if I'm wrong, but I believe that's what the crop factor is for. It serves as a factor between the sensor size and 36x24mm film, like this: [diagonal of sensor] x [crop factor] = [diagonal of 36x24mm film] --~--~-~--~~~---~--~~ 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: fov computation from exifless data
On 14 apr, 18:37, Yuval Levy goo...@levy.ch wrote: Bart.van.Andel wrote: Correct me if I'm wrong, but I believe that's what the crop factor is for. It serves as a factor between the sensor size and 36x24mm film, like this: [diagonal of sensor] x [crop factor] = [diagonal of 36x24mm film] you're right - crop factor is another approximation of size relative to 36x24. If the form factor is the same, it works. Else it is an approximation. What do you mean by form factor? If you mean the relation between width and height - that has been taken account for, since the diagonal is used, or am I mistaken here? Bart --~--~-~--~~~---~--~~ 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: fov computation from exifless data
Ah, I think I see now where the trouble is. You are not taking into account the ratio between horizontal and vertical sensor size. Standard analog film has a ratio of 3/2 (36/24), whereas most digital cameras - like yours - have a ratio of 4/3 (2272/1704). Hugin takes this into account in the computation of the hfov, as can be seen in the SrcPanoImage::calcHFOV(...) function. See this file: http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/src/hugin_base/panodata/SrcPanoImage.cpp?view=markup Hope this makes things clear. Best, Bart --~--~-~--~~~---~--~~ 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: getting strange blending errors for a very wide panorama
Looks to me like Enblend causes the trouble. Most obvious in the sky, the artifacts seem to be caused by a low frequency blending error (which explains the wide bands). The errors should not be visible in the intermediate files generated by Hugin during the process, could you confirm this? You could try using Smartblend instead of Enblend, just make sure you set the options right before you do, otherwise you'll be waiting 6-8 hours ending up with an error and no final output. Of course you could also have Hugin keep the intermediate files and perform the last step (the final blending) manually, so you can try different options without having to recompute the intermediate images every time. Besides, I'm wondering if the resolution you chose for the output really makes sense. As far as I can see from the output, there are only two series of images overlapping vertically about 50 percent (except for the obelisk), spanning about half of the final image. Unless the vertical resolution of the images is about 10,000 real pixels, this is nonsense. And remember, a 12MP point-and-shoot camera may deliver 4000x3000 pixels, but at 100% zoom you can see that it does not really contain that much detail / information. --~--~-~--~~~---~--~~ 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: Enhancement request for Batcher
Mike, Please open a new topic if the subject of your post is *completely* different from what you are replying to, as you have now done twice. This keeps the discussion list as clean as possible. Mixed topics are hard to track, as you will probably agree. Thank you. Bart --~--~-~--~~~---~--~~ 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: Pure JavaScript pano viewer
Did you post a test blogpost so we can take a peek at it? Otherwise, there are (free) products on the market to reduce/obfuscate javascript code, for instance JSMin [1], YUI Compressor [2] and Dojo Compressor [3]. This might help fit the javascript code into the blog. I don't know what exact restrictions apply, so I cannot guarantee this will work. Best, Bart [1] http://crockford.com/javascript/jsmin [2] http://developer.yahoo.com/yui/compressor/ [3] http://dojotoolkit.org/docs/shrinksafe --~--~-~--~~~---~--~~ 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: Pure JavaScript pano viewer
On 2 apr, 02:33, Yuval Levy goo...@levy.ch wrote: Bart.van.Andel wrote: I don't want to be wasting the mentor's, GSOC's or my own resources on a project which is bound to fail for lack of time... if you can't work full time on your GSoC project, than it is better not to apply. Too bad, Exactly my thought. I really like the Javascript viewer, even though I would prefer if the mouse controls would be like traditional VR viewers (inverted left and right). I gave that one a thought, but decided somehow that inverted left and right belong to viewers which also implement autoscroll. I'll add it as an option (which is really too easy), because the idea attracts me as well. Autoscroll can be added fairly easily as well, although it's probably useless when the speed is only 3 fps. Best, Bart --~--~-~--~~~---~--~~ 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: Pure JavaScript pano viewer
I don't mind hosting. Great! What type of traffic can we expect? Very little. It's only the html and js that have to be hosted, the images can be hosted anywhere. The example html uses one picture directly from my Picasa photo album and two other images I found using Google. I´m a bit busy right now, but when I get more time, I´ll update the html and js so parameters (like hFovDst and mode) can be tweaked more easily. Tweaking is already possible, but at the moment a call to setMode is needed to propagate the changes to the individual div elements. Best, Bart --~--~-~--~~~---~--~~ 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: Pure JavaScript pano viewer
Well, this page here suggests that 3D is very well possible with the canvas element: http://www.xs4all.nl/~peterned/3d/ That's exactly how it can be done, there is everything here for a no-plugin cubic panorama viewer, and the speed is comparable to flash panoramas. Cubic panoramas: yes. Other types: challenge. Hey, GSOC is approaching... ;-) Best, Bart --~--~-~--~~~---~--~~ 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: Pure JavaScript pano viewer
Thanks (a lot) to Dale, a pretty minimalistic demo can now be viewed here: http://www.tatteredmoons.org/jspanoviewer.html Best, Bart --~--~-~--~~~---~--~~ 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: Pure JavaScript pano viewer
Hi all, Great to see that I'm not the only one who likes the idea of a javascript panorama viewer :) Regarding speed, I've been fiddling around a bit myself with the current version, and here are some of my (mostly quite obvious) findings: - Smaller dimension of input image: faster - Smaller dimension of panorama viewer: faster - Less vertical slices (larger wSlice): faster (but less accurate) - Smaller visible part of the input image (smaller vertical field of view): faster. Compare MODE_PRESSx to MODE_NORMAL or MODE_PANNINI for example. - Google Chrome or Firefox versus Internet Explorer: faster. I've tested the script on my new laptop (Core2 Duo at 2.23 GHz), my 4 year old desktop (Athlon64 at 2.2 GHz) and a pretty recent computer at my job, with the current html file (720x300 pixels). It doesn't run nearly as smooth as most Flash viewers, but 1 or 2 frames per second using IE, and a little more using Chrome and Firefox. Considering it's just Javascript, I found this pretty okay. But of course I hope to get newer versions to run faster. It's open source, so others are of course welcome to contribute. Best, Bart --~--~-~--~~~---~--~~ 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: Pure JavaScript pano viewer
On 1 apr, 15:26, Yuval Levy goo...@levy.ch wrote: Bart.van.Andel wrote: Cubic panoramas: yes. Other types: challenge. Hey, GSOC is approaching... ;-) want to apply? the deadline is April 3, and I think that this is a project worth considering. I'm limping on two legs here (Dutch saying, haha). I'd love to get this thing working, but first I have to finish my studies. And this summer is the absolute deadline. After that, I won't be a student anymore, plus I seriously need a vacation... So probably, this isn't gonna work well with a GSOC, or is it? I don't want to be wasting the mentor's, GSOC's or my own resources on a project which is bound to fail for lack of time... Maybe I'm guessing wrong, if so, please elaborate! Best, Bart --~--~-~--~~~---~--~~ 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 error: Mask is entirely black, but white image was not identified as redundant
Okay I have to admit that the files I fed into Hugin were quite different from normal panorama input. Instead of using pictures taken from a single point, I moved the camera along the scene. This will obviously make it more difficult to find a pleasing solution, but I wasn't going for the aestetics anyway. Still, errors like this shouldn't occur, even with the strangest input. Basically, the pictures themselves are normal 35mm (equivalent) rectilinear pictures (within the margin of the camera of course), with a 4:3 ratio. The final output has a ratio of about 7:2, so not really strange here. All 31 images are connected. The output TIFFs are all normal, except for the final output, which is an illegal/incomplete 8 byte file. I've just uploaded both the pto and the log as Google documents: pto: http://docs.google.com/Doc?id=dhb9htjv_20fnckngd6 log: http://docs.google.com/Doc?id=dhb9htjv_21dczt5bdd The log seems a little bit different from what I posted above, as you can see. Either the logging system doesn't always handle the output in the correct order, or things are really not always executed in order and may interfere??? I've encountered the error with the enblend.exe bundled with Hugin- svn3649, which is enblend version 3.2. No options changed, except for TIFF compression. --~--~-~--~~~---~--~~ 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: Hugin Build Version 3649 for Windows
On 18 feb, 07:35, lxegs clement.batt...@gmail.com wrote: i think i know 7zip and even if that's just an advice , the primary purpose was to test that version and not speaking about possible compression do you give some advices on p2p/illegal sites when people don' t compress with 7-zip ??? It almost seems if you're offended, which really wasn't my goal. Relax man, I'm just trying to be helpful here: it saves you uploading time and a bunch of people a lot of downloading time. I don't see what warez have to do with this at all, so cool down. Actually I'm really appreciating that you share your build with the world, and I was pretty eager to try it out. That's why I didn't want to wait for too long for the thing to download :) Anyway I've tried it out (of course) and it really looks nice. Progress is really being made! As you can see in another thread I encountered an Enblend bug, but none within Hugin-SVN3649 itself so far. And I like the new icon set! --~--~-~--~~~---~--~~ 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] Enblend error: Mask is entirely black, but white image was not identified as redundant
I just encountered an enblend error. At the end of a Hugin run, I get this message: ---(1)--- enblend: an exception occured Mask is entirely black, but white image was not identified as redundant. make: *** [blend.tif] Error 1 ---(1)--- After that, the process is interrupted. All intermediate TIFFs are generated, but not the final, enblended, one. A little back in the log, I read this: ---(2)--- [...] Loading next image: blend0019.tif Loading next image: blend0020.tif Loading next image: blend0021.tif Creating blend mask: 1/4 2/4 3/4 4/4 Optimizing 1 distinct seam. Strategy 1, s0: 1/4enblend: some images are redundant and will not be blended. enblend: some images are redundant and will not be blended. 2/4 3/4 4/4 Strategy 2: s0 Using 7 blending levels [...] ---(2)--- From the preview it is clear that some images are completely overlapped by other images and probably won't be shown in the final output. However this shouldn't prevent enblend from finalizing the image, I'd presume. It seems the issue has been encountered earlier by Michael Galloway. Guio Kohlmeyer's solution was to pass the option '--fine-mask' to enblend. I find that a strange solution slash workaround, which did the trick by the way. But I still consider this an error. One thing I noticed was that message (2) is still spawned, but in a different form. Instead of the enblend message coming after 'Strategy 1, s0: 1/4', it now appears just before it. Could the error be in this part? It looks like this: ---(3)--- [...] Optimizing 1 distinct seam. enblend: some images are redundant and will not be blended. enblend: some images are redundant and will not be blended. Strategy 1, s0: 1/4 2/4 3/4 4/4 Strategy 2: s0 Using 7 blending levels [...] ---(2)--- (see http://groups.google.com/group/hugin-ptx/browse_thread/thread/c42857dceb7b6fe4/3297012a01321a1d for the other thread) --~--~-~--~~~---~--~~ 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] [Ubuntu 7.04] Building Enblend-Enfuse - glut / libxmu dependency
Hi all, I've spotted a missing dependency on the Panotools wiki regarding compiling Hugin under Ubuntu (http://wiki.panotools.org/ Hugin_Compiling_Ubuntu). On my freshly installed Ubuntu 7.04 system (under coLinux), ./configure printed a warning message stating: [...] configure: WARNING: WARNING: GL/GLU/GLUT not found, disabling GPU mode [...] I've checked a dozen times that the necessary freeglut etc. libraries were installed correctly, and I couldn't find any problems there. But warnings are not errors, so I thought I could just compile without glut. Heck no! I got messages like this: [...] make[3]: Entering directory `/home/bart/src/enblend/enblend' g++ -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I../include - DVIGRA_STATIC_LIB -I/usr/include/OpenEXR -O3 -ffast-math -DNDEBUG - Wall -DENBLEND_CACHE_IMAGES -ffast-math -o enfuse enfuse-enfuse.o vigra_impex/libvigra_impex.a -lGLEW -lGLU -lGL -lglut -lSM -lICE -lXi - lGLU -lGL -lIlmImf -lImath -lHalf -lIex -lz -llcms -ltiff -lpng -ljpeg -lz enblend-gpu.o: In function `wrapupGPU()': gpu.cc:(.text+0x1b9): undefined reference to `glutDestroyWindow' enblend-gpu.o: In function `initGPU(int*, char**)': gpu.cc:(.text+0xa87): undefined reference to `glutInit' gpu.cc:(.text+0xa93): undefined reference to `glutInitDisplayMode' gpu.cc:(.text+0xa9f): undefined reference to `glutCreateWindow' gpu.cc:(.text+0xc68): undefined reference to `glutDestroyWindow' collect2: ld returned 1 exit status make[3]: *** [enblend] Error 1 [...] It seems ./configure doesn't work correctly here, trying to compile glut-specific code even after finding out that there is no glut installed. Obviously the problem here is caused by a missing -lglut in the command line. Solution: after examining the config.log file generated by ./ configure, I found out that the problem wasn't glut, but a missing libxmu. ./configure then incorrectly assumes that glut is missing. After installing libxmu-dev, the problem was solved. So I guess the wiki should be updated with libxmu-dev. Best, Bart NB: output of uname -a: Linux ubuntu 2.6.22.18-co-0.8.0 #1 PREEMPT Tue Jan 13 20:59:56 UTC 2009 i686 GNU/Linux Running under coLinux version 0.8.0 (13 January 2009 21:04:42) --~--~-~--~~~---~--~~ 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: Parrallax (?)
Hi, I'm not sure if I understand what you mean exactly. I assume you're taking multiple photographs from a tripod (without a panoramic head) which you want to compile into a panorama, and you're asking if parallax is a problem which can be automagically solved? I this case the answer is no, unfortunately. Although some algorithms can work around parallax errors (Smartblend does quite a decent job), it's better to avoid them. For landscape photography, small movements of the camera won't cause trouble because everything is far away, but for closer subjects, parallax movements will be visible almost instantly (just see what happens to your view when you move your head half a centimeter left or right). A properly calibrated panoramic head on your tripod will do the trick, but these things can be quite expensive. For using Smartblend within Hugin, get the necessary files here (read the readme files for instructions on how to use the scripts): http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/platforms/windows/smartblend-wrapper/ or http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/platforms/linux/ If you meant something else with your post, please explain. I couldn't figure out the sentence, really. Best, Bart --~--~-~--~~~---~--~~ 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: 0.61 update of Panini perspective tool available
Aaaarghh! Mac users are reporting all sorts of problems with cubic format, you are not alone... But why only on Macs? And with 3 different video systems at least? For the record, I don't have a Mac (I only wish I had one, haha). I'm running WinXP SP3 and just updated my graphic card drivers (ATI Radeon 9600SE) to the newest version. I just installed the drivers, not that piece of memory consuming bloatware called Catalyst. I wouldn't have any idea how to set up mapping of multiple texture images onto one surface. If you do know, please tell me. Well, basically they're just 6 rectangular projections 90 degrees apart, which shouldn't be too difficult to backproject onto the panosphere. I guess you're already doing the same thing when loading a rectangular image? Am I safe in assuming that you can display the non-cubic formats OK? Correct. Only trouble with cubics. I'll see if I can figure out more details later. Any help you can give would be most welcome. I am not a Mac developer and have no Mac to test on. Me neither, unfortunately. I've read through the source code a bit and couldn't find anything wrong there. Moreover, I compared your code to some of the code available on other websites (by googling), and if not pretty much an exact copy, it's still fairly the same amount and order of operations. Strange. If you look closer at the picture I linked to in my previous post, it's not only that the same image is shown on every face. It's shown with a *different* error on every face. The images are shifted in both X and Y directions (in texture coordinates), and have border issues which differ from face to face. It popped into my mind that something might be wrong with texture coordinate generation internally, but this does not quite explain the cloning behavior. By the way this is the first time I dive into OpenGL, so don't expect me doing wonders just yet ;) Cheers, Bart --~--~-~--~~~---~--~~ 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: any way of replacing low-resolution images with higher-resolution originals?
I think what breic means is downsizing in resolution, not merely jpeg file compression. Although jpeg images will load faster than tiffs due to their file size, they use the same amount of memory when loaded and will slow down CP finding, CP manipulation and preview displaying. Since Hugin and the tools used by Hugin use pixel coordinates for the CPs, reoptimizing will fail after replacing small images with bigger ones, because the pixel locations will be different. Just open a .pto file in a text editor to find the coordinates. However, when you have already optimized with the smaller images, you can then close the project, replace the image files with the bigger files and load the project back into Hugin. Don't reoptimize, but go to the Stitcher tab immediately and stitch the image. I just tested it on a small 2 image panorama. It works because after optimizing, the .pto file contains the necessary information about roll, pitch, yaw and other warping values, next to the (at this point unnecessary) CP information. Best, Bart On Dec 19, 2:38 pm, Don Holeman dholem...@cox.net wrote: Forgot to add, jpeg to a lower resolution for the mapping images, but keep the image dimensions the same. -Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of breic Sent: Thursday, December 18, 2008 11:21 PM To: hugin and other free panoramic software Subject: [hugin-ptx] any way of replacing low-resolution images with higher-resolution originals? Since Hugin is slow at loading images on my laptop, I sometimes downsize the photos before starting the panorama. This lets me keep my sanity waiting for Hugin, and is often okay if I just want an equirectangular projection. (I am shooting 10 megapixel images at 27mm equivalent.) However, if I decide to make a stereographic projection, then I want all the megapixels available to minimize pixelation in the distorted areas. Is there any way of replacing the smaller versions with the originals in a project? Basically, I'd like the control points to be placed appropriately and, if possible, to reoptimize each control point (although that might not be necessary). --~--~-~--~~~---~--~~ 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: hugin 0.7.0 crashing in WinXP SP2 - solved
Yes this is a known bug and workaround, but thanks anyway. I suppose the source could be adapted to use the short path name (8.3 format) when calling external tools which fail on the unicode paths. To my knowledge, these won't contain unreadable symbols (although spaces can occur technically). I checked this by making a folder named Vysočina. When dir/x is typed in a cmd window, it shows the following: C:\tempdir /x [...] 15-12-2008 14:30DIR VYSOIN~1 Vysočina So, this Vysočina folder can also accessed by using VYSOIN~1 instead. The win32 c++ function to use is GetShortPathName which is documented at http://msdn.microsoft.com/en-us/library/aa364989(VS.85).aspx --~--~-~--~~~---~--~~ 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: Release 0.5 of pvQt viewer
Hi Tom, First, please make sure you have version 0.5.72. I posted 0.5.71 before testing on a system with only power-of-2 textures. That revealed a serious error in scaling cubic textures -- fatal there, but could affect cubic panos on any system. 0.5.72 fixes that. I checked and I have the 0.5.72 release. But as no error message is produced anywhere (as far as I can see anyway) I can't tell whether it has to do anything with my video card having problems with non-power- of-2 textures. That would not be the case in OGL version 2.1. More likely I'm asking for something really stupid, when you do that OpenGL often just aborts the operation without reporting an error. Hmm, I just ran the program through an OpenGL debugger (I found a free one at http://www.vis.uni-stuttgart.de/glsldevil/, but there are more), and there seems to be no detectable error. I find this quite strange, a behavior of aborting without reporting. It is interesting however to see when the image gets redrawn, see for yourself that this happens even when nothing really changes in the image (e.g. when opening the Load File window). By the way, as requested, the details from the about box: About your OpenGL implementation: Version: 2.1.7976 Release Vendor: ATI Technologies Inc. Video: RADEON 9600 SERIES Limits: texPwr2 0, texMax 2048, cubeMax 2048 The dialog states pvQt version 0.5.71 although I just double checked that I'm using 0.5.72, by redownloaded the thing, unpacking it to a different location and running it again. --~--~-~--~~~---~--~~ 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: Rendering high-resolution panorama
Well, I have an example here which consists of two images with almost 50 percent overlap. The source resolution is 2576 pixels wide, and Hugin suggests an optimum of 5055 pixels (rectilinear projection). Although it need a little cropping, this resolution is too wide to prevent pixels from being upscaled. Like I said before, I don't know how Hugin determines the optimal resolution, but it seems to me that it isn't always a correct estimate. (by the way, 70 percent minus 10 percent of that 70 percent would be 63 percent, not 60 percent) --~--~-~--~~~---~--~~ 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: Rendering high-resolution panorama
On Dec 14, 5:01 pm, Erik Krause erik.kra...@gmx.de wrote: Bart.van.Andel wrote: Well, I have an example here which consists of two images with almost 50 percent overlap. The source resolution is 2576 pixels wide, and Hugin suggests an optimum of 5055 pixels (rectilinear projection). Although it need a little cropping, this resolution is too wide to prevent pixels from being upscaled. This depends on the angle of view. Rectilinear output is same resolution only in the image center and needs to be stretched outside. Only if you restrict output hFoV to the hFoV of a single input image you can compare the values. The case you describe is a pretty obvious case. A single picture taken with a rectilinear lens will remain the same when using a rectilinear projection. My point is, how does Hugin determine this estimate for a multiple image panorama? To give Ralf a nice answer as to why the estimate wasn't correct, this would really help (together with the other information I requested). Ralf, maybe you could upload your source images (jpg will do) and .pto somewhere? --~--~-~--~~~---~--~~ 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: Release 0.5 of pvQt viewer
First, please make sure you have version 0.5.72. I posted 0.5.71 before testing on a system with only power-of-2 textures. That revealed a serious error in scaling cubic textures -- fatal there, but could affect cubic panos on any system. 0.5.72 fixes that. I checked and I have the 0.5.72 release. But as no error message is produced anywhere (as far as I can see anyway) I can't tell whether it has to do anything with my video card having problems with non-power- of-2 textures. Yes, Bart, the display of empty frames when you cancel an image load is intentional. The main idea was to make the cube faces visible as drag-and-drop targets; but I have come to rely on this behavior so much for debugging texture mappings that I doubt if I will want t change it any time soon. It should be quite easy to disable this for a release build through the use of some #define and #ifdef statements, I guess, but never mind, it's not a serious problem at all :) --~--~-~--~~~---~--~~ 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: Rendering high-resolution panorama
Well I don't know exactly how the suggested size is computed by Hugin and how it relates to the input images (amount, resolution, sharpness, field of view etc. etc.) and the projection chosen (type and parameters). Based on the very little information that you provide there is not much to suggest, except to just fiddle around a bit. As an example however, if you create a rectilinear panorama from two 35mm equivalent images which have an overlap of about 25 percent, the center will always look a lot sharper than locations further from the center. At the very left and right (assuming a horizontal panorama), the source pixels will be stretched quite a lot, while at the center they might be a little squeezed. If the horizontal resolution of your source images were a 1000 pixels, a very wild guess for the output horizontal resolution would be something like 1750 (2 times 1000 minus the overlap) before details get blown up too much, but the distortions caused by the rectilinear projection would still be visible. On Dec 11, 6:15 pm, ralf i...@planetdsl.de wrote: Hello, rendering a panorama with about 4000 pixel width looks sharp, rendering the same with 19000 pixel (suggested size) it doesn't look so sharp. I used Nona/spline 64. Are there any recommendations? Ralf --~--~-~--~~~---~--~~ 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: Rendering high-resolution panorama
Okay. So now we have: - Panorama at 4000 pixels width looks sharp overall, but it doesn't at 19000 pixels. - Source images: 20 in 3 rows, so about 7 images per row? - Resolution of source images: unknown. - Sharpness of source images: unknown. - Images taken in portrait or landscape mode (or tilted otherwise): unknown. - Amount of overlap of source images (or at least an estimate): unknown. - Projection chosen: unknown. For an equirectilinear panorama using source images taken in landscape mode at 20 percent overlap per image (for better results you should take more overlap), you'd need source images of about 19000 / (7 - 6*0.20) = 3276 pixels wide (or about 8MP) to achieve a more or less 1- to-1 correspondence between input pixels and output pixels. Of course this isn't really true because the images are warped during projection, and some parts will probably be cut of to get rid of empty spaces in the final panorama, but to get an idea of what you need this computation should do. So, fill in the blanks and someone might give you an even smarter answer, I can't guess them for you :) On Dec 12, 7:00 pm, ralf i...@planetdsl.de wrote: thanks for your reply. There are 3 rows together 20 images (because handheld). It`s a rectlinear panorama, the horizontal view is 118 degree. I guess it is width but not to width (landscape). It`s not the distortion or the edges which are looking unspharp it is the overall impression. The smaller image with about 4000 pixel is sharp, (details are much sharper in center and edges). For the smaller image I used Nona/Poly 3. On 12 Dez., 17:46, Bart.van.Andel bavanan...@gmail.com wrote: Well I don't know exactly how the suggested size is computed by Hugin and how it relates to the input images (amount, resolution, sharpness, field of view etc. etc.) and the projection chosen (type and parameters). Based on the very little information that you provide there is not much to suggest, except to just fiddle around a bit. As an example however, if you create a rectilinear panorama from two 35mm equivalent images which have an overlap of about 25 percent, the center will always look a lot sharper than locations further from the center. At the very left and right (assuming a horizontal panorama), the source pixels will be stretched quite a lot, while at the center they might be a little squeezed. If the horizontal resolution of your source images were a 1000 pixels, a very wild guess for the output horizontal resolution would be something like 1750 (2 times 1000 minus the overlap) before details get blown up too much, but the distortions caused by the rectilinear projection would still be visible. On Dec 11, 6:15 pm, ralf i...@planetdsl.de wrote: Hello, rendering a panorama with about 4000 pixel width looks sharp, rendering the same with 19000 pixel (suggested size) it doesn't look so sharp. I used Nona/spline 64. Are there any recommendations? Ralf --~--~-~--~~~---~--~~ 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: Has anyone ever installed hugin in shared web hosting?
What is it that you try to accomplish? Hugin is not a web application... it runs on the local machine. On Dec 9, 7:28 pm, xhe [EMAIL PROTECTED] wrote: Hi, I am wondering if anyone has ever successfully installed hugin in shared web hosting server? Since many libraries are required for using hugin, and in shared hosting server, I won't have admin access right, it may be really a big challenge to install hugin in shared server. Can you share with me your procedure if you ever did it? Thanks in advance. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: Release 0.4 of pvQt pano viewer.
On Nov 20, 9:03 am, Guido Kohlmeyer [EMAIL PROTECTED] wrote: The movement up and down should be blocked on nadir and zenith, because I felt like doing a somersault. Actually I like being able to navigate across zenith and nadir, a feature which I haven't found in any other panorama viewer I've come across so far! Of course it could be added as an option, just like any other restriction in moving around. For instance, a 180x90 degree pano could have such restrictions as well, e.g. horizontal between -90 and 90 degrees, vertical between -45 and 45 degrees, like some other viewers provide. It would be interesting to be able to move around in 3D space relative to the current projection surface as well I think (variable camera position). This could generate some very weird but interesting views I guess... --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: hugin creating random panoramas
On Nov 9, 12:00 am, Erik Krause [EMAIL PROTECTED] wrote: Am Saturday, November 08, 2008 um 14:10 schrieb Bart.van.Andel: After removing these wrong matches, the problem was solved. It took quite a lot of effort to remove all these CPs by hand though. The place to do that is the global control point table (F3). First sort by right image, then sort by left image. Now scroll down and compare image numbers. That is one possible way to deal with it, although maybe not the most intuitive one, having to sort twice first. Using a graph displaying thumbnails of the images and connections between them if Hugin found at least one matching CP, it should be far more easy to see the correspondences found by Hugin very quickly. Especially with a large number of input images. It could be as simple as found in M. Brown and Lowe's paper on Automatic Panoramic Image Stitching using Invariant Features (http://www.cs.ubc.ca/~mbrown/papers/ijcv2007.pdf, top of page 5). compare image numbers. If it is a one row panorama any image n should have control points to n-1 and n+1 only. If it is a 360° one the last image should have points with the first one of course. This is only true of course if the images are taken in order, and it doesn't apply to multi-row panoramas either. Ususally there are few wrong points only, hence you might spot them in the P CP (private control point number) column, too. Ah, that's what P CP stands for. I assume that G CP then stands for global control point? Guess this is one of these examples where tool tips come in handy :) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: hugin creating random panoramas
most of the time hugin forms the panoramas totally wrong and on the preview i get all kinds of shapes and circles and diagonals Could you explain this a bit more, by showing a screenshot for example? I've had a problem recently which kind of sounds like what you're trying to explain, I think. In my case, there were very nice control points between the right images, but also some between images which aren't adjacent at all. This caused Hugin to screw up the alignment completely. After removing these wrong matches, the problem was solved. It took quite a lot of effort to remove all these CPs by hand though. Feature idea: a graph showing which images are matched to which could be a nice idea, with an option to remove edges in the graph, to speed up the process of removing such wrong image match CPs quite a bit. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: Enfuse artifact -- Fairy ring
I've spotted the same behavior with Enblend, while stitching a normal panorama from two images with a slightly different exposure and white balance (auto settings from digital point-and-shoot camera). It happens seldom, and after some tweaking of parameters (can't remember which) the effect was gone, at least visibly. I guess just like Tennevin that it has to do with an overly active vignetting correction, so playing around with that might do the trick. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: A new release of pvQT pano viewer
Hi Tom, I like your program a lot! Even though it's still an alpha, I think it already does quite a good job, and I'm happy you're sharing it with us. A couple of possible displaying improvements though: - Enable anti-aliasing and line blending (for the grid which is displayed before an image is loaded), with a few lines of code like this: glHint(GL_LINE_SMOOTH_HINT, GL_NICEST); // Set Line Antialiasing glEnable(GL_BLEND); // Enable Blending glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); // Type Of Blending To Use - Enable anisotropic filtering. Another few lines of code, see http://www.gamedev.net/reference/programming/features/oglch9excerpt/#Heading3 - I like the way some flash viewers have implemented mouse moving, which doesn't stop moving the image abruptly when releasing the mouse button. But that's probably a matter of taste. Also, it seems that the screen stutters a bit when moving around diagonally using the mouse. It feels like the frames aren't always displayed in the right order. Maybe a buffering issue? Using version 0.3.46 on Windows XP SP3 / ATI Radeon 9600SE with up-to- date drivers (OpenGL 2.1 compatible) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: newbie introduction - hugin usability
I have to agree with 'newbee' and Dale Beams. Hugin is a great program, and I'm quite used to programs which aren't that user friendly, so for me, it's no problem to use it. However, from a usability perspective, certain things definitely should be changed. I think any program which is intended to be used by a large group of people (like Hugin) should be as intuitive as possible. The comments 'newbee' has given, are really worth investigating. In fact, I think he/she tackles the problem quite well. Unfortunately I don't have the time nor the skills (in terms of C++) at the moment (yet) to implement it, but it might really help putting Hugin on the map a lot better. Maybe it doesn't have the highest priority, but in the end, it should be dealt with anyway, so I think we should really welcome such helpful comments on how the Hugin process works. Best, Bart --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: Smartblend: Potential use with Hugin
Great! Bob's bash script (as shown earlier in this thread) should be added as well. One thing in the readme is incorrect: 1. save smartblend-hugin.bat to a known path should be 1. save smartblend-hugin.bat to the path where smartblend.exe resides The script uses its own path to determine the location of smartblend.exe, so they have to be in the same path (either that, or one has to modify the batch file manually to enter the correct path). Concerning integration: it seems Hugin is prepared to use different blenders from the GUI, as the Stitcher tab shows a pulldown menu. It would be most convenient of course if the items in that menu are configurable through the options menu, so Smartblend can show up there as well. For instance like the following: Name: Enblend Type: blender Executable: path\to\enblend\enblend.exe Parameters: --compression=%compression -f %widthx%height+%x0+%y0 -o enblend-%out %in Name: Smartblend Type: blender Executable: path\to\smartblend\smartblend.exe Parameters: -o smartblend-%out %in Name: Nona Type: remapper Executable: path\to\nona\nona.exe Parameters: (whatever parameters apply) Just an idea. Of course you still want most options to be configurable through the GUI, but that's what placeholders can be used for (like %in or %out). On Oct 9, 4:20 pm, Yuval Levy [EMAIL PROTECTED] wrote: Bart.van.Andel wrote: I just adapted Bob's bash script into a Windows batch file Thanks a lot. I've added it to SVN (rev. 3489) and will try not to forget to add it to the next Windows installer. http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/platforms/w... Yuv --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: Could not decode image (JPEG)
I tried to find a file exiv*.* on my computer, but there is none... You won't find or need such a file unless you are building from source. Upon compiling, it is integrated into the program. FieldOfView doesn't seem to be a real tag in the Exif specification by the way; it can't be found in http://www.exif.org/Exif2-2.PDF anyway (specifications for Exif version 2.2). I guess it is computed from other tags. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: Smartblend: Potential use with Hugin
I just adapted Bob's bash script into a Windows batch file, for usage with Windows 2000 and up. Save the script at the end of this post to a file named smartblend-hugin.bat and store it in the folder where smartblend was installed. Usage: 1. Start Hugin. 2. Open File - preferences. 3. Switch to Enblend tab. 4. Check Use alternative Enblend program. 5. Choose smartblend-hugin.bat as the executable (use the full path). 6. Press OK to save the settings. 7. On the Stitcher tab in Hugin, click the Options button next to the Remapper and make sure Save cropped images is unchecked. 8. Enjoy SmartBlend! Script (everything below this line): @echo off setlocal set SMARTBLEND=%~dp0\smartblend.exe set SMARTBLENDARGS= :paramstrip set arg=%1 if not %arg%== ( if %arg%==--compression ( rem Skip compression parameter and its argument shift ) else if %arg:~0,2%==-f ( rem Skip ... ) else if %arg:~0,2%==-l ( rem Skip ... ) else if %arg:~0,2%==-o ( rem Reformat output parameter: add smartblend- prefix set SMARTBLENDARGS=%SMARTBLENDARGS% -o smartblend-%2 shift ) else ( rem Copy other parameters set SMARTBLENDARGS=%SMARTBLENDARGS% %1 ) shift goto :paramstrip ) echo. echo Executing smartblend.exe %SMARTBLENDARGS% echo. %SMARTBLEND% %SMARTBLENDARGS% endlocal --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: Could not decode image (JPEG)
Just curious, and trying to pinpoint the problem. Could you try saving/ converting those images as TIFF first, before loading them in Hugin? As you mentioned, there might be something wrong with loading JPGs with Hugin on your computer, but does loading TIFF work? If not, Exif might not be the problem. If you'd really want to test if Exif is the problem on your computer, you could also try to strip off the Exif data from the JPG and see what happens then. A way to do that is to open the image in an image editor, select all, paste as a new image and save it (of course this isn't exactly the most sophisticated way). --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: Smartblend: Potential use with Hugin
On Sep 23, 6:51 pm, Bob Bright [EMAIL PROTECTED] wrote: For the record: I'm not a fan of closed software. I'm using smartblend (for the time being) only because [...] Actually I emailed Michael Norel (the author of SmartBlend) about it earlier this month, asking whether development had stopped at 1.2.5. In turn, he replied that: It is true, the development of SB is freezed. Just because i have other , very nice projects. At least i'll find time to publicsh sources. Sounds like a nice promise! I pointed him to this group for informing us when he does. Cheers, Bart --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: Huign-0.7.0-rc5 for Windows available
Thanks for posting! Just a tip: to save yourself some bandwidth, you could compress the archive using 7-Zip (7zip.org), which compresses Hugin twice as much as WinRAR does, apparently. For instance, your rc5 file is 19.6 MiB, while the SVN3407 build takes up only 9.26 MiB of disk space. The actual content of the SVN build is actually even a little bigger than the rc5 content, in bytes. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
