Removing magnifier hiding timer etc. from CPImageCtrl.cpp

[johnfi...@gmail.com]

If there are no objections (in time before I actually do it) I will make a branch and make the small change described here as my first (of I expect many) commits on that branch.

If there is any disagreement on details (rather than overall objection to the change), please tell me that as well.

There are conditions under which the magnifier for the selected point in the control points dialog gets hidden without the point being deselected.

As a user, I find that very inconvenient.  Bruno seemed to agree in earlier discussion.

On occasion, I really want to hide the magnifier.  But there is no correlation between when it gets hidden by current code and when I want it hidden.  I want to add a key (my choice would be 'm') that will temporarily hide the magnifier if it wasn't hidden and will bring it back if it was.  Hiding would only be temporary: other actions make the magnifier appear and "hiding" would not suppress that.

I would entirely remove the timer.  It's only purpose is to hide the magnifier.  I see no logic to when that timer is used vs. not used.  Maybe the original intent was to always have that timer (never let the magnifier stay in view for over 2 seconds).  As a user I see zero value in timer based hiding of the magnifier.  But if others strongly disagree, (with significantly more work) I could invent a setting to allow that feature to be disabled (rather than take the feature away from everyone).

With my limited understanding of mercurial, I was able to see the timer feature was added by ippei in commit 91503d5bebff

I don't know this environment well enough to know how to find out who ippei is nor to find out when/why that commit was made.

I also want to remove all other existing logic for hiding the magnifier, such as hiding it when the image itself is zoomed 200%.  Subject to having a control point selected to be magnified, I want the new 'm' key operation to be the only thing that hides the magnifier.

Separately, I want to commit my changes adding 400% and 800% zoom and my changes adjusting the magnifier for higher zoom.  I expect the purpose of removing the magnifier at 200% zoom is that it isn't much extra magnification.  But I both still would want it even if it was only a little extra and want to increase how much extra it is.

Separately, I think the controls over the magnifier that are only in the registry on Windows (and I haven't looked for where they are on Fedora) ought to be in the GUI settings so they can be changed without regedit (I'm very comfortable with regedit but I expect most Windows Hugin users aren't).  At the same time a bit more control should be included.

I would tend to want to pretest and commit all those and related features all together.  But I have been warned that doing so would make things too hard for whoever reviews/merges my changes.  So I think the right size first chunk is just the changes related to hiding the magnifier.

[Luís Henrique Camargo Quiroz]

     Hi John!

     I have never really used 200% magnification, and the lack of the magnifier in it was the culprit. Even if the magnification were low, an important feature is the "high contrast" the magnifier provides.

     What about keeping the views at 200% and just the magnifier (or a bigger one) at the intended 400 and 800%? So the left and right views would show a bigger field of view.  I like to use manual control points, so the CPs are not on wrong places, never, so the stitched pano will have no great flaws... for my use case I like a big view, it helps to understand where I am moving to mouse in the scene. I fear that at 400 or 800% the view will show very few from the broader scene.

     I thank you in advance for your efforts and ideas for a better Hugin.  Wish you good work and luck!

    sincerely,

    Luís Henrique

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/22486fd0-4c32-43c2-ad90-49c45c4a7cfbn%40googlegroups.com.

--

--
Luis Henrique Camargo Quiroz
http://luishcq.br.tripod.com - http://www.christusrex.org/www2/cantgreg
http://panoramaslh.net/

[Gunter Königsmann]

That might be a point: If you want to hit exactly the right pixel on a retina display you'll have to resort to a powerful magnifier. If you find the right part of a scene on my 1280x800 screen a 8xmagnifier might instead be a way to get completely lost while a 1x magnifier will introduce helpful contrast.

[T. Modes]

It is difficult to comment because you are often mixing things. Or as an example you contradict yourself

johnfi...@gmail.com schrieb am Dienstag, 1. Februar 2022 um 15:41:14 UTC+1:

 Hiding would only be temporary: other actions make the magnifier appear and "hiding" would not suppress that.

and later

I want the new 'm' key operation to be the only thing that hides the magnifier.

 

I would entirely remove the timer.  It's only purpose is to hide the magnifier.  I see no logic to when that timer is used vs. not used.  Maybe the original intent was to always have that timer (never let the magnifier stay in view for over 2 seconds).  As a user I see zero value in timer based hiding of the magnifier.  But if others strongly disagree, (with significantly more work) I could invent a setting to allow that feature to be disabled (rather than take the feature away from everyone).

I disagree: I like the feature that the magnifier disappear so I have a better view on the whole neighbourhood of the cp. This makes it easier for me the judge the cp.

 

 

With my limited understanding of mercurial, I was able to see the timer feature was added by ippei in commit 91503d5bebff

No. This was a major overhaul of the structure. The timer was added in changeset 689b688f70f5.

I also want to remove all other existing logic for hiding the magnifier, such as hiding it when the image itself is zoomed 200%. 

The disabling of the magnifier for the 200 % view was added as a feature request. So there are uses which prefer this.

 

I would tend to want to pretest and commit all those and related features all together.  But I have been warned that doing so would make things too hard for whoever reviews/merges my changes. 

Please, one change - one changeset. Do not mix things in one changeset. You can also send patches (diff files) for other people for testing.

[johnfi...@gmail.com]

On Tuesday, February 1, 2022 at 11:31:43 AM UTC-5 Luís Henrique Camargo Quiroz wrote:

     What about keeping the views at 200% and just the magnifier (or a bigger one) at the intended 400 and 800%? So the left and right views would show a bigger field of view.

I think what I plan to do will fit your needs.  I still want 400% and 800% as choices in the menu for overall zoom.  You won't need to use them.

Currently (without any of my changes), the size and zoom level of the magnifier itself are set by registry settings in Windows and by ?? in Linux.  I forget what the default was for that zoom, but it was at least 400%.  I want to make the size of the magnifier user settable without regedit and I want to change the setting logic for the magnifier's own zoom level in addition to making that setting user settable without regedit.

I think the magnifier's own zoom should be set as both a minimum and a minimum relative to overall zoom (so it gets the larger of the two).  So you might select a magnifier zoom with its minimum at 400% and its relative minimum at 800%, in which case at overall zoom 50% or lower, the magnifier would be 400%, while at 100% or higher, the magnifier would be at 8 times the main zoom.  Alternately, you could set the X% as the minimum (meaning only) zoom for the magnifier and the special lowest (labeled "none" rather than 100%) relative value.  So for overall zoom below X% the magnifier would be X% and for overall zoom at or above X%, the magnifier would go away (similar to the go away at 200% existing feature, but more sensible).

> If you find the right part of a scene on my 1280x800 screen a 8xmagnifier might instead be a way to get completely lost

I recently switched the two portrait mode displays on my Fedora system from 1440x2560 each to 1620x2880 each.  So I have an overall 3240x2880 display.  So my needs are different from ordinary and I want Hugin to span the range between my needs and others.  I want the overall zoom to be higher and I need the magnifier itself to occupy more pixels of the physical screen.

[johnfi...@gmail.com]

On Tuesday, February 1, 2022 at 11:48:46 AM UTC-5 T. Modes wrote:

It is difficult to comment because you are often mixing things. Or as an example you contradict yourself

johnfi...@gmail.com schrieb am Dienstag, 1. Februar 2022 um 15:41:14 UTC+1:

 Hiding would only be temporary: other actions make the magnifier appear and "hiding" would not suppress that.

and later

I want the new 'm' key operation to be the only thing that hides the magnifier.

Not a contradiction at all.  I was saying 'm' would be the only thing that hides the magnifier, but would not be the only thing that brings the magnifier back once hidden.

But since that suggestion does not seem to fit the needs of others, I will drop the idea that 'm' should be the only thing that hides the magnifier.  I'll need more thought on how the things that hide the

magnifier should interact with each other.

I disagree: I like the feature that the magnifier disappear so I have a better view on the whole neighbourhood of the cp. This makes it easier for me the judge the cp.

Thanks for telling me in time that I can refine my plans (rather than do work I would later undo).

That feature you like, is so inconvenient for others (I'm not alone on this one) that a setting is required and I will now sidetrack into creating that.  I'm even fine with the default being the way you like it (though I suspect more users would prefer it my way).

Please, one change - one changeset. Do not mix things in one changeset. You can also send patches (diff files) for other people for testing.

It would be hard to split the changes for creating that setting (that I now understand I need, after previously hoping I wouldn't) from the changes I expected to make first, that now include applying that setting.  It probably would be ugly to split that from the related magnifier settings that I would have done next if this change didn't need a setting.  So I'm seem to be forced into the high side of the meaning  of "one change", relative to what you maybe happy with for a first commit from someone you don't have experience with.  I'll do my best to make it clean and to pull in as little as practical of the related planned changes.

I'll use diff files if those are strongly preferred in this group.  But all my professional experience in group software development tells me using public branches in a source code control system works a lot better than emailing diff files.  I assume that anyone who could use a diff file could more easily get the full files from the branch and in rare cases that they couldn't use files from a branch, they could get the diff from the branch.

[johnfi...@gmail.com]

On Tuesday, February 1, 2022 at 11:48:46 AM UTC-5 T. Modes wrote:

The disabling of the magnifier for the 200 % view was added as a feature request. So there are uses which prefer this.

I really hate that feature and I don't even get why someone else might like it (unlike the timer feature, where I understand the purpose and just don't like it).  BUT, that option is not too ugly to include within the choices for relative zoom of the magnifier.

 

Please, one change - one changeset. Do not mix things in one changeset.

I'm now intending one change for managing and implementing settings for the behavior of the magnifier.  I hope that is self contained enough.

The relative zoom part of that would be immediately testable and even have some narrow use case before I commit the change (that I'm already using myself) for overall zoom of 400% or 800%.  But most of the reason for relative zoom won't exist until 400% and 800% are available for overall zoom.

[T. Modes]

johnfi...@gmail.com schrieb am Dienstag, 1. Februar 2022 um 18:15:24 UTC+1:

On Tuesday, February 1, 2022 at 11:48:46 AM UTC-5 T. Modes wrote:

It is difficult to comment because you are often mixing things. Or as an example you contradict yourself

johnfi...@gmail.com schrieb am Dienstag, 1. Februar 2022 um 15:41:14 UTC+1:

 Hiding would only be temporary: other actions make the magnifier appear and "hiding" would not suppress that.

and later

I want the new 'm' key operation to be the only thing that hides the magnifier.

It would be hard to split the changes for creating that setting

Not a contradiction at all.  I was saying 'm' would be the only thing that hides the magnifier, but would not be the only thing that brings the magnifier back once hidden.

But I like this behaviour of automatic hiding when needed and I don't want to additionally press a key to get this behaviour.

Just to recapitulate how the magnifier work:

a) When a cp is selected (via the list or by clicking on it) the magnifier is shown. As soon as the mouse moves over one image it is hidden. -> So no need for an additional shortcut IMO. Just move the mouse.

b) The magnifier is then showing again when dragging the selected cp with the mouse. When the dragging is finished the magnifier is hidden after 2 s. During dragging I think the magnifier is helpful for better selection of the position.

So which behaviour is disturbing you?

> It would be hard to split the changes for creating that setting

You misunderstand me. When the changes requires a new setting then this belongs to the same changeset. I meant only don't mix different "features" in one changeset.

[johnfi...@gmail.com]

On Tuesday, February 1, 2022 at 12:34:49 PM UTC-5 T. Modes wrote:

Just to recapitulate how the magnifier work:

a) When a cp is selected (via the list or by clicking on it) the magnifier is shown. As soon as the mouse moves over one image it is hidden. -> So no need for an additional shortcut IMO. Just move the mouse.

