SPIKE: qview zooms to the incorrect portion of one pixel per band cubes
When viewing a cube with 1 sample and 1 line per band, the qview application does not correctly zoom the viewport. When initially loaded or using "Fit in Viewport" function of the zoom tool, the center of the viewport is set to sample 0.5, line 0.5 with a width of 1 pixel. This results in only the upper left corner of the band being visible. The viewport should zoom to sample 1, line 1 with a width of 1 pixel.
This may be affecting cubes with larger bands, but is not as visually apparent.
- Documentation as to cause
- Plan with estimates to fix (fix must be well tested by Lynn, Tammy, Bob, Jesse, Kris)
- Document impact on ISIS
#4 Updated by Lynn Weller 8 months ago
I've confirmed what Jesse has documented with a somewhat larger but still small file to demonstrate this is occurring for larger images as well.
I created a 5x5 cube using ascii2isis and loaded it into qview and ran through the same motions. The data are clearly pushed down and to the left of the upper right corner of the viewport.
When "Fit in viewport" is selected, all samples are visible (though shoved to right) but only half of the last line is visible. I'll add an attachment to demo this observation.
A user test will be added in the near future. For now, if interested, my fabricated file is /work/users/lweller/Isis3Tests/Qview/Zoom/test.cub
I'll see if adding bands makes any difference or not. Doubt it.
The barely red dot visible in the lower left is the result of using the find tool to locate sample 5, line 5, followed by selecting "Fit in viewport".
#9 Updated by Ian Humphrey 7 months ago
- Status changed from In Progress to Resolved
This problem occurs with a setScale(double newScale, double sample, double line) call made in the ZoomTool::zoomFit() and the CubeViewport::showEvent(QShowEvent *). These calls calculate their samples and lines to pass to setScale() as follows:
- cubeSamples() / 2.0
- cubeLines() / 2.0
In the mentioned setScale() method, there is a call to center the viewport data at a certain sample and line: center(sample, line).
This logic is not following the ISIS definition for the center of a pixel. ISIS defines the center of the pixel as an integer (e.g. 1,1).
If we have a 1x1 cube, the center pixel of the entire image should be 1,1.
With the logic above (the bullet points), we get a sample and line of 0.5, 0.5. The center() call is going to use 0.5, 0.5, which will center on the top-left of the image. This is shown by the image zoom_fit_nirs.png attached to the description of this ticket. This creates the same issue with the 5x5 test.cub (zoomFit.png).
Fixing this requires modifying the setScale calls in ZoomTool::zoomFit() (gets called when activing the zoom fit feature) and CubeViewport::showEvent(QShowEvent *) (gets called immediately before initially showing the viewport for the first time) so that their center sample and lines have 0.5 added to the calculation.
Since this was a (seemingly) quick fix, I've gone ahead and made these changes in:
There are two test files located at /work/projects/isis/latest/m04756/test_data : 1x1.cub and test.cub (copy of 5x5 cube mentioned by Lynn W.).
qview has been built for astrovm4 in this area.
SPs used so far: 1
#11 Updated by Lynn Weller 7 months ago
I've taken a look at the changes using the 5x5 cube I created and it looks good. Makes much more sense.
Honestly, I don't know what else to test. As soon as you start viewing images of "normal" size (anything over 100 pixels in either dimension and even less), there are just too many pixels on screen to see the problem when loading using fit in viewport. I'm not sure there's a lot more to be tested, except for Jesse's data and his agreement that it's fixed.