Output of "shadow" program drifts as DTM resolution changes.

[rvwagner]

ISIS version(s) affected: 3.10.2, 7.0

Description
As you reduce the scale of the input DTM put into the shadow program, the position of features in the output drifts away from being aligned to the DTM. They even drift relative to null pixels copied in from the DTM, so it doesn't seem to be a simple misalignment of the input cubes.

I suspect that the cause of this error is simply that the output of shadow, at least in south polar stereographic projection on the Moon, is always shifted 2 pixels up and to the left of the correct position, and this only becomes noticeable when comparing ~20m/px data to ~3m/px data at the same point. This is based on the relative offsets between shadow-produced images of a NAC DTM reduced to various levels, and the orthophotos of that same DTM (I do not have a code example for doing that comparison, unfortunately).

How to reproduce
The attached files provide a base for the following code, which produces the files in the animation above. It's a tiny clipping from a polar NAC DTM, converted to radius, and an arbitrary NAC image that overlaps it.

for x in 1 2 3 4 5; do
reduce from=dtm.cub to=t$x.cub lsc=$x ssc=$x;
shadow from=t$x.cub match= M1146718551L.shift.cub to=s$x.cub;
done
qview t[1-5].cub s[1-5].cub

shadow_error_demo.zip

[Kelvinrr]

We can probably look into this as part in the coming days as part of the LROC work. Another possibility is the reduction app might be pulling the pixels towards the origin on the image, although like you said that by itself wouldn't explain the null pixels moving as well.

[rvwagner]

I’m pretty sure it’s shadow that’s causing the issue. The reduced cubes (left panel of animation) show no sign of drifting, at least not by more than a fractional pixel. Also, I originally spotted this bug after using map2map to downsample the DTM, and got the same pattern of non-offset reduced DTM and significantly offset shadow image.

[Kelvinrr]

I think to replicate this we need the shape model cube /ser/geodata/basemaps/MOON/Lunar_topography/LOLA/March2013/LDEM_75S_30M.demprep.cub that these were prepared with.

[rvwagner]

Whoops. That file's obnoxiously large, so how about just switching back to the built-in shapemodel? The result of the above demo code stays the same after doing this:

editlab grpn=Kernels keyw=Shapemodel value='$base/dems/ldem_128ppd_Mar2011_clon180_radius_pad.cub' from=M1146718551L.shift.cub

[Kelvinrr]

Looks like the gist of the issue is has to do with Hillshade's buffer at the edge of the image going off the image and becoming nulls which create a final pixel value of LRS. The buffer is also shifted by +1 in both the line/sample direction. Im like half way through finding a good solution as the buffer object is passed though 3 different classes.

[Kelvinrr]

I think I got it, the window for computing the DN was shifted one pixel. Inside that window, the origin was further shifted one pixel.

[Kelvinrr]

Fixed with #5047