Modeless "Adjust" windows can be annoying

[Mike Cowperthwaite]

While analyzing images, I frequently use the Image>Adjust dialog
windows, Threshold and Window/Level in particular.  These modeless
dialogs have a feature which I assume is intentional: when it's open and
you change the active window from an image to the dialog, the dialog's
settings are automatically, immediately applied to the image.

This leads to the following undesirable behavior:  I have two images
open.  On one, I set a threshold, then eventually close that image
window.  The other image becomes "active."  Then I click the Close
widget on the Threshold dialog, and suddenly my other image is
unintentionally thresholded.  I now have to reopen the dialog, click
Reset, and then close it again.

I'm not sure how useful the automatic apply-on-activate-dialog feature
is, given the Apply button on the dialogs that does the same thing under
explicit user control.  I would say that the on-activate action should
be removed.  But, if there is a compelling use case, then at least the
action should be suppressed when the Close widget is clicked.


Additionally, these dialogs should not be maximizable or resizable; I
don't think they should have Minimize buttons either, but I can see how
some people might need those.  If the Minimize option is kept and the
apply-on-activate feature is also kept, then I would say the automatic
apply should also be suppressed when the window is restored from minimized.


--
Mike Cowperthwaite
Lathrop Engineering, San Jose CA

[Gabriel Landini]

On Monday 21 December 2009, you wrote:
> This leads to the following undesirable behavior:  I have two images
> open.  On one, I set a threshold, then eventually close that image
> window.  The other image becomes "active."  Then I click the Close
> widget on the Threshold dialog, and suddenly my other image is
> unintentionally thresholded.  I now have to reopen the dialog, click
> Reset, and then close it again.

You need to press "Reset" before closing. Otherwise when you activate the
thresholder (not surprisingly) the threshold will be computed and shown as a
red LUT.

> I'm not sure how useful the automatic apply-on-activate-dialog feature
> is, given the Apply button on the dialogs that does the same thing under
> explicit user control.

No, the apply button applies the computed threshold (either automatic or
manual) to the currently greyscale image that has the red (or one of the
others) LUT. Otherwise you would not know what you are applying until you
pressed "Apply".

> I would say that the on-activate action should
> be removed.  But, if there is a compelling use case, then at least the
> action should be suppressed when the Close widget is clicked.

I do not think this would be desirable. How and when should the thresholder
get the image histogram to compute a threshold and show it? Are you proposing
another button to do this?
If I understand correctly, the problem is that one needs to press Reset to
"not show" it, so really one would be changing pressing one button for
pressing another. There are many more presses to do to gather histograms than
resetting the last one when closing the dialog. I would vote for leaving as it
is.

However, I wonder if on closing the dialog AND while on LUT (red or other)
mode, the image LUT should be reset. That could prevent the issue you raised.
I haven't looked into how easy would be to implement this or whether it might
interfere with macro recording as resetting the threshold might be sending a
resetThreshold() to the recoded macro and one would not like that.

Cheers

G.

[Mike Cowperthwaite]

On 22-Dec-09 4:03 am, Gabriel Landini wrote:

> On Monday 21 December 2009, you wrote:
>> This leads to the following undesirable behavior:  I have two images
>> open.  On one, I set a threshold, then eventually close that image
>> window.  The other image becomes "active."  Then I click the Close
>> widget on the Threshold dialog, and suddenly my other image is
>> unintentionally thresholded.  I now have to reopen the dialog, click
>> Reset, and then close it again.
>
> You need to press "Reset" before closing. Otherwise when you activate the
> thresholder (not surprisingly) the threshold will be computed and shown as a
> red LUT.

First, I shouldn't need to press Reset, because the image in question is
not thresholded at the time I close the Threshold window.

Furthermore, I simply do not agree with the "not surprisingly" part.
It's not surprising only to people who have grown used to this
surprising behavior.  I'm curious if you know of any other program where
a change is performed in response to a window activation.

There is more to the problem.  An image window that is minimized can
become "active" with absolutely no user cue to that effect.  I close the
Threshold window, that image gets thresholded, and I don't find out
until I restore the window, at which point I *am* surprised and have to
stop thinking about my imaging problem in order to figure out what went
wrong -- did I restore the wrong image window?  Have I lost an edit
somewhere?


>> I'm not sure how useful the automatic apply-on-activate-dialog feature
>> is, given the Apply button on the dialogs that does the same thing under
>> explicit user control.
>
> No, the apply button applies the computed threshold[...]

Right you are.  However, the AUTO button *does* behave as I meant.


> If I understand correctly, the problem is that one needs to press Reset to
> "not show" it, so really one would be changing pressing one button for
> pressing another. There are many more presses to do to gather histograms than
> resetting the last one when closing the dialog. I would vote for leaving as it
> is.

You are under-stating the issue.  One needs to (1) reopen the dialog,
(2) press Reset, (3) close the dialog *again* -- three steps.

But it's not a question of how many button presses.  It's a question of
a program action being inappropriately tied to a user action.  There is
an expected behavior when activating a window, but here that's been
overloaded in a non-obvious and problematic way.

Even if you're willing to accept that nonstandard behavior, I don't
think you can reasonably defend the auto-application of thresholding (or
Window/Level, Brightness/Contrast, Color Balance) when the dialog's
close button has been clicked -- that is just wrong.


> However, I wonder if on closing the dialog AND while on LUT (red or other)
> mode, the image LUT should be reset. That could prevent the issue you raised.

This is compounding the problem -- you are now introducing a second
instance of a program action being executed, unexpectedly, in response
to a standard user action, and it should be easy for you to come up with
cases where resetting the LUT on closing the dialog would cause problems
for some users.

--
Mike Cowperthwaite
Lathrop Engineering, San Jose CA

[Michael Schmid]

Hi Gabriel, Mike,

the current behavior of the threshold adjuster does not make me happy
either. Unfortunately, it is not so easy to cure the problem: When closing
the Threshold panel, it gets activated, and there is no elegant way to
find out whether a Close operation is imminent.

What could be done is changing the behavior in such a way that bringing
the Threshold panel to the foreground does not lead to automatic
thresholding of the current window. Immediate auto-thresholding would only
happen if the Threshold panel is opened (from the menu or via the keyboard
shortcut). Would this be ok?

[Wayne, in case you read this: what I have in mind is an additional
boolean argument 'doAutoThreshold' for the setup method; true when invoked
from the constructor, false when invoked from windowActivated]

Michael
_______________________________________________________________________

On Tue, December 22, 2009 18:40, Mike Cowperthwaite wrote:

> On 22-Dec-09 4:03 am, Gabriel Landini wrote:
>> On Monday 21 December 2009, you wrote:
>>> This leads to the following undesirable behavior:  I have two images
>>> open.  On one, I set a threshold, then eventually close that image
>>> window.  The other image becomes "active."  Then I click the Close
>>> widget on the Threshold dialog, and suddenly my other image is
>>> unintentionally thresholded.  I now have to reopen the dialog, click
>>> Reset, and then close it again.
>>
>> You need to press "Reset" before closing. Otherwise when you activate
>> the
>> thresholder (not surprisingly) the threshold will be computed and shown
>> as a
>> red LUT.
>
> First, I shouldn't need to press Reset, because the image in question is
> not thresholded at the time I close the Threshold window.
>
> Furthermore, I simply do not agree with the "not surprisingly" part.
> It's not surprising only to people who have grown used to this
> surprising behavior.  I'm curious if you know of any other program where
> a change is performed in response to a window activation.
>
> There is more to the problem.  An image window that is minimized can
> become "active" with absolutely no user cue to that effect.  I close the
> Threshold window, that image gets thresholded, and I don't find out
> until I restore the window, at which point I *am* surprised and have to
> stop thinking about my imaging problem in order to figure out what went
> wrong -- did I restore the wrong image window?  Have I lost an edit
> somewhere?
>
>
>>> I'm not sure how useful the automatic apply-on-activate-dialog feature
>>> is, given the Apply button on the dialogs that does the same thing
>>> under
>>> explicit user control.
>>
>> No, the apply button applies the computed threshold[...]
>
> Right you are.  However, the AUTO button *does* behave as I meant.
>
>
>> If I understand correctly, the problem is that one needs to press Reset
>> to
>> "not show" it, so really one would be changing pressing one button for
>> pressing another. There are many more presses to do to gather histograms
>> than
>> resetting the last one when closing the dialog. I would vote for leaving
>> as it
>> is.
>
> You are under-stating the issue.  One needs to (1) reopen the dialog,
> (2) press Reset, (3) close the dialog *again* -- three steps.
>
> But it's not a question of how many button presses.  It's a question of
> a program action being inappropriately tied to a user action.  There is
> an expected behavior when activating a window, but here that's been
> overloaded in a non-obvious and problematic way.
>
> Even if you're willing to accept that nonstandard behavior, I don't
> think you can reasonably defend the auto-application of thresholding (or
> Window/Level, Brightness/Contrast, Color Balance) when the dialog's
> close button has been clicked -- that is just wrong.
>
>
>> However, I wonder if on closing the dialog AND while on LUT (red or
>> other)
>> mode, the image LUT should be reset. That could prevent the issue you
>> raised.
>
> This is compounding the problem -- you are now introducing a second
> instance of a program action being executed, unexpectedly, in response
> to a standard user action, and it should be easy for you to come up with
> cases where resetting the LUT on closing the dialog would cause problems
> for some users.
>
> --
> Mike Cowperthwaite
> Lathrop Engineering, San Jose CA
>

[Gabriel Landini]

On Tuesday 22 December 2009, you wrote:

> the current behavior of the threshold adjuster does not make me happy
> either. Unfortunately, it is not so easy to cure the problem: When closing
> the Threshold panel, it gets activated, and there is no elegant way to
> find out whether a Close operation is imminent.
>
> What could be done is changing the behavior in such a way that bringing
> the Threshold panel to the foreground does not lead to automatic
> thresholding of the current window. Immediate auto-thresholding would only
> happen if the Threshold panel is opened (from the menu or via the keyboard
> shortcut). Would this be ok?

I have a further suggestion that might be easier to implement, but I have not
looked at the code yet.
How about: on activation, the auto threshold gets the image histogram and the
value is calculated, but the Red (or other) LUT is not applied to the image.
The Auto button remains functioning as it is.
That way, there is no need of resetting it before closure.

Cheers

G.

[Michael Schmid]

On Tue, December 22, 2009 20:47, Gabriel Landini wrote:

>
> I have a further suggestion that might be easier to implement, but I have
> not
> looked at the code yet.
> How about: on activation, the auto threshold gets the image histogram and
> the
> value is calculated, but the Red (or other) LUT is not applied to the
> image.
> The Auto button remains functioning as it is.
> That way, there is no need of resetting it before closure.
>
> Cheers
>
> G.

Hi Gabriel,

there are a few cases where an invisible threshold could be confusing:
- The wand tool would behave differently
- Measure would report an area fraction related to the invisible threshold
- Analyze particles on a gray level image would sometimes work (hidden
threshold), sometimes create an error message (no hidden threshold)

Michael

[Gabriel Landini]

On Tuesday 22 December 2009, you wrote:
> there are a few cases where an invisible threshold could be confusing:
> - The wand tool would behave differently
> - Measure would report an area fraction related to the invisible threshold
> - Analyze particles on a gray level image would sometimes work (hidden
> threshold), sometimes create an error message (no hidden threshold)

Hi Michael,
Ah, yes, I see that problem, but there must be a flag that indicates whether
the threshold has been set (as this is reported by the particle analyzer when
no threshold has been set).
I only looked briefly, is that: ImageProcessor.NO_THRESHOLD  that gets
assigned to the min and max threshold values?
Anyway, your solution seems better than doing it and not showing it.

Cheers,

G.