Yeah, HiRISE has been missing RED9 for some time now, which hasn't had a big impact because it was at the edge of the array, and just made the HiRISE swath narrower. However, we have now lost RED4, which leaves a "missing tooth" in the RED noproj mosaic and results in hiedr2mosaic not being very happy.
Since each of the CCDs is tied to the next via a few tens of pixel overlap, this means that we essentially have two mosaics (RED0 through RED3, and RED5 through RED8) that can’t really be put together (because they got tied through RED4 but now just float independently of one another).
One solution is just to treat the RED0-3 and the RED5-8 groups as two "independent" images. The other approach is that IR10 and BG12 are above and below where RED4 is and can be used to create a “synthetic” RED4 that could be used to bridge the two “real” halves together to make a single “RED” noproj image again like before, and then you can use a pair of these to make a stereo model.
This is the procedure that the HiRISE team is currently using to build stereo models from the new data.
But how does that help? So our old hiedr2mosaic.py script is really pretty basic, and not all that sophisticated. There is a new approach that I'm building which replicates the processing that the HiRISE team does (
https://github.com/rbeyer/hiproc), but it does not yet make a synthetic RED4.
However, you could make a synthetic RED4 and see if you could feed it into hiedr2mosaic or the hiproc programs and see if that works. Alternately, if the area of interest was only in the RED0-3 part of the observation (or the RED5-8 part), you should be able to use hiproc's HiccdStitch to just build the 0-3 or 5-8 part, and then use that to make stereo with another just 0-3 or 5-8 part.
Hopefully we'll port the "synthetic RED4" process from the internal HiRISE process into hiproc for people to use, but there's no timeline on that, sadly (too many other things to do).
- Ross