Support CASA image types: concatenated, componentlist, LEL

[jott3077]

CASA produces a number of different image formats. CARTA needs to support these image types:

• CASA Concatenated image
• CASA Componentlist image
• CASA LEL images

Supporting various data types (bool, int, complex, etc.) has been moved to new issue #520.
Supporting other image types (UV, pV) has been moved to new issue #663.

A link to examples is given in the google doc
https://docs.google.com/document/d/1qH118KxBtxX4xtLNrV18meScxciFCVyIc9kelZ0JCvo

[pford]

The backend needs FileLoader subclasses for the additional types, and to support templated classes. See casacore::ImageOpener::openImage for an example which returns appropriate templated type (PagedImage, HDF5Image, ImageConcat, ImageExpr for LEL images) as LatticeBase*, but data types do not include Boolean or Int. We could adapt this for our backend and make CartaHdf5Image a templated class like PagedImage.

I tested Juergen's CASA images:

• ComponentList opens and looks okay (?)
• PV opens but incorrect (backend sets spectral and stokes coordinate axes incorrectly)
• UV opens with no axes in render widget - frontend issue? (CTYPE1=UU, CTYPE2=VV, CUNIT=CUNIT2=lambda)
• Concatenated images are currently ignored and do not appear in the file list

[veggiesaurus]

We should probably investigate alternative data delivery mechanisms for integer and boolean images. For integers, the byte-shuffling and Zstd compression approach taken with contours would probably work nicely. For booleans, sending them as bit arrays rather than byte arrays, and using Zstd (or even just the gzip compression built into WebSocket transmission) should be sufficient.

Converting to floating point and doing lossy compression with ZFP on quantized data would be counter-productive.

[zarda]

The concatenated image in example fold can be opened in the branch. The next branch is not able to test because of no example file for LEL image.

[zarda]

For PV image loader, there is an issue while setting region on PV image, the backend will crash as #327 happening. In one case for a PV image file (M17_SWex_pv.fits) with one spatial dimension and another spectral dimension, the backend will crash if starting any region functionality. In another case for a PV image (pVimage.image) with only one spatial dimension on canvas, there will be no issue. I suppose the CARTA may need the functionality for one dimensional image.

[pford]

Where is the crash? A PV image is not a 1D image, it has a casacore::LinearCoordinate and a casacore::SpectralCoordinate. According to the CASA viewer, the shape of pVimage.image is [160, 1, 52]. You cannot assume that the axes are in any particular order; CASA often puts the spectral axis last. casacore::CoordinateSystem (casacore/coordinates/Coordinates/CoordinateSystem.h) has various functions to find out if the image has a certain type of axis and where it is.

M17_SWex_pv.fits has shape [482, 25, 1]. If you push your branch I can have a look why it is crashing. Not sure what you mean by "region functionality".

[pford]

@jott3077 can you point us to some documentation on LEL images? Do they reside on disk or are they created dynamically with a lattice expression applied to an image? How would this be done in CARTA?

[jott3077]

Hi Pam,
LEL images are created dynamically. We would have to get an interface similar to the CASA viewer where one can enter the mathematical expression.

[zarda]

May I commit the current changes only? At least close part of list.

[pford]

@zarda which image types are supported in your hj/388_imageExpr branch (@kswang1029 available in mix 'n' match)? You checked off componentlist in the issue description, but the switch in FileLoader does not return a loader for this type.

[kswang1029]

@pford I have put Juergen's test images to "set_CASAImage_flavors" on our test server.

[zarda]

@zarda which image types are supported in your hj/388_imageExpr branch (@kswang1029 available in mix 'n' match)? You checked off componentlist in the issue description, but the switch in FileLoader does not return a loader for this type.

The componentlist could be opened well so I check off this item. Do I need to create a new class loader for this type?
Thanks.

[Kechil]

This is a backend issue as well as frontend.

[kswang1029]

adding "requiring_frontend" tag as

• Images with UV coordinates
• pV images

need the frontend (AST) to display the axes properly.

[kswang1029]

Note that this issue (esp. pv images) is critical for the coming release and v3.0.

[jott3077]

The title of the ticket is now misleading. UV and pV images are not only exclusively CASA formats but also fits, miriad, hdf5 etc.

[pford]

I moved UV and pV images to new issue #663 .

LEL images are created dynamically. We would have to get an interface similar to the CASA viewer where one can enter the mathematical expression.

@kswang1029 @jott3077 it sounds like this still needs the frontend tag.

[pford]

@kswang1029 please determine if this issue is still included in release 2.0.

[kswang1029]

@pford @jott3077 the relevant frontend issue is created as CARTAvis/carta-frontend#1264

I suppose this requires changes in protobuf message too?

[pford]

@jott3077 your sample componentlist.image type is returned as a PagedImage (CASA) type, already supported in CARTA.

The casacore::ImageOpener looks at the table.info file and if it contains "Type = Image" it is image type ImageOpener::AIPSPP (PagedImage), but if "Type = Component List" and the table description keywords include "coords" then it is image type ImageOpener::COMPLISTIMAGE. Your sample image has type "Image" and keyword "coords". Is this a bug in the casacore::ImageOpener code, a bug in the componentlist tool, or should we just continue treating this as a CASA image?

@zarda the ComponentListImage is defined in imageanalysis/Images/ComponentListImage.h (conveniently derived from casacore::ImageInterfacecasacore::Float). This loader should be created and added to the FileLoader::GetLoader switch.

I would like to get these new loaders into the backend before I templatize the images for issue #520 (supporting image data types bool, int, complex), since the concat and LEL images can also have various data types.

[pford]

@kswang1029 the CARTA backend supports displaying two types of images, those existing on disk and those created dynamically in CARTA (moments, pV, and LEL), with an option to save the in-memory image to disk.

Creating a moments image loader was done by Mark as part of the moments generator feature, but pV image support has been split into separate issues for the loader (#663 ) and the generator epic (#155 ). I suggest we do the same for LEL images and limit this issue to an LEL loader (no frontend required), then create a new issue to create LEL images in CARTA (labels: enhancement, requiring_frontend) linked to the frontend issue 1264 and requiring protobuf changes.

Then this issue can proceed with a pull request once the branches have been updated, and I will proceed with supporting additional data types (#520 ) in the complete set of loaders.

[kswang1029]

@pford the plan sounds ideal. Please just create issues directly.

[pford]

Creating LEL images dynamically moved to #665

[pford]

Closed #388 via #666

[jott3077]

I received the component list image from Kumar - I assume he would also know more about the actual interpretation in casacore.