Earthdata Forum

I have been trying to process some NISAR data over Mexico city. I am looking at descending track 113, frame 79, and ascending track 019, frame 11. I am taking the level 1 RSLC data, and using GAMMA's par_NISAR_RSLC ingestor. To help coregister images, I am taking a series of small chips from a primary scene and a secondary scene and I am doing a cross-correlation between the chips to find the best range and azimuth offset. By doing this for a series of chips across the image, I can come up with a rubber sheet coregistration. This seems to work reasonably well for most images. However, I am having trouble with two images in particular. Namely, the 20260323 ascending image (NISAR_L1_PR_RSLC_016_019_A_011_4005_DHDH_A_20260323T120544_20260323T120619_P05023_N_F_J_001.h5) and the 20260423 descending image (NISAR_L1_PR_RSLC_018_113_D_079_4005_DHDH_A_20260423T011335_20260423T011410_P05023_N_F_J_001.h5) For these two images, I am finding that there is a sharp transition along a set azimuth value where above that line in the image there is one azimuth offset and below that line there is a different azimuth offset. I have attached an image showing such a sharp offset for the 20260323 ascending image. I should note that I have previously cropped the images to a 10k x 10k patch around my area of interest.

I'm not sure if it is related, but in the descending image, I do see an odd discontinuity in the amplitudes, with the image being sharper above and below a middle band. I've attached an image of the amplitudes of this dsc image, (with a fair bit of cropping and downsampling to keep the file size reasonable for upload here). For the ascending image, I don't see any obvious discontinuities in the amplitude.

Can I ask if there was perhaps something that went wrong in focusing these two images? Could ther

Thank you for reporting this issue.
This is a known issue due to missing rangelines or discarded rangelines in raw data and an edge case in raw data processor that does not properly update the time tag of remaining pulses after discarding some (in this case probably only one pulse out of 100s of thousands). If even one pulse is discarded and the time-tags are not updated, the block of data after the discarded rangeline is shifted by one pulse (around 4 m shift) which is consistent with your azimuth offset plot. We have confirmed that a fix to the level-0B raw data processor to properly time tag the rangelines after discarding corrupted data has resolved this issue in multiple test cases with similar behavior. The fix will be in place for our next delivery.