-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KaguyaTC Footprint Generation Failures #4651
Comments
@jlaura, I have successfully processed 19 of the images in your failure list (morning data) through footprintinit and caminfo. I have found in the past that letting caminfo calculate footprints might lead to failure (for a variety of data), so clearly there is an issue here. The tendency of past projects has been to let footprintinit calculate the footprints and let caminfo uselabel=true. I have also been using numvertices for footprints over linc/sinc since those seem to be more sensitive to problems and have a tendency to produce enormous footprints depending on the values selected. Here's the processing history for image TC2S2B0_01_05982N028E2423 which is in your list:
I also grabbed the image your command line above and ran footprintinit and caminfo with no errors (under /work/projects/kaguya/lweller/TC/Global/Morning/Test/JLFootFailures):
Again, I'm not saying there isn't potentially something wrong with caminfo, but using footprintinit's info straight from the label has proven to be more reliable (of course this is not 100%). Something to consider. You might be interested in a global version of somewhat higher resolution DEM which has been used for many lunar projects (/archive/projects/TOPO/LOLA_MAR2014/LRO_LOLA_Global_LDEM_118m_mar2014_radius.cub). Because of past problems with the Kaguya TC data and global DEMs I am hitting up a few different DEM products if you are interested. |
@jlaura I was unable to find your list from the path provided I believe I have pinpointed the issue with the caminfo failure. There is a check in the ImagePolygon class that checks if the incidence angle is less than the max incidence, in which it is failing for every pixel. When checking against footprintinit, this check passes. That is why Lynn was able to run footprintinit without failure. So why is footpritinit passing but caminfo is failing? The difference is between caminfo and footprintinit default parameters:
My questions are:
Overall, I have not tested enough images to confirm this is the case across all of the failing KaguyaTC images. But felt that it was worth mentioning in this case. |
@amystamile-usgs Great questions! I personally would love to see the defaults between caminfo and footprintinit match (with footprintinit being the reference because I suspect more people use footprintinit). If those changes are made to caminfo will this impact only footprint generation or are max incidence and emission used for other checks by caminfo? @jessemapel @rbeyer If we make changes here, are we considering this to be API breaking because these are default values based on our current agreed upon definition? |
Thanks for all the detailed information @amystamile-usgs. In my opinion, we should not be super restrictive with illumination angles by default because, for instance, there are datasets out there like Themis IR where incidence angles are very large by default, but the data are perfectly good to work with. So in that case, I am inclined to retain a value of 180 for programs like footprintinit and if not breaking, caminfo. FYI - I have a database all all the Kaguya TC monoscopic and stereo data (information pulled from the .lbl files) and the maximum incidence angle for all images is about 174 degrees - super terminator or pole images no doubt. It is reasonable for the user to set incidence and emission values when creating footprints. That being said, I usually let footprintinit default for mapping data and I tend to set hard values (like 89.5) for flyby images and those likely to have limb and disk in the scene. There is some inconsistency between footprintinit and caminfo footprint/polygon generation that we may want to address. But I'm not sure this is the post to the do it. |
@jlaura I verified that there are not any other checks that use max incidence or emission in caminfo. The documentation also indicates that these parameters are specifically use for polygon/footprint generation. |
+1 I would synchronize the homogenize the defaults with footprintinit and put in a PR. We can determine on that PR if this is API breaking and merge into the appropriate branch / leave in a feature branch while we collect other API breaking changes, etc. |
ISIS version(s) affected: 6.0.0
Description
When attempting to generate footprints for KaguyaTC data, I am seeing ~117 errors in all of the monoscopic data. These data are not polar and spiceinit correctly.
Error output is:
How to reproduce
Changing linc/sinc to 5 (the only other value I tested does not alter the output.
Possible Solution
No suggestions.
Additional context
This is 0.1% of the total data. Many, but not all of these data are 'bad' in that the data, as visualized in qview, are garbled.
Lat/lon bounds for the above example:
PATH to the full list of images that are failing: /work/users/jlaura/github/ard_processing/kaguyatc/kaguyatc_failedcaminfo.csv
The text was updated successfully, but these errors were encountered: