Open thjarrett opened 4 years ago
- primary cube is HI (say from MeerKAT), and second (2nd) cube is H-alpha from an IFU observation. What makes this tricky is that the spatial scales will be very different. (WCS can handle this of course, but It may require some serious smoothing of the secondary)
The spectral scales would also be completely different if the cubes are stored in frequency space (we'd have to match them in velocity space, since it's HI versus H-alpha). Our approach in CARTA follows something similar to what DS9 does, and approximates any spatial projection effects as simple transform (consisting of rotation, scaling and translation), which is applied uniformly to the secondary image. The WCS headers are used to determine this transform though, and it is designed to be exact at the center of the image, and an approximation everywhere else.
good point about the different CTYPE3, they are very likely to be different -- you have to assume that, and do some kind of transformation to homogenize the 2nd (cube) to the first. Would a pre-processing step be the way to go? That is , create a utility function that does the transformation (off line), creating a new, homogeneous cube. This is a specialty beyond the VR realm, something the cube community would have experience with, and have the tools to do the transforms. Still, if we could do this on the fly, it would be amazing.
On Thu, Apr 23, 2020 at 4:37 PM Angus Comrie notifications@github.com wrote:
- primary cube is HI (say from MeerKAT), and second (2nd) cube is H-alpha from an IFU observation. What makes this tricky is that the spatial scales will be very different. (WCS can handle this of course, but It may require some serious smoothing of the secondary)
The spectral scales would also be completely different if the cubes are stored in frequency space (we'd have to match them in velocity space, since it's HI versus H-alpha). Our approach in CARTA follows something similar to what DS9 does, and approximates any spatial projection effects as simple transform (consisting of rotation, scaling and translation), which is applied uniformly to the secondary image. The WCS headers are used to determine this transform though, and it is designed to be exact at the center of the image, and an approximation everywhere else.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/idia-astro/idia_unity_vr/issues/72#issuecomment-618209116, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHHMRA5RKJ22VMSUGBDXEELRN7O4PANCNFSM4MOYY5KQ .
this has always been a tricky issue. It is easiest if the user provides the two cubes on the same grid and projection. Then it is presumably easier and more straightforward to display both as the voxels have identical pixel coordinates. Doing this on the fly requires quite some extra intelligence and computing power (need to know both the projection, WCS coordinates and resolution in all three dimensions to do this properly and this information usually is not all in the FITS header).
This is advanced for VR/3D, yet super useful and pretty standard with ALL 2-D displays. The ability to overlay a 2nd cube on top of the 1st (primary) cube based on the WCS. The most effective method would be to use 3D contours as the overlay, but of course we would have to fiddle with tuning to get this right; or perhaps using Grey transform for the primary, and color (say JET) for the secondary will work -- (between prime and second) is the key.
Typical scenarios:
primary cube is HI (say from MeerKAT), and second (2nd) cube is H-alpha from an IFU observation. What makes this tricky is that the spatial scales will be very different. (WCS can handle this of course, but It may require some serious smoothing of the secondary)
primary is HI (say MeerKAT), and secondary is another radio cube, say from older observations (early MeerKAT) or comparable observations (such as ASKAP). Here we would be comparing and looking for artifacts or calibration differences.