b) The magnifier is then showing again when dragging the selected cp with the mouse. When the dragging is finished the magnifier is hidden after 2 s. During dragging I think the magnifier is helpful for better selection of the position.

So which behaviour is disturbing you?

That description doesn't fit the behavior that I think I've experienced.  But I never had a good mental model of what that behavior was and the surprises in behavior were part of the problem.  Later I may try to test a bit and see where the behavior doesn't fit your description.

I hope Bruno and others will answer your question, because I'm pretty sure Bruno disliked the current magnifier hiding and would be more competent to explain why and/or have more mainstream reasons.

For myself, I am slow at parsing visual information, such as comparing what I see in one magnifier to what I see in the other, so as I'm deciding whether to move it more, the magnifier is gone and I can't finish deciding.

I also find it very odd that there is so often a magnifier on one image but not on the other.  Is there a point to that, which I'm missing?  The basic activity is comparing the location of the cp in one image to its location in the other.  When is that helped by seeing the cp in a different way in one image vs. the other?  When the context (from hiding the magnifier) is helpful, isn't it needed on both;  When the magnifier itself is helpful, isn't it the comparison between the two, which is actually helpful?

[Bruno Postle]

On Tue, 1 Feb 2022, 17:53 johnfine wrote:

I hope Bruno and others will answer your question, because I'm pretty sure Bruno disliked the current magnifier hiding and would be more competent to explain why and/or have more mainstream reasons.

I never really considered the possibility that the magnifier was on a timer, it just seemed to disappear, and it wasn't clear how to make it reappear.

On investigation, it looks like the magnifier doesn't appear when you click down on a control point, it only appears once you have dragged it away from the original location, then when you let go it vanishes after a couple of seconds.

It seems to me that it would be useful to see the magnifier straight away on clicking, so you can decide *not* to move the point.

It is there while you are moving the point with the arrow keys, which seems good to me, and frankly this is the only time when the magnifier is any real use anyway.

It makes sense that it disappears when not being moved, since it obscures a lot, though maybe two seconds is a bit quick.

When click-dragging a point, the other viewpoint actually shows a magnifier for the previous control point, not the point you are actually moving, only on mouse-up is the current point selected and the correct magnifier shown. It only works correctly if you first click on the point, then click again to drag - this is surely a bug.

When hovering/switching the mouse between viewports, the magnifier appears, but only in the other viewport, I'm not sure what benefit this has.

-- 

Bruno

[johnfi...@gmail.com]

I wasn't giving proper attention to where the mouse was hovering when I was trying to understand the magnifier behavior.  I was instead thinking about where the last mouse click had been, which doesn't seem to matter as much.

In testing now, it seems that the magnifier appears when the hovering mouse leaves the image (subject to there being a cp selected).  So you get the other when when you hover to the other image and both when you hover to the lower section of the cp dialog outside both images.  Then sometimes the arrow keys work to move some side of the selected cp with both magnifiers in view, and sometimes not (I still don't have a great mental model).  That is more control (without making a code change) than I thought I had.  But the lack of mental model means I still don't know what to expect when I do things.

[T. Modes]

Hi Bruno,

bruno...@gmail.com schrieb am Dienstag, 1. Februar 2022 um 23:20:14 UTC+1:

On investigation, it looks like the magnifier doesn't appear when you click down on a control point, it only appears once you have dragged it away from the original location, then when you let go it vanishes after a couple of seconds.

This is not reproducible here. The magnifier appears when only clicking on the cp.  (and also when dragging)

It seems to me that it would be useful to see the magnifier straight away on clicking, so you can decide *not* to move the point.

This works here: when clicking on the cp in the image and also when selecting the cp in the list.

When click-dragging a point, the other viewpoint actually shows a magnifier for the previous control point, not the point you are actually moving, only on mouse-up is the current point selected and the correct magnifier shown. It only works correctly if you first click on the point, then click again to drag - this is surely a bug.

This was introduced when switching the selecting behaviour from mouse down to the mouse up event done last week. Will have a look on this one.

When hovering/switching the mouse between viewports, the magnifier appears, but only in the other viewport, I'm not sure what benefit this has.

I see two main usage scenarios:

1) Move the cp -> here the magnifier would be useful

2) Select another cp -> here the magnifier could be in the way and the magnifier could hide the other cp which the user wants to select. So hide the magnifier (as currently done) when moving the mouse pointer above the active control would be one way to handle this case (but it is not ideal when only moving the cp I admit, it is a compromise for different use cases).

Just some more remarks:

The logic implemented in the cp tab is already very complex to handle all use case - there are many possible user interactions, many have been improved in the last years. So doing changes based on a feeling can be very dangerous and has the possibility to break other interactions with the tab.

Also in the last years with the improvements of the automatic cp detectors I'm using the cp tab to less and less amount. So the necessarity for bigger improvments is very low for me.

Thomas

[johnfi...@gmail.com]

On Wednesday, February 2, 2022 at 11:38:37 AM UTC-5 T. Modes wrote:

bruno...@gmail.com schrieb am Dienstag, 1. Februar 2022 um 23:20:14 UTC+1:

On investigation, it looks like the magnifier doesn't appear when you click down on a control point, it only appears once you have dragged it away from the original location, then when you let go it vanishes after a couple of seconds.

This is not reproducible here. The magnifier appears when only clicking on the cp.  (and also when dragging)

Yesterday, I was seeing the behavior Bruno described.  I don't have a steady enough hand, so usually when I clicked, I accidentally dragged, but sometimes I just clicked and got no magnifier.

But I can't reproduce it today (as I tried to prepare to comment on what you just wrote) and I can't think of anything that could have changed.  I think a few of these times I clicked carefully enough to not drag.  But I can't be sure.  I almost never can release the mouse carefully enough to not drag.  The displayed x,y coordinates change on release and so far as I understand, there isn't a way to know after just clicking whether the point has moved slightly.

Just some more remarks:

The logic implemented in the cp tab is already very complex to handle all use case - there are many possible user interactions, many have been improved in the last years. So doing changes based on a feeling can be very dangerous and has the possibility to break other interactions with the tab.

I'm pretty sure I can retain the exact current behavior for the default value of new pref items.  I will need to make changes very slowly and carefully with a lot of research into current behavior.  But I can do that.

I don't believe the current behavior is very close to the intended behavior when coded.  In most cases I see, the magnifiers stay indefinitely.  From what you said as well as from what I would guess by looking at the code, that is not intended behavior.  For my own use, that probably unintended  behavior is necessary for me to be able to use the tool at all and the apparently (to me) random situations in which the intended behavior occurs are a massive inconvenience.

Still in changing the code, this would be one of the uncommon (as compared to other work I've done) cases in which maintaining the default of behavior I'll never understand would be easier than fixing that behavior.

Also in the last years with the improvements of the automatic cp detectors I'm using the cp tab to less and less amount. So the necessarity for bigger improvments is very low for me.

Maybe there is more I need to learn about using the automatic detectors.  But so far, I've never been able to construct a decent panorama without removing many automatically created cp's and adding several new ones.

[Luís Henrique Camargo Quiroz]

   John just told us about another annoyance that I, while adding manually my control points, see all the time. I put the text in bold, in his first paragraph below.

   I even tried, in vain, to immobilize the mouse -- with both hands! -- before releasing the button to create a CP, however the carefully chosen position moves and then I have to use the arrow keys to reposition it where intended. I think the movement is always to the right, maybe a little up, and it seems to be by a fixed amount.

--

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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/a5c5fbe4-10ef-4ef9-bc70-c22be5a462e2n%40googlegroups.com.

[johnfi...@gmail.com]

On Wednesday, February 2, 2022 at 2:36:28 PM UTC-5 Luís Henrique Camargo Quiroz wrote:

   John just told us about another annoyance that I, while adding manually my control points, see all the time. I put the text in bold, in his first paragraph below.

   I even tried, in vain, to immobilize the mouse -- with both hands! -- before releasing the button to create a CP, however the carefully chosen position moves and then I have to use the arrow keys to reposition it where intended. I think the movement is always to the right, maybe a little up, and it seems to be by a fixed amount.

I'm pretty sure you are talking about a different problem than the ones I was talking about (in what you highlighted).

1) I was talking about the fact that the displayed numeric change on release includes movement that occurred earlier and was not numerically displayed earlier, so if you perfectly freeze before releasing, the displayed numbers do not represent where the point actually is (the displayed point does represent where it is).

