Ok, I have now read the tutorial and thank you again for pointing me to it. Given the problems my sloppy postings have already caused, I probably ought to just move on to the next part of the challenge, but as I am still confused, and suspect that others are as well, let me add some comments concerning that tutorial.
First, credit is due to JohnG who, in response to an earlier version of my 'cry for help' first pointed out the necessity of correctly setting the check boxes on the Optimizer Panel as a means to 'guide' the software. His suggestions helped me get to something workable, but he recommended that the settings be such as to tell the software to work on yaw, pitch and roll, which seemed contrary to me, and indeed, resulted in a pretty nice composite, but one that had 'wavy distortions'. It was from that that I came to the idea of setting the check boxes so as to have the software attempt to solve the [to me] simpler matter of mere X,Y,Z offsets. My latest, successful tests do, as it turns out, almost exactly mimic the recommendations of the tutorial. So, here is the big question. John is very knowledgeable and he suggested yaw, pitch, and roll AND the tutorial says that we ought also be able to 'skin the cat' by letting the software optimize the r, v, d and e parameters. Is there a nice article, in lay terms with minimal jargon, to explain either why the results would be identical, or if the results would not be identical, what the shades of difference would be between those three seemingly very different approaches? Moving on, assuming that the technique of the tutorial, provides a very good outcome, I would appreciate any input on the next problem. For those who read the earlier postings, I was first able to get a good outcome with Photoshop, but even after upgrading to CS5, the limit of that solution stands at around a 4x4 grid, so I am looking at Hugin, or PTGui to not only get a good outcome, but get a much larger sub-set of the entire 104-patch composition. So, last night's successful run, using full-resolution tif inputs and a full-resolution tif output, I watched/monitored Task Manager as NONA did her thing, then I watched ENBLEND start working on the first two patches, then it added a third, then a fourth, until it had blended all six. Since the logging mechanism did not include timestamps, you just have to accept that I was a pretty reliable observer. Two blends, about two minutes, add the third and add another 4-5 minutes, add the next patch, and that cycle extended to 8-10 minutes. It seems like a processing signature doomed to failure if I try to process 40-50 patches -- each successive iteration close to exponentially slower [though memory consumption remained about level, just under 1.5GB]. The total run took just under an hour for just six patches, and it seems as though the reason it might be less susceptible to memory management problems is that it has opted for a file management strategy. The CPU utilization would only briefly and intermittently jump up to 25% [on my quad-core box], most of the time the process is completely disk I-O bound. So, two questions. Other than using compressed data [which I do not wish to do, because much of the value of the end product is directly proportional to the high quality, greatly zoomable tiff formatted data], are there things that can be done to improve the projection/ blending output stages? And, assuming that, as was elsewhere suggested, I just have to click the button and cross my fingers, if I am going to launch a process that might very well run for more than 24- hours, is there any check-point/restart capability in all those underlying make file shell scripts? On Mar 5, 10:44 am, Andreas Metzler <[email protected]> wrote: > tcorbet <[email protected]> wrote: > > [...]> So, let me first dare to disagree with the opinion that the set of > > images are "not shots of one drawing". I believe that, in contrast to > > what happens when a single camera takes multiple of shots of a scene > > without changing its XYZ coordinates on the planet, the result of this > > super-human drawing effort results in precisely one image, not the > > patchwork of images that would result from a camera. What is > > different about those 104 plates is that if they were placed on the > > floor of a basketball court, but instead of letting the small [about > > 1/4 inch] of overlap exist, you took out your box cutter and precisely > > trimmed them to eliminate overlap, to people sitting in the bleachers, > > the scene total would be displayed almost perfectly. > > [...] > > If that is the case, you are > here:http://hugin.sourceforge.net/tutorials/scans/en.shtml > cu andreas -- 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
