# Use nan for saturation level to prevent masking

XMLWordPrintable

#### Details

• Type: RFC
• Status: Implemented
• Resolution: Done
• Component/s:
• Labels:
None

#### Description

The saturation level for each amplifier is specified in the AmpInfoTable and is of type int. However, the ISR code that masks saturated pixels checks if the saturation level is nan and avoids masking if so. An int can never be nan so saturation is always flagged. I am guessing we never noticed because all cameras set a reasonable saturation value.

I want to fix this because I am adding an analogous level for setting the SUSPECT mask plane. It is used in the same way as the saturation level and set at the same point in the ISR code, but few cameras are likely to use it (at least initially), so a workable value for "do not mask" is important.

I see two good solutions:

• Keep saturation level an int but use a value of <= 0 to indicate "do not mask"
• Make saturation level a float and continue to use nan for "do not mask"

Is there a strong technical argument for one or the other? I can't think of one. float and int both have adequate dynamic range. I plan to add a field to AmpInfoTable, so the schema will change in any case. The ISR task detects saturation on a float32 image, but any casting is done once for many pixels, so the choice will not have a measurable effect on speed.

My main desire is to pick something quickly and move on.

Solutions I rejected:

• Add a separate flag to the AmpInfoTable for "the saturation level is invalid". I want to avoid the clutter of an additional field and having two closely related values when one would suffice. And such a solution does not answer the question of which type to use for the saturation and suspect levels.
• Specify a huge value to avoid masking. This works, but is hard to read. Also, we either have to test if the value is larger than the camera can output (which is non-trivial) or loop over all pixels. I prefer an obvious value such as nan or 0.

#### Activity

Hide
Robert Lupton added a comment - - edited

I'd switch to float and continue using NaN. Saturation levels are specified above bias so theoretically you can have negative values in an image (if the sky level is low enough). You can
certainly have negative values in dark frames, where there could be saturated heavy ion events (yes; you're probably going to be masking them anyway).

Show
Robert Lupton added a comment - - edited I'd switch to float and continue using NaN. Saturation levels are specified above bias so theoretically you can have negative values in an image (if the sky level is low enough). You can certainly have negative values in dark frames, where there could be saturated heavy ion events (yes; you're probably going to be masking them anyway).
Hide
Russell Owen added a comment -

Robert Lupton that sounds like a good argument. I'm going to use double instead of float unless there is significant pushback because it's just a few more bytes but offers more headroom in the number of digits (in case there are future high dynamic range imagers).

Show
Russell Owen added a comment - Robert Lupton that sounds like a good argument. I'm going to use double instead of float unless there is significant pushback because it's just a few more bytes but offers more headroom in the number of digits (in case there are future high dynamic range imagers).
Hide
Russell Owen added a comment -
Show
Russell Owen added a comment - Modifying old tables may take some work: http://community.lsst.org/t/how-to-update-a-saved-catalog-to-a-new-format
Hide
Russell Owen added a comment -

Adopted. saturation and suspect levels will both be double and nan will mean "do not mask".

Show
Russell Owen added a comment - Adopted. saturation and suspect levels will both be double and nan will mean "do not mask".

#### People

Assignee:
Russell Owen
Reporter:
Russell Owen
Watchers:
Jim Bosch, Paul Price, Robert Lupton, Russell Owen, Simon Krughoff, Tim Jenness, Yusra AlSayyad
0 Vote for this issue
Watchers:
7 Start watching this issue

#### Dates

Created:
Updated:
Resolved:
Planned End:

#### Jenkins

No builds found.