Skip to content
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

Closed
jlaura opened this issue Oct 7, 2021 · 6 comments · Fixed by #4671
Closed

KaguyaTC Footprint Generation Failures #4651

jlaura opened this issue Oct 7, 2021 · 6 comments · Fixed by #4671
Assignees
Labels
Products Issues which are impacting the products group
Milestone

Comments

@jlaura
Copy link
Collaborator

jlaura commented Oct 7, 2021

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:

Group = Kernels
  NaifCkCode                = -131350
  NaifFrameCode             = -131351
  LeapSecond                = $base/kernels/lsk/naif0012.tls
  TargetAttitudeShape       = ($base/kernels/pck/pck00009.tpc,
                               $kaguya/kernels/pck/moon_080317.tf,
                               $kaguya/kernels/pck/moon_assoc_me.tf)
  TargetPosition            = ($kaguya/kernels/tspk/moon_pa_de421_1900-2050.b-
                               pc, $kaguya/kernels/tspk/de421.bsp)
  InstrumentPointing        = ($kaguya/kernels/ck/SEL_M_ALL_D_V02.BC,
                               $kaguya/kernels/fk/SEL_V01.TF)
  Instrument                = $kaguya/kernels/ik/SEL_TC_V01.TI
  SpacecraftClock           = $kaguya/kernels/sclk/SEL_M_V01.TSC
  InstrumentPosition        = $kaguya/kernels/spk/SEL_M_071020_090610_SGMH_02-
                              .BSP
  InstrumentAddendum        = $kaguya/kernels/iak/kaguyaTcAddendum007.ti
  ShapeModel                = $base/dems/ldem_128ppd_Mar2011_clon180_radius_p-
                              ad.cub
  InstrumentPositionQuality = Reconstructed
  InstrumentPointingQuality = Reconstructed
  CameraVersion             = 2
  Source                    = isis
End_Group
**USER ERROR** No lat/lon data found for image.

How to reproduce

conda activate isis6.0.0
caminfo from=/scratch/kaguya/jaxa_FEB2021/cub_monoscopic/TC1S2B0_01_00295S305E0609.cub to=/scratch/kaguya/jaxa_FEB2021/cub_monoscopic/TC1S2B0_01_00295S305E0609.caminfo.pvl format=pvl isislabel=true statistics=true originallabel=true polygon=true spice=true

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:

    UpperLeftLatitude           = -29.726359 <deg>
    UpperLeftLongitude          = 61.629792 <deg>
    UpperRightLatitude          = -29.739581 <deg>
    UpperRightLongitude         = 60.116273 <deg>
    LowerLeftLatitude           = -31.269636 <deg>
    LowerLeftLongitude          = 61.656691 <deg>
    LowerRightLatitude          = -31.283006 <deg>
    LowerRightLongitude         = 60.114045 <deg>

PATH to the full list of images that are failing: /work/users/jlaura/github/ard_processing/kaguyatc/kaguyatc_failedcaminfo.csv

@jlaura jlaura added the Products Issues which are impacting the products group label Oct 7, 2021
@lwellerastro
Copy link
Contributor

@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:

kaguyatc2isis from=TC2S2B0_01_05982N028E2423.lbl to=TC2S2B0_01_05982N028E2423.lev0.cub setnullrange=yes nullmin=-32768 nullmax=-0.00001 
spiceinit from=TC2S2B0_01_05982N028E2423.lev0.cub web=false attach=TRUE cksmithed=FALSE ckrecon=TRUE ckpredicted=FALSE cknadir=FALSE spksmithed=true spkrecon=TRUE spkpredicted=FALSE shape=user model=/work/projects/kaguya/TOPO/GlobalMerge/Lunar_LRO_LOLAKaguya_DEMmerge_-
        Global_512ppd_radius_demprep.cub 
camstats from=TC2S2B0_01_05982N028E2423.lev0.cub attach=true format=PVL append=FALSE linc=100 sinc=100 
footprintinit from=TC2S2B0_01_05982N028E2423.lev0.cub increaseprecision=FALSE inctype=vertices numvertices=40
caminfo from=TC2S2B0_01_05982N028E2423.lev0.cub to=TC2S2B0_01_05982N028E2423.lev0.pvl isislabel=true geometry=true originallabel=true statistics=true camstats=true linc=100 sinc=100 uselabel=true

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):

footprintinit from=TC1S2B0_01_00295S305E0609.cub inctype=vertices numvertices=40
caminfo from=TC1S2B0_01_00295S305E0609.cub to=TC1S2B0_01_00295S305E0609.pvl isislabel=true geometry=true originallabel=true statistics=true camstats=true linc=100 sinc=100 uselabel=true

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.

@AustinSanders AustinSanders added this to the 6.2.0 milestone Oct 19, 2021
@amystamile-usgs amystamile-usgs self-assigned this Nov 3, 2021
@amystamile-usgs
Copy link
Contributor

@jlaura I was unable to find your list from the path provided /work/users/jlaura/github/ard_processing/kaguyatc/kaguyatc_failedcaminfo.csv. I did grabbed TC2S2B0_01_07414N012E2061.cub from /scratch/kaguya/jaxa_FEB2021/cub_monoscopic/ since it did not have a caminfo.pvl file, and it failed for me when running caminfo.

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:

  • For footprintinit, MAXEMISSION and MAXINCIDENCE is defaulted to be excluded if not specified on the command line. It will then default to 180 for both.

  • With caminfo, the MAXEMISSION and MAXINCIDENCE are not excluded if not specified. Therefore the MAXEMISSION defaults to 89.5 and MAXINCIDENCE defaults to 120. Therefore if in the situation of the image I tested, it was failing at the incidence check due to the incidence angle equaling around 124 and it was being check against the max of 120.

My questions are:

  • Is it a better check for MAXEMISSION default to equal 89.5 and MAXINCIDENCE default to equal 120 instead of both defaulting to 180?

  • If so, would a good solution be to specify the MAXINCIDENCE when running caminfo, if we want to specifically bypass the strict check?

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.

@jlaura
Copy link
Collaborator Author

jlaura commented Nov 4, 2021

@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?

@lwellerastro
Copy link
Contributor

lwellerastro commented Nov 4, 2021

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.

@amystamile-usgs
Copy link
Contributor

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?

@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.

@jlaura
Copy link
Collaborator Author

jlaura commented Nov 4, 2021

+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.

@jlaura jlaura moved this to In Progress in ASC Software Support Nov 11, 2021
@jlaura jlaura moved this from In Progress to Mergable in ASC Software Support Nov 11, 2021
Repository owner moved this from Mergable to Done in ASC Software Support Nov 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Products Issues which are impacting the products group
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants