You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is primarily because DN is not a unit that is recognized by the FITS standard but also because until recently, the closest representation of DN in astropy.units is u.count. However, as of astropy 4.3, there is now a u.DN: https://docs.astropy.org/en/v4.3.1/units/index.html#module-astropy.units.astrophys. This raises the question of whether we should switch to using u.DN instead of u.count once we pin to >= 4.3.
The main disadvantage to this would be that any map with units of u.DN would not be FITS serializable.
I think there are three reasons we should NOT be making this replacement of "DN" for "count":
We currently only cover a subset of the cases here, e.g. "DN/pix/s" results in the unit key not being parsed at all. It seems impractical to continue to try to cover all possible uses of "DN".
The use of "count"/"ct" is ambiguous and a confusing substitute for "DN". This can sometimes mean "electrons" or "photons", but is rarely used to denote "DN". Furthermore "DN" is commonly used throughout solar physics and it is confusing to not use this convention.
astropy.io.fits can write and read files with "DN" in the BUNIT key without issue.
Provide a general description of the issue or problem.
DN is a commonly used unit in solar physics and often shows up in FITS headers. Currently, we replace DN with "count" in
GenericMap
,sunpy/sunpy/map/mapbase.py
Lines 722 to 726 in dbcf1b5
This is primarily because DN is not a unit that is recognized by the FITS standard but also because until recently, the closest representation of DN in
astropy.units
isu.count
. However, as of astropy 4.3, there is now au.DN
: https://docs.astropy.org/en/v4.3.1/units/index.html#module-astropy.units.astrophys. This raises the question of whether we should switch to usingu.DN
instead ofu.count
once we pin to >= 4.3.The main disadvantage to this would be that any map with units of
u.DN
would not be FITS serializable.See also the discussion in the chat on this topic: https://matrix.to/#/!JYqfIVJjWANcHnfktY:cadair.com/$166743304126958mwNUw:matrix.org?via=cadair.com&via=matrix.org&via=openastronomy.org
The text was updated successfully, but these errors were encountered: