Use Z axis rather than spectral axis to offset slicer before accessing channel cache

[confluence]

Description

• What is implemented or fixed? Mention the linked issue(s), if any.

I believe that this slicer transformation should be using the Z axis rather than the spectral axis.

This may be related to the incorrect rendering of a VEL-RA-DEC test image (although I cannot reproduce this locally -- I only see a blank image rendered in both versions of the code). Related (closed) issue: #1178 The image is rendering correctly; it's just too zoomed out to be visible by default.

I have, however, confirmed that the dev code causes a crash if you try to calculate the histogram for a region in the test file. This is caused by a shape mismatch (printing out the cache shape and the slicer start and end makes this clear). Using the Z axis in the transformation produces the expected result. The test region covers the whole image; the modified code produces the same histogram for the region as for the whole image.

This is likely to affect other functions that use GetSlicerData with the current Z and Stokes; this was just the simplest case to reproduce.

• How does this PR solve the issue? Give a brief summary.

If the image has rotated axes, the spectral axis does not necessarily correspond to the depth axis (in this case it's one of the render axes). The Z axis is always the depth axis.

• Are there any companion PRs (frontend, protobuf)?

No.

• Is there anything else that testers should know (e.g. exactly how to reproduce the issue)?

A link to the test image was shared on Slack. I have also shared the test region file.

Steps to reproduce:

1. Load the test image
2. Import the test region file
3. Open the histogram widget
4. Select the test region

In the dev code, this causes a crash. With this fix, the result should be a valid histogram which is the same as the image histogram.

Checklist

• changelog updated / no changelog update needed
• e2e test passing / corresponding fix added / new e2e test created
• ICD test passing / corresponding fix added / new ICD test created
• protobuf updated to the latest dev commit / no protobuf update needed
• protobuf version bumped / protobuf version not bumped
• added reviewers and assignee
• GitHub Project estimate added

[pford]

I have had mixed results with a rectangle histogram in the _0231.fits image [GLON, STOKES, FREQ, GLAT] in rotated_cube.zip. I select channel ~300 so there is data in the region. Sometimes it works, sometimes the 2D LCRegion fails so the code does not get to GetSlicerData (casacore bug?), but I also get the error below (another casacore bug?). I printed the slicer and the image cache shape (as a casacore::Array) in GetSlicerData, and the slicer looks like it should work with the array:

cache slicer=[246, 0, 0, 0] to [474, 0, 9, 0] with stride [1, 1, 1, 1], length [229, 1, 10, 1]
image cache shape=[746, 1, 10, 1]
libc++abi: terminating due to uncaught exception of type casacore::ArrayShapeError: ArrayBase::validateConformance shape [229, 2, 10, 1] differs from [229, 1, 10, 1]

So I guess catch the exception?

casacore may be the reason we do not fully support rotated images.

[kswang1029]

I have had mixed results with a rectangle histogram in the _0231.fits image [GLON, STOKES, FREQ, GLAT] in rotated_cube.zip. I select channel ~300 so there is data in the region. Sometimes it works, sometimes the 2D LCRegion fails so the code does not get to GetSlicerData (casacore bug?), but I also get the error below (another casacore bug?). I printed the slicer and the image cache shape (as a casacore::Array) in GetSlicerData, and the slicer looks like it should work with the array:

cache slicer=[246, 0, 0, 0] to [474, 0, 9, 0] with stride [1, 1, 1, 1], length [229, 1, 10, 1]
image cache shape=[746, 1, 10, 1]
libc++abi: terminating due to uncaught exception of type casacore::ArrayShapeError: ArrayBase::validateConformance shape [229, 2, 10, 1] differs from [229, 1, 10, 1]

So I guess catch the exception?

casacore may be the reason we do not fully support rotated images.

@pford If the field is distorted, world coordinate is non-linearly distributed in the spatial-spatial plan. So if we define a region in world coordinate and apply it to such cube (eg FREQ-RA-Dec), I would imagine the region size (and shape!) appeared in the FREQ-RA plan will change along the depth axis (Dec). We can still provide statistics/histogram for rotated cube but best with region defined in pixel coordinate only for simplicity (if we plan to support region analytics for rotated cubes, we will find a way to warn users), although the use case is quite limited.

[confluence]

@pford I have reproduced your crash. What is happening in this case is that the original region slicer spans multiple values on the Stokes axis. In some of the cases that don't crash, the Stokes dimension is 1, but the Stokes being requested is not the current Stokes. This sounds like it could be the distortion in the translation between world and image coordinates that @kswang1029 is talking about -- but I'm not sure exactly where it's happening -- in the GUI I only see pixel coordinates in the region dialog, but perhaps somewhere internally these are being transformed.

I'm currently trying to figure out how the slicers for a different Stokes are being applied to the cache code (IsCurrentZStokes should be failing!) -- I think there's another bug somewhere in the StokesRegion creation code.

[confluence]

I think I've found the problem: in RegionHandler::ApplyRegionToFile there's some slicer maths where the x and y axes are hardcoded to be axes 0 and 1 (which leads to a nonsense result here because axis 1 is Stokes). I'm testing a fix.

[confluence]

I can confirm that using the XY axes from the frame fixes this issue.

I noticed that there is still a problem with calculated Stokes (no crash; just a failure). I noticed recently that the Stokes calculator is repeating all the calculations for detecting axes from the loader, but is making a lot more assumptions. I'm going to check whether it is producing the correct values for these test images. Eliminating this repetition is part of the refactoring I'm currently doing in parallel, but if it's causing a bug, I will add it to this PR.

[confluence]

I'm pretty sure that the polarization calculator is making the same error (using the spatial axes as XY and the spectral axis as Z). I'm going to test a fix.

[confluence]

I think that with this change the polarization calculator is working correctly with the rotated axes (but I haven't validated the data). I would like to simplify the calculator code, but in this PR I am only making the minimum changes required to fix the bug.

[github-actions]

Package	Line Rate	Health
src.Cache	72%	➖
src.DataStream	44%	➖
src.FileList	67%	➖
src.Frame	36%	❌
src.HttpServer	42%	➖
src.ImageData	28%	❌
src.ImageFitter	83%	✔
src.ImageGenerators	43%	➖
src.ImageStats	75%	✔
src.Logger	37%	❌
src.Main	52%	➖
src.Region	69%	➖
src.Session	4%	❌
src.Table	52%	➖
src.ThreadingManager	67%	➖
src.Timer	85%	✔
src.Util	37%	❌
Summary	46% (8640 / 18965)	➖