2) I was talking about my own inability to release a mouse button without moving the mouse.  Maybe others have the same problem.  Maybe some mice force that problem.  But it is far from a universal problem.  One of my sons can use and release (without extra movement) the same mouse in the same program (though he hasn't tried hugin) that I fail with.

Consistent up and to the right?? A fixed amount??

We aren't talking about the same thing.  If there is some hugin problem there, I don't even have the manual dexterity to try to test for it.

Need to adjust with arrows after releasing the mouse:  I just assume that as fact of life, not as something that could be corrected.  But I also assume that is just me, not most users.

[Bruno Postle]

On Wed, 2 Feb 2022 at 16:38, T. Modes <Thomas...@gmx.de> wrote:
>
> bruno...@gmail.com schrieb am Dienstag, 1. Februar 2022 um 23:20:14 UTC+1:
>>
>> On investigation, it looks like the magnifier doesn't appear when you click down on a control point, it only appears once you have dragged it away from the original location, then when you let go it vanishes after a couple of seconds.
>
> This is not reproducible here. The magnifier appears when only clicking on the cp. (and also when dragging)

It could be a platform issue. If I click (mousedown and mouseup) on a
control point, the magnifier appears. If I click (mousedown) the
magnifier doesn't appear until I start dragging the control point, or
I mouseup.

--
Bruno

[chaosjug]

Hi Thomas

Am Mittwoch, 2. Februar 2022, 17:38:37 CET schrieb T. Modes:
> Also in the last years with the improvements of the automatic cp detectors
> I'm using the cp tab to less and less amount. So the necessarity for bigger
> improvments is very low for me.

In which releases are those improvements you are talking about? cpfind usually
gives me no good control points but Hugin in my Ubuntu install is 2019.2 so a
newer version could help. Or would I need to compile master?

Regards,
Stephan

[T. Modes]

Hi Bruno,

bruno...@gmail.com schrieb am Mittwoch, 2. Februar 2022 um 22:46:54 UTC+1:

It could be a platform issue. If I click (mousedown and mouseup) on a
control point, the magnifier appears. If I click (mousedown) the
magnifier doesn't appear until I start dragging the control point, or
I mouseup.

Okay, this is now reproducible here. It is also a side effect of moving the selection code from the mouse down to the mouse up handler.

I had to revert this change. I found no way to fix all these issue.

I tried the fix the issue with selecting and moving cp in another way in changeset 577d2a6299ff.

Please test it. Hopefully it works now better and does not break something other.

Thomas

[Bruno Postle]

On Thu, 3 Feb 2022 at 18:42, T. Modes wrote:
>
> Okay, this is now reproducible here. It is also a side effect of moving the selection code from the mouse down to the mouse up handler.
> I had to revert this change. I found no way to fix all these issue.
> I tried the fix the issue with selecting and moving cp in another way in changeset 577d2a6299ff.
> Please test it. Hopefully it works now better and does not break something other.

Thanks, seems to work ok.
Single-clicking a control point selects, centres it, and shows the
magnifier (unless already zoomed to 200%)
Click-dragging shows the magnifier, and only centres the point after
dragging. This is fine, though for myself I could do without the
centering after dragging, as I get a little bit lost with the jump
(the point I just moved isn't where I left it) - I'm not sure what
others think about this?

--
Bruno