[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 thres

[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

[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 su

[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'Angelo 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

[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 dr

[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 Martin<360cit...@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 fisheye

[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 CP

[hugin-ptx] Re: cpfind ransac mode

Hi Oskar, Am 11.02.2011 08:12, schrieb Oskar Sander: Maybe a stupid question, what happens when ypr are not the most significant parameters like in a "mosaic"?Will any of the RANSAC models work (I would assume one has to use the old version if anything...) The homography model should work

[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 Sca

[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 availabl

[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 th

[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 i

[hugin-ptx] Re: BEBUG_WARN, cerr and Python

Hi Kay, Am 23.01.2011 09:32, schrieb kfj: cerr<< "WARN:"<< "blah blah"<< endl ; All I get to see in Python is WARN: Speicherzugriffsfehler (that is, memory error.) - so I get to see the first string 'WARN:' but then the crash happens, which looks like an error in cerr.operator<<(). The st

[hugin-ptx] Re: Test case for cpfind

Hi Yuv, Am 23.01.2011 04:33, schrieb Yuval Levy: > can somebody please check why Hugin/cpfind has difficulties with this set of > images from Michel Thoby? > > http://www.sendspace.com/file/vnek81 I tried the set with the following steps: With assistant: 1. load images, set 14 mm rectilinear

[hugin-ptx] Re: clustered hugin

Hi Michael, Am 22.01.2011 12:20, schrieb michael.grant: Unless you do something like this, I can't see how hugin is going to be able to create a pano any greater than the available swap space. How difficult would it be to rework emblend to do something like the above? Enblend can use temporar

[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

[hugin-ptx] Re: Cpfind for Dummies

Hi Carl, On 21 Jan., 09:07, Can-C. Dörtbudak 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.doertbuda

[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 mig

[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

[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

[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,

[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

[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 sho

[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. Th

[hugin-ptx] Re: hairy bug: control points outside image crop circle

Hi Tomato, On 17 Jan., 16:03, bloody tomatoes 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

[hugin-ptx] Re: hugin plugin interface - developers please liaise

Hi Kay, On 17 Jan., 11:47, kfj <_...@yahoo.com> wrote: > On 16 Jan., 19:39, Pablo d'Angelo wrote: > > > Btw. in order to make it easier for us track your work (and add > > improvements etc.), it would be great if you could offer a hg branch of > > it (maybe not

[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

[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: > 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

[hugin-ptx] Re: hugin plugin interface - developers please liaise

Hi Kay, Am 16.01.2011 18:32, schrieb kfj: > Once I've test-run the code from hugin I'll publish through the usual > channel. So far there has been so little echo to my work that I am > getting the feeling that hardly anyone actually reads my posts or is > at all interested. This is regrettable,

[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 bef

[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 f

[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) correction

[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 project

[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 the

[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ý 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 c

[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 pe

[hugin-ptx] Re: patent-free panomatic: segfaulting on 64bit MacOSX

Hi Harry, Harry van der Wolf schrieb: Hi, 2010/4/23 Pablo d'Angelo <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

[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 o

[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 projec

[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 m

[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

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

[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 c

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.

[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, how

[hugin-ptx] Re: preview and fast preview clipped to 180deg

Hi Alexandre, Alexandre Duret-Lutz wrote: Hi, Any idea why hugin would clip all pictures (but the first!) on a 180x180 square in the middle of my 360x180 panorama? http://farm5.static.flickr.com/4060/4365499963_b446f6ab2f_o.jpg This can happen if an image has nonzero TrX, TrY, TrZ parameters

[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 stra

[hugin-ptx] Re: Towards a non-patented control point detector

Pablo d'Angelo wrote: Currently, it should be a drop in replacement. A new name would be nice. There is no way to build my extended package without the SURF descriptor, so its not yet suitable for general redistribution, some more small modification to the build scripts are necessary

[hugin-ptx] Re: Towards a non-patented control point detector

Bruno Postle wrote: On Thu 11-Feb-2010 at 09:18 +0100, Harry van der Wolf wrote: I'm not totally happy with the name panomatic is that is already an existing name for an existing CP matcher/detector. Can't we call the panomatic binary something like "cp_matcher" or "hugin_matcher" or "hugin_

[hugin-ptx] Re: Hugin's vignetting formula

Robert wrote: Hi, I find this a bit dubious, since the input is a camera JPEG, and therefore I would expect the manufacturer to compensate for sensor gain and normalise it for display purposes (i.e., apply inv. gamma). Cameras are made to make nice to look at pictures, not as scientific measu

[hugin-ptx] Re: Towards a non-patented control point detector

Tom Sharpless wrote: Hi If OpenSurf is legitimately GPL there cannot be a patent problem with SURF. So why not use it? From what I have seem, it pretty much uses the algorithm as it is described in the SURF patent, so I doubt that it is a safe alternative in that sense. > It is the fastes

[hugin-ptx] Re: Towards a non-patented control point detector

Hi Harry, Harry van der Wolf wrote: - The mail mentions that a "a small part of the SURF algorithm to estimate the orientation of the interest point" is still used. You mention that you hope to replace this in the future. Can you give a rough estimate or could this be a GSOC 2010 project? A

[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 messag

[hugin-ptx] Re: APSC gives array out of bounds?

Zoran Zorkic wrote: On Jan 29, 12:01 am, Bruno Postle 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.

[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 t

[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

[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 fix

[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 correspo

[hugin-ptx] Re: Towards a non-patented control point detector

Hi Harry, On 3 Jan., 13:08, Harry van der Wolf 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

[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)

[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 shou

[hugin-ptx] Re: CP Detector vs. Generator

bruno.postle wrote: > On Dec 21, 2:51 pm, Mick Crane 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

[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 (maxflo

[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 th

[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 diff

[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 t

[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 su

[hugin-ptx] Re: GSoC2009_layout with XYZ for Windows - please test

Oskar Sander schrieb: > Pablo, when you said that you are working on this, did you refer to > the "optimization strategy" above, or the image-load-bug? That was for the optimisation strategy. I'm also playing around with extenting the XYZ with two more parameters that specify the plane that is

[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 afte

[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 capt

[hugin-ptx] Re: Aerial Photography Stitching

Hi Matt, Matt Williams wrote: > 2009/9/22 Pablo d'Angelo : >> >> 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

[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

[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,

[hugin-ptx] Re: I just committed the following:

Hi! I have just added support for the TrX, TrY, TrZ parameters to the gsoc2009_layout branch. This branch now requires the latest svn version of libpano. ciao Pablo D M German schrieb: > > > In a nutshell, > > First warning. I had to reindent some functions. use svn diff -x -w to > get

[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

[hugin-ptx] Re: Aerial Photography Stitching (using new mosaic mode)

Hi Oskar, Oskar Sander schrieb: > Thanks, I see. So the method was to take one shot as straight down as > possible and then to take consecutive shots panning out towards the > horizon perpendicular to the flightpath, and then repeat that procedure > from the downward view, right? Looks like i

[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 ima

[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

[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

[hugin-ptx] Re: Aerial Photography Stitching (using new mosaic mode)

Pablo d'Angelo schrieb: > Matt Williams wrote: >> 2009/9/22 Pablo d'Angelo : >>> Hi Matt, >>> >>>> This is the method I had been using before, but obviously without the >>>> Tilt parameters and so it really struggled. >>> Ac

[hugin-ptx] Re: Aerial Photography Stitching

Matt Williams wrote: > 2009/9/22 Pablo d'Angelo : >> 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 satisfie

[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?

[hugin-ptx] Re: Aerial Photography Stitching

Matt Williams wrote: > 2009/9/22 Oskar Sander : >> 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 ae

[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 pla

[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 (la

[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

[hugin-ptx] Re: cpclean - put it into trunk?

Hi Yuv, lets put it in. ciao Pablo Yuval Levy schrieb: > Hi all, > > cpclean is a button in the Hugin GUI that prunes outlaying CPs by > statistical methods. It has been written by Thomas Modes' and it works > like Bruno's tried and tested CLI tool ptoclean. A useful addition IMO. > > It

[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

[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 d

[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 Open

[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

[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

[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

[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 lis

[hugin-ptx] Re: Exposure value handling weirdness

T. Modes wrote: >> Why does hugin deal with absolute values of exposures of images? >> >> Can we bring in all of the images with an exposure of zero and then just >> apply exposure compensation instead? >> > > When using LDR output (enblend, enfuse) relativ or absolute exposure > should make no

[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 optimize

[hugin-ptx] Re: new project: glpano

Hi prunkdump, prunkdump wrote: > argh!! I'am discovered! > > Hi, > > I'am the author of glpano. I'am very new in programming (and in > english) so excuse me if some of my code is not conform to the open- > souce coding standards or if I the project doesn't respect some GNU > licences. This will

[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.

[hugin-ptx] Re: GSoC2009 Students: Next Steps

Lukáš Jirkovský schrieb: > 2009/4/4 Faruq : > 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

[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::Poin

  1   2   >