[hugin-ptx] Re: questions about cpfind
Am 03.06.2011 08:29, schrieb kfj: Hi all! I have some questions about cpfind: - if my images have been taken with a stereographic lens (I use the Samyang fisheye), will cpfind notice the fact (it's in the input pto) and omit remapping the image, even though the hfov is above the remapping threshold? yes. - cpfind only ever matches image pairs. Other CPGs, like autopano-sift- c, seem to take the feature points of all images together and run one matching step on the lot. If I understand the process correctly, the pairwise approach is more likely to join images which aren't so well- matched, but with lots of images and without constraints like linear matching the pairwise approach is very time-consuming. Is there a chance that the 'match all feature points in one go' approach could be implemented in cpfind? I have implemented a simple version of that, but its not yet commited, as the results are worse than that of the pairwise matching. I'll look into commiting that change. - other CPGs have a 'maxmatches' feature that limits the number of CPs returned. In cpfind the only way to influence the number of CPs gnerated seems to be via the sieve parameters. Wouldn't it be possible to employ a mechanism similar to cpclean to the end result to kick out the 'worst' few points if there are more than the desired number? Yes, that might be possible, but one the simple approach will loose the well distributed characteristic. Maybe some more advanced heuristrics might be found for keeping that, but I haven't thought about that yet. - the documentation is thin when it comes to explaining the sieving mechanism. I think 'buckets' and 'sieves' are technical terms straight out of the matching algorithms, but aren't so easy to understand for someone who merely wants to use cpfind. I'd like to know more about the 'buckets' involved. I think what happens is that the image is subdivided into sections and each section is treated so that it doesn't get too many CPs, or has at least some even if they aren't so good, resulting in a more even spread than if the whole image was looked at. Its something similar to that. There are two thinning filters: Sieve 1: filters the interest points (based on location and interest point strength). This minimizes the computation expense in the descriptor computation and matching steps. Uses sieve1width by sieve1height buckets/sections over the whole image. Only sieve1size interest points are kept in each bucket. Sieve 2: thins the successfully matched points. The rectangular region covered by the matches is divided into sieve2width and sieve2height sections. Note that not the full image area is used here, but the area where matches have been found. Each bucket gets --sieve2size matches (if enough are available) If that is so, wouldn't it be a good idea to look at the aspect ratio of the images to calculate appropriate bucket numbers? This may seem of little use for the standard case of the images being 3:2 or 2:3, but I often have images of greatly varying aspect ratio and a mechanism where I can just say I want, say, roughly 24 buckets spread so that they all cover as-near-as-possible square areas would be helpful. This question is particularly relevant for use of cpfind with woa, where I intend to make cpfind the default CPG, now that the --fullscale issue is settled. That might be a nice feature, so one specify the number of buckets for the larger dimension and computing the number of buckets for the smaller dimension based on the aspect ratio. - in woa, I use pre-warped images and feed them to the CPG. The iamge pairs cpfind gets to see are therefore quite similar geometrically. What ransac mode should I use? So far I have set hfov to 30 and projection to rectilinear for all my prewarped images - after all I have already warped them to be geometrically compatible and I dont want them to be reprojected in any way - so the mode chosen would be 'hom'. Would I maybe be better off with 'rpy'? Both should work. If you just want to allow shift and rotations 'rpy', together with a small fov (10) would be best. the homography will also allow shearing and mirroring, which is probably not needed for your case. cpfind (and SIFT and related algorithms in general) are however not ideal for the refinement of matching points, as it expects precisely repeatable interest point detection. A direct, intensity based matching is preferrable for that case, for example Least square matching. http://www.photogrammetry.ethz.ch/general/persons/AG_pub/ALSM_AWGruen.pdf This typically yields points with an accuracy of 1/10th of a pixel. The drawback is that is requires good initial approximations (~2 pixel accurate) of the relative orientation of the images. It would be a good refinement technique for inclusion into cpfind and the hugin control points tab. ciao Pablo -- You received this message because you are subscribed to the Google Groups Hugin and
[hugin-ptx] Re: enfuse for tonemapping of a single RAW
Hi Bruno, Am 07.04.2011 20:20, schrieb Bruno Postle: On Wed 06-Apr-2011 at 23:54 -0700, Jeffrey Martin wrote: If I knew what a standard response curve looked like as EMoR parameters then I would suggest that Hugin used it as a default. Currently we use 0,0,0,0,0 which doesn't correspond to any real camera. Thats something like the mean response curve of all cameras/films that where used to derive the EMoR model, so it should be a good start. 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: [REVIEW] Pushing Hugin changes to VIGRA upstream
Hi Lukas, Please review them and comment on them, because I'd like to send them to the upstream soon. I'm not sure about copyrights in some cases (eg. canvasSize patch) but I think most of it is Pablo's work. I'll look it up in the subversion history. great, looks good, feel free to submit those to vigra! 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: How should the 'Grey picker' work?
Hi kfj, Am 04.03.2011 10:23, schrieb kfj: On 3 Mrz., 19:26, Pablo d'Angelopablo.dang...@web.de wrote: But just throwing in a new free lunch feature without documentation for everyone to figure out how it works by trial and error isn't what I consider good style. For example, it took me quite a while to figure out that to see any effect of the grey picker at all, I had to remove the 'photometric' check mark in the preview. It looks a bit like a quick shot to me. I haven't tested the gray picker yet, so I can't comment the ease of use. Having to fix 8 bit images with a second application of a curves tool will degrade the image quality, if 8 bit images are used. I agree, and, sadly, 16bit isn't yet an option for everyone and increases processing time and memory use considerably. The resulting degradation from successive processing steps may become quite noticable. So there's another good feature waiting: how about an option to convert to 16 bit on input and/or convert to 8 bit on output? Or am I missing something here? All the internal processing during remapping is done in floating point, so no need to convert 8 bit to 16 bit before input. The only drawback is that enblend will work on the 8 bit images. When I process my 16bit TIFFs with hugin, I'd quite like to be able to get 8bit TIFF out, but it seems like I can only store in 16bit. I think that on the pto file level, the output bit depth can be specified, but I don't remember if the up or down casting done there is useful for your workflow. Second, I haven't found any free image processing application performs white balancing as good as hugin. That said, a gimp or other plugin with the same algorithm would be nice ;-) You seem to imply that hugin uses a special white balacing algorithm. I always thought white balance was merely putting a linear scaling factor on the magnitudes of the red and blue channel compared to green. Other tools might do this. For a RAW converter this makes sense, but not for already processed photos, such as JPEGs. Try adjusting the color balance of a JPEG using linear scaling in GIMP or some other software. I found that nearly impossible without introducing various color distortions (not only related due to the missing dynamic range). Hugin estimates the camera response curve, much like proper HDR tools do, and respects that during white balance adjustments, see the paper at http://hugin.sourceforge.net/tech/ for more details. And, while asking for documentation, is the openGL preview considering the colour profile of the monitor, and does it do so an all platforms, be it via the OS or by itself? Otherwise white balancing would merely make the image look nice on that particular screen in the hugin preview. As far as I know, hugin is ignorant of color profiles, other than passing them through. It would be nice to have a calibrated workflow, but this doesn't mean that tools for color balancing (and especially a gray picker) are completely useless. 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: How should the 'Grey picker' work?
Hi Kay, Am 03.03.2011 18:34, schrieb kfj: Hmmm... I'm very much in two minds about features like this. I feel that image processing functionality should be kept out of hugin. Of course we need to align the images photometrically, but manually finetuning the white balance is close to where I'd draw the border. I don't think so. Its basically a free lunch, and one that makes technically sense, too. Having to fix 8 bit images with a second application of a curves tool will degrade the image quality, if 8 bit images are used. Second, I haven't found any free image processing application performs white balancing as good as hugin. That said, a gimp or other plugin with the same algorithm would be nice ;-) 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: Region of Interest (ROI) for Control Point Finding/Image Alignment?
Am 13.02.2011 16:25, schrieb kfj: On 13 Feb., 11:13, Jeffrey Martin360cit...@gmail.com wrote: I was thinking also... for panos, the centers of images usually do not overlap. isn't searching the WHOLE of images a big waste? There is another aspect which becomes more important with fisheyes and stereographic images: if you feed the CPG with a partial image, it can't decipher the warp to adapt it's feature point detector: the image geometry is quite different from center to margin. So you can't just use partial images, but you have to use the whole images and mask them appropriately. Masking means introduction of additional data into the process, either in the shape of a separate mask or as an alpha channel. Using an alpha channel might be a reasonalbly inexpensive and transparent (hah) way of doing the needful, but I'm not sure if the current CPGs honour alpha channels - I rather doubt it. cpfind does honor alpha channels and masks defined in the pto file. It removes any matches found in the alpha channels (this is needed for remapped images, otherwise one could get false matches at the corners/edges of a remapped image.) It will still analyse all parts of the image, though, so there is not much computational benefit. I think the typical savings are not really worth the coding effort. I am currently toying with this mechanism for use in another demo plugin, but I want to throw in rewarping of the parts of the images that correspond to the ROIs to a common projection to make them geometrically as similar as possible, thus improving CPG performance especially with fisheye images and avoiding warp-related CPG problems - some sort of high-end matching which would produce very good quality, well-distributed CPs, particularly for applications like lens calibration. Yes, something like that would be very nice. Or one could try Least squares matching. (estimates local affine transformation as part of the matching process, is typically accurate to ~ 0.1 pixel). However, it needs good initialisations (1-2 pixels error, good estimate for the initial affine transform). 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: cpfind ransac mode
Hi Jeffrey, Am 07.02.2011 23:10, schrieb Jeffrey Martin: I'm quite swamped with real work right now, so I don't have time to work on cpfind for the next weeks. HI Kay, a bunch of nice ideas! comments below On Monday, February 7, 2011 3:34:25 PM UTC+1, kfj wrote: If I could tell the CPG to scale all images to, say, 50 pixels per degree overall, I would achieve precisely the effect I want by specifying one single parameter. It'd make things so much easier for mixed-lens takes. ok, with a minimum image width of say 320 (long side), this would be great, i think. The FOV normalisation is a nice idea, but I needs a bit more effort than a simple scaling. I know that theoretically SURF and SIFT features are (quite) scale- insenstive, but my experience tells me that this truth only goes so far. I'm not sure how scale-insenstive the gradient-based detector in cpfind is. But I feel that implementing my proposition might be easy and it'd give us the opportunity to see if this might be a cheaply bought improvement in performance. It should perform similar to SURF in that respect. The idea is to run the process on smaller images and once the orientations are established, to replace the images with full scale versions and have all pto parameters that build on image coordinates rescaled. I wrote this because I wanted to work on the screen-sized images I carry with me on my laptop and apply the results to the full- scale images back home with the fat data corpus. It works, and surprisingly well. The scaled-down versions are usually a fair bit crisper than the full-sized images, so there is enough detail for the CPGs to work on - and since the feature detectors produce subpixel accuracy, the scaled-up pto often stitches without any need for further intervention - if you want you can run a global fine-tune on the CPs. Note that a global finetune is not really the best thing, as most of the control points found by cpfind/panomatic/sift will be in some higher scale, and the finetune only uses a small window for correlation. The next idea, to look at the overlapping parts once the overlap has been roughly established, is also promising and heas been previously exploited, though I'm not entirely sure where the code is. The --multirow option of cpfind does that. Another interesting aspect along these lines is to warp the overlapping parts of two images to a common projection and run the CPGs on those warped partial images, to later retransform the CPs to original image coordinates. This has also been done, and I've experimented with it myself, but found the gain not so noteworthy as to make me want to investigate the matter more deeply - do you want some 2000 image panos to test it on? in that case the time savings might be very significant. what I mean is, sure for panos containing 4 or 10 images this just won't matter but for gigapixel images it might save minutes or hours. Have you tried the multirow mode of cpfind for this type of panoramas? It was specially designed for that, and should be faster than doing a miniature pano and then reusing the overlaps, as it first matches only the consecutive images, connects strips, optimizes and then looks for control points in the overlapping images. I don't have such a large pano, so I don't have much experience with it, though. 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: can't build latest hugin from source on ubuntu (error with flann_cpp_s)
Hi Jeffrey, Am 27.01.2011 23:42, schrieb Jeffrey Martin: I'm trying to build hugin from source, on Ubuntu (I installed Ubuntu today) After some missteps with getting the latest pano13 compiled, I finally got to building Hugin, but now I'm getting this error: [ 36%] Built target flann_cpp_s Scanning dependencies of target flann_cpp make[2]: *** No rule to make target `src/foreign/flann/CMakeFiles/flann_cpp.dir/build'. Stop. make[1]: *** [src/foreign/flann/CMakeFiles/flann_cpp.dir/all] Error 2 make: *** [all] Error 2 If anyone can explain what to do, it would be very much appreciated :-) I haven't seen that error (I'm using ubuntu maverik). The only difference is that I'm using a separate build directory. I usually do something like this: $ cd hugin.hg $ mkdir build_release $ cd build_release $ cmake .. $ make 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: cpfind ransac mode
Hi Kay, Am 24.01.2011 18:12, schrieb kfj: J. Martin asks so your standard 6 shots around and 1 shot up pano (fullframe fisheye) where the up shot has been rotated to landscape orientation by the camera - this should not pose any problems for hugin? I'd say - not really a problem, but if the first six are portrait and the up shot landscape, if it's a manual lens (like my Samyang) I have to tell hugin every time it's the same, even if the image dimensions are the same to the other shots.More a nuisance. I have to have two lens.ini files handy, or go through the dialog every time of 'do I want to accept the parameters even though the image dimensions are different'. So all your image are physically in Landscape mode (i.e. width height)? Then hugin should ask only once, otherwise its a bug. Pre-rotating the images outside hugin is not a good idea. Even if hfov and a/b/c parameters are applicable, what about the shift parameters d/e? Left or right rotation makes a big difference here, and there is no reliable way for hugin to figure that out. 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: Where to get a nightly build for windows?
Hi Can, Am 24.01.2011 09:20, schrieb Can-C. Dörtbudak: Hi guys, could anyone please tell me, where i can get a development Version of hugin like 2010.5 something? As far as I know, nobody produces nightly builds for windows. Some outdated information on building hugin for windows is available on the panotools wiki: http://wiki.panotools.org/Hugin_Compiling_Windows I don't use Windows anymore, so I can't help with building. Even for experienced Windows developers, it might be easier to install linux and build and run hugin there... 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: Test case for cpfind
Hi Yuv, Am 23.01.2011 15:10, schrieb Yuval Levy: Michel's test/challenge was for this to work out of the box and I did not have time to investigate further. I realize now when running Exiftool that it reports 0mm focal distance; and that Hugin sets the focal length to 50mm by default, even if the exif data reported 0mm. Maybe we should change that and instead of assuming a default, ask the user? Actually, the exif data in these images is inconstent, and reports 0 and 50 mm, so hugin believes it is 50 mm... $ exiv2 IMG_0114.JPG ... Focal length: 50.0 mm ... $ exiftool IMG_0114.JPG ... Field Of View : 40.5 deg Focal Length: 50.0 mm (35 mm equivalent: 48.8 mm) Lens: 0.0 mm (35 mm equivalent: 0.0 mm) ... I fear that we can't really fix that. Long live EXIF. 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] cpfind ransac mode
Hi all, panomatic and thus cpfind use a RANSAC step for outlier removal. This used to be based on a homography, which works ok for non-wide angle images. It breaks for fisheye images, here a large error tolerance must be choosen, and this results in a rather weak outlier check for wide angle and fisheye images. Additionally, the homography is more general than what we expect for panoramic images (it can also mirror images, for example), and this can result in some false matches slipping through, even when a relatively strict RANSAC threshold is choosen. Unfortunately, this can sometimes connect unrelated images together, and cpclean doesn't help as it won't remove all matches in an image pair. I have thus implemented a new RANSAC model that can make use of the restrictions we have in panoramas, and also include prior information about lens type, HFOV and distortion etc. Basically, it tries to estimate roll,pitch and yaw for each image pair (using two control points), and checks if the remaining points are consistent, and repeats that a few times. A new --ransacmode parameter can be used to switch between the ransac modes. By default it uses the homography and switches to the roll,pitch,yaw model if the HFOV is bigger than 65 degrees, the same value that is used to decide whether to remap to stereographic or not. For testing, the HFOV can also be estimated in the RANSAC routine, but this is quite fragile due to panotools problems with estimating HFOV on image pairs. Some examples: --ransacmode rpy (new) http://www.flickr.com/photos/vonengel/5378995090/ --ransacmode auto (default mode, uses homography) http://www.flickr.com/photos/vonengel/5378994908 Unfortunately, in some cases, the HFOV is not know very well (incomplete EXIF data, bad crop factors entered by the user etc...), so one cannot unconditionally recommend --ransacmode rpy. It might be possible to work around that problem, but it will require some significant work, and I'm not sure if it worth it. For the user that means: 1. User has a good estimate of the HFOV (EXIF Data or prior calibrations) - use cpfind --ransacmode rpy which makes cpfind virtually bullet proof to really bad mismatches. 2. Bad EXIF Data and user doesn't know about crop factors or the like - use cpfind --ransacmode auto (the default) or cpfind --ransacmode homography, and accept some outliers. I hesitate to default to --ransacmode rpy, as this will probably lead to quite some breakage for novice users, who enter bad crop factors. I find 2. a bit unsatisfying as it means that we will get suboptimal results for many inexperience users (and many experienced ones too, who don't know about all the cpfind internals...). Whats your opinion about that? - Should we add more default presets to the control point detector preferences? - Try to automatically add --ransacmode rpy, if the hugin could successfully read HFOV from the EXIF data? - Try to robustly add HFOV to the RANSAC model? Maybe just trying a range of initial HFOVs would be sufficient... However, I'm not sure if I can do that with my limited time budget. Another way to reduce the problem would be to use a camera-crop factor database, such as the one from Autopano PRO: http://www.autopano.net/wiki-en/Cameras.txt 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: Cpfind for Dummies
Hi Carl, On 21 Jan., 09:07, Can-C. Dörtbudak doertbu...@googlemail.com wrote: same problem for me. I've tried the fullscale option and sieve1size etc. as well. I can't find control points in the pictures of my walimex fish eye. If somebody wants to verify this here is the link to the pictures:http://www.doertbudak.de/test_can.zip I just tried your images and it worked fine with the current development version, and the default cpfind settings. Hugin 2010.4 will NOT work, you need the most recent development version (harrys latest OSX build might work too, although it doesn't yet contain a proper RANSAC for fisheye images). I did the following steps: 1. Load images 2. Set full frame fisheye, HFOV 3. Press Align button And this properly connected all images, even though the overlap is quite small. 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: Cpfind for Dummies
Am 20.01.2011 10:48, schrieb Jeffrey Martin: Hi Pablo, Thanks for the explanation. A couple questions and clarifications: On Wednesday, January 19, 2011 10:46:59 PM UTC+1, Pablo d'Angelo wrote: Yes, it should. I have seen that the circle in your example was a bit offset. This might be related to the center on d/e in the crop panel. This means that the circle is always centered on the d/e parameters, which worked nicely with my peleng. If bad d/e parameters are used, the circle will be shifted. You could try without the center on d/e. with my example, the vertical offset is about 100 pixels - due to the lens being on an adapter, maybe. anyway, You can savely untick the center on d/e, then you move the crop circle freely. I filed a bug report about this yesterday. https://bugs.launchpad.net/hugin/+bug/704884 I can confirm that. I tried searching for the right spot in the code, but I'm not very familiar with the refactoring that James had done on SrcPanoImage class. Where can I insert a hook for intercepting changes to the d/e parameters? Maybe some other Developers (Thomas, James?) can give me a small hint. i am using the command line to do this stuff, is this maybe where my problem is? Can you give a summary what you have done (in hugin and on the command line?) 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: Cpfind for Dummies
Hi Bloddy, Am 17.01.2011 17:52, schrieb bloody tomatoes: Hello, I'm reading this http://wiki.panotools.org/Cpfind and i have a few questions: 1) The default settings of cpfind - this is the best setting for normal (non-fisheye) images? or it's probably good enough but as cpfind is very new, it could use more testing? I did test the default setting (cpfind as in hugin-mac-2010.5.0-4854_d29b1d6da0e0 by Harry) mainly on different fisheye images Jeffrey send me, and they worked fine. In general, I think the settings are fine for most panos. If you have examples where the default settings fail, please let me know. 2) What does --ransaciter and --ransacdist do (in plain english) ? Part of the ransac based outlier removal, see http://en.wikipedia.org/wiki/RANSAC Basically it tries to optimize an image pair and keeps only matches which have an error smaller than ransacdist. Setting this too strict will remove more matches than nessecary. Values between 10 and 50 are probably good. The current implementation in cpfind is a bit crude and works best for normal images. Wide angle and fisheye images are currently not handled well, and the ransacdist is currently increased if that happens. I'm working on a proper solution though. 3) To achieve good control points images with a high horizontal field of view (e.g. ultra wide rectilinear or fisheye) are therefor remapped into a conformal space (cpfind is using the stereographic projection http://wiki.panotools.org/Projection#Stereographic_projection) and the feature matching occurs in this space. how does cpfind decide what to remap to conformal space, or not? or is it depending on the lens type? (rectilinear no, fisheye yes) ? All images with a hfov 65 are remapped into stereographic (unless they are already stereographic, as the Samyang 8mm fisheye is, so choose stereographic as input projection if you have a Samyang 8mm fisheye.) 4) When doing linear and multirow matching, does it try to join the images in a 360? or only the first/last image? or not at all? I'm not sure on the linear matching, but the multirow matching will try to connect all overlapping images. However, it might not work if the roll angles of the images change a lot, as overlap is only computed on a pano where yaw and pitch have been optimized. That is probably fine for large multirow projects shot from a panohead, but maybe not so great for hand held sphericals with wide angle lenses... 5) Changing --kdtreesteps and --kdtreeseconddist affect the final number of keypoints found. is there anything more specific that should be known? or should these numbers stay as they are (i'm guessing they should be played with, since the parameters are there to be played with!) Larger kdtreesteps tell cpfind to look harder for matches. I think 200 is probably good enough, but it could be improved. Not so important. kdtreeseconddist determines how similar corresponding matches need to be. Smaller values force cpfind to accept only unique matches, larger values accept more, but potentially bad matches. If no points can be found, increasing this to 0.4 or so might be worth a try, but there will be more errors. 6) Is there any good reason to have --sieve1size at 30 and not 3000 (more is better) ? More is also slower... Sievesize 3000 basically means take all features found. 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: Cpfind for Dummies
Hi Jeffrey, Am 19.01.2011 22:23, schrieb Jeffrey Martin: Thanks Pablo for the detailed explanations. By the way, with these photos, I am still getting CP's outside the cropping circle. does anyone have any idea why that would be the case? www.vrlog.net/temp/cpfind-pablo/bad-cp-shaved-nikkor.zip http://www.vrlog.net/temp/cpfind-pablo/bad-cp-shaved-nikkor.zip questions: 1) is cpfind using the lens FOV to calculate CP's? (as autopano sift C does) (only FOV? or also a/b/c ?) It uses the full information (including a/b/c), crop circle and masks. 2) is cpfind supposed to use the crop in hugin (so that there should not be CP's outside the crop)? Yes, it should. I have seen that the circle in your example was a bit offset. This might be related to the center on d/e in the crop panel. This means that the circle is always centered on the d/e parameters, which worked nicely with my peleng. If bad d/e parameters are used, the circle will be shifted. You could try without the center on d/e. I haven't added any safety margin for the crop in cpfind, so the the crop circle should never be outside the image. So far I used the following procedure for fisheye panos: 0. (Do only once:) Enter Preferences/control point creator. Create a new cpfind detector entry change the default cpfind entry to use only the -o %o %s arguments and make it the default. (multirow might or might not be suitable for this purpose..) 1. Load images into hugin 2. Select fisheye and enter focal length and crop factor 3. Set crop on all images. 4. Press align button 5. (straighten + look for bad control points), optimize with a,b,c, d,e if required. 6. save lens settings for later usage. Once you have saved your lens, you can load the parameters and crop with the Load lens button, and skip step 2 and 3. 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: hugin plugin interface - developers please liaise
Hi Kay, Am 19.01.2011 10:04, schrieb kfj: hg export 4852:bf77427fe623 4853:9de97bcfd3b2 patch4853 gzip patch4853 I hope this is just what you need and convenient enough to use. Echoes welcome. From http://mercurial.selenic.com/wiki/Export, it seems that hg bundle is the preferred way for contributing changesets. I have tried to import your changes into the sourceforge repository using hg import, I hope it worked fine. 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: cmake help needed for python interface
Hi Thomas, Am 18.01.2011 19:24, schrieb T. Modes: But I found an issue: I can not access the image variables of SrcPanoImage like getImage(0).getYaw() and so on Thats probably because these functions are defined using some macros inside Panorama.h. Maybe swig needs to call the C preprocessor or we need to call swig on an already preprocessed Panorama.h. 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: hairy bug: control points outside image crop circle
Hi Tomato, On 17 Jan., 16:03, bloody tomatoes bloodytomat...@gmail.com wrote: using the latest hugin (2010.4) and cpfind, i have many control points outside the circle used to crop my images. the cpfind included in 2010.4 unfortunately performs quite badly on fisheye images. Yesterday I did commit quite a few fixed that will boost performance with fisheye images a lot, it might be helpful to wait for a new OSX prerelease binary. Unfortunately I don't have fully circular fisheye images, and I haven't tried cpfind on those. Can you post an example somewhere? I'd like to use that for tuning cpfind. 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: hairy bug: control points outside image crop circle
Hi all, unfortunately, there is still a bug in cpfind, which prevents it from processing fisheye images with a fov 170 degrees or so.. I'm working on a fix. ciao Pablo Am 17.01.2011 22:13, schrieb bloody tomatoes: Harry, this build [OSX] New hugin-mac-2010.5.0-4854_d29b1d6da0e0 incl. Thoby projection, new cpfind and gsoc 2010 panorama projection contains Pablo's newest changes? i was under the impression that those changes were only made in the last day or two. -- 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 -- 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: hairy bug: control points outside image crop circle
Hi Tomato, Am 17.01.2011 18:12, schrieb bloody tomatoes: Hi Pablo, I have sent you the files. Let me know if you received it ok. I got the files, thanks. I did fix some cpfind issues with circular fisheye images. With the new fixes I didn't get points outside the crop circle. Btw. you should really calibrate your panohead, there was horrible parallax in your example images. Still they were sufficient for testing cpfind. 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: Show Stopper? (was Re: Re: 2010.4.0-beta1 Win32 test)
Hi all, Am 25.12.2010 19:26, schrieb Yuval Levy: I have started a tracker ticket: https://bugs.launchpad.net/hugin/+bug/694329 I have improved cpfind to be much more reliable when using fisheye images. Most tests so far have been positive, except for images with very little overlap. If there are still problems with the latest development version (hg: 3da7ecaa2dea), please comment on the above bug request. 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: cpfind rocks!
Hi Tom, Am 16.01.2011 23:28, schrieb Tom Sharpless: Great. Now please, publish a URL for a current windows release package. Everyone says it exists, no-one will say where :- I'm currently running 2010.2. Got cpfind from a zip of 2010.3 (bin directory only) that has defective Hugin, but working cpfind. Sorry, I don't use Windows, but I have just commited some major improvements to the feature detector used by cpfind, so anything from 2010.3 is a bit outdated (and I'm suprised that it worked so well for you). 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: what should be in the scripting interface? please have your say!
Hi Kay, Am 10.01.2011 12:39, schrieb kfj: I have set out creating a scripting interface for hugin. Great, I think that hugin can benefit greatly from such an interface, both for custom utilities, as well as quick prototyping of new ideas. So the next thing that I feel needs to be done before I proceed is this: - decide which part of the hugin functionality should be scriptable In addition to the basic Data model (as you seem to have done already), the algorithms in hugin_base/algorithms might be useful for scripting workflows. Here, maybe only the static driver functions are required in the scripting language as the multi step approach (custruct algorithm object, call runAlgorithm() get the results out of the object) is probably quite a hassle when writing scripts. Btw. is your code available in some repo? Maybe a new hugin_scripting branch would be a good idea. The next step, the 'mechanism to use scripted content from hugin', would require code linked into hugin to interface with a scripting language, enabling stuff like 'plugins'. That would be especially helpful for customizing workflows etc. If the integration also extends to wxPython, new GUI functionality could be quite easily prototyped or even implemented in python. 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: idea for CP deletion
Am 06.01.2011 19:03, schrieb kfj: Bruno, thank you for your advice. I have started out on a new project towards the goal of eventually providing a scripting interface for hugin, that would be really nice! I once tried with boost::python, but I hit some strange roadblocks, which prevented me from creating a useful interface... I've run into another problem with finding the CP errors here - if I call the optimizer on the Panorama object, the errors are filled in, but now I wonder if there isn't a way to just ask for the calculation of the distances without actually optimizing the CPs? After all, if the transformations for the images are known, the distances should be calculable without optimization. cpclean also calls the optimizer, probably because it had the same problem? I don't think there is a ready made function for computing the distances inside the hugin source. The distances can also be computed using the PTools::Transform objects (transform both points from input image coordinates into panorama space equirect and compute the great circle distance (haversine formula) there. Note that the distances depend on the output image projection and size. 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: ptmender or nona?
Am 04.01.2011 20:24, schrieb dmg: oh, if I remember correctly, nona does multithreading. But I am not an expert, so I'll let Pablo and those who know nona describe it. Yes, nona is multithreaded. As far as I know, ptmender doesn't perform the photometric (vignetting white balance) corrections as nona does. 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: Declaring 2010.4.0 final
Hi all, I have found that the integrated control point creator fails when images are rotated with respect to each other, which might be problematic with handheld and wide angle/fisheye images. I haven't tried many panos, so I'm not sure if I just was unlucky or if it only affects a few projects. I will investigate and hopefully fix this in the first week in 2011. Not sure if this is a blocker or not. I quickly skimmed the hugin list, but haven't found much on the cpfind performance, except that it didn't work for Jan Martin. ciao Pablo Am 30.12.2010 01:33, schrieb Yuval Levy: Hi all, is there any reason not to declare 2010.4.0 final? I see a Windows distribution (thank you Matthew), an OSX distribution (thank you Harry), a Fedora distribution (thank you Terry). I see a Debian experimental distribution [0] and must have missed Andreas announcement. Will get Ubuntu going in the coming hours. My intention is to declare 2010.4.0 final December 31 before popping the Champagne. Yuv [0]http://packages.debian.org/experimental/hugin -- 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: Blending very large numbers of files
Hi Matthew, Am 16.12.2010 18:49, schrieb Matthew Gates: An example DSS plate .tgz cab be found here: http://porpoisehead.net/misc/S357.tgz (13 meg) There are many of these files 1792 of these files - the one above is the smallest. Total size ~65 gig! I love me some hefty data. :D Is there a summary of the production process for you data? I assume the following: 1. You got the tiled DSS plate files from some observatory. 2. You have some software to reproject the tiles into TOAST. If you want to try the hugin vignetting correction, one needs to know corresponding pixels between the overlapping plates. There are two possibilities: 1. Add support for the input image (plate) format to hugin, and write a script that creates a PTO file from the metadata in the plate files. Then the standard workfow could be used (on the x64 images). The corresponding parameters could then be used for radiometric correction of the individal plates. If we add the toast projection, to panotools, it would be possible to directly output toast, otherwise its possible to produce corrected plate images. 2. Keep all the geometry stuff outside hugin and produce a input file for hugins vig_optimize tool with corresponding pixels within your software. This should be a simple text file with the following format: img1_nr img2_nr x1 y1 x2 y2 r1 g1 b1 r2 g2 b2 0 radius_1 radius_2 0 where r,g,b are the respective RGB values and radius is the distance from the center, divided by the distance to the edge (if I remember correctly). Together with a fake pto file, this could be feed into vig_optimize to determine the correction parameters. Looking at http://porpoisehead.net/images/dss_blend_needed.jpg I'm a bit sceptical how well it might work with hugins vignetting correction though. Do you know if the position of the plate in the telescopes focal plane is available in the metadata? Do you have a document describing the metadata? The x64 directories in the .tgz files might be useful here, as they are full-plate at low res. We could maybe extract these, experiment with blending and even stitch them together into a panorama to check it. 1792 300x300 tiles isn't so bad. I can do the extraction of this data on the server and create a single archive file which should be a manageable size. For a first experiment, a smaller subset of the mosaic would be sufficient, maybe a 5x5 grid. For this test, the alignment could be done in hugin to avoid the steps I have mentioned before. The full data will be a real challange, even when using the tiny images. The full mosaic would be much simpler, if we had a reference image that covers the whole mosaic. It only needs to contain the background brightness, not all the stars etc. This would make the vignetting correction much simpler and probably yield a nicer result. 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: Hugin parallelization
Hi Markku, Am 05.06.2010 13:40, schrieb markku.kol...@iki.fi: On 5 kesä, 09:33, Lukáš Jirkovskýl.jirkov...@gmail.com wrote: OpenMP isn't supported in the Express edition of VisualC++, you need at least the Professional version to use it: http://msdn.microsoft.com/en-us/library/hs24szh9%28VS.100%29.aspx This will cause problems for Windows users that want/need to compile Hugin. Not really, if OpenMP is not mandatory (Which should be easily possible). Users of the Express edition won't get parallel support though. As parallelizing with OpenMP is really so much easier than with explicit threads, I think the missing support in the free Microsoft compiler should not stop Linux or OSX users from using all their processor cores. 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: Hugin parallelization
Am 04.06.2010 15:42, schrieb Lukáš Jirkovský: Hello, today I decided to improve the performance of deghosting in hugin. First try using SSE didn't work really well [1]. Did you check that your data was properly aligned for use with SSE? Second one using OpenMP show noticeable increase of performance, because the code can be parallelized quite easily (the only thing needed is to add two pragma's) and efficiently (it runs four times faster on my Core i7). I can see that the most of the threaded code in Hugin uses boost::thread but I remember that the thread class from wxWidgets was also mentioned. What should I use? Personally I'd like to avoid wxWidgets threads because both deghosting_mask and hugin_hdrmerge are console applications. If OpenMP works fine for you, go ahead and use it. When I parallized the remapping with boost::thread, OpenMP was not properly supported by gcc, but this has changed since then. If you need generic thread support use boost::thread, except if it tied to the wxWidgets UI, where wxThreads might be more suitable for some tasks. 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: patent-free panomatic: segfaulting on 64bit MacOSX
Hi Harry, Harry van der Wolf schrieb: Hi, 2010/4/23 Pablo d'Angelo pablo.dang...@web.de mailto:pablo.dang...@web.de I had already built a debug version. I hoped that would create a better crash report. First a gdb run starting panomatic (I renamed it back) without parameters: Hmm, if the crash happens even without arguments, then it must be something very early in the program. I tried reproducing it on my machine (64 bit linux), but I couldn't find any problem with valgrind. Unfortunately, the your backtrace is very strange, and I don't see any symbols from panomatic in it. They all seem to be from the system linker. The first thing panomatic does is to print its usage: Pan-o-matic 0.9.4 by Anael Orlinski - nao...@naouel.org It seems that you don't even get this message, so the problem occurs before the main() function is executed. This could be due to the instantiations of some global C++ objects, which is are created before the main() function is executed. I think this mostly happens in the zthread library. Maybe there is something wrong with the way I use CMake to build the zthread library. The keypoints program doesn't link to zthread, can you try running this and see if it also crashes? 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: patent-free panomatic: segfaulting on 64bit MacOSX
Hi Harry, Harry van der Wolf schrieb: Hi, I tried to file a bug via the tracker on https://code.launchpad.net/~pablo.dangelo/hugin/panomatic-lib;, but I can't find how to do that. Has the Launchpad bug tracker been activated for panomatic-lib? I haven't looked at the bug tracker setup on launchpad yet, probably that needs some more work. In the long term, this will be merged in the hugin source tree anyway. When starting to run a 64bit (x86_64) version of the patent-free panomatic it segfaults. It doesn't matter whether I start it with options or without options. Please note that panomatic is referred to as patfree-panomatic as I renamed it to patfree-panomatic to prevent confusion with the other panomatic. Ok, so it crashes also if invoked without images? Can you post the detailed steps (commands to run) to reproduce the bug? I copied the crash report into to this mail. I hope it makes sense to the experts as it doesn't to me. Not really. the best thing would be a compilation in debug mode (set CMAKE_BUILD_TYPE to Debug), and run it under gdb: $ gdb patfree-panomatic $ r -o crash.pto image1 image2 ... ... $ bt That would help a lot! 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: [OSX] Hugin 32bit vs. 64 bit and the way to go forward
Bruno Postle schrieb: On Mon 19-Apr-2010 at 14:17 -0700, Battle wrote: So where are my bottle necks? The optimization process in hugin proper in the 32 bit build seems slow. On smaller projects of 10 to 20 images the optimization tab can take almost as long as actually stitching the project. I don't know whether a 64 bit version of the Hugin UI would address this or if this is an issue with another sub program. Since I don't know where the optimization is taking place or if it is multithreaded or otherwise optimized for multiple core machines I think its not possible for me to answer whether a 64 bit build of Hugin is useful. Yes for big projects the optimisation is a bottleneck as it is single-threaded. As far as I know there is no plan to make this multi-threaded, or even if it is possible. The best way to speed up the optimisation is to exploit the problem structure when doing the optimisation. Currently a general purpose nonlinear least square minimiser is used in libpano This is very inefficient for large problems where the variables are only sparsely connected. A sparse levenberg marquardt algorithm would work wonders there. There is a fast implementation for 3D reconstruction problems that could be adapted to optimize panoramas http://www.ics.forth.gr/~lourakis/sba/. However, it is too inflexible (all pictures can only have the same number of parameters, no linking of parameters possible) for use within hugin or libpano. 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: Can I join?
Antoine Deleforge schrieb: Hi Antoine, Thanks for your clarification Bruno. So if I understood well, the idea here is just to assume that consecutive pictures will likely overlap, since users usually take pictures consecutively along rows/columns while shoting their panorama. What I was mentioning was more about doing some fast pre-computation to eliminate pictures having a very low probability of overlapping. Maybe we could use some simple geometrical properties of the set of control points within each picture (eg. density of points, alignments) in order too set aside unlikely pairs. However, I don't know if this has be done before nor if it is relevant to the project. This would be mainly useful for panoramas composed of a high number of images (eg 300): instead of using ANN 90,000 times during the matching phase, it would eventually be computed only for likely overlapping pairs. There are two different strategies for matching: pairwise (panomatic does this), or by placing all feature vectors in a big kd-tree (autopano-sift does this). For a really large and completely unordered images, techniques like vocabulary trees are used to find candidate matching pairs. However I don't think that we need to go into this direction. The feature matching should be included in the hugin source, so that it can leverage all the libs available (projections for ransac, optimisation and exif reading in the base hugin code). We had a GSoc project in 2008, which has just implemented the basic feature matching part (both the pairwise and global ANN matching state), but it was based only on the not so well performing matchpoint descriptor, so it wasn't merged in. 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 To unsubscribe, reply using remove me as the subject.
[hugin-ptx] Re: Repository
Hi Yuv, Yuval Levy schrieb: Hi Pablo, On March 20, 2010 02:41:16 am Pablo d'Angelo wrote: I think that moving to mercurial would good, and now is the right time to do so. OK, let's try to fix what still needs fixing. I can see the value in keeping a subversion repository, but I dislike keeping the SVN repo as the central repository for our branches. (Ie, no developer will have/use an SVN checkout in any way). I think we should keep it at least for historical / documentation purposes. Can stay unmaintained, i.e. revoke write access to everybody and put a note that the code has migrated to Hg. Yes, I would leave the svn that way (and maybe commit some lines to the CMakeLists.txt file in the svn repo that prints a warning message and breaks compilation unless it is removed). When I switched from CVS to SVN, I didn't keep a CVS mirror. It might not be completely comparable to the current situation, but I don't remember any complaints. most of the CVS history seems to be available in SVN, while in the migration from SVN to Hg so far I have three options: a) hugin/trunk only, with all revisions from about 24.. (when Ippei's GSoC 2007 branch became officially trunk): 162 MB b) hugin the whole story, that includes autopano-sift-c, panoglview, kimagefuser, etc.: 5.2 GB c) import trunk without history (top-skimming) and start from scratch: 1.1MB I tried the following procedure: 1) rsync full svn repo at file level rsync -Lav hugin.svn.sourceforge.net:svn/hugin hugin-svnrepo 2) convert full repo to hg - 997 MB $ hg convert hugin-svnrepo/hugin hugin-hgrepo I used no special options (there seems to be a config file for branches etc. Its usage might improve things, as our repo is not structured as the usual svn repo, and we made some strange use of svn) 3) use hg convert to extract only the trunk from the full hg repo - 51 MB $ cat hgtrimfilemap include hugin/trunk rename hugin/trunk . $ hg convert --filemap hgtrimfilemap hugin-hgrepo hugin-hgrepo-trunk-only So it is 51 MB vs 1.1 MB. I suspect that hgsvn does not deal well with branches. Probably digging a bit further things could be improved, but what for? Given the choice I am inclined to leave pre-Hg history in SVN (properly set to read-only) and start from a clean import of trunk. What do others think? While there are probably usecases for having the full history, it might be overkill. If possible, I'd like to keep at least the recent history, though, that might be a compromise. I just did some hunting why the full history is so much bigger, and the main culprit seems to be the videos and pdf files that Ippei added to the SVN repo during his GSOC 2007. Also my svn mv to swap trunk and ippeis branch was not a good idea in hindsight. It would be great if these could be removed either from the SVN repo (local copy), or we could take just the revision after the point where the video has been removed from the trunk again. yes, SF is constantly under extreme load. The good thing is that with Hg the centralized repo becomes less and less important. It is easy, once we have Hugin on Hg, to move it to another Hg service provider. Unless you already know that you want to move to a specific service provider and that it does not offer Hg. E.g. Launchpad AFAIK is bzr only. I'm inclined to stay with SF for now, and do the migration. Better the devil you know... Ack. Some other points with the repo conversion: - renaming of the authors (there is a name map feature in hg convert. I wonder if we should move from the sf id to real names (and maybe email, for people that agree with that?) - Should we use named branches in hg (for the release branches etc), or not? If we choose to do so, it might be nice to convert them (if its not too hard). 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 To unsubscribe from this group, send email to hugin-ptx+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [hugin-ptx] GSOC 2010 – Accepted
Hi Bruno, Bruno Postle schrieb: On Thu 18-Mar-2010 at 21:00 +0100, Lukáš Jirkovský wrote: I've just got a great news – it seems that hugin was accepted[1] for the Google summer of code 2010! Great! We have two or three mentors volunteered so far, we need more at least to do backup roles. Now is the time to volunteer for mentoring. We also need a backup admin as I will have limited connectivity for some of the SoC period. I'm willing to be a backup admin and backup mentor. I won't be available at mid to end of June. 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 To unsubscribe from this group, send email to hugin-ptx+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[hugin-ptx] Re: Repository
Hi Yuv, I think that moving to mercurial would good, and now is the right time to do so. Yuval Levy schrieb: On March 19, 2010 01:55:36 pm T. Modes wrote: It's easy to lock SVN making it read-only and allowing commits only from an hgsvnpush cron job. But then the svn repository is only a copy of the mercurial. What is then the purpose of the svn repo? distribution. There are plenty of read-only application. A user can download a tarball, or fetch from SVN. This is particularly handy for source based distributions such as Gentoo or FreeBSD, where it is technically possible to fetch code from a repository rather than from a downloaded tarball. I also don't know how packagers for distros such as Fedora, Debian, Ubuntu and the dozens or hundreds of other do get their source code. Simply interrupting SVN read-only service may interrupt the flow. I can see the value in keeping a subversion repository, but I dislike keeping the SVN repo as the central repository for our branches. (Ie, no developer will have/use an SVN checkout in any way). If there is a real need for a SVN repo for distribution, I would much more like a svn mirror of the trunk hg branch. However, as many projects have moved from SVN to DVCS, I think that the major builder (Gentoo, Freebsd) could handle a switch to hg relatively easily. When I switched from CVS to SVN, I didn't keep a CVS mirror. It might not be completely comparable to the current situation, but I don't remember any complaints. Another question is about the quality of service of the hg repos at sf net. I haven't tried them yet, but in the past, I was not really satisfied with the sf.net service. Btw. when playing with conversions, it is best to download the entire svn repository (was called svndump or similar 2 years ago, IIRC) from sf and work with that. It would be a good idea to try hg with panoglview source, this is not critical and also relatively small. 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 To unsubscribe from this group, send email to hugin-ptx+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [hugin-ptx] GSOC 2010 – Accepted
Hi Bruno, Pablo d'Angelo schrieb: I'm willing to be a backup admin and backup mentor. I won't be available at mid to end of June. I tried to apply as a mentor for hugin at http://socghop.appspot.com, but I couldn't find a way to do so. Hugin is not listed when I select Apply to become a mentor. Hugin is also in the list of projects that haven't completed their organisation profile, maybe thats the reason. 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 To unsubscribe from this group, send email to hugin-ptx+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[hugin-ptx] Re: Towards a non-patented control point detector
Hi Aron, Aron H schrieb: I've just been successful in building on Win XP with VS 2005, and started playing with panomatic_nopatent :). With the default settings from the readme, on a 2 row, 360 panorama, I'm finding a number of false matches. I'd like to provide helpful input, or other help, however I can. It currently is more sensitive to distortions than the other descriptors. I hope to improve this (and add a better ransac model for outlier checking). Unfortunately, I have been rather busy with some other stuff lately. What kinds of cases is this algorithm suited for? What would give it problems? My problem panorama has varying white balance and exposure, for example. I think you mentioned some research papers about the algorithm - can you point me to them? Hmm, the algorithm is not really based on a published approach, just on some ideas that are mentioned in a few of them, and its currently simpler than any of them: http://www.eecs.berkeley.edu/~aberg/gb.html http://cvlab.epfl.ch/~tola/daisy.html http://cvlab.epfl.ch/~brown/learndesc/learndesc.html The descriptor is basically just x and y gradient strength computed in a daisy like layout, where the radius of the circles define the scale of the gradient filter. The code is relatively simple: localfeatures/CircularKeyPointDescriptor.cpp I did some quick evaluation and parameter tuning using two panoramas, to learn the best radi and scales, but probably some kind of aggregation of the gradients is needed to really improve the performance. I have also fixed the typo you mentioned in a later mail, and liblocalfeatures will be build as a static library on windows now. 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: Announcement: Photoropter lens correction library
Robert wrote: === Announcement: Photoropter lens correction library === Seems to be very similar to lensfun: http://lensfun.berlios.de/ I think lensfun is really good, however, it never really got of the ground nicely (its used by ufraw though), because adding new lenses etc. is not as straightforward as it could be. It would be great if the database storage could be kept similar or easily convertible, so that both projects can feed of the same data. 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: HDR Remapping in NONA results in loss of dynamic range?
hdrpano wrote: I had the same problem a month ago. Concluded that nona is unable to preserve hdr when remapping. Let me know if you figure this out... It should work, if you set the Camera response type to linear. (Lens tab, photometric sub tab). cheers, 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: APSC gives array out of bounds?
Zoran Zorkic wrote: On Jan 29, 12:01 am, Bruno Postle br...@postle.net wrote: In practice Hugin doesn't cope with any of these '=' references pointing to an image with a later number, so image 0 should never have any. This sounds like a bug, do you only see this with the trunk? Only with recent builds. 2009.4 works fine. This is probably related to the merging of the layout branch. There shouldn't be any '=' references in the first image at all. 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: Tests for Pablo's (almost) patent free CP detector (was: Towards a non-patented control point detector)
allard wrote: I did a first attempt to build on Wndows XP and that was not successful. Let me describe the steps. -Downloading and installing bazaar from their webpage and getting the trunk trough their GUI went smooth. -I ran CMake (i use 2.8.0 RC5 GUI), which went smoothly except that I had to point it to some libraries directories, but I'm used to that from the hugin builds (boost, wxtiff, jpeg, png and zlib). -I opened the 'panomatic.sln' MSVC++ solution (I'm on the 2008 express edition) and pressed 'build'. Many 'file not found' errors came up, which were related to the fact that the boost directory and the vigra directory were not added to the 'additional include directories'. I was a bit surprised about the boost directory as this was certainly in the cmake cache file. Oh, if forgot to add a check for the vigra stuff. The boost include path should be picked up now. -I added the directories through the 'properties/C++' tab of MSVC and rebuilt. This time there were errors in CircularKeyPointDescriptor.cpp , related to M_PI not being defined. Fortunately, some googling told me this is a known problem and that this can be solved by adding '#define _USE_MATH_DEFINES' and '#include math.h' at the top of the file Fixed in bzr -I rebuilt. This time two more errors came up that I couldn't solve. These were: error C4716: 'PanoDetector::LoadKeypoints' : must return a value' in panodetectorlogic.cp, line 110 This was an error in the source, I just commited a fix. and LINK : fatal error LNK1181: cannot open input file '..\localfeatures \Release\localfeatures.lib' Maybe these are related? Could you update and try again. 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: libpano13 1214 broken on Linux
Hi Matthias, Matthias Kabel wrote: Hello, I just tried to update my libpano13 and hugin installation with libpano13 revision 1214 there is an error with hugin. hugin: queryfeature.c:376: panoProjectionFormatCount: Assertion `sizeof(panoFormatNames) == 20 * sizeof(int)' failed. I fixed that error in libpano13 rev. 1203 See: http://panotools.svn.sourceforge.net/viewvc/panotools/trunk/libpano/queryfeature.c?r1=1199r2=1203pathrev=1203 This has removed the line were you backtrace shows the crash. Maybe something went wrong when updating your libpano13 checkout. I tried make clean for libpano13 and hugin. Did you also do make install for libpano13? 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: libpano13 1214 broken on Linux
Hi all, Jean-Luc Coulon (f5ibh) wrote: For me [tm] 1203 works 1214 doesnt. assert(sizeof(panoFormatNames) == PANO_FORMAT_COUNT * sizeof(int)); ^^ This is the offending line and present on 1214 This line was existing in 1202, has been removed in 1203. It is not present from 1203 until 1209 and appears agn in 1210 and still here since. I just removed it again in rev. 1215. 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: large multi-row panoramas (was:Makefile generation)
Hi Bruno, Bruno Postle wrote: So here is my recipe for efficiently matching a multi-row panorama: 1. First use ptochain to connect all consecutive photos in the project, the result will be a project with one or more groups of connected photos - With luck each of these groups will correspond with a 'row' of the panorama. 2. Then take the first and last photos from each group and match them all together in one go (this is another tool with the same interface: ptobind). With luck there will be a single group of connected photos in the project (if not you can open this subset in Hugin and manually add points before continuing). 3. Next optimise this project, but only optimise pitch and yaw (not roll), this will distribute the photos around the scene even if there is only one control point between each photo. 4. Use ptofill to place control points between the remaining overlapping photos that are not already linked. Though this works fine for me, and there is another tool called 'gigastart' to manage all the steps, there is no reason why the same steps couldn't happen in a different standalone tool at some point. http://search.cpan.org/dist/Panotools-Script/bin/gigastart This is really great! Now I just have to finish the work on the patent free control point detector (btw. has anybody tested it?) and it should be possible to replace autopano-sift-c with a truly free solution. For typical point and click users, a script similar to gigastart (or small wrapper), that expects a pto file (or image list or so) and runs the whole process would be great. This could then be used directly as a control point generator from within hugin. 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: Towards a non-patented control point detector
Hi Harry, On 3 Jan., 13:08, Harry van der Wolf hvdw...@gmail.com wrote: Hi Pablo, Many thanks for this achievement. Even though the current autopano-sift-c and panomatic doe their job very nicely, it is really getting a pain in the backside to have to deal with this patent/license circumstances. I've tried to build it but it breaks on [ 23%] Building CXX object keypoints/CMakeFiles/ keypoints.dir/keypoints.cpp.o /Users/Shared/development/hugin_related/panomatic-lib/keypoints/keypoints.cpp:35:27: error: vigra/impex.hxx: No such file or directory When installing vigra it works OK, but vigra is not part of this bazaar branch. Yes, it requires an external vigra lib. Did you intend this to be or become part of hugin. If so, do I need to or can I put this panomatic-lib somewhere in the hugin tree? Currently it is not part of hugin. I'm still undecided if I should keep it as a separate program, or embed it directly into hugin. For the moment it is really a first test and not meant for shipping as a default control point generator. Next to this I get a lot of errors about: -- Performing Test boost_python_/usr/lib_/usr/include/python2.5_boost_python-gcc-mt_compile -- Performing Test boost_python_/usr/lib_/usr/include/python2.5_boost_python-gcc-mt_compile - Failed -- Performing Test boost_python_/usr/lib_/usr/include/python2.5_boost_python-mt_compile -- Performing Test boost_python_/usr/lib_/usr/include/python2.5_boost_python-mt_compile - Failed (and many more lines) It creates the build files though and everything is compiled fine as well (after installing vigra). Is this python_boost thing a requirement? And what does it do? It is not required, but can be used (in the future...) to call the core detection routines from python. This is useful for further parameter tweaking scripts. Currently this is an untested features. Finally when starting panomatic it displays the normal help screen but ends in: ThreadQueue waiting on remaining threads... Reference thread created. 1 reference-thread added. pollUserThreads() pollReferenceThreads() Thread destroyed. 1 reference-thread reclaimed. ThreadQueue destroyed Is this normal or is it something from OSX or boost-python or..?? I also get that message, it could be that I enabled a debug flag in March 2009, but forgot about it. Its not serious. 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] Towards a non-patented control point detector
Hi all, I have taken some time in the last few days and continued my work on on a patent free control point detection algorithm, which I haven't had time to continue since I started it in March 2009. I have taken panomatic as base, as it is a relatively clean code base (compared to the others), and implemented a new descriptor based on the geometric blur and DAISY papers. This is a relatively simplistic (and very cheap to compute) descriptor, and its probably not as powerful as the original SURF descriptor. I'm still using a small part of the SURF algorithm to estimate the orientation of the interest point, so it is not 100% patent free yet, but I hope to replace that part in the future. I have further modularized the panomatic source code and added a new program called keypoints, which can be use to compute the descriptors only (similar to generatekeys from autopano-sift). The main panomatic executable now also supports loading of these files instead of recomputing them based on the images. This is mainly useful for testing and some more advanced control point finding strategies. The code lives in a bzr repository on launchpad: https://code.launchpad.net/~pablo.dangelo/hugin/panomatic-lib See the README file on how to build and use it. It is not tested on many panos yet, and might or might not work. I'm interested in feedback to see how well it works with typical panos. Note that it can't properly handle fisheye images (like the original panomatic). It might be possible to use it with match-n-shift, but I haven't tried that yet. 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: [PanoTools-devel] bug in libpano/PTmender
D M German wrote: FYI, Adding Tr parameters to the script will restrict the output of the any remapped image be at most 180 degrees, even if it can spawn longer (such as most of the cylindrical panoramas). I am not sure why this happens yet. Only images that have nonzero TrXYZ should be affected by this, as they are fist projected onto a plane and thus cannot have more than 180 degrees in the final panorama. The behaviour of images with Tr(XYZ)0 should not change. 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: CP Detector vs. Generator
bruno.postle wrote: On Dec 21, 2:51 pm, Mick Crane mick.cr...@gmail.com wrote: Common point 'shared features' is another one I like. In photogrammetry, what we call control points is called tie points. I like that term it more than control points, but panotools has used control point, and for the sake of consistency, I think we should keep it. 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: Fwd: Re: Re: possible memory leak in enblend enfuse?
Rogier Wolff schrieb: On Wed, Oct 28, 2009 at 10:56:08PM +0100, Pablo d'Angelo wrote: Implementations of Minimum cut algorithms are widely available, for example from the boost graph library or http://www.cs.ucl.ac.uk/staff/V.Kolmogorov/software.html (maxflow v2.2 is GPL licensed). I think an implementation in enblend wouldn't be too hard to do, and might be simpler than trying to fix all special cases with the current approach. The current approach, I think, is very good at hiding some differences between adjacent images. Getting a good initial cut-line might help a bit. But just switching to a good cut line according to this algorithm you described is not good enough. I have been thinking about THIS algorithm for the past few weeks. Your edge cost function I think is too simple. I would add in the costs (i.e. absolute pixel differences) of a circle around the current edge. Actually, I believe that enblend also uses a very similar cost function currently, ie absolute gray value differences, with a much more restrictive state space. Thus I am not convinced that the simple absolute differences cost function is not good enough, when comparing to the current state. Suppose we have a person half on an image. The intention is to cut completely around this person. (cutting through the person should incur high costs because the pixels differ a lot.) Now suppose a small black line is in front of the person. Now both images have this line where the absolute difference between pixels is quite low (both black), but closeby pixels DO differ. Of course it is possible to fool this simple cost function, as it is possible with the current enblend. The pragmatic approach would be to first implement the graph cut optimization and then see where the problems with the simple absolute differences cost. Then the cost function can be further tuned. I suspect that maybe adding a soft constraint that tries to keep the seam line closer to the center of the overlap region might also be helpful. 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: Fwd: Re: Re: possible memory leak in enblend enfuse?
Hi Andrew, Andrew Mihal schrieb: Hi Pablo, Can you elaborate a little on your criticism of snakes? Is the problem: - That the polyline formulation cannot describe a good solution at all? A polyline can describe all possible solutions, if it is fine enough. - That the size of the state space in the current implementation is too restrictive? While I don't have a strict proof, I feel that the state space of the snake model is too restrictive and too powerful at the same time, as it allows self crossings of the seam line etc. Also, only a small part of the image content (on lines perpendicular to the initial seam) is used to determine the major location of the seam line. I believe that a state space that includes the whole overlap area and not only some profiles of it would lead to better results. The second step (dijkstra shortest path) does try to remove these limitations but it can't undo the decisions made by the polyline optimisation. A straightforward state space is an image that holds 0 for image pixels in the first image, and 1 for image pixels in the second image. This statespace has the advantage that it directly models the problem. Finding a solution can be done by modelling it as a graph and finding the minimum cut. In this approach, each pixel in the overlap region would be a node in the graph. The edges connect each pixel to the 4 nearest neighbours. The edge value is the sum of the absolute color difference between the nodes connected by the edge. The source node is connected to all pixels that are on the boundary of the overlap regions and are only valid in the first image. The sink node is connected to all pixels that are on the boundary of the overlap regions and are only valid in the second image. Finding the minimum cut in this graph will give the seam line that has the smallest color difference (note that this is the global minimum), and hence a good position for a seam line. This also means that only the cost function and not the parameterization of the optimization algorithm influence the result. This should be relatively efficient, and it should be able to handle all special cases with strange overlap situations with holes, small overlaps etc. naturally. There are some illustrations of the above in: http://www.cs.huji.ac.il/course/2006/impr/lectures2006/Tirgul9b_Panoramas_blendStitch.pdf slides 29ff Some more ideas on how to refine the cost function so that other constraints can also be added: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.129.8181 Implementations of Minimum cut algorithms are widely available, for example from the boost graph library or http://www.cs.ucl.ac.uk/staff/V.Kolmogorov/software.html (maxflow v2.2 is GPL licensed). I think an implementation in enblend wouldn't be too hard to do, and might be simpler than trying to fix all special cases with the current approach. Additionally, I believe that it would find better seams, so it is worth trying. Unfortunately, I currently don't have the time to do so... :-( - That the current implementation's cost functions do not correlate with a good solution? No, I think these are good enough. - That the current implementation's GDA solver is insufficiently powerful to find a good answer to the optimization problem? Yes, combined with the problems of the statespace indicated above. - something else? The main source of bugs seems to be related to the bitmap - vector - bitmap approach required by the polyline optimisation. It seems to me that the best seamline can be modeled as a polyline, and the search space can be defined in such a way as to include the best seam as a possibility. I admit that the current search space definition is a little rough, and that the GDA is buggy and needs parameter tuning. I think the hard part is defining what is best and turning that into equations. But surely the graph cut approach has this same requirement? The main reason why I advocate trying graph cut approach is: It should allow a different state space, which I think will sidestep most of the painful problems related to many special cases with the vector seams. This might be also possible to optimize the pixel labeling directly with the simulated annealing, however it would probably take forever to find a good solution due to the higher dimensionality of the state space. 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: 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
Oskar Sander schrieb: Ok! I think one of the big challenges with this is to visualize the paramters in some some of tutorial/online manual. Indeed. But so far I'm not sure if I have found the right parameters... The camera plane is Z=0,Xc,Yc right? Yes. How do you then describe subject projection plane with the 2 parameters? My experimental implementation does use plane yaw and plane pitch, to specify the surface normal of the plane, and the plane is always tangent to the unit sphere around the panorama camera. This works very similar to the yaw and pitch of the input images. For example, a plane at the nadir would be specified by plane_pitch=-90. However I get strange results when placing this plane at the nadir of a spherical pano and then optimizing, this is why I haven't commited anything yet. Do you aaume something about the geometry with respect to PrincipalPoint or Nadir? http://www..r-s-c-c.org/rscc/v1m6images/pitch.jpg http://www.r-s-c-c.org/rscc/v1m6images/pitch.jpg Ehm, not sure what you want to express with that picture? 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] Te0 and Te1 parameters in libpano13
Hi all, I have just commited some experimental extension to the TrX, TrY, TrZ parameters for mosaicing images of a planar scene to the libpano13 SVN trunk One of the main drawbacks of the Tr* parameters is/was that the images had to be located on plane straight ahead of the panorama. This is too restrictive for the nadir and wall patching usecase. As hinted in an earlier mail to hugin-ptx, I have added two more parameters that allow specification of the plane on which the off center images should be projected for each image by means of plane yaw (Te0) and plane pitch (Te1) parameters. They define the normal of the plane in 3D space, similar to yaw and pitch, which define the looking direction of a camera. So for nadir patching, off center shot should be set to Te00 Te1-90. For fixing something on the left wall, the following parameters should be used: Te0-90 Te10. etc. The main drawback of these parameters is that it is quite hard to optimize them: It is easily possible to have cameras that do not look onto the plane. This will confuse the optimization process and it won't be able to find a good solution. So initialization with good values or very careful stepwise optimization is required. 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: windows binary release
allard schrieb: no panomatic is definitely not in the SDK. and it adds short term problems - until the patent (SURF) expires. I think we need to follow the lead of the Mac OSX builds and make separate installers for the CP generators. But I also think that this should come after the SDK-build, binaries-build and installer compilation work well enough in sync. not now. for now leave it as it is, but leave it broken (i.e. don't add panomatic itself). I was recently looking for that patent on SURF. I couldn't find it. See: http://v3.espacenet.com/publicationDetails/biblio?CC=EPNR=2027558A2KC=A2FT=Ddate=20090225DB=EPODOClocale=en_V3 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
Hi Oskar, For these two mosaics I did this by forcing only XYZ optimization first, then adding angles in the next run. That converged nicely, and exposed a few CP that were completely off. Other things i can think of are: * Observed initial values - Some UW mosaics uses ROV that captures XYZ position and ypr of the mission. These are then used as starting values in the optimization * Determine lens distortion parameters before, and use as starting value. * An iterative optimization strategy much like the one used for panoramas where XYZ is iteratively optimized around anchor, then ypr I'm currently working on that... BTW, What are the units of XYZ? The Plane is currently located at z=-1 (straight in front of the camera). If you keep one camera at TrZ=0, then TrX,TrY and TrZ need to be multiplied by the physical distance between the camera position of that image and the plane. 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: Aerial Photography Stitching
Hi Matt, Matt Williams wrote: 2009/9/22 Pablo d'Angelo pablo.dang...@web.de: At work, we have a full frame camera system ( 3xCanon EOS-1d) with 50 mm lenses. Flying that at 1000m gives reasonable detail when looking straight down and the imaged area is much larger than with your example images, making them easier to handle. Ok. That's definitely something worth considering for the future. For the shots you've seen, the camera was provided by whoever in the area had a camera and free time for when the plane was booked. It's possible we could obtain a higher quality camera as a community. Actually, the camera was ok, but maybe just use a wider angle lens and do mostly downward looking shots, and fly higher, if possible. Flying higher will also make the mosaicing and interpretation of the pictures easier. Btw. real aerial cameras (for example. UltraCam http://www.microsoft.com/ultracam/default.mspx ), as used by the mapping agencies, are probably 50 to 100 times as expensive as a Canon EOS 1D something. 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: tilt functions
Brent wrote: Pablo, Now that I think about it, there is something odd in the fact that doing a multi-step optimization by changing which variables are optimized works any better than a full optimization. Maybe my explanation in the previous email was a bit misleading. What I meant is to start optimizing with optimizing two images (with good connections etc.), then add the third, optimize again, add the fourth etc. This is done by the incremental optimization in hugin. (Note that here, control points in the non-optimized images are ignored). That is, if the current solution is in a local minima with respect to 10 variables, for example, then it will still be in a local minima if fewer than the full number is optimized starting from that point. However, there might be other local minima, which can also be found by the optimizer, as its way though the solution space is changed, and some shortcuts might be blocked (such as modifying lens distortions and d,e shift to make images fit better during the first iterations), might send the iterative optimization into the wrong direction, from which it might be unable to recover. Then the first local minima of will be different, and thus later optimization with more parameters will also find another solution. If there's a way out of trap when optimizing a subset of the variables, then that same way out is available when more variables are allowed to vary. Hmm, I don't think there are always ways of of local minimas, and adding some new parameters to the optimisation do not nessecarily mean that the previous local minima ceases to be one in the new parameter space. 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: tilt functions
Hi Brent, Brent schrieb: From a purely empirical point of view, it appears that there is some undesirable linkage between these parameters that makes the minimization process get trapped into local minima and have difficulty finding a solution in some cases. I have had the same problem, with both the tilt parameters (TiX,TiY,TiZ, TiS) and the position parameters (TrX, TrY, TrZ). The problem that the optimizer gets trapped in local minima isn't really something new, so we have worked a bit around that with multi-step optimization, and especially the incremental optimization in hugin and autooptimizer (cmd line optimisation program, part of the hugin package). I found that with adding image by image to the optimisation process, I didn't get really bad random behaviour anymore, even when later finetuning the project and doing reoptimisations, as the project is already close to a nice minima (I hope). As for correlation between the parameters, I quite sure that d,e and TrX, TrY are highly correlated when using rectilinear images, especially if they are shot without large variation in yaw and pitch. In my experiements with the graffiti wall example posted by Bruno, I got some problems when optimizing d,e (linked between all images), even if the solution before was quite good, and his images contain shots from many different angles. I haven't expected an high correlation between p and TrZ though, so this is interesting and should be analyzed in more detail. It might just be that the starting point in the solution space is very far from the global optima. 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: Control point generation in difficult conditions - some success
Hi Oskar, did you also try panomatic? It might work better than autopano-sift-c. ciao Pablo Oskar Sander schrieb: My idea is to run CP finding on preprocessed images, and then substitute these for the originals before the stich step. I'd like to understand the APC inner working better though, maybe there are potential improvements. I've been peeking a bit in the code of APC and the LoweFeature detector. It seems to look for contrast rich areas, is it using the colour channels separately or luminance? Any suggested reading? Hmm, no it did not improve much when tried en-masse unfortunately. The places where controllpoints are found ar typical protruding features that are better lit man more contrasty than the deck, but these does not work for optimization as they are not in the deck-plane. Is there an APC constant or parameter to lower the threshold of APC critera, that could be tweaked in order to experiment with the selection criteras if the images are too soft in general? -- /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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: tilt functions
Jim Watters schrieb: Pablo d'Angelo wrote: If I understand correctly both models will align an image so it is on the same plane as others. After some more reading of the code, I'm quite sure that the tilt can only work well with rectilinear input images. If only that case is interesting, one doesn't even need angles, a simple 3x3 homography matrix transform is sufficient, and probably more stable than the tilt model. The XYZ model calculates the position of the camera, this will cause certain distortions to the image. XYZ have to be optimized with ypr. The TxTyTzTs model calculates the actual distortion to align the image after it has been placed correctly after optimizing ypr. I don't believe that ypr and the TxTyTzTs are independent. For the shift compensation, the TxTyTzTs model will also require simultanious optimisation of d and e. The advantage to the XYZ model is it uses fewer overall parameters. But when I try imagine manipulating images in my head using TxTyTzTs i don't see how Tz is any different than r. And maybe Tz it is not necessary. The advantage to the TxTyTs model is ypr can be optimized first to get a good placement before distorting the image by optimizing TxTyTs overall needing fewer control points. You still need Tx, Ty, Ts and d,e. This assumes that you do not need to touch y,p,r from a previous optimisation. However, I think y,p,r will try to compensate for the parallax, and they will thus be quite wrong, in an attempt to rescue the situation. I'm not sure that a later tilt estimation works satisfactory with the previously estimated y,p,r parameters. Maybe one can get away, if the camera hasn't been moved too far. My experience with the tilt model was not so good. I have prepared a nice testset with the aerial images posted earlier, and it works quite well with the XYZ mode. I'll give more details later. 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] XYZ mosaic mode in hugin
Hi Bruno, Bruno wrote: Works for me, I also found that I can successfully optimise lens parameters: http://www.flickr.com/photos/36383...@n00/3947727801/ ..so when can we have this in Hugin? ;-) It doesn't make sense to add these the the trunk, as it would complicate the merging of layout. I'll looking into adding them to the layout branch. Btw is there a list of issues in the tracker (or somewhere else) for the problems in the layout branch? 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: [PanoTools-devel] tilt functions
D M German wrote: Pablo dAngelo twisted the bytes to say: Pablo I'm still struggling to understand the geometric interpretation of the Tx,Ty,Tz angles and the Ts parameters. hi Pablo, I have created this document to explain the use of the three parameters. Thank you for the pdf, it explains the idea. For interested people on hugin-ptx: Read this to see the context of the discussion http://thread.gmane.org/gmane.comp.graphics.panotools.devel/1517 The pdf mentioned can be downloaded from http://cache.gmane.org//gmane/comp/graphics/panotools/devel/1522-001.bin The purpose of the tilt is to remap a photo to match another plane. basically, the second image is moved in an angle in its own sphere (Tx, Ty, and Tz, similar to yaw, pitch and roll) No, actually the rotation happens in image coordinates, not in its own sphere. This is a fundamental difference (in my opinion, it is also a fundamental flaw). At least thats how it is implemented. Thus, I don't see how the currently implemented tilt parameters allow a general modelling, even when using only rectilinear - rectilinear. The XYZ mode I recently implemented actually does its rotation in an own sphere: It rotates image B in its own sphere and then translates (X,Y) and scales (Z) the input image (still on the sphere!), which is then projected onto the panorama plane (when using rectilinear output). When using another output projection than rectilinear, the image is projected onto a intermediate plane, from where it is reprojected into the output projection. In that repect, I think the XYZ mode actually fits you description better than the tilt mode. Note that for fisheye images, it does not make sense to imagine image A and image B as a plane, as it is illustrated in your example. For that case, the transformation (ignoring lens distortion etc.) is a simple matrix multiplication of the pixel coordinates with a homography matrix T (T is a 3x3 matrix, with T(3,3) = 1). So that leaves 8 free parameters that need to be determined (note that this also allows non-square pixels, so effectively 7 parameters are needed for most usecases). With the tilt mode, at least v,r,p,y, Tx,Ty,Ts and d,e are required for the warping, so there must be something wrong the model, as it should only require 7 parameters and not 9. Using an overparametrized model is not good for the optimisation, as it will confuse the optimizer. With the XYZ model, only v,r,p,y, Tx,Ty,Tz are required, which is the minimum amount of parameters, and they can handle a all possible camera positions. This should work also work independently of the projection of the input images. 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: Aerial Photography Stitching
Hi Matt, This is the method I had been using before, but obviously without the Tilt parameters and so it really struggled. Actually, I played around a little, and I wasn't satisfied with the tilt parameters, so changed libpano to allow estimate the X,Y and Z camera position (assuming a planar earth). I still need to do some final testing, but so far it doesn't look too bad. Thanks a lot for all your suggestions. I think I'm going to have to get a working group together within OSM to try to work on these problems. This experiment with aerial photography will likely be repeated again and so I feel it's worthwhile for us to create a strong open source workflow for creating full stitched images. Please keep me updated. Where do you discuss these issues? 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: Aerial Photography Stitching
Matt Williams wrote: 2009/9/22 Oskar Sander oskar.san...@gmail.com: Hi Matt, If you experiment on this further, it would be really sweet if you did a tutorial writeup here even if it doesn't work out perfect right now. I absolutely will. This won't be the last time that OSM hire a plane for some aerial photography and so it's important that we find a decent way of doing it. I have played a little with the images, and from my perspective, it would be more usable, if the camera with a wide angle lens (maybe 28 mm instead of 50 mm) would be used especially for the nadir shots. Flying at a higher altitude will probably also help. They probably still have enough detail for mapping (you probably do not need 5 cm ground resolution or so, 10 or 20 cm are probably enough to recognize most details required for mapping. At work, we have a full frame camera system ( 3xCanon EOS-1d) with 50 mm lenses. Flying that at 1000m gives reasonable detail when looking straight down and the imaged area is much larger than with your example images, making them easier to handle. 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: Aerial Photography Stitching
Stefan de Konink wrote: We did; we have a rectifying program, and like I posted before I was pointed myself to efoto. From there on we can use qgis and mapserver for final positioning. Come and idle in #osp on oftc ;) Do you have a procedure that works nicely for the large amount of image? I couldn't find anything on http://www.openstreetphoto.org ? 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: Aerial Photography Stitching
Matt Williams wrote: 2009/9/22 Pablo d'Angelo pablo.dang...@web.de: Hi Matt, This is the method I had been using before, but obviously without the Tilt parameters and so it really struggled. Actually, I played around a little, and I wasn't satisfied with the tilt parameters, so changed libpano to allow estimate the X,Y and Z camera position (assuming a planar earth). I still need to do some final testing, but so far it doesn't look too bad. I see you've checked some of these changes into SVN, I've uncommented the '#define MOSAIC_XYZ 1' line in adjust.c. Is there anything I need to do elsewhere to allow it estimate these variables? No. With these you could just try to optimize y,p,r,Tx,Ty,Tz for all images except the first one. 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: Aerial Photography Stitching (using new mosaic mode)
Pablo d'Angelo schrieb: Matt Williams wrote: 2009/9/22 Pablo d'Angelo pablo.dang...@web.de: Hi Matt, This is the method I had been using before, but obviously without the Tilt parameters and so it really struggled. Actually, I played around a little, and I wasn't satisfied with the tilt parameters, so changed libpano to allow estimate the X,Y and Z camera position (assuming a planar earth). I still need to do some final testing, but so far it doesn't look too bad. I see you've checked some of these changes into SVN, I've uncommented the '#define MOSAIC_XYZ 1' line in adjust.c. Is there anything I need to do elsewhere to allow it estimate these variables? No. With these you could just try to optimize y,p,r,Tx,Ty,Tz for all images except the first one. There is a bug in panotools. Sometimes it does not optimize parameters if they are exactly set to 0. This seems to affect the Tx, Ty and Tz parameters as well (a,b,c parameters are the other parameter that suffer from this). So simply add Tx0.1 Ty0.1 Tz0.1 to i lines, except for the first one. Note: the names of the Tx, Ty, Tz parameters are only valid with the current svn and the MOSAIC_XYZ define in adjust.c. They will be available under another name in the future (probably just X Y Z). Here is the result of merging images 539-549 from http://vps-1005786-1584.united-hoster.de/tmp/539-549.jpg It is not referenced to an OSM map (too late in the evening...), but the result looks very promising. It also shows that the sideward views are probably not that helpful for mapping, at least when reprojecting them. Quick procedure: 1. panomatic -o 539-549.pto *.jpg 2. hugin 539-549.pto - set focal length to 50mm (~ HFOV 26°) - open fast preview - set projection to rectilinear, - select hfov and vfov ~ 100 - show only the first image. - use the drag tool to move the first image so that it roughly looking like a nadir image - select all images again - Go to the optimizer tab, select (optimize y,p,r) - tick edit script - copy script into a text file 539.549.txt - Edit script, add Tx0.1 Ty0.1 Tz0.1 to i lines, except for the first one. - modify the v lines to include Tx# Ty# Tz# (where # is the image number) - run PToptimizer 539-549.txt - run PTmender -o 539-549 539-549.txt - run PTroller -o 539-549.tif 539-5490*.tif - crop 539-549.tif in your favorite image editor. 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: Aerial Photography Stitching
Hi Matt, The general workflow for proper orthorectification (as used by the professionals) is: 1. Measure some ground control points (GCPs) in the images. These associate an image point with a 3D world position (lat, lon, height). If a full bundle adjustment is used, this is not needed for every images as tie points (called control points in hugin) can also be used. These are usually measured against maps, orthoimages, gps traces. The height is often derived from the SRTM dataset, or from high precision GPS measurements with post processing at specific corner (centre of roundabouts etc.). 2. With the GCPs and tie points, the position and orientation of each photo is estimated using bundle adjustment. This works a bit similar to what hugin/panotools does, but it solves for full 3D geometry. 3. Orthorectification is preformed using the estimated positions and orientations and a digital terrain model. If there is a lot of overlap in the photos, the terrain model can also be computed from the photos itself (This is actually what I currently do in my day job). All data that is required for this is freely available. You can use well traces streets in OSM for establishing the ground control points in step 1). The SRTM model required for orthorectification is available in the public domain (at least for areas south of 60° northern latitude). The main problem is that there is no complete open source software package for this job. All the components are available in various software packages, but they are not integrated: - Tie points can be created in hugin or with other matching software. With a bit of scripting, GCPs can be derived from tie points measured against OSM maps (its just coordinate transformation and lookup in the elevation model). - A complete package that takes care of most steps required for 1) and 2) is bundler, http://phototour.cs.washington.edu/bundler/ however, this is not designed to handle ground control points, so it won't give you absolute coordinates. It uses a customized version of SBA http://www.ics.forth.gr/~lourakis/sba/ for the bundle adjustment. SBA recently been extended so that it supports both tie points and ground control points. - Orthorectification can be done using open source remote sensing software packages such as http://www.ossim.org or http://www.orfeo-toolbox.org. However, these packages are mostly designed for handling commercial satellite and aerial imagery, and I'm not sure if the support a simple camera model. Then there is e-foto, which I have just downloaded as tried, but I didn't manage to do something useful with it. So the correct way to produce nice orthophotos as shown by the map providers is not that simple using open source software, and needs quite some gluing together of several packages. Hugin is currently not really suited for aligning all your images. However, the latest work in panotools (as mentioned in the reply by Lukas) might help if your area is reasonably flat. The new parameters Tx, Ty and Ts parameters in panotools should allow you to orthorectify your images to a plane. As these are are very new, they are not supported in hugin yet. This means that you need to use the panotools script interface from the command line directly. Maybe the following procedure might work (disclamer: I haven't tried anything of that myself!): 0. Get and compile the current trunk of libpano13 1. Load a few overlapping images captured from different viewpoints (maybe start with 3 or so) into hugin, and create a few good control points between them (make sure that they are good, to avoid confusion due to mismatched control points later on). Try to load a very well downwards looking image as first image. This image will define the plane to which the other images are warped later on. Do not optimize yet. Make sure that the field of view of the images is reasonably correct. (Computation from EXIF data is probably good for the first try). 2. Set the projection to rectilinear, and choose a wide HFOV and VFOV, such as 90 degrees or so. Press the compute optimum size button. 3. Export everything as panotools compatible project. The 100% bulletproof way is to go to the optimisation tab, tick the edit script before optimisation (or similar) checkbox, press Optimize and select the text of the checkbox and save it into a textfile named optimize.txt 4. Now you need to select which variables to optimize, using by adding them to the v line in optimize.txt. I would try optimizing roll, pitch, yaw and Tx, Ty, Ts for all but the first image. Run $ PToptimizer optimize.txt to perform the optimisation. Check the file to see some information about the errors. Here some trial and error with different parameter sets is probably needed. 5. Test remapping the images with PTmender: $ PTmendler optimize.txt 6. Combine the without any blending using PTroller $ PTroller -o output.tif remapped1.tif remapped2.tif
[hugin-ptx] Re: Aerial Photography Stitching
Pablo d'Angelo wrote: Hi Matt, The general workflow for proper orthorectification (as used by the professionals) is: 1. Measure some ground control points (GCPs) in the images. These associate an image point with a 3D world position (lat, lon, height). If a full bundle adjustment is used, this is not needed for every images as tie points (called control points in hugin) can also be used. These are usually measured against maps, orthoimages, gps traces. The height is often derived from the SRTM dataset, or from high precision GPS measurements with post processing at specific corner (centre of roundabouts etc.). Sorry, this was confusing. This is a better explanation: Tie point are measured between the images, Ground Control points are measured between the image and some reference data (maps, gps traces, digital elevation models, geodetic gps measurements etc.). 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: Integration Queue - current status
Hi Yuv, 6. vigra-1.6 (Lukáš): it has been decided to push the changes upstream; wait for vigra-1.7 with the changes; then make Hugin work with [vigra]-1.7. @Lukáš and @Pablo: what does it take to prepare Lukáš' work to go into vigra; and how do we make it available to vigra? I'll make a patch that fits the current vigra development version (They now have an mercurial repository) and submit it to the vigra developers. 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: Integration Queue - how do we add features to trunk and to release
Bruno Postle wrote: Cpclean is ready to go in as far as I'm concerned, the only question is do we run it automatically with the Align... button?: If in doubt: Make it configurable. I guess that it should be done for people that use the automatic method. However, if somebody adds some control points manually and presses Align again, it might remove the manually added points, which is probably not desired... 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: OpenEXR three bands
Hi Lukas, Lukáš Jirkovský wrote: Hi, while working on my GSoC project I've noticed that current OpenEXR implementation has only 4 bands. This makes it's usage inconvenient sometimes because it makes everyone to use ImportImageAlpha even when alpha is not necessary. It seems that OpenEXR is almost exclusively used with RGBA but when someone doesn't need alpha it should be allowed to use it with assumption that all pixels are opaque. Actually, its not that simple, as the alpha is usually pre-multiplied: value_in_file = value * alpha. This makes alpha blending in computer graphics applications faster. Hugin doesn't use anything of that though (only 0 and 1 alpha...), but a general solution needs to take care of that. The best solution would be to write a RGBA - RGB vigra accessor that could be passed to import image and would convert the RGBA - RGB. the importImageAlpha() functionality is also a hugin/enblend only feature, I haven't submitted that to the main vigra branch last time I sent my changes there. However, that is not really a problem, as its just an extension and could easily be moved into our own vigra_ext lib. I'd like to try to implement this. My question is: Is it acceptable or not? I mean when OpenEXR is stored as RGBA is it against some non-written rules in VIGRA to allow loading/storing with using only RGB values? Vigra is a multi purpose lib, and not restricted to a specific number of channels. For example, many remote sensing satellites have blue, green, red and infrared channels (The infrared channel contains valuable information about vegetation). Vigra is pretty dumb when it comes to image import/export, as it doesn't have a proper handling for alpha channels. I have added the ImageInfo::getExtraSamples() (or something similar), so that it is at least possible to differentiate between real channels and mask or alpha channels. I don't want to block it's way into upstream only because of this. If you want to hear my opinion I don't see any problem here because eg. tiff allows using from 1 to 4 bands. I don't think that this will be a problem, as the vigra import/export is quite bare bones anyway. One also needs to submit test cases for the new functionality, otherwise it won't be accepted by the vigra maintainers. 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: Hugin Qt
Lukáš Jirkovský wrote: Hello, there's one part of hugin code which I'm thinking of. I have many questions about it. It's code in src/hugin_qtbase. Is it alive? Is there anyone who actually cares about it? For now it seems dead. This is part of Ippei' GSOC 2007 project, where he did a lot of refactoring in the hugin core and started to lay a foundation for a QT based GUI, however, due to lack of development manpower and improvements in wxWidgets, we haven't really started developing a QT based GUI. 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: Integration Queue - how do we add features to trunk and to release
Yuval Levy schrieb: Hi all, particularly develoeprs, - vigra-1.6 (Lukáš' patch from before 0.8.0) I think this is best done by adding the hugin changes to the main vigra lib. Most changes are related to the vigra impex functinality, and it shouldn't be hard to get them integrated (Maybe except for one place were I have changed the behaviour when saving floating point images into an integer format.) After that we can simply wait until vigra 1.7.0 is released with our patches in and then remove vigra from our tree. - control-point cleaning (Thomas patch) - auto-crop (Gary's patch) - gsoc_2008_masking (Fahim's project) - gsoc_2008_feature_atching (Onur's project) The longer we wait, the more trunk will diverge and the more difficult integration will become. Moreover, there is a risk that newer changes will be implemented against the current trunk and will not be compatible once what is in the queue enters trunk. I'd like to go systematically and efficiently through the integration of the above features. There are three steps: 1. Maturity 2. Trunk Integration 3. Release and then there is a 4. Shortcut 1. MATURITY Only mature codelines/patches will be considered for integration in trunk can we verify the maturity of the PROJECTS? Build and test them! Actually, I did start a little work on the feature matching, however this is half finished and does not even compile, so I haven't commited that yet. I think the two remaining gsoc2008 are the ones that need most work, and therefore aren't in a position to be included before some work has been done on them. 2. TRUNK INTEGRATION IMO there is currently one feature that needs this sort of special attention: it is gsoc2009_layout. It introduces a very important, significant and welcome change in the underlying panorama model. It affects almost every part of the code. The longer we wait, the more difficult it will be to integrate. The question (to James, and his mentor Bruno) is: is it mature? if yes, when do you have time to take care of the integration? Planning around James' project: what should we send to integration before and what after? I haven't yet looked at: - control-point cleaning (Thomas patch) - auto-crop (Gary's patch) but I suspect that they are not too dependent on the layout work. So they could go in either before or after James. I think gsoc2009_layout should be integrated as soon as possible after 2009.4, if the marturity allows it. 4. SHORTCUT Specifically: lens calibration does not affect Hugin's main functionality at all. Should we send one extra chunk of code with it, and if yes which one? I couldn't find the control point cleaning patch in the patches tracker of hugin, can somebody point me to it? It might a good candidate for merging into trunk before 2009.4 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: cmake compilation of enblend [was: Enblend bug tracker and developer mailing list]
Kornel Benko wrote: Am Mittwoch 09 September 2009 schrieb Ryan Sleevi: As you indicated in your follow-up, the CMAKE_BUILD_TYPE is what controls whether or not the compiler is set to be optimized for release mode. For the Windows platforms, all the build types are exported into a single .sln and can be chosen within the MSVC ide / vcbuild command-line (CMake tries to preserve the native build semantics, and that's how it is done on Windows). FindLibraryWithDebug further eases this process for the Windows world. What is missing now, is the control from command line for this. Do you mean: cmake -DCMAKE_BUILD_TYPE=Release If I remember correctly, the enblend autoconf script does use more aggressive optimisation options than most other packages. 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: Mailing List(s)
Hi Yuv, Yuval Levy wrote: James Legg wrote: hugin-ptx is the only list linked to on hugin.sourceforge.net, and sourceforge makes the lists it hosts difficult to find. Could all the lists be listed there and at sourceforge.net/projects/hugin/? I am not sure what can and can't be listed on sf.net/projects/hugin. We control hugin.sf.net and so we can list anything there. Yes the lists are difficult to find and part of this process will end in better documentation on where to find what - lists, RSS feeds, etc. To encourage public conversations I think the reply-to address on hugin-cvs (and other notification lists) should be hugin-ptx rather then the commiter's sourceforge address. I'm not sure if (a) it makes sense for all notifications lists and (b) if it is possible with the current mailing list infrastructure (SF). I do see an added value with the reply to committs notification going to hugin-ptx (or a dev-list). it defintely should not go to the committer. What scares me a bit is replies to bug tracker notifications. This may defeat the purpose of keeping follow up information attached to the bug tracker ticket, rather than a discussion on a mailing list. Indeed. A reply to the bug tracker notification should end up as a comment on the bug tracker, instead! Most people might be happy with the additional complication of using a web-only forums (signing in, navigating back to the bug etc, scrolling down, replying there), but I suspect that the people using the tracker more often would prefer that a simple reply-to. It is so much easier and would lead to better usage of the tracker, especially when categorizing new bugs as they occur (I hope). Unfortunately, the sourceforge trackers cannot handle that, but there are systems that do (bugs.python.org, for example). I would of course subscribe to -dev, and read it. I suspect that most developers are probably happy with the current situation. Taking the low level dev talk of the main list will probably mostly affect the users on the main list. What do you users think? Are you tired by the low level tech talk here? 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: Fusing before or after
Hi all, This description is correct. Note that align_image_stack was really written more like a proof of concept and is not really well optimized. Actually, the implementation of the normalized cross correlation in hugin is very basic and thus quite slow. Replacing it with a properly optimized version (I believe opencv has a nicely optimized correlator) would make both align_image_stack and the fine tune functionality much faster. ciao Pablo Bruno Postle wrote On Thu 28-May-2009 at 07:52 -0700, Tom Sharpless wrote: So align_image_stack does use local correlations, then generates CP's as a way of communicating the required alignment to other tools? It generates control points because it uses the hugin optimiser to do the alignment (which is also why it accepts projection and field of view parameters). Is this done in such a way as to allow some warping as well as simple shifting in the final alignment step? The alignment uses the usual roll, pitch, yaw and fov distortion. That is, are the CP's based only or mainly on local shifts? No idea, the image is divided up into a grid and a feature detector tries to place an even distribution of points over the image area. In practice, with the -p option it behaves like a control point generator that only works with stacked photos, but which produces very few 'bad' points and which works very well with large exposure differences. --~--~-~--~~~---~--~~ 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: Layout panorama model (GSoC)
Hi James, Just a quick note below: James Legg wrote: It probably wouldn't take too long to combine this with the OpenGL preview, and might even be less work than putting it in its own tab. Sounds good! I don't know about animating the transition between preview and layout mode though. That would be doable, but it might take a couple of weeks that could be better spent on something else. I guess the simplest and hopefully useable method could be to temporarily use a smaller field of view for each image in the layout view. Stacks could probably shown by shifting their yaw and pitch values a little. 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 Students: Next Steps
Lukáš Jirkovský schrieb: 2009/4/4 Faruq writefa...@gmail.com: Hi, you should take a look at the: src/hugin1/tools_vips/* src/hugin1/tools/img2vips.cpp These are some toy programs I wrote some time ago. these are unfinished results from the Google Summer of Code project to integrate VIPS several years ago. Actually, the GSoC code is here: http://hugin.svn.sourceforge.net/viewvc/hugin/libpanorama/trunk/src/ 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: Fine-tune and wide-angle lenses.
Hi Peter, Peter Gawthrop schrieb: Hi Pablo, I'd like to have a look at this. Could you tell me exactly where the current algorithm lives within the hugin tree? The main correlation happens in: src/hugin_base/vigra_ext/Correlation.h vigra_ext::PointFineTuneRotSearch() vigra_ext::PointFineTune() these are relatively straightforward (and SLOW) implementations of normalized cross correlation, which I wanted to replace with something faster since ages but never got around to do so. As these functions know nothing about the image geometry, its hard to add the projection specific stuff to them. The functions are called from src/hugin1/hugin/MainFrame.cpp:1308 and src/hugin1/hugin/CPEditorPanel.cpp:1016 There all the image parameters are available from the m_pano object. Additionally, some time (several years in fact) ago, I have started to play with a window that shows corrected closeups of the control points. That code is still available in src/hugin1/hugin/CPZoomDisplayPanel.cpp but the window is currently not build nor used. I think there are might be some smaller mistakes in how the image is transformed, but the CPZoomDisplayPanel::updateInternal() function should contain code that tries to point a virtual camera on the control point location and uses that to remap the image. Probably it would be best to create some wrappers that look a bit similar to vigra_ext::PointFineTuneRotSearch() vigra_ext::PointFineTune() which actually remap the images (using the half finished code from CPZoomDisplayPanel::updateInternal() as a blueprint) and then in turn call vigra_ext::PointFineTune. 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
Hi Lukáš, Lukáš Jirkovský wrote: Hello, I'd really want to participate, but I've not yet decided what should be my application. think about two things: 1. Making deghosting act more like as a library. This probably would ease integration to enfuse. The second part would be adding algorithm described in [1] or adding support for deghosting to enfuse. The problem of this is that I think I'd not be able to do the math of the algorithm without help (there are some things I've never seen before). While I won't be able to be a full time mentor this year, I'd be more than happy to answer your questions about the algorithm in [1]. Don't let the formulas scare you. From a quick look it seems to work quite similar to the khan deghosting (whose paper also sounds more complicated than it really is), but contains additional steps to further improve the results. If I would decide to integrate it to enfuse instead of implementing mentioned algorihtm the problem would be in fact that both khan and this algorithm are intended for use with HDR. Actually, both algorithms produce a weight values for each pixel in each exposure. This weight value could be combined with the weight enfuse computes for each pixel. Anyway, even if I would choose one of these goals I'd like to implement also the second one but I think it would be quite problematic to do the both during summer so the second one wouldn't have so high priority. I don't think doing both is possible in a summer, especially when time for learning how the algorithms really work is also needed. 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: Fine-tune and wide-angle lenses.
Hi Peter, Peter Gawthrop wrote: As far as I know, Fine-Tune is unaware of lens effects. If so, it seem that the general solution would be to make Fine-Tune aware of the lens and, for example, map the two small areas used by Fine-Tune to the centre of the image for processing and then map back again. Indeed, that would be very nice, if the lens parameters (mainly HFOV) are approximately known. An additional least square matching after the correlation search would lead to even better subpixel accuracy for the control points. 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: Celeste.model is not found on win32
Yuval Levy schrieb: Guido Kohlmeyer wrote: Meanwhile I found huginApp::Get()-GetXRCPath(), which is the same. is there a reason to have twice the same thing, or is this a redundancy? if it is, from which class does it make sense to get the XRCPath? from huginApp.h or from MainFrame.h? Hmm, I don't remember why I did this. Probably because initially the path was handled by MainFrame and not by HuginApp. Probably MainFrame::GetXRCPath() can now be removed and replaced with HuginApp::GetXRCPath(), which I probably intended to do by somehow forgot to actually do. 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: What is the status of keypoint detection and keypoint matching: machpoint (gsoc2007) and feature_matching (gsoc2008)
Hi Bruno, Bruno Postle schrieb: On Wed 25-Feb-2009 at 14:19 +0100, Harry van der Wolf wrote: During gsoc 2007 Zoran Mesec created/worked on matchpoint: the patent free keypoint detector. As far as I'm aware matchpoint works fine, but still has problems dealing with transparency masks. True or wrong? Anyone who does know, please explain. Any relevant info that I didn't ask here is welcome too. If I understand Zoran correctly, matchpoint is very good at detecting scale invariant features, but the feature descriptors generated are not as good as those from SIFT or SURF. Yes, the interest point detector in matchpoint works ok, but the descriptor is currently not good. I'm not sure that this is very important - Current feature matching tools such as those in Onur's project, panomatic or autopano-sift work entirely by comparing these descriptors, but for panoramas we can compare the geometrical relationships between points too. During gsoc 2008 Onur Küçüktunç created/worked on feature_matching to be used in combination with matchpoint. Is this now (relatively) mature or not? It worked for me, but I have no idea why it wasn't integrated. Even if the results are not so good, any patent-free control point finder is better than none. I remember that the feature detection code just contains duplicate copies of the matchpoint code, so we would have the same code in two locations: src/hugin_base/algorithms/control_points and src/matchpoint The code in matchpoint should be made a library and linked from within hugin. I will have some time for hugin development this month (wife and baby are traveling, I'm stuck at home...), and I will look into these issues and make sure that we will have patent-free solution that is well integrated into hugin. It is implemented as part of the hugin GUI which makes it impossible to script around. I would very much like a command-line version (equivalent to the 'autopano' tool from autopano-sift-C). Combination of matchpoint and match-n-shift: Is this now a working keypoint detection/matching combination as such or does match-n-shift just use autopano for the keypoint matching? match-n-shift uses a combination of autopano-sift-C and align_image_stack. There is a --matchpoint option which substitutes the 'generatekeys' part of autopano-sift-C, but it doesn't work because of the alpha channel bug. Even so match-n-shift still uses the 'autopano' part of autopano-sift-C for feature matching. [later...] I just added an ImageMagick workaround to match-n-shift --matchpoint and now it seems to work ok. Also match-n-shift runs ptoclean as a final step, so it kind-of does the 'geometrical' check needed. I hope Pablo will add to this thread, he mentioned that between the various projects (matchpoint, panomatic, autopano-sift-C, feature_matching) there is all the code necessary to paste together a complete patent-free solution. So we have: matchpoint (see above) autopano-SIFT (patented algorithm (although the SIFT patent seems rather weak and might not apply if the SIFT descriptor is used together with another interest point detector). panomatic (SURF, also patent. However, the interest point detector alone is not really patented, so we just need another feature descriptor). The panomatic code is very nice and clean, and contains all the required matching stages, including a ransac step for throwing out outliers (which probably currently doesn't work with fisheye images and very wide rectilinear ones). I have already created a separate executable of the keypoint generator, it should be quite easy to do so for the matching stage, too. Otherwise, a command-line version of Onur's feature matching would be enough to allow me to make match-n-shift 'patent-free'. Actually, something like ptoclean should really be part of the core functionality in hugin. Hmm, so should we make your perl modules a requirement for hugin? Actually, I have also started a python wrapper around the core hugin libs (using boost-python). I also hope that this will be finished the end of this month, but I'm not sure if I can finish both the feature matching and the python interface. (as I mostly write code during the day, so its sometimes not that attractive to do the same in the evening, too). 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: EXR tweaks
Lukáš Jirkovský schrieb: Hello, As I'd like to show that I'm still not bored hacking hugin I've done some tweaks to EXR implementation in Hugin, unfortunately none of them is tested. 1.) workaround for bug causing clipping of some data (changes in ExrEncoderImpl::nextScanline() and rewriteFileUsingScaleFactor() function). This really needs testing but I don't have any image suffering from it. My ask for any test case is still valid. Anyway, what do you think about it? May it work correctly? I've explained how it is supposed work in comment in bug #1850361. You can simply set the ev parameter (lens tab, photometric) of an image to something above 16 and should be able to see the results. Rewriting the image has the nice property that it is completely independent of the calling code, but unfortunately its a bit costly. It would be possible to compute the scaling factor without rewriting the image, but this would require that the max of the image is computed somewhere inside the exportImage() functions and not in the codec itself. However, the vigra impex code is quite messy and hard to understand. 2.) added support for different compression algorithms. I've not have enough time to test because I'd like to add it to the GUI first (I don't like changing this directly in code even for testing). This part of the patch should probably work. I think enblend handles the compression arguments straight to vigra. With hugin it should be possible to modify the .pto file and set the type by changing #hugin_outputImageTypeHDRCompression newcomp 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: Trying to build hugin under native mingw
tennevin yves wrote: I have been trying to build hugin under native mingw, I am trying first with hugin7.0 source, since it's supposed to compile. I managed to compile the dependencies Now I am getting some errors when wxWidget is invoved in the make. getting errors like `wxConvISO8859_1' was not declared in this scope Anyone know how to fix it (or to have an idea of what is exactly the problem)? Maybe its a wxWidgets ANSI vs UNICODE build problem. Hugin should be build and linked against wxWidgets compiled with unicode support. ciao Pablo Y. tennevin / esby -- Make buildlog $ make [ 9%] Built target huginANN [ 19%] Built target huginvigraimpex [ 22%] Built target huginlevmar [ 24%] Built target huginjhead [ 24%] Built target huginlensdb [ 55%] Built target huginbase [ 55%] Built target open_file [ 56%] Built target align_image_stack [ 57%] Built target autooptimiser [ 57%] Built target fulla [ 58%] Built target nona [ 59%] Built target pto2mk [ 59%] Built target tca_correct [ 60%] Built target vig_optimize [ 62%] Built target matchpoint [ 65%] Built target hugin_hdrmerge [ 66%] Building CXX object src/hugin1/base_wx/CMakeFiles/huginbasewx.dir/PTWXDlg.obj In file included from c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin1/common/utils.h:27, from c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin1/panoinc.h:70, from c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin1/base_wx/PTWXDlg.cpp:28: c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin_base/hugin_utils/utils.h: In function `Target hugin_utils::lexical_cast(Source)': c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin_base/hugin_utils/utils.h:233: error: `wxConvISO8859_1' was not declared in this scope In file included from c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin1/common/stl_utils.h:36, from c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin1/panoinc.h:72, from c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin1/base_wx/PTWXDlg.cpp:28: c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin_base/hugin_utils/stl_utils.h: In function `typename Map::mapped_type map_get(Map, const typename Map::key_type)': c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin_base/hugin_utils/stl_utils.h:95: error: `wxConvISO8859_1' was not declared in this scope c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin_base/hugin_utils/stl_utils.h: In function `const typename Map::mapped_type const_map_get(const Map, const typename Map::key_type)': c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin_base/hugin_utils/stl_utils.h:107: error: `wxConvISO8859_1' was not declared in this scope c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin_base/hugin_utils/stl_utils.h: In function `typename Map::mapped_type map_get(Map, const char*)': c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin_base/hugin_utils/stl_utils.h:120: error: `wxConvISO8859_1' was not declared in this scope c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin_base/hugin_utils/stl_utils.h: In function `const typename Map::mapped_type const_map_get(const Map, const char*)': c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin_base/hugin_utils/stl_utils.h:132: error: `wxConvISO8859_1' was not declared in this scope In file included from c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin_base/panodata/PanoramaData.h:37, from c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin_base/panodata/Panorama.h:28, from c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin1/PT/Panorama.h:27, from c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin1/panoinc.h:77, from c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin1/base_wx/PTWXDlg.cpp:28: c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin_base/panodata/SrcPanoImage.h: In member function `void HuginBase::SrcPanoImage::setRadialDistortion(const std::vectordouble, std::allocatordouble )': c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin_base/panodata/SrcPanoImage.h:170: error: `wxConvISO8859_1' was not declared in this scope c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin_base/panodata/SrcPanoImage.h:170: error: `wxString' was not declared in this scope c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin_base/panodata/SrcPanoImage.h:170: error: `wxLogFatalError' was not declared in this scope c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin_base/panodata/SrcPanoImage.h: In member function `void HuginBase::SrcPanoImage::setRadialDistortionRed(const std::vectordouble, std::allocatordouble )': c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin_base/panodata/SrcPanoImage.h:178: error: `wxConvISO8859_1' was not declared in this scope c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin_base/panodata/SrcPanoImage.h:178: error: `wxString' was not declared in this scope c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin_base/panodata/SrcPanoImage.h:178: error: `wxLogFatalError' was not declared in this scope c:/msys/1.0/home/keby/hugin-0.7.0/src/hugin_base/panodata/SrcPanoImage.h: In member function
[hugin-ptx] Re: Patches for TMPDIR, which one is better?
Hi Lukáš, I had a quick look at the patch, and it looks good (I haven't had time to do any testing...). ciao Pablo Lukáš Jirkovský wrote: No response? So if nobody will complain about it, I'll put it into the trunk tomorrow. --~--~-~--~~~---~--~~ 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: patch for bug #2033756 call for testing
Hi Yuv, Yuval Levy wrote I've tested quickly hugin_hdrmerge in Windows. I applied your two patches (30/Jan and 31/Jan). The good news is that it builds and it seems to get further than it used to. The bad news is that it still crashes. I am trying to merge three 16bit TIFF images of 8megapixel with the following command: hugin_hdrmerge.exe -wl -ad -v -o p.exr p1.tif p2.tif p3.tif Actually, hugin_hdrmerge assumes that p1.tif, p2.tif and p3.tif are already images where the gray values correspond to intensity values (ie. if corresponding pixels are exposed well, they should have the same value). Suitable images are the .exr files created by nona, but not the original 8 or 16 bit images. The deghosting will not function properly if it is feed with raw, non-exposure normalized input images (.jpg or normally converted RAW image). The deghosting will compute differences between the images and choose the color values where most images agree. This means that the gray values inside the images must be comparable (for example, proportional to the physical intensity). 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: patch for bug #2033756 call for testing
Yuval Levy schrieb: Hi Pablo, Pablo d'Angelo wrote: Actually, hugin_hdrmerge assumes that images where the gray values correspond to intensity values Aha. (ie. if corresponding pixels are exposed well, they should have the same value). Suitable images are the .exr files created by nona, but not the original 8 or 16 bit images. The deghosting will not function properly if it is feed with raw, non-exposure normalized input images unlike enfuse? so if we want deghosting for enfuse we need to first normalize the input images? wouldn't that defeat the purpose and the beauty of enfuse? It is possible to do a shortcut, as we only need a function that can tell us how well two gray values in an image pair fit together. I think it is possible to compute such a similarity fuction using mutual information, or just using the joint histogram (sometimes called coocurrence matrix) as distance metrics. It would be possible to add a special mode for that to hugin_hdrmerge. The output would then be the normal images, with the ghosts masked out in the alpha channel. I haven't really played a lot with enfuse and the alpha channel, but if I remember correctly, there are some problems with visible seams when fusing images with masked out areas. It would be good to try a manual deghosting first, and see what happens when painting the ghost black, and masking it out using the alpha channel. 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: new projection: architectual
Daniel German schrieb: Now, regarding hugin. Some time ago I modified libpano to report the projections available to hugin. The idea was that hugin does not need to hard code the projections, but rather can query them from libpano. This meant that you just need to recompile, install libpano and the new projections are available. Isn't that the case any more? The function that reports all data about a projection is query_feature, I think. In principle, that is used, however, there are some problems with the heuristics used to do the FOV computations and the fast preview. I'd have to do a deeper check if that could be abstracted out of hugin and placed into libpano as well. 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: Release 0.7.0 for Win32 available
Hi Guido, Guido Kohlmeyer wrote: Dear Yuv, I modified the license text slightly and build a new setup file. It can be found at http://hugin.panotools.org/testing/hugin/hugin-0.7.0_win32-setup.exe the MD5 checksum is available as well http://hugin.panotools.org/testing/hugin/hugin-0.7.0_win32-setup.exe.md5 I have just uploaded this installer to the sourceforge. Thanks a lot for building it! 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: hugin-0.7.0 released
Hi Bruno, Bruno Postle wrote: Congratulations to everyone responsible for this release! Thanks a lot for doing the final hard work for making the release possible. Also thanks to all other developers who made this happen. I have been very busy with day time work and other commitments lately, so I didn't have the time to really contribute to hugins development lately. As for the further development, I agree with Garry that we should do an svn cp hutin/trunk hugin/branches/release-0.7.0 to create a stable branch, which could be used for urgent bugfixes, should the need occur. We could then merge the gsoc_integration branch into the trunk and contine developing the new functionality for the 0.8 release. Any objections? 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
