astropy / astropy/specreduce

SpecreduceOperation has a method to coerce everything to Spectrum1D which does not make sense for some operations

Open
#195 0 comments 1 reaction 0 assignees View on GitHub
Dominant language
Jupyter Notebook
Stars
69
Forks
43
Avg merge
4d 22h
Merged PRs (30d)
3

Description

The `SpecreduceOperation` class has as its superclass `_ImageParser`. That seems to do nothing other than offering a `_parse_image` method, which notable coerces *Everything* into a Spectrum1D object (https://github.com/astropy/specreduce/blob/ddb0f7b354ac17a35e391bd38fc26cf8371534e8/specreduce/core.py#L78-L79).

In a spectroscopic workshop last week, several people were confused by this given that most of the operations illustrated here: #71 do *not* take in an image and output a spectrum1D. Many instead take in or output spectrumcollection, or take in spectrum1d, etc.

It's actually unclear to me why this class even exists. It seems to do a very specific parsing operation that's used a couple different places but very confusingly - e.g. an "image" is converted into a spectrum1D but then set to be an image, whereas an image really should be an image class (i.e., a `CCDImage`) unless it has a meaningful wavelength solution.

It's possible this is all just an oversight, as that particular code hasn't been touched in like a year or more even as other things were implemented. It might be the straightforward fix is to remove the subclass and instead implement this as some kind of utility function? Or maybe it should just be removed entirely and the one or two blocks that use it be re-imagined to use images directly?

Contributor guide

Open the contributing guide

Research direction

Start in core.py at _ImageParser._parse_image and trace the one or two blocks that use it, along with the operations referenced in issue #71. Determine whether SpecreduceOperation needs this superclass and how image, Spectrum1D, and SpectrumCollection inputs and outputs are expected to behave. Done means the parsing design is clarified and the affected operations consistently use the appropriate object types.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
data
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.