Isis3: Kaguya TC Camera Model Issues

[lwellerastro]

ISIS version(s) affected: 4.0.0 and higher
Needing to work in 4.0.0 to get serial number access to build a network but have confirmed that 4.4.0 produces the same campt error.

Description
I have a handful of image measures that are failing the lat/lon check via cnetcheck. Although I can view the measure sample/line and latitude/longitude information in qnet without failure, other programs produce errors.

campt produces the following error for certain samples/lines in one of my images:

    Message = "Requested position does not project in camera model; no surface
               intersection"
    File    = CameraPointInfo.cpp

But when I pass campt the lat/lon for the same samp/line that is loaded in qnet, it runs, but the resulting sample/line is completely different than expected. It can go one way through the model but not the other.

And the same image has failures in camtest:

    FailedConversionsToLatLong    = 2005
    FailedConversionsToSampleLine = 0
    SuccessfulConversions         = 19068971
    Average                       = 2.22441491881646e-04
    StandardDeviation             = 2.91071978016582e-04
    Minimum                       = 1.4561180065561e-09
    Maximum                       = 0.010785455326883

There are currently 5 images with this problem as identified by cnetcheck, but this only highlights problems where points intersect problem locations so it's possible there are few more. I haven't checked all of them, but these images have offsets from other Kaguya TC images in the set that are massive - like >7km massive. The other images have offsets more to the tune of 10's to 100's of meters so these stand out (when I can identify them - lots of images!).

I inquired about geom chip failures I was having with my data in an astrodiscuss post that aren't included in my cnetcheck failure list, but are in a similar revolution and possibly have a similar operating mode. Just wondering if some of these things are tied together and if maybe this type of data isn't being properly handled by the camera model.

How to reproduce
One of the problem images is under /work/users/lweller/Isis3Tests/KaguyaTC/CameraModel/.

This will fail
campt from=TC1S2B0_01_05565S795E1345.lev1.cub type=image sample=674.287 line=2292.52

This will run but returns the wrong sample/line. Both values show up in qnet when the image measure is loaded in the point editor.
campt from=TC1S2B0_01_05565S795E1345.lev1.cub type=ground latitude=-79.5468 longitude=136.536

The output from camtest is also in the same directory as is the print.prt with the results information from above.
camtest from=TC1S2B0_01_05565S795E1345.lev1.cub to=cameratest_TC1S2B0_01_05565S795E1345.cub format=err

Possible Solution

Additional context
Please let me know if you would like additional data or if you'd like me to run some additional tests. Thanks!

[jessemapel]

Could be a lot of things. I would guess the distortion model not working correctly. Maybe there's a singularity or something that throws the result wildly off.

Also +1 to this causing the qnet geom warp issues.

[lwellerastro]

I ran camtest on all of sites images and 66 of the 306 images have camtest failures, though some images have only a few failed pixels.
The images also span all flavors of the available data and are not restricted to a particular type.

[KrisBecker]

Hi @lwellerastro, I can report we have seen the same behavior in older versions of ISIS. I had also thought this was due to the use of tessellated plate models (DSK in NAIF), but we still had (camtest) failures in tests with ISIS Cube DEMs. However, when we tested PCK target body ellipsoids we did not see any failures. If you haven't done so yet, I would look carefully at your DEM at those ground locations. You might see if the problem also exists with PCKs but I suspect the issue is with the DEM and/or surface intersections somewhere.

Otherwise, here are a couple things that generally may be causing or help explain/pinpoint the issues:

1. There are seams that occur in the DSKs at some facet boundaries, thus a few ray traces can and do traverse through. This would be similar to a NULL in an ISIS cube DEM.
2. Your camera-to-ground look vector is coplanar with the surface intercept point on a DEM/DSK facet. Very, very few cases of this should be expected but it is certainly not unheard of.
3. Roundoff. All the different ways data is feed to the camera model API could cause a certain amount of inconsistency. For example, I don't think you have enough digits in your campt ground coordinates.
4. Failures in various validity checks in the ISIS Camera API (like emission angles in CameraGroundMap).

Hope this helps.

[lwellerastro]

I would look carefully at your DEM at those ground locations

Well that is certainly part of the problem. There is a pretty massive spike in the DEM near this location that mostly corresponds to the failures coming out of camtest and the campt failure above. Darn. I'm using one of the high resolution polar LOLA DEMs. I guess I had better look at other resolution/coverage versions since there seem to be more than a few dings in the one I am using.

I haven't checked all of my camtest failures, but the ones with 100'-1000s' of pixel failures are easier to locate in qview and they all appear to be near spikes in the DEM.

I don't know if this explains all of the weird things I am seeing with my data so thanks for the suggestions. I wouldn't know what to look for in the PCKs to know if there is a problem or not.

[KrisBecker]

You could use phocube to generate backplanes derived from the DEM (e.g., local emission angle) or fx to create a radius plane at the resolution and observation/orientation characteristics of the images. You would look for odd features/anomalies at areas in the resulting backplanes that correlate with your problem points.

You might run a noise/std filter over the DEM to help smooth out some of the spikes, but be careful as it could suppress real topography if the tolerance is too low.

Using the PCK in camtest helps limit tests/issues to the camera model, including distortion. You would see large errors or outright conversion failures at pixel locations. Once you add in a DEM/DTM, that significantly expands camtest's scope by testing lots of ShapeModel software, including intersections. This can result in misleading conclusions about the camera model when the problem is actually the DEM and/or related software.

[lwellerastro]

The issues I have been seeing are likely due to the DEM which is really bad news for me since these data only intersect a very small portion of it. I imagine it full of blunders.

I found time to reprocess my images setting spiceinit shape=ellipsoid. There are no lat/lon failures from cnetcheck (using the same network as my original post) and there are no camtest failures.

I've added some files to /work/users/lweller/Isis3Tests/KaguyaTC/CameraModel/. In addition to what I put there earlier, I also added the sphere version of one of my failing images including the camtest output (see *lev1.sphere.cub). I also added the directory Network/ which includes the network points involved in the cnetcheck failures and the list of images for the network. There are two lists, one pointing to images initialized with my DEM and the other with ellipsoid. The output of cnetcheck is there for both as well.

KTC_SBasinEve_FF10kCombine_2.net network
scratch_lev1_del_dem.lis dem init images
scratch_lev1_del_sphere.lis sphere init images

All images are on /scratch as indicated by the file names.

[lwellerastro]

Since it appears the problems I was having have to do with the DEM, I am going to close this post. There is a hybrid global lunar DEM Tammy and Ken created while working on Apollo Metric that combines the Kaguya/LOLA SLDEM and a global LOLA DEM to fill the poles that I will try to work with when I get back to this project.

If I encounter issues in the future that can't be resolved by working with a different DEM then I will reopen this post. Thanks for all the suggestions!