On 8 Dez., 19:29, Lukáš Jirkovský <[email protected]> wrote:
> I quickly draw a sample image. I deformed the upper area a bit to > imitate possible deformed lines in panorama due to a bad fit. In fast > preview you would see something like this. Then you would draw lines > on it (red and green lines in image) - the crosses (yeah, that strange > thing is supposed to be cross) are control points of the line. > > The GUI would translate drawn line into control points defining a > line. The control points of the line doesn't have to correspond to the > "panorama" control points (ie. points which are now generated by > cpfind or any other detector). For example vertical lines in the > picture consists of three line control points but internally it could > create two control points defining a vertical line in each image > separately and add another two control points defining vertical line > across the images. NOTE: this was just an example, it could be > implemented differently. These control points could even be hidden to > the user in the control points tab, but that's an implementation > detail. Okay, I'll try and explain better what my argument is. The preview shows you an assembly of warped images, warped and positioned according to the roll, pitch, yaw, X, y, Z, fov etc. values currently in effect for each image. An arbitrarily picked point on the preview will correspond to a point in each of the images which populate that area. But the corresponding points in the images don't have to be images of the same object (in other words: the overlap isn't always perfect). They may be (within the bounds of matching precision) - particularly if the chosen point coincides with a fine- tuned control point, but somewhere else there may be a significant difference. You can visualize that in the preview by selecting to show differences - you'll see that the areas where images overlap aren't necessarily totally black. If there is a difference (and mostly there is, even if it may be small) - then which object point do you refer to - the one depicted by the first image, or the second image - or the third...? Control point creation - be it 'point' points or 'line' points always has to make references to locations in individual images, and not to the output, which isn't even known at that stage, that's why there is only a preview of it. Since hugin is such a good piece of software ;-) one sometimes forgets that the overlaps between images aren't perfect - even the preview often looks very convincing, and the intelligent stitching puts the seam so the errors are minimized - but, especially where one image's margin or corner overlaps with some other image, or where there are parallactic errors in the images, the differences are larger. Still the point remains that line control point creation currently is a bit awkward and could well do with a UI better suited to it's purpose. I have previously stated and am still convinced, that some editing features should be available that display warped images and possibly work on an assembly of those images in a view similar to the preview. My idea to deal with the issue of which of the images to apply the edit to is to allow to put them 'into focus' individually or in groups, thereby making it possible to set points in several images synchronously (if they overlap where the click happens) - but you must have a choice to do so, it mustn't be done automatically to all images which happen to be where you click. The current fast preview is not a totally precise instrument - it is there to give you an idea what the output will look like, but it's not as precise as the actual stitching process, and it doesn't know where the stitcher will put the seams. Control point picking should be done as precisely as possible - that's why in the control points tab you have the option to look at the image in 100% size, and then you can even fine-tune the control point to achieve sub-pixel precision. So the current fast preview is not precise enough for that, and it does not have a zoom facility yet. Bearing these inadequacies in mind, one could still attempt to instrumentalize it for the purpose of CP editing by equating image visibility to 'in-focus' status and then apply the picked points to all visible images, which would be very close to what you would like to have - it might be enough for many applications, and if more accuracy is needed one could fine-tune with the control points tab. But - and that's where I will end my tedious nit-picking monolog ;-) someone has to do it. I can't, since I still have only very vague ideas HOW hugin actually does what it does. It's apparently been put together by extremely clever people using very advanced libraries (and a fair number of those, too) - assuming that mere mortals (like me) could figure it out by just reading the code :( So all I can do for now is write wish-lists. with regards Kay -- 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
