I'm not sure anyone will care about this bug, but I noticed it while working with Voyager images and thought I should record it somewhere for posterity.

The DESPIKE program does a 3x3 median filter. Part of the sorting code at https://github.com/nasa/VICAR/blob/master/vos/p2/prog/despike/despike.f#L225 says:

            if (d1.gt.d3) then	!d2 < d3 < d1
               d(n) = d2
               d(n+1) = d3
               d(n+2) = d1
            else		!d2 < d1 < d3
               d(n) = d2
               d(n+1) = d3
               d(n+2) = d1
            endif

This is clearly wrong - the last d3 and d1 should be the other way around. This will cause it to occasionally pick the wrong value as the median.

I suspect there's another bug in the median code but my knowledge of Fortran is extremely limited so I'm not confident. median3 declares:

      real*4 d(9),d1,d2,d3

so I think the lower bound of d is the default 1. It sets n=1 and accesses d(n), d(n+1), d(n+2) which is fine. But at the end of the loop it does:

      n = mod(n+3,9)

so n will be wrapped to the range 0 <= n < 9. When the code writes d(n) with n=0, I think it is an out-of-bounds access. That will probably also cause incorrect median calculations for the first few pixels in a line.

I'm wondering, lacking any other reference we could cite, if you want to make a Github release and submit it to https://zenodo.org to receive a cite-able DOI for VICAR?

VOS 3.0's centos7_for_vos_installed.img.gz contains a docker Centos7 image with VOS and JRE 1.7. A number of libraries in VICAR require JRE 1.8, e.g. java jpl.mipl.io.jConvertIIO. Perhaps someone could upload an updated docker image? It's a bit jarring to get everything up only for the assumed good container not to contain a notable dependency.