cam2map and ASP integration

[oleg-alexandrov]

Description

Here starting a discussion on making cam2map being compatible with ASP (on Kelvin's advice).

The proposal seems to be to ensure cam2map and mapproject produce interchangeable products with the right options. The plan I have for now is the following:

• Add new option asp_map with default of false. If true, it will use new logic.
• Add a new option called dem with value a string. This dem should be prepped as expected by ISIS.
• Take a projection string, either with the map option, or with useproj = true and PROJString.. The latter has some issues in my experiments with regular proj str and takes in only wkt I think, this will need looking into.

The produced cub file will have PVL strings with the following info

BUNDLE_ADJUST_PREFIX = NONE
CAMERA_MODEL_TYPE = isis
INPUT_IMAGE_FILE = path to input .cub
DEM_FILE = path to DEM

These are for use of ASP.

The precise image created with mapproject and cam2map should be on same grid and same values, up to numerical precision. The extent may differ by a pixel or two given that the two use different logic for that, but I don't think this would be a problem for practical use. I'll try to harmonize these.

ASP should be able to take in mapprojected images from cam2map and produce stereo results that are indistinguishable than the ones with its own mapproject. ASP expects a non-prepped DEM. Not sure what to do about this. Likely may have to have on-the-fly prep in ISIS while loading the un-prepped one.

Thoughts? I think this came from @jlaura if I remember right. Want to hear also what @acpaquette thinks given his work with projections.

[Kelvinrr]

I wonder it is worth adding a ISD/State param as well to allow CSM camera model to be input seperately. This is something we plan to add to other aspects of ISIS and it might be good to start here.

@acpaquette might have some insight on best way to pass in an SRS since he added that functionality to ISIS.

[oleg-alexandrov]

Sure, can add a new ISD param to cam2map. If set, the camera will be used from the ISD and passed where needed. In the output, it will then have:

CAMERA_MODEL_TYPE=csm
CAMERA_FILE=isd.json

These are needed for ASP.

I will see if there's other metadata in the output .cub that needs updating in that case.

[acpaquette]

@oleg-alexandrov When working with proj strings I used proj_create with proj strings and that seemed to work fine. I think it would be better to use wkt strings, and it seems like proj_create also supports that. I'm not sure what issues you've run into in the past.

When using proj strings, I have had to add +type=crs to get them to play nice with the other translations.

W.r.t. adding an ISD param. It might be better in ISIS to load it as a sidecar file rather than add a new parameter. That new parameter will need to be added to other apps that use cameras. I also have no idea how one would propagate that to the various ISIS qapps. Just my 2 cents

[Kelvinrr]

@acpaquette if we were to implement this in other apps, the idea of it being passed makes it easier to AB test cameras (e.g. post adjustment), without needing to regen, or in the case of a sidecart file (I assume youu mean {image_name}.json), you would have to rename the files

[oleg-alexandrov]

I won't work on the ISD field for a while, so if there is a decision let me know. I would be inclined to have it as a separate param. If exists in the sidecar and not set in separate param, can be used from there. So, I'll put it on for now when I get to it then we will see.

[jlaura]

Pardon my naivety, but is there a change on the ISIS side that would remove the need to prepare a DTM? Is that a necessary step or a legacy thing that has stuck around?

[Kelvinrr]

@jlaura what do you mean specifically? Do you mean a non-2.5 DTM? Use a spheroid instead?

[jlaura]

From Oleg's original issue: "ASP expects a non-prepped DEM." This implies that ISIS expects a prepped DEM. What is the difference and can this be homogenized to reduce friction?

[oleg-alexandrov]

ISIS assumes its DEMs to have radius as the value, while ASP assumes height above datum. Looks that I can use a height-above-datum DEM, which won't be an issue as cam2map has no DEM param for now. So I will not be passing the DEM as a DEM shape to the cub as ISIS does.

[acpaquette]

@jlaura demprep just adds padding to the dem and updates the mapping information with the extra padding. Like Oleg mentions DEMs in ISIS are just expected to be radius values rather than height-above-datum. It would be a good idea for ISIS to support height-over-datum DEMs as well as conventional radius DN DEMs