You might want to jump down to the "TESTING" section below before reading all this concept level content:
In a branch of the Hugin++ fork of Hugin, I fixed a bunch of minor bugs that Hugin has display of CP labels and magnifier. After I do some other related enhancements and corrections, all that will be merged into the main branch of Hugin++, but I doubt it will ever get merged into Hugin. I'm writing this because of a few questions I'm curious about, including whether other Hugin users are bothered by these glitches (which bother me enough as a Hugin that I took the time to fix them. But I'm not a typical user). Also some of the glitches are Windows specific for reasons I understand, while many others also occur on my Windows system, but not on my Fedora system, but I can't tell whether the difference is due to Windows vs. Linux or is due to the obsolete WxWidgets I'm forced to use on Linux (due to an obsolete video driver I need for an obsolete display card). So if someone tests any of this on Linux with up-to-date WxWidgets, I'd like to know whether those bugs appear. A big part of the issue is related to a behavior that I decided to eliminate, because it would be very hard to get exactly right and because I didn't like it anyway: In Hugin, the positions of CP labels and magnifier are adjusted based on the edges of the visible portion of the scrolled image. In my version, those positions are set based only on the edges of the whole image. So a CP that is near the edge of the visible portion but not near that edge of the whole image might have its label or even magnifier off screen. I think it is perfectly reasonable and expected for those to be off screen: If the CP's you cared about were that near the visible edge without being near the whole image edge, you would have scrolled to fix that. Any opinions on that? In Hugin, the labels visibly jump around at unexpected moments for non obvious reasons because of the many flaws in the code for adjusting based on visible region. So eliminating that feature eliminates that distracting behavior. That was very frequent in Windows and happened, but less, in Linux. But also (maybe Windows only) those jumps interacted with race conditions in the use of WxWidgets, so you could have half the label stay in one position while the other half jumps to a new position. In Hugin there was code to avoid having the label overlap the magnifier except when you are so close to a corner as to have no choice. But that code was mostly wrong, so the overlap often occurs when the point is close to an edge but not close to a corner, so the overlap is unnecessary. I believe my version fixes that (overlaps only when there isa no choice). Another part of the same Hugin bug loses the label entirely for a CP very near the top left corner of the whole image. Another part incorrectly decides a 3 digit label (more than 100 CPs connecting two images) doesn't fit near the top or bottom edge, when actually it does fit. TESTING: Select a CP, then use the scroll bars to slide that CP out of view then back into view, being careful to keep the mouse on the slidebar and/or outside the image window (not over the image). On Windows, various different glitches occur depending on the speed at which you scroll to bring it back into view (and also varying based on which of the four edges it was temporarily off of). When you then move the mouse onto the image, it redisplays, fixing whatever glitches were visible, but also moving labels, which I find annoying. There is also a more serious bug, Windows only, that I fixed earlier in the same branch: With the mouse over the image press and hold shift then move the mouse (don't press a mouse button). Both images are supposed to move with the mouse, and actually do so if very few CPs connect them. If many CPs connect them (whether they are in the visible portion or not) then the images just jump around a bit with little if any net movement. How many CPs that takes depends on CPU speed and details of your display, but it is not likely to take any unreasonably large number. If you get and build my branch, it may be interesting to compare (hugin vs. my branch) for the behavior of CPs near the edges and corners of the whole image. That shows lots of subtle wrong behaviors in Hugin that fixed (but only bothered to fix because that was related to the more commonly seen glitches). I can provide Windows binaries of Hugin++, but it is enough effort to package those, that I won't do so unless asked. Providing Fedora binaries would be harder and there would be much less point. Building Hugin++ in Fedora from source code should not be difficult (Bruno answered my questions, making that easy. I will "pay that forward" if anyone needs any answers for making that easy. The wiki is obsolete, so you need different -dev packages installed than it says, but if you are just a bit more Fedora competent than I was when I started this, you can easily discover what packages you need). Building Hugin++ requires building its associated pano13 (rather than using the standard pano13) but it is easy to have both at once (both both forks of pano13 of Hugin). -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/a9750471-e9ff-490f-9252-74c94d9e60bcn%40googlegroups.com.
