reproject icon indicating copy to clipboard operation
reproject copied to clipboard

Allow spectral-cube as an input type

Open keflavich opened this issue 4 months ago • 4 comments

I tried running reproject_to_hips with a SpectralCube input and that failed.

The next obvious thing, reproject_to_hips(cube.hdu) (which is a bit potentially-dangerous because of loading TB into memory...) also failed with

ValueError: The input (VRAD) and output (FREQ-LOG) spectral coordinate types are not equivalent.

reproject_to_hips(cube.with_spectral_unit(u.GHz).hdu, ...) worked.

It would be better if we supported direct operation on spectral_cubes (and nddata cubes), but we should at least document the above limitations (apparently velocity frame isn't allowed output? or I need to specify it but I didn't immediately see how)

keflavich avatar Nov 02 '25 17:11 keflavich

In principle I would be on board with this, but I wonder if to avoid growing the list of acceptable inputs for reproject we should instead define a magic method such as __reproject_input__ which data classes can define that would return an (array, wcs) tuple which can be used by reproject? In the case of SpectralCube, array could be a dask array.

@Cadair @svank @keflavich - what do you think?

astrofrog avatar Nov 02 '25 22:11 astrofrog

Sounds good to me.

keflavich avatar Nov 02 '25 22:11 keflavich

Just to note that the spectral reprojection thing with the mismatching axes types is an issue which I will fix separately.

astrofrog avatar Nov 03 '25 08:11 astrofrog

I feel like Astropy already has NDData for this? And Reproject already accepts NDData.

The base NDData class is hardly overbearing, and it's an ABC right so you could register to it without subclassing?

Cadair avatar Nov 03 '25 09:11 Cadair