Repository navigation
Conceptual difference between units.DN and units.adu? #20851
Description
Carrying this discussion over from Slack.
#11591 added a DN unit, which stands for either "data number" or "digital number". There is also adu, which stands for "analog-to-digital unit". To me, it seems like both of these represent the same (or very similar) concepts, but the two units are not compatible or convertible (i.e., u.DN.is_equivalent(u.adu) is False and (1*u.adu).to(u.DN) raises an error). Is there a good reason for this? Could they be made compatible/equivalent?
Both are separate from units.ct, which implies a raw count (as opposed to something that may have had a gain factor applied). I agree that this should be kept conceptually separate, since the distinction matters for things like whether or not
Activity
pllim commentedon Nov 13, 2026
Thanks! cc @jdavies-st and @mhvk
mhvk commentedon Nov 13, 2026
looking back at #11591, I see we had quite a bit of a discussion (e.g., #11591 (comment)), but ended up deciding it was its own unit. A data number indeed does not have to come from an analog to digital converter. To me, it seems best to stay with the status quo, refusing the temptation to guess and letting users be explicit if they want ADU and DN to be equivalent. In principle, we could document the solution (easy, see link), though of course one always has to wonder where to put that documentation such that people will actually find it...
cgobat commentedon Nov 13, 2026
Right, I also saw that discussion, but it seemed to mostly focus on whether
DNshould be equivalent tocount(which I concur; it should not). There didn't seem to be as much conversation at the time aboutDNandadurelative to one another.cgobat commentedon Nov 13, 2026
Maybe there is also some clarification to be had about whether DN is digital or data number (or if astropy is agnostic). I see that the changelog entry for #11591 originally said "digital number", but was later changed to "data number" before it was merged. If it's "digital" (or if that's an accepted interpretation) that strengthens the case in my mind for it being equatable to
adu.ayshih commentedon Nov 13, 2026
My perspective:
aduis an "analog-to-digital (converter) unit" and is enshrined in the FITS standard. This unit has a specific physical meaning.DNis a "digital number", which simply means that the value is based on a discretized unit. It does not attach any assumptions about the nature of the source of the value. It shouldn't be used in unit conversions without an explicit relationship/equivalency because, for example, the the unit of aDNquantity could be consideredDNas well (just a different flavor ofDN).That is,
aduis a specific type ofDN, but an arbitraryDNunit should not be treated as equivalent toadu.pllim commentedon Nov 13, 2026
If nothing else, should such reasoning be documented somewhere on astropy doc for these units?
mhvk commentedon Nov 13, 2026
I think it should, including with a nice example of using equivalencies to convert one to the other. The main questions are where would be good, and who has the time to do it...
pllim commentedon Nov 13, 2026
Where is a good question. This is a very instrumentation specific discussion... Current topics at https://docs.astropy.org/en/latest/units/index.html#using-astropy-units
pllim commentedon Nov 13, 2026
Or is https://docs.astropy.org/en/latest/nddata/ccddata.html a better place?