Details
-
Type:
Bug
-
Status: In Progress
-
Resolution: Unresolved
-
Fix Version/s: None
-
Labels:
-
Story Points:8
-
Epic Link:
-
Team:Science User Interface
Description
In the image stretch dialog, if you start out in the default state where the min and max data type menus are showing "%", then type in a number for "max" that is greater than 100 (but less than the maximum pixel value in the image), you get an error highlight for the field. That's as designed, of course.
If you then change the "max" menu to the "Data" setting, the error highlight does not go away (and the value in the field is unchanged). If you click "Refresh" you also get a data validation error. So it appears that the change from "%" to "Data" is not actually taking effect.
If you then attempt to edit the value in the field, more weird things happen. If you add a digit to the value in the field, it still stays in the error state. If you backspace over a digit, the whole value in the field is replaced by the data value corresponding to 99%. At this point validation is switched to being in "Data" units and you can actually enter the number you want.
This is a combination of an outright bug and a further annoying behavior.
It is such a common user behavior to type the value before changing the units that we need to support this. If I type "150" into the field when in "%" mode, and I get a warning that it's an invalid value, I should be able to just change units to "Data" and proceed, without retyping my value.
(Simon Krughoff has raised the separate question of whether we should be enforcing limits at all. It is arguably useful to be able to base the stretch on the range of possible values, and not limit it to the range of actual values. This is essential when setting up a stretch to produce common colors for a common data value across multiple images with different actual minima and maxima. I've made a separate ticket for this, DM-16457; please don't discuss it here.)
IPAC Firefly ticket https://jira.ipac.caltech.edu/browse/FIREFLY-139
Attachments
Issue Links
- relates to
-
DM-14797 Support stretch bounds outside the actual data range
- Won't Fix
Activity
| Field | Original Value | New Value |
|---|---|---|
| Epic Link |
|
| Description |
In the image stretch dialog, if you start out in the default state where the min and max data type menus are showing "%", then type in a number for "max" that is greater than 100 (but less than the maximum pixel value in the image), you get an error highlight for the field. That's as designed, of course.
If you then change the "max" menu to the "Data" setting, the error highlight does not go away (and the value in the field is unchanged). If you click "Refresh" you also get a data validation error. So it appears that the change from "%" to "Data" is not actually taking effect. If you then attempt to edit the value in the field, more weird things happen. If you add a digit to the value in the field, it still stays in the error state. If you backspace over a digit, the whole value in the field is replaced by the data value corresponding to 99%. At this point validation is switched to being in "Data" units and you can actually enter the number you want. This is a combination of an outright bug and a further annoying behavior. It is such a common user behavior to type the value before changing the units that we need to support this. If I type "150" into the field when in "%" mode, and I get a warning that it's an invalid value, I should be able to just change units to "Data" and proceed, without retyping my value. ([~krughoff] has raised the separate question of whether we should be enforcing limits at all. It is arguably useful to be able to base the stretch on the range of _possible_ values, and not limit it to the range of _actual_ values. This is *essential* when setting up a stretch to produce common colors for a common data value across multiple images with different actual minima and maxima. I'll make a separate ticket for this; please don't discuss it here.) |
In the image stretch dialog, if you start out in the default state where the min and max data type menus are showing "%", then type in a number for "max" that is greater than 100 (but less than the maximum pixel value in the image), you get an error highlight for the field. That's as designed, of course.
If you then change the "max" menu to the "Data" setting, the error highlight does not go away (and the value in the field is unchanged). If you click "Refresh" you also get a data validation error. So it appears that the change from "%" to "Data" is not actually taking effect. If you then attempt to edit the value in the field, more weird things happen. If you add a digit to the value in the field, it still stays in the error state. If you backspace over a digit, the whole value in the field is replaced by the data value corresponding to 99%. At this point validation is switched to being in "Data" units and you can actually enter the number you want. This is a combination of an outright bug and a further annoying behavior. It is such a common user behavior to type the value before changing the units that we need to support this. If I type "150" into the field when in "%" mode, and I get a warning that it's an invalid value, I should be able to just change units to "Data" and proceed, without retyping my value. ([~krughoff] has raised the separate question of whether we should be enforcing limits at all. It is arguably useful to be able to base the stretch on the range of _possible_ values, and not limit it to the range of _actual_ values. This is *essential* when setting up a stretch to produce common colors for a common data value across multiple images with different actual minima and maxima. I've made a separate ticket for this, |
| Description |
In the image stretch dialog, if you start out in the default state where the min and max data type menus are showing "%", then type in a number for "max" that is greater than 100 (but less than the maximum pixel value in the image), you get an error highlight for the field. That's as designed, of course.
If you then change the "max" menu to the "Data" setting, the error highlight does not go away (and the value in the field is unchanged). If you click "Refresh" you also get a data validation error. So it appears that the change from "%" to "Data" is not actually taking effect. If you then attempt to edit the value in the field, more weird things happen. If you add a digit to the value in the field, it still stays in the error state. If you backspace over a digit, the whole value in the field is replaced by the data value corresponding to 99%. At this point validation is switched to being in "Data" units and you can actually enter the number you want. This is a combination of an outright bug and a further annoying behavior. It is such a common user behavior to type the value before changing the units that we need to support this. If I type "150" into the field when in "%" mode, and I get a warning that it's an invalid value, I should be able to just change units to "Data" and proceed, without retyping my value. ([~krughoff] has raised the separate question of whether we should be enforcing limits at all. It is arguably useful to be able to base the stretch on the range of _possible_ values, and not limit it to the range of _actual_ values. This is *essential* when setting up a stretch to produce common colors for a common data value across multiple images with different actual minima and maxima. I've made a separate ticket for this, |
In the image stretch dialog, if you start out in the default state where the min and max data type menus are showing "%", then type in a number for "max" that is greater than 100 (but less than the maximum pixel value in the image), you get an error highlight for the field. That's as designed, of course.
If you then change the "max" menu to the "Data" setting, the error highlight does not go away (and the value in the field is unchanged). If you click "Refresh" you also get a data validation error. So it appears that the change from "%" to "Data" is not actually taking effect. If you then attempt to edit the value in the field, more weird things happen. If you add a digit to the value in the field, it still stays in the error state. If you backspace over a digit, the whole value in the field is replaced by the data value corresponding to 99%. At this point validation is switched to being in "Data" units and you can actually enter the number you want. This is a combination of an outright bug and a further annoying behavior. It is such a common user behavior to type the value before changing the units that we need to support this. If I type "150" into the field when in "%" mode, and I get a warning that it's an invalid value, I should be able to just change units to "Data" and proceed, without retyping my value. ([~krughoff] has raised the separate question of whether we should be enforcing limits at all. It is arguably useful to be able to base the stretch on the range of _possible_ values, and not limit it to the range of _actual_ values. This is *essential* when setting up a stretch to produce common colors for a common data value across multiple images with different actual minima and maxima. I've made a separate ticket for this, DM-16457; please don't discuss it here.) |
| Sprint | SUIT Sprint 2019-06 [ 875 ] |
| Sprint | SUIT Sprint 2019-06 [ 875 ] |
| Story Points | 8 | |
| Description |
In the image stretch dialog, if you start out in the default state where the min and max data type menus are showing "%", then type in a number for "max" that is greater than 100 (but less than the maximum pixel value in the image), you get an error highlight for the field. That's as designed, of course.
If you then change the "max" menu to the "Data" setting, the error highlight does not go away (and the value in the field is unchanged). If you click "Refresh" you also get a data validation error. So it appears that the change from "%" to "Data" is not actually taking effect. If you then attempt to edit the value in the field, more weird things happen. If you add a digit to the value in the field, it still stays in the error state. If you backspace over a digit, the whole value in the field is replaced by the data value corresponding to 99%. At this point validation is switched to being in "Data" units and you can actually enter the number you want. This is a combination of an outright bug and a further annoying behavior. It is such a common user behavior to type the value before changing the units that we need to support this. If I type "150" into the field when in "%" mode, and I get a warning that it's an invalid value, I should be able to just change units to "Data" and proceed, without retyping my value. ([~krughoff] has raised the separate question of whether we should be enforcing limits at all. It is arguably useful to be able to base the stretch on the range of _possible_ values, and not limit it to the range of _actual_ values. This is *essential* when setting up a stretch to produce common colors for a common data value across multiple images with different actual minima and maxima. I've made a separate ticket for this, DM-16457; please don't discuss it here.) |
In the image stretch dialog, if you start out in the default state where the min and max data type menus are showing "%", then type in a number for "max" that is greater than 100 (but less than the maximum pixel value in the image), you get an error highlight for the field. That's as designed, of course.
If you then change the "max" menu to the "Data" setting, the error highlight does not go away (and the value in the field is unchanged). If you click "Refresh" you also get a data validation error. So it appears that the change from "%" to "Data" is not actually taking effect. If you then attempt to edit the value in the field, more weird things happen. If you add a digit to the value in the field, it still stays in the error state. If you backspace over a digit, the whole value in the field is replaced by the data value corresponding to 99%. At this point validation is switched to being in "Data" units and you can actually enter the number you want. This is a combination of an outright bug and a further annoying behavior. It is such a common user behavior to type the value before changing the units that we need to support this. If I type "150" into the field when in "%" mode, and I get a warning that it's an invalid value, I should be able to just change units to "Data" and proceed, without retyping my value. ([~krughoff] has raised the separate question of whether we should be enforcing limits at all. It is arguably useful to be able to base the stretch on the range of _possible_ values, and not limit it to the range of _actual_ values. This is *essential* when setting up a stretch to produce common colors for a common data value across multiple images with different actual minima and maxima. I've made a separate ticket for this, DM-16457; please don't discuss it here.) IPAC Firefly ticket https://jira.ipac.caltech.edu/browse/FIREFLY-139 |
Work is starting on this ticket now, under FIREFLY-139 at IPAC.
| Status | To Do [ 10001 ] | In Progress [ 3 ] |
This bug creeped in sometimes after the React/Redux re-write. WISE application behaved correctly. There is another ticket about allowing out of range values when "data' is selected.