Thanks Yuv for your very detailed response! The project did use a pano head, so all stacks will be aligned with the exception of the nadir, which may have some slight movement, so I add control points to align the Nadir and specify a different lens after the intial alignment. I am still using autopano-sift-c. Yes, I use a lot of control points then delete many during the processes of successive optimizations. I can usually acheive about 0.3 pixel mean error for a 16k wide pano.
For this project, the intital alignment looked fine. It was when I removed the outlier control points and realigned when I ran into problems. Seems like my choice for optimization parameters may have caused the problems. Let me try it again when I finish my current project. Should be able to report back in a few days. If I continue to have problems, I will open a bug report. Thanks again for your very detailed response! Regards, Rick On Dec 27, 12:39 pm, Yuval Levy <[email protected]> wrote: > Hi Rick, > > On December 26, 2010 09:33:28 pm RueiKe wrote: > > > My attempt to use the latest build on a typical complex project > > indicates significant issues. > > I downloaded your PTO file but did not have time to look at it right away and > now I don't have the "significant issues" you mentioned present. However I > played with it and found no "significant issue". > > The project loaded well (with placeholder images, that is). The application > is responsive. > > I see 31 stacks defined. I see a lot of CPs. I don't recall how you > generated them; nor can I visually judge their quality. I find the quantity > excessive - personally I would do such a project with less than 200 CPs, while > you have more than 9000. Even if this was about stitching 217 individual > frames (single exposures; or misaligned stacks), 1000-1500 CPs would be more > than enough. > > I assume that the stacks are perfectly aligned (shot on a tripod or so), and > that you want to tonemap a resulting HDR. Have you considered merging each of > the stacks first into an HDR image first using pfstools or LuminanceHDR? This > would cut computational work by as much as 80%. > > It would be helpful if you could detail the issues in ticket(s) on the bug > tracker so that when trying to figure them out, developers don't have to > scramble around for information. > > I am working on this in my spare time. I keep folders on my HDD - one folder > per issue - and the name of the folder is usually the number of the tracker > ticket (but in this case it was your pseudonym because there was no tracker > ticket). It takes only a few seconds to be back on the right page that way. > It takes much longer if there is no ticket. > > > I understand that my use case of 217 images is not typical > > It may not be typical in the sense that it is not the average project; and > that probably there is a more efficient way to deal with the project; but it > is not unique in terms of size. There are other users processing that amount > of images and more. > > > , but I think it has always been a critical feature for hugin to be able to > > handle very large projects. > > "critical feature" is a bit of an inflated qualification. There has never > been any kind of warranty, implied or explicit, that Hugin is fit for any > purpose. It is true that Hugin has been handling successfully projects of > this size and larger in the past; that we take seriously reports such as yours > and try to help you get the most out of Hugin. But a single report from a > single user is never critical until confirmed. > > If the report was in the bug tracker, other users experiencing the same issue > could confirm; add their own experiences and observations; and we would get a > better picture of whether this is critical or not and what we are dealing > with. > > The basic assumption for now is that this is a specific issue of your specific > situation. And with all due respect, even if you say that this happens to you > in a number of projects (like Milkman with the Samyiang lens), the basic > assumption stays that it is an issue of your setup and not of the Hugin code. > > To be considered an issue with the Hugin code, it must be confirmed by more > than one user. This is what we have triagers working on the bug tracker for. > > > I have gone back to 2009.4 with no issues. > > That's a long way back. I would be surprised that an issue is hiding in the > code for one year with no report. You will forgive me for thinking that the > issue is on your end rather in the Hugin code until proven different. > > > Let me know if there is any other > > testing needed for the issue I described the the RC1 thread. > > I see that the optimizer is set to optimize custom parameters. The choice of > custom parameters is to optimize one exposure for each stack; and for each of > those exposures it is set to optimize y/p/r/X/Y/Z. Plus the lens parameters. > > all in one go. This is calling for troubles. > > I assume this is a panorama, not a mosaic. 2009.4 works for you because it > did not have X/Y/Z so it did not let you optimize for those parameters that > need no optimization. > > Indeed, I get what seems to be very reasoable results. > > To do so, I first optimize only y,p,r,v in a first run. > > Optimizing the lens distortion parameters before the images are properly > distributed is risky since the optimizer can run into a bad local minimum. > > In general I would recommend that you calibrate your lens once and then use > those calibrated values for the v/a/b/c values. Or not optimize for a & c at > all. > > I also see that you have two lenses defined. I assume it is for the nadir? I > would optimize nadir position and lens in separate optimization runs. > > My ageing Athlon 64 X2 6000+ with 8GB RAM processed the optimizations in a few > minutes while staying very responsive, playing an internet radio in the > background and letting me play backgammon and write this message. > > I can not verify the results visually, and did not go into much more detailed > optimization (e.g. using X/Y/Z for the nadir only, but only if the CPs > connecting the nadir to the other images are on a flat surface; and by > temporarily transforming the pano so that the nadir is at the center of the > equirect, on the horizon. > > I am sure better results can be obtain with pruning and further fine tuning. > But overall I see no problem. > > Attached is my (blind) result. Please confirm if it is garbage or not, and if > you can improve on it by pruning CPs, etc. > > I hope this feedback helps you make sense of 2010.4 and that we can see more > of your creations on Flickr. > > Yuv > > dummified_DR13_Rev1.pto > 638KViewDownload > > signature.asc > < 1KViewDownload -- 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx
