On Friday, January 21, 2022 at 7:20:51 PM UTC-5 [email protected] wrote:
> > I never quite understood what made the magnifier come and go, so > anything you can do to make this more predictable. > Without a clear statement of the original intent, there is no way I would try to fix the code for removing the magnifier to behave as intended and predictably. For my own use (and based on what you said, maybe for others), I would entirely eliminate the existing code for removing the magnifier other than because that control point is no longer selected: never remove based on a timer, never remove based on the main zoom level. Then I would select some key and make that hide the magnifiers. > > > When zoomed-in, if I go to drag a control point that is not in the > centre of the viewport then the view jumps to centre the viewport on > this location - but my mouse is still in the corner of the viewport - > placing the control point in a location nowhere near the original > location. Thanks for explaining several of my problems. I should have realized that was what was happening. But somehow I failed to understand and just thought that sometimes a really random glitch occurred. That sounds like something harder to fix than I was expecting to tackle soon. But also it sounds like the most important defect to fix. I'll take a look at the code. I assume it will be obvious where/why that happens and entirely not obvious what can be done instead. But I'll look and think about it. > > > The Mask tab can show the location of include masks in other images as > an overlay on the current image. Sounds like code I'll be interested to look at. In the Control Points tab it would be > nice to do something similar But likely more than I want to attack. > > 5) Global stable numbering of points (as an option if this gets shared > with others). I'm sick of losing track as points renumber. I want a gap > left when I delete a point, that may be reused for a new point but won't be > reassigned to a different point. > > This might be difficult given the underlying data structure, but I > don't know for sure. > Maybe I'll be surprised. But from what I've seen, it shouldn't be too hard. I really want that feature, so even if it is difficult. > > Note that the pano13 library doesn't support > control points that match more than two images (at the moment). > Thanks for the warning. That will be a big annoyance. But would not really defeat my initial intent for this. Some of my follow-on ideas for control points in 3+ images would need pano13 library support. I'll worry about that when/if I get closer to it. > > Hugin builds on most Linux systems using standard libraries that are > provided by the distribution, i.e. if you download the right -dev > packages using apt or dnf or whatever, building Hugin is incredibly > simple. What problems are you having (maybe start a new thread)? > I didn't take notes as I kludged past issues. I'd rather be in Fedora than in Ubuntu for this anyway. So I think my best path on that is to do it over from scratch on Fedora and capture details each time I need to kludge something. Then I'll put all that in a new thread here. Some of the Ubuntu issues seemed to imply the dependency packages in Ubuntu were too new for hugin. That took some minor kludges. It did not take downgrading any packages (as more serious such issues would). My son's suggestion (which I might be forced to follow) is to create a VM in order to install whatever package version is easiest for hugin build even when that is too old for other things in the real system. My Fedora install is several versions more up to date than Ubuntu on several things, so I expect such issues to be bigger. But I still expect to kludge past any rev-too-new issues rather than downgrade dependencies. Despite lots of varied software engineering experience, I never used cmake before trying to build hugin. Likely I'm just using cmake wrong. But I usually couldn't get it to believe it had found dependencies even when it not only had found them but reported the correct location right before aborting because the result variable of looking was set to "not found". On Linux I got past that with lots of manual edits to CMakeCache.txt. On Windows, I never got past that and build hugin.exe from source files without cmake. Anyway, that is too much build issue sidetrack for this thread. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/6af9c424-650c-4fa8-b87d-d5fc62b2628en%40googlegroups.com.
