Serve ORex Kernels #4060
Comments
|
OCams data can be found at the small bodies node: https://sbn.psi.edu/pds/resource/orex/ocams.html we will likely need to check that we support the latest release of data in the ingestion and sensor model. |
|
After more discussion, the latest kernels need to be checked with the latest image data. There is likely some amount of issues with the IAK and the camera model that will need to be addressed. For whomever works on this, I have some makedb scripts and kerneldbs from the mission team that should be useful. |
|
The attached tarball has the osirisrex data area configuration from @KrisBecker in it. You'll want to use the kernel.db and makedb files located inside the kernels directories alongside the downloaded kernels. The scripts in there are for more complex kernel management that you can take a look at too. |
|
@jessemapel Kernels are in using @KrisBecker's makedb scripts and kernel.db files. Where would be the best place to get the new images? I'm sure I asked this before and forgot to write it down... |
|
@Kelvinrr You can get data from the Small Bodies Node: https://sbn.psi.edu/pds/resource/orex/ocams.html |
|
@jessemapel Thats what I figured, thanks. |
|
I would recommend data from orbit b or recon b |
|
If you want to let me know which images you select, I will run phocube and caminfo in our system to provide a relative comparison. |
|
@KrisBecker Full caminfo from |
|
I imagine we can close this out with a PR setting the default IsisPreferences to point to the new data area? Is there a justification for keeping the old data_local path? |
|
I would perhaps keep the local directory in some archive. It might be useful for historical regression testing or comparisons. But you need to update IsisPreferences to the correct path in the ISIS distribution. We have |
|
@Kelvinrr Below are the basic commands that I believe you ran on the OCAMS MapCam image take during Orbit B phase: Here is the caminfo output. Note UA/ISIS version is not adding the oblique emission/detector angles: However, more accurate geometry be achieved using a Bennu shape model provided in the PDS SPICE Archive. These shape models are included in the download configuration. Here are the commands to add the Bennu global shape model: This provides significant differences in the geometry at the image center pixel: Another geometry precision enhancement can be adding by applying the center of gravity structure offsets. This should work in the current system. The NAIF DSK toolkit containing ray tracing methods is the default when a DSK (.bds) is provided. Using the Bullet ray tracing engine (which OREX/IPWG uses for all geometry) will improve mapping efficiency and provides occlusion detection enhancements. We do not recommend using the Embree ray tracing engine as we have encountered significant problems in our testing. We do not know the state/capabilities of these ray tracing functions in the current version of ISIS. One important difference with MapCam camera model in UA/ISIS is it uses the OpenCV calibration model to correct for detector distortion. I recommend you process a PolyCam image as well. It uses the old distortion model and may be a better test. |
|
BTW, here is the kernel configuration on the UA/ISIS system for 20190608T005825S208_map_iofL2pan.cub that produced the ellipsoid results: |
|
@Kelvinrr Is this work completed? |
|
Hi @Kelvinrr, @jessemapel, et al... Just wanted to let you know that the OREX team has released more data to the PDS, including kernels. This update provides kernel coverage through 2020-08-17. It should be a very simply process to add these kernels to ISIS using the kernel maintenance script. Just rerun with the OREX PDS configuration and it will add the new kernels to ISIS and create new versions of the kernel DBs. It should not impact any s/w app tests. Let me know if you encounter problems. Thanks... |
|
@KrisBecker Kernels were updated earlier this week for use internally including the newer kernels you just posted. The kernels will be publicly available with the next ISIS release in April. |
|
I don't know whether to reopen this issue or create a new one, but I am downloading all of the ISIS4+ data area (isisdist.astrogeology.usgs.gov::isisdata) and am seeing some things that may need to be addressed or at least documented. There is a significant increase in the number of OREX CK and SPK kernels that don't appear to be used or needed in ISIS. The OLA CKs, of the form orx_ola_YYMMDD_scil2idNNNNN.bc, are instrument specific (i.e., scan mirror adjustments) and there is no support for OLA in ISIS so they are not needed. There are lots of these. The S/C gimble CKs are also not used. These kernels are of the form orx_sa_rel_YYMMDD_YYMMDD_vXX.bc. These should be removed. There are also a number of expressly named kernels that I have no idea where they came from. They are not in the PDS archive and the IPWG did not use these kernels. Some examples of these kernels are Equatorial_Stations_1.bc, Plume_Search_1.bc, etc... The point is that these kernels are likely redundant that are also contained in the S/C REL kernels. Anybody know where they came from and their fidelity? Currently, some appear to be tagged as Predict types in the kernel DB file, but I don't think they are necessary. Currently there are only two types of CK kernels that need to included in the ISIS release - S/C orientation (orx_sc_rel_YYMMDD_YYMMDD_vXX.bc ) and payload structure kernels (orx_struct_mapcam_v01.bc and orx_struct_polycam_v01.bc). I am also seeing additional SPK kernels that are not in the PDS archive. Some of the examples of these SPK kernels are ORX_Recon_225mSortie_Case02.bsp, OrbitalA_600s_20181203T230000_20190109T000000.bsp, etc... Again, these could be redundant with the standard general coverage kernels (of the form orx_YYMMDD_YYMMDD_YYMMDD_odNNN_vX.bsp) but we have not used them. Anybody know where they came from? Some of these also appear to be tagged as Predict in the DB, which I don't think are needed. There are s/c SPKs in the TSPK directory that should not be there. In fact, they appear to be a copy what is in the SPK directory. All the kernels in $ISISDATA/osirisrex/kernels/tspk of the form orx_YYMMDD_YYMMDD_YYMMDD_odNNN_vX.bsp should be removed. There appears to be some residual files that I think are remnants of MacOSX tar file extraction that should be removed. There are some in the IAK directory (e.g., iak/._orex_ocams_addendum_v04.ti). Unless there are compelling reasons to include these additional kernels, they should be removed so as to try to keep it clean and limit the size of the ISIS DATA download. Thanks... |
|
@KrisBecker I've spun your post off into a new issue so that it's easier for us to track completion on it. I'm also going to get it added to the support prioritization |
Description
Both #4054 and #4058 show a community desire to be able to use ISIS to work with ORex data. Currently, these kernels are not available within the ISIS ecosystem. This enhancement request asks that the kernels be made available.
I see that ORex kernels are available via NAIF here. I do not know if these are the kernels we would want in a format that is immediately usable (so I do not have a handle on the scope of effort required to make this happen).
Example
Spiceinit works without throwing an error.
The text was updated successfully, but these errors were encountered: