Known issues specific to NIRCam data processing in the JWST Science Calibration Pipeline are described in this article. This is not intended as a how-to guide or as full documentation of individual pipeline steps, but rather to give a scientist-level overview of issues that users should be aware of for their science. 

Specific artifacts are described in the Artifacts section below. Guidance on using the pipeline data products is provided in the Pipeline Notes section along with a summary of some common issues and workarounds in the summary section.

Information provided in this article affects all NIRCam observing modes. For mode-specific issues, see the coronagraphy, imaging, TSO, and WFSS issues pages. Please also refer to NIRCam Calibration Status.

Artifacts

Scattered light artifacts

Please see NIRCam Scattered Light Artifacts for further details.

Snowballs

Extreme cosmic ray impacts introduce large artifacts in near-IR detectors called snowballs that are corrected by the pipeline in the jump detection step. Most snowballs appear round. Some are elongated. Some have long tails or streaks. None of these features are properly flagged as cosmic rays by the current pipeline. Four or more dithered exposures enable the pipeline to reject these features as outliers. See Shower and Snowball Artifacts for further details.

Persistence

Bright sources produce faint residual images that persist in subsequent integrations. This persistence declines exponentially in the detector pixels subjected to illumination.

Bad pixels

Ground testing revealed isolated bad pixels and some clumps up to 1.7" across, as seen in pre-launch NIRCam flat fields. Small high priority targets should avoid these regions. Primary dithers are recommended to fill in the large clumps of bad pixels in most exposures (any pattern is large enough).

Pipeline notes

The topics below affect all modes and reflect common questions about how to improve the quality of the data from the pipeline. 

1/f noise

Horizontal striping across the data

The SIDECAR ASICs (detector readout electronics) generate significant 1/f noise during detector operations and signal digitization. This 1/f noise appears as horizontal banding that spans the entire width of the image, as seen in Figure 1. More discussion of 1/f noise is provided in NIRCam Detector Performance and NIRCam 1/f Noise Removal Methods.

Figure 1. NIRCam pupil and filter wheels 

Cosmic ray flagging

Noise flagged as jumps

If it appears too many pixels are being flagged as jumps in the data quality (DQ) maps, it may be that the noise in the image is being erroneously flagged. The jump step documentation lists arguments that users can provide when running the step. In a case where the jump detection appears to be too aggressive and is flagging noise, increasing the rejection_threshold parameter is one way to make the step less sensitive. Note that there are separate cosmic ray rejection thresholds for ramps that have 3 or 4 groups, each of which have a different default value that can be changed: three_group_rejection_threshold, four_group_rejection_threshold (default values are 6.0 and 5.0, respectively). For a similar case with overflagging of outliers when creating a mosaic image, see the Outlier Detection section.

# call only the jump step
from jwst.jump import JumpStep
result = JumpStep.call('my_file.fits', rejection_threshold=5, save_results=True)
 
# call the entire pipeline while updating the jump step rejection_threshold
from jwst.pipeline.calwebb_detector1 import Detector1Pipeline
params = {'jump': {'rejection_threshold': 5}}
result = Detector1Pipeline.call('my_file_uncal.fits', steps=params, save_results=True)

Small number of groups

For integrations that have a small number of groups (e.g., 4 groups or less), default parameters for the jump detection step may not work well. The jump detection step uses the differences in signal between groups to determine whether there is a jump in the data. With very few groups in an integration, the jump step has only very limited data to work with. The set of parameters listed below may do a better job flagging jumps than the default values used by the pipeline.

# call only the jump step
from jwst.jump import JumpStep
result = JumpStep.call('my_file.fits', rejection_threshold=3, only_use_ints = False, minimum_sigclip_groups = 20, save_results=True)
 
# call the entire pipeline while updating the jump step parameters
from jwst.pipeline.calwebb_detector1 import Detector1Pipeline
params = {'jump': {'rejection_threshold': 3,
                   'only_use_ints': False,
                   'minimum_sigclip_groups': 20
                   }
          }
