Address issues discovered during transition to operations review
Opened this issue · 0 comments
GoogleCodeExporter commented
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:19