fix flux unit conversions in plugins

[cshanahan1]

Flux unit conversions done in plugins go through the 'flux_conversion_general' function that handles all equivalencies and special cases where the angle needs to be multiplied out before conversion. plugins that listen to unit conversion are tested with every combination of units to ensure all units that the spectral y axis can be translated to work in the plugin. Test coverage was added to each plugin that listens to flux unit changed messages from the Unit Conversion plugin to make sure the plugin in question actually supports all advertised flux units.

[gibsongreen]

Leaving another note here to retest model fitting in Specviz2d following merging this PR (#3253). Bug was preexisting unit conversion plugin but still worth retesting.

[gibsongreen]

Should we keep the parameters the same here as in flux_conversion? Originally adding spec and slice had to do with the image-viewers (the one case I explicitly remember testing for is working with the current state here) and eventually image data. I'll need to test this out a bit more to, might not be necessary but I will add a note about this on the Imviz implementation ticket.

[codecov]

Codecov Report

Attention: Patch coverage is 92.69231% with 19 lines in your changes missing coverage. Please review.

Project coverage is 88.80%. Comparing base (3dc6573) to head (ba347c7).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
jdaviz/core/unit_conversion_utils.py	93.33%	8 Missing ⚠️
...igs/default/plugins/model_fitting/model_fitting.py	64.28%	5 Missing ⚠️
...imviz/plugins/aper_phot_simple/aper_phot_simple.py	86.11%	5 Missing ⚠️
...configs/cubeviz/plugins/moment_maps/moment_maps.py	92.85%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3228      +/-   ##
==========================================
- Coverage   88.81%   88.80%   -0.02%     
==========================================
  Files         125      125              
  Lines       19041    19118      +77     
==========================================
+ Hits        16912    16977      +65     
- Misses       2129     2141      +12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[pllim]

Would spectral axis ever have NaN (e.g., from masking)?

Suggested change

	eqv = u.spectral_density(np.mean(slab.spectral_axis))
	eqv = u.spectral_density(np.nanmean(slab.spectral_axis))

[pllim]

This is an assumption that mean wavelength represents the effective wavelength of a collapsed cube. Does this assumption always hold? If not, the converted value might be misleading. If we cannot promise correctness, maybe better to disallow.

[cshanahan1]

that was the assumption i made, but I'm not sure it's correct. is there a better way to calculate an 'effective wavelength' for a cube? i don't think it makes sense to convert the unit of the whole cube before calculating the moment, even though that would solve the issue (cc @camipacifici)

[pllim]

In my INS days, we grabbed the effective wavelength from the header based on the filter used. But that is hard to generalize for arbitrary telescope/instrument. If we must allow unit conversion, we might have to give user the option to manually enter the correct effective wavelength. But I say just disallow it if straight conversion is not possible.

[camipacifici]

I think we should leave the decision to the user and not assume a conversion that might be inaccurate. For narrow subsets, using the median of the wavelength range of the subset should be fine, but for, e.g., collapsing the full wavelength extent of the cube, the two procedures (convert then collapse vs collapse then convert) could return different results. If there is a default and a warning is returned, the user might miss it. Could the offended dataset be grayed out if a conversion of this kind is needed? The user could then decide whether to keep it with the approximate conversion or discard it and create the collapsed image again in the new units.

[kecnry]

Could the offended dataset be grayed out if a conversion of this kind is needed?

Grayed out where? We could (without too much effort) create some sort of infrastructure for warnings/alerts about specific data layers where the legend and data menu get a ‼️ symbol with text in the tooltip, or we could maybe (I'd need to think through the consequences more first) migrate some of these to be auto-updating like spectral extraction and react to a change in units 🤔

[pllim]

Maybe less confusing to use nested parametrization here? This is a bit hard to read.

https://stackoverflow.com/questions/40164910/nested-parametrized-tests-pytest

[pllim]

I also wonder if this is more effective as a test class where the moment map is pre-calculated and re-used in a test method via parametrization, instead of recalculating for each combo. Does that make sense?

[pllim]

Same comment as https://github.com/spacetelescope/jdaviz/pull/3228/files#r1850728257

[pllim]

Thanks! A few more minor things.

[pllim]

Thanks for the huge clean up and adding tests!

Let's get this in soon before more conflicts occur.

[pllim]

Hmm... Isn't it more natural for specutils to do this upstream, @rosteen ?

[pllim]

Does this mean we can archive the ticket to think about wavelength input for moment map (someone created a ticket, right?)?

If CI stays green, my approval stands. Thanks!

[gibsongreen]

This was an awesome effort, great work! I created the two new bug tickets that I had mentioned in Slack, all the remaining plugin behavior went smoothly with many rounds of testing and recent code changes all look good to me.