LSST Applications
21.0.0+04719a4bac,21.0.0-1-ga51b5d4+f5e6047307,21.0.0-11-g2b59f77+a9c1acf22d,21.0.0-11-ga42c5b2+86977b0b17,21.0.0-12-gf4ce030+76814010d2,21.0.0-13-g1721dae+760e7a6536,21.0.0-13-g3a573fe+768d78a30a,21.0.0-15-g5a7caf0+f21cbc5713,21.0.0-16-g0fb55c1+b60e2d390c,21.0.0-19-g4cded4ca+71a93a33c0,21.0.0-2-g103fe59+bb20972958,21.0.0-2-g45278ab+04719a4bac,21.0.0-2-g5242d73+3ad5d60fb1,21.0.0-2-g7f82c8f+8babb168e8,21.0.0-2-g8f08a60+06509c8b61,21.0.0-2-g8faa9b5+616205b9df,21.0.0-2-ga326454+8babb168e8,21.0.0-2-gde069b7+5e4aea9c2f,21.0.0-2-gecfae73+1d3a86e577,21.0.0-2-gfc62afb+3ad5d60fb1,21.0.0-25-g1d57be3cd+e73869a214,21.0.0-3-g357aad2+ed88757d29,21.0.0-3-g4a4ce7f+3ad5d60fb1,21.0.0-3-g4be5c26+3ad5d60fb1,21.0.0-3-g65f322c+e0b24896a3,21.0.0-3-g7d9da8d+616205b9df,21.0.0-3-ge02ed75+a9c1acf22d,21.0.0-4-g591bb35+a9c1acf22d,21.0.0-4-g65b4814+b60e2d390c,21.0.0-4-gccdca77+0de219a2bc,21.0.0-4-ge8a399c+6c55c39e83,21.0.0-5-gd00fb1e+05fce91b99,21.0.0-6-gc675373+3ad5d60fb1,21.0.0-64-g1122c245+4fb2b8f86e,21.0.0-7-g04766d7+cd19d05db2,21.0.0-7-gdf92d54+04719a4bac,21.0.0-8-g5674e7b+d1bd76f71f,master-gac4afde19b+a9c1acf22d,w.2021.13
LSST Data Management Base Package
|
afw
There is no universally-adopted standard on how the bits in a mask are to be interpreted, and accordingly the LSST code tries to be flexible.
The mapping name --> bitmask
is defined by a dictionary in the Mask class (e.g. EDGE -> 4 -> 2^4 == 0x10
).
When Mask is created, the dictionary is initialised with a number of useful values; a convenience function is provided to list them:
(where we slipped in a convenient function showMask
to show masks in name-order)
You can add more mask planes:
That last example was a little misleading; I could just as well have written Mask.addMaskPlane("RHL")
as addMaskPlane
is a class static function — it adds the named mask plane to all masks. I can remove a mask plane just as easily with Mask.removeMaskPlane("RHL")
:
(note that getMaskPlaneDict
is not static; we needed to create an object to be able to call it).
Unfortunately we have a problem; we set the beloved RHL
bit in msk
, but now it's gone. The resolution is that each mask remembers the version of the mask dictionary that was current when it was created, so:
If you want to get rid of msk's
RHL
bit, use msk.removeAndClearMaskPlane("RHL")
or msk.removeAndClearMaskPlane("RHL", True)
if you want to drop RHL
from the default mask too. This does two things: It clears any RHL
bits that are set in the Mask (it isn't static, so it can do that), and it removes RHL
from the Mask's dictionary.
It's clear that you can make things inconsistent if you try:
But you can't actually do much harm:
The version numbers aren't actually compared directly, rather a hash of the contents is computed, so:
(We removed the errant planes from msk
, then re-added the ones that are already defined in the default dictionary)
Adding planes has no such difficulties, so they are added to all pre-existing dictionaries that don't have conflicts:
However, as expected,
will raise an exception.
What did I mean by, "conflicts"? Here's an example:
Note that msk
hasn't acquired a P3
plane as plane 1
is already in use.