result = Detector1Pipeline.call('my_file_uncal.fits', steps=params, save_results=True)

Outlier detection

Too many pixels flagged as outliers

When combining images to produce a final mosaic, the outlier detection step can sometimes flag too many pixels as outliers, even when a pixel may appear to be useable. There are several options in the outlier detection argument list that may be helpful to prevent the step from flagging good pixel values. The algorithm description gives information on how each of these input keywords are used. First, the equation in the fifth bullet point of step 6 describes how outliers are identified. By increasing the values in the snr parameter, you can specify that only pixels with larger deviations from the median are flagged as outliers. Another option is to change the value of the maskpt argument (see step 4 in the algorithm description). maskpt gives the fraction of the maximum weight to consider data to be good (the default is 0.7). By lowering this value, lower weighted pixels will be included when resampling the data to create the median image. 

# call only the outlier detection step
from jwst.outlier_detection import OutlierDetectionStep
result = OutlierDetectionStep.call('my_file.fits', snr='5.0 4.0', save_results=True)
 
# call the entire pipeline while updating the outlier_detection parameters
from jwst.pipeline.calwebb_image3 import Image3Pipeline
params = {'outlier_detection': {'snr': '5.0 4.0'}}
result = Image3Pipeline.call('my_asn.json', steps=params, save_results=True)

Saturation and Frame 0

Use of the zeroframe and first group

Sometimes data that uses one of the frame-averaged readout patterns (e.g., BRIGHT2) saturates after the first group on a few peak pixels, resulting in NaNs in the output calibrated files. NaNs indicate that no slope could be calculated. Similarly, bright objects in the data may be saturated even though the ETC predicted that they would not saturate "fully." For these cases, it's possible the zeroframe and first group may not be saturated and could be used to get valid slopes for those pixels, but they are not used by default in the Operations Pipeline.

The ramp-fitting step (ramp_fit) contains a parameter called suppress_one_group, which has a default setting of True. The name of this parameter can be misleading—it refers to the case where there is only one good data point for a ramp, regardless of whether that one good data point is from the first group or the zeroframe. When suppress_one_group=False, a slope should be computed for pixels that have either a good zeroframe or a good first group. If the first group is good, that will be used by itself to compute the slope. If the first group is saturated but the zeroframe is not, then the zeroframe will be used to compute a slope. 

# call only the ramp_fitting step
from jwst.ramp_fitting import RampFitStep
result = RampFitStep.call('my_file.fits', suppress_one_group=False, save_results=True)
 
# call the entire pipeline while updating the saturation step parameters
from jwst.pipeline.calwebb_detector1 import Detector1Pipeline
params = {'ramp_fit': {'suppress_one_group': False}}
result = Detector1Pipeline.call('my_file_uncal.fits', steps=params, save_results=True)

Snowballs

Empty cores and halos

Sometimes signal rate data contain sources with an empty core and surrounding halo with elevated signal. These features are residual signal from snowballs. Recent improvements to the jump step include an algorithm for better identification and removal of snowballs, which is turned on by default in the Operations Pipeline for NIRCam. There are several keywords that affect the snowball detection algorithm, for example, the parameter controlling the minimum number of contiguous pixels needed to trigger the snowball flagging, min_jump_area (the default is 5.0). These are listed in the "Parameters that affect Near-IR Snowball Flagging" section of the jump step arguments documentation page.

# call only the jump step
from jwst.jump import JumpStep
result = JumpStep.call('my_file.fits', min_jump_area=4.0, save_results=True)
 
# call the entire pipeline
from jwst.pipeline.calwebb_detector1 import Detector1Pipeline
params = {'jump': {'min_jump_area': 4.0}}
result = Detector1Pipeline.call('my_file_uncal.fits', steps=params, save_results=True)

Summary of common issues and workarounds

The sections above provide detail on each of the known issues affecting NIRCam data; in this table we summarize some of the most likely issues for users to encounter along with any workarounds if available.  Note that greyed-out issues have been retired, and are fixed as of the indicated pipeline build.