Address issues discovered during transition to operations review

3) In the cfmask shadow code, it needs to properly initialize the
   temp_obj_max and temp_obj_min values to SHRT_MIN and SHRT_MAX
   respectively to allow the real cloud min/max temperatures to be found.
   Currently, it incorrectly initializes them both to zero.  Without this
   change, the minimum temperature was often not found since it was
   higher than zero.

4) The handling for small clouds is not working properly (the pct_obj
   assignment in the “object” routine).  If pct_obj is > 1 (which happens
   for clouds with a radius of 1.5 pixels or smaller), use the minimum
   cloud temperature instead of calling the prctile routine with pct_obj
   set to 1.0, which would find the maximum temperature instead of the
   minimum temperature.  This change was suggested by Zhe Zhu and Song
   Guo after it was identified as an issue.

5) The prctile and prctile2 routines need to initialize the returned
   result to the maximum.  Due to the way the comparison is done to find
   the correct value to return, it is possible that it will return
   without ever assigning a value without this change.   An alternate
   (or maybe additional fix) would be to fix the comparison.  It
   currently reads:

        if ((((float) sum * inv_nums_100) - prct) > MINSIGMA)

  But, to me, this would make more sense:

        if ((sum * inv_nums_100) >= prct)

  The MINSIGMA there is meaningless, but the real fix would be to use
  >= instead of >.  I haven't made that change since it does change
  results a little bit.

6) In the cfmask main routine, there is a block of code at line 166 that
   tries to change the solar angle by 180 degrees for polar scenes.  The
   logic making that decision is using corner latitudes that haven’t been
   initialized at that point, so it is not operating as expected.

7) In the object_cloud_shadow_match routine, there is a block of code
   that is meant to find the 4 corners (upper-left, upper-right,
   lower-left, lower-right) of the imagery.  It has a couple of issues:

   a. In the nominal UTM projection for a descending scene, the corners
      identified are rotated 180 degrees from the correct corner.  The
      UL corner it finds is really the LR corner; the UR corner it finds
      is really the LL corner; etc.  This can be fixed by breaking out
      of the outer loop for each of the corners when the inner loop
      breaks.  The impact of this bug is that the estimated satellite
      viewing angles the algorithm uses later are slightly off from
      where they should be.  Fixing this bug results in some minor
      improvement in matching shadow locations.
Original issue reported on code.google.com by rd.alt.5...@gmail.com on 19 Mar 2015 at 6:17
Shahmed / cfmask

Address issues discovered during transition to operations review #24
