cam2map "Programmer Error"

[lhongIM]

ISIS version(s) affected: 4.3.0

Description

I received this error: **PROGRAMMER ERROR** Angle cannot be a non-Null special pixel. I was trying to map project an LRO NAC cube file onto a map I had previously built.

How to reproduce

The specific command I ran to get the error was: cam2map from=M1142518395L.tr.cub to=M1142518395L.map.cub map=mosaic01.map warpalgorithm=forwardpatch patchsize=47

The NAC image pair used: http://wms.lroc.asu.edu/lroc/view_lroc/LRO-L-LROC-2-EDR-V1.0/M1142518395LE# http://wms.lroc.asu.edu/lroc/view_lroc/LRO-L-LROC-3-CDR-V1.0/M1142518395RC

ISIS commands ran on NAC images: 1) lronac2isis 2) spiceinit spksmithed=true cksmithed=true shape=user model=/path/SLDEM.demprep.cub (SLDEM shape model built from mosaicking full 512 res tiles together) 3) lronaccal 4) lronacecho 5) trim Left: left=46 right=26 Right: left=26 right=46 6) maptemplate Projection: Orthographic CLON: 349.153 CLAT: 25.37 7) cam2map cam2map from=M1142518395L.tr.cub to=M1142518395L.map.cub map=mosaic01.map warpalgorithm=forwardpatch patchsize=47 (also tried with patchsize=100)

Possible Solution

Additional context

[jessemapel]

Can you post the label of M1142518395L.tr.cub? You can get it using the catlab application.

[lhongIM]

M1142518395Ltrcub_label.txt

[lhongIM]

Update: I got the same error running that command on an equirectangular projected maptemplate as well. Could this be an area specific issue, or is it the method used? Any suggestions are appreciated, thanks!

[jessemapel]

Looks to be #2150 which we couldn't reproduce before. This type of error generally happens when the camera model cannot compute a valid pixel to lat/lon transformation. I'll attempt to reproduce this again and see what I can get.

For right now, try using the default automatic warpalgorithm and see if that can be a temporary work-around.

[lhongIM]

Got it I see, thanks for the info. I tried it again without specifying any warpalgorithm, (cam2map from=M1142518395L.tr.cub to=M1142518395L.map.cub map=mosaic01.map) and it came back with the same error. I'll see if I can get it working with a different NAC image set.

[kmgill]

Would like to mention that I am now getting this error on the latest Juno Perijove 33 imagery when attempting cam2map on a framelet. Still appears to work on imagery from previous perijoves.

The source to my pipeline can be found here: https://github.com/kmgill/cassini_processing/blob/master/sciimg/pipelines/junocam/processing.py

At a high level, it runs junocam2isis trim (optionally) initspice cam2map

Kernels have been updated from naif archive and makedb edited and run to update db files.

[jessemapel]

Try running camtest on the cubes you feed into cam2map. This will do pixel -> ground -> pixel and compute the error. It should be < 0.01 for all pixels, usually we see ~1e-6 or so.

[kmgill]

Ran camtest from=work/__JNCE_2021105_33C00018_V01_raw_GREEN_0017.cub to=test.cub

Output:

Group = CamTestResults
  FailedConversionsToLatLong    = 210944
  FailedConversionsToSampleLine = 0
  SuccessfulConversions         = 0
  Average                       = -1.79769313486231e+308
  StandardDeviation             = -1.79769313486231e+308
  Minimum                       = -1.79769313486231e+308
  Maximum                       = -1.79769313486231e+308
End_Group

[kmgill]

__JNCE_2021105_33C00018_V01_raw_GREEN_0017.cub.gz

[jessemapel]

So, every pixel failed the test, strange. I'll take a look at your cube and see if I can find anything.

[kmgill]

Thank you! (This perijove has some storms I'm really interested in)

[kmgill]

The problem persists even with the latest spice update from the NAIF archive.

[lhongIM]

Quick update from my end, finally got around to trying 2 more LRO NACs in different areas and came back with the same non-Null error. Additionally found that using mosrange instead of maptemplate to create the map file comes back with both of these errors: **USER ERROR** Problems with file M183682730R.tr.cub **PROGRAMMER ERROR** Angle cannot be a non-Null special pixel. but I'm not sure as to what the user error is.

M183682730Rtrcub_label.txt

[jessemapel]

@lhongIM You're going to get errors with anything that attempts to intersect the body and compute lat/lon values. These images aren't properly computing any intersections and I'm not sure why.

[kmgill]

Also, the JunoCam issue appears to have been caused by an error in the reconstructed spk kernel. I switched to the predicted and cam2map worked.

[lwellerastro]

Could the problem possibly be with the shape model? I can not reproduce the problem under isis4.3.0 with M183682730R and the only very obvious difference is the shape model. I let spiceinit default to the global lola dem.

While comparing the Kernels Group in my image to the information in the above supplied label dump, I see we are picking up different SpacecraftClock kernels (@lhongIM on the top, mine on the bottom):

<     SpacecraftClock           = $lro/kernels/sclk/lro_clkcor_2021090_v00.tsc
---
>     SpacecraftClock           = $lro/kernels/sclk/lro_clkcor_2021111_v00.tsc

I can't imagine this is the problem.

I pulled the image from the local pds archive and executed the most basic of steps (camstats to see where the data are located, etc):

lronac2isis from=/pds_san/PDS_Archive/Lunar_Reconnaissance_Orbiter/LROC/EDR/LROLRC_0010/DATA/SCI/2012043/NAC/M183682730RE.IMG to=M183682730RE.cub
spiceinit from=M183682730RE.cub spksmithed=true
camstats from=M183682730RE.cub linc=100 sinc=100
cam2map from=M183682730RE.cub to=M183682730RE.lev2.cub pixres=mpp resolution=10

@jessemapel, I realize this particular problem has not be reproducible on our end in the past, but I thought I'd have a look anyway. The only thing that sticks out to me is the DEM which appears to be a chunk out of the LOLA/Kaguya SLDEM going by the name. Maybe it's worth a run letting spiceinit default on the DEM to see if that makes any difference?

[lhongIM]

@lwellerastro you were right, it was the shape model! I ended up rebuilding my SLDEM shape model to include the whole moon (instead of just the latitudes I needed) and everything worked perfectly. Thanks everyone for your suggestions and help :)

[jessemapel]

I'm going to close this as it seems to be data issues and not software.