HiRISE Image Offsets

[richardleis]

ISIS version(s) affected: 3.1.18 through 3.2.1 and 3.4.13

Description

We have discovered offsets of several hundred pixels (differences in latitude and longitude from 0.0002 to 0.002 degrees) when reprocessing HiRISE observations and geometry products with ISIS 3.4.13. These offsets were detected while reprocessing merged products (the mapped color swath overlaying the mapped RED mosaic.) Reprocessing occurs in the following steps:

• COLOR4 and COLOR5 balance cubes are reprocessed with the latest SPICE kernels using ISIS 3.4.13 • COLOR4 and COLOR5 are geometrically mapped and mosaiced into a COLOR cube • A RED Mosaic cube is recreated from the PDS-released RED RDR *.jp2 product created from an older version of ISIS (ISIS 3.1.18 through ISIS 3.2.1) using JP2_to_PDS and hirdr2isis • The COLOR and RED mosaics are merged to create new MIRB and MRGB products

These MIRB and MRGB products reveal the color swath offset from the red mosaic with shifts in latitude and longitude between 0.0002 and 0.002 degrees (tens to hundreds of pixels.)

HiRISE observations reprocessed prior to January 08, 2019 do not have this offset. Observations reprocessed starting January 08, 2019 have this offset. Reprocessing both COLOR and RED mosaic cubes directly from the CCD and color balance cubes (in other words, not recreating a RED mosaic cube from the PDS-released RED RDR) results in no offset, but the new Mapping group in the new RED mosaic cube does not match the originally-processed mapping group by between 0.0002 and 0.002 degrees.

I went through the exercise of applying original SPICE kernels (LSK, FK, IK, SCLK) with spiceinit to the CCD balance cubes, then creating a RED Mosaic cube. Using these old SPICE kernels did not reproduce the original mapping group results, suggesting that those specific SPICE kernels are not the problem.

We also considered the shape model (we started using version 2 on February 14, 2011) but the changes were related to a format change for ISIS rather than a model change.

Here is an example using HiRISE observation ESP_012300_1440. The color swath mosaic cube is reprocessed, the RED Mosaic cube is recreated from the latest RED RDR released to the PDS:

SPICE kernels:

LSK: naif0010.tls (01/11/12) versus naif0012.tls (07/27/16 – latest) FK: mro_v14.tf (05/01/09) versus mro_v15.tf (10/25/12 – latest) IK: mro_hirise_v11.ti (02/27/09) versus mro_hirise_v12.ti (05/24/11 – latest) SCLK: MRO_SCLKSCET.00048.65536.tsc (05/23/12) versus MRO_SCLKSCET.00081.65536.tsc (03/04/19 – latest)

Original Mapping group results using ISIS 3.1.18:

PRODUCT_ID ESP_012300_1440_RED IMAGE_CENTER_LATITUDE -35.7996 IMAGE_CENTER_LONGITUDE 154.394 MINIMUM_LATITUDE -35.8898 MAXIMUM_LATITUDE -35.7093 MINIMUM_LONGITUDE 154.327 MAXIMUM_LONGITUDE 154.46 UPPER_LEFT_LATITUDE -35.8791 UPPER_LEFT_LONGITUDE 154.46 UPPER_RIGHT_LATITUDE -35.8898 UPPER_RIGHT_LONGITUDE 154.353 LOWER_LEFT_LATITUDE -35.7093 LOWER_LEFT_LONGITUDE 154.433 LOWER_RIGHT_LATITUDE -35.7199 LOWER_RIGHT_LONGITUDE 154.327 LAST_UPDATE 1/9/19 10:42

PRODUCT_ID ESP_012300_1440_COLOR IMAGE_CENTER_LATITUDE -35.7996 IMAGE_CENTER_LONGITUDE 154.394 MINIMUM_LATITUDE -35.8898 MAXIMUM_LATITUDE -35.7093 MINIMUM_LONGITUDE 154.327 MAXIMUM_LONGITUDE 154.46 UPPER_LEFT_LATITUDE -35.8826 UPPER_LEFT_LONGITUDE 154.417 UPPER_RIGHT_LATITUDE -35.8848 UPPER_RIGHT_LONGITUDE 154.396 LOWER_LEFT_LATITUDE -35.7128 LOWER_LEFT_LONGITUDE 154.391 LOWER_RIGHT_LATITUDE -35.715 LOWER_RIGHT_LONGITUDE 154.369 LAST_UPDATE 3/22/13 11:00

New Mapping group results using ISIS 3.4.13:

PRODUCT_ID ESP_012300_1440_COLOR IMAGE_CENTER_LATITUDE -35.7999 IMAGE_CENTER_LONGITUDE 154.391 MINIMUM_LATITUDE -35.89 MAXIMUM_LATITUDE -35.7095 MINIMUM_LONGITUDE 154.325 MAXIMUM_LONGITUDE 154.458 UPPER_LEFT_LATITUDE -35.8828 UPPER_LEFT_LONGITUDE 154.415 UPPER_RIGHT_LATITUDE -35.885 UPPER_RIGHT_LONGITUDE 154.394 LOWER_LEFT_LATITUDE -35.713 LOWER_LEFT_LONGITUDE 154.389 LOWER_RIGHT_LATITUDE -35.7152 LOWER_RIGHT_LONGITUDE 154.367 LAST_UPDATE 1/13/19 1:45

Differences (236636.93053097 pixels per degree):

                                        degrees pixels

IMAGE_CENTER_LATITUDE -0.0003 -70.9911 IMAGE_CENTER_LONGITUDE -0.0030 -709.9108 MINIMUM_LATITUDE -0.0002 -47.3274 MAXIMUM_LATITUDE -0.0002 -47.3274 MINIMUM_LONGITUDE -0.0020 -473.2739 MAXIMUM_LONGITUDE -0.0020 -473.2739 UPPER_LEFT_LATITUDE -0.0002 -47.3274 UPPER_LEFT_LONGITUDE -0.0020 -473.2739 UPPER_RIGHT_LATITUDE -0.0002 -47.3274 UPPER_RIGHT_LONGITUDE -0.0020 -473.2739 LOWER_LEFT_LATITUDE -0.0002 -47.3274 LOWER_LEFT_LONGITUDE -0.0020 -473.2739 LOWER_RIGHT_LATITUDE -0.0002 -47.3274 LOWER_RIGHT_LONGITUDE -0.0020 -473.2739

How to reproduce
• COLOR4 and COLOR5 balance cubes are reprocessed with the latest SPICE kernels using ISIS 3.4.13 • COLOR4 and COLOR5 are geometrically mapped and mosaiced into a COLOR cube • A RED Mosaic cube is recreated from the PDS-released RED RDR *.jp2 product using JP2_to_PDS and hirdr2isis • The COLOR and RED mosaics are merged to create new MIRB and MRGB products

Possible Solution
Reprocess both COLOR and RED Mosaics with the latest SPICE kernels. However, is the shift in latitude and longitude by up to hundreds of pixels acceptable?

Additional context
Reprocessing of HiRISE data has been halted while this problem is investigated.

Thank you,

Richard Leis HiRISE Operations Specialist & Downlink Lead University of Arizona Tucson, AZ

[jessemapel]

Richard,

Are the offsets in any particular direction? down-track, cross-track?

We're probably going to need your re-processed files. @scsides Do you remember how we've gotten files like these before? I'm concerned about how large these can be.

[jessemapel]

@jlaura This may be a good candidate for the next support sprint.

[jlaura]

We should tag this for the next support sprint. I would also appreciate knowing if this is still present in 3.7.0? If we make the fix, that is the version that is going to see it (3.7.x).

@richardleis Can you reproduce with 3.7.0? The newest release.

[richardleis]

I've validated many of these reprocessed images visually and they can be offset in either direction.

We generally make files available to the USGS/ISIS team by putting them on a temporary webpage and sending a link to someone who can download them (instead of putting the link on the GitHub site.) After someone there has downloaded them, I can take the temporary webpage down.

I have also been testing ISIS 3.7.0; reprocessing an observation from EDRs through calibration, color, and geometry results in the same latitude and longitude values we see in ISIS 3.4.13. These are shifted from values calculated years ago with older versions of ISIS when these images were originally taken and processed here in Tucson.

Here's a screenshot of offset from ESP_012300_1440_MRGB.

[jessemapel]

@richardleis Can you get the files up at a download link and send that link to Jay, Stuart, and myself (jlaura (at) usgs.gov, ssides (at) usgs.gov, & jmapel (at) usgs.gov)? This seems like a high priority for next week, but even if we don't get to it, we can get the files downloaded at the ASC so it's ready to be worked on.

As Jay said, we will test any fixes in 3.7.0 and then it will be made available in 3.7.x, is that okay?

[richardleis]

A fix in 3.7.x would be fine. I'll make relevant files available shortly and send you all the link.

[scsides]

@thareUSGS Just in case anyone is wondering, The projection offset changes were first made available in 3.5.0

[scsides]

Data is on: /work/projects/progteam/bugs/hirise#3257/

[acpaquette]

@richardleis We are starting to look into this in more detail and are having a hard time reproducing the error you're seeing. So far we have reproduced a single red image (specifically RED5) in both ISIS3.4.13 and ISIS3.8.0 and there is no offset.

A more detailed description of how these products are being produced/processed would really help in determining the cause of this offset you're seeing. Specifically if you could give us a list of the commands, ISIS and others, that are being run that would be ideal.

[richardleis]

Step 1: We reprocess the HiRISE color products (using ISIS 3.4.13) using the HiColorInit, HiJitReg, HiSlither, and HiColorNorm processing pipelines to generate new COLOR4 and COLOR5 products.

Step 2: We then convert the older PDS-released mapped RED JP2 (created using ISIS 3.1.18) to an ISIS cube:

% JP2_to_PDS -I ESP_012300_1440_RED.JP2 -LA ESP_012300_1440_RED.LBL % hirdr2isis from= ESP_012300_1440_RED.mosaic.IMG to= ESP_012300_1440_RED.mosaic.cub

Step 3: COLOR4 and COLOR5 are combined into a new mapped COLOR.mosaic cube using ISIS 3.4.13 with the HiGeomInit, RedGeom, and RedMosaic pipelines.

Step 4: We run the HiMosMerge pipeline with ISIS 3.4.13 to merge the old RED.mosaic cube with the new COLOR.mosaic cube and this is where we are seeing the offsets because the edges of the COLOR mosaic do not match up with the terrain in the RED mosaic.

I have tried reprocessing the RED mosaic as in Step 3 above with ISIS 3.4.13 (instead of converting the old RED JP2 into a cube as in Step 2 above.) A new RED mosaic merges with a new COLOR mosaic results in no offsets, but the center and corner latitudes and longitudes of the old (ISIS 3.1.18) and new (ISIS 3.4.13) RED mosaic do not match. We don't know why these values have shifted between 3.1.18 and ISIS 3.4.13.

[acpaquette]

@richardleis Would it be possible to break down the HiColorInit, HiSlither, HiJitReg, and HiColorNorm processing pipelines along with the HiGeomInit, RedGeom, and RedMosaic pipelines down further to what commands are being run in each? I'm not 100% sure but I don't believe that we have access to those pipelines.

[richardleis]

Sure. This will get a little lengthy, but I have included an overview of the ISIS tools used:

HiColorInit prepare images for coregistration with RED4 - BG12 - IR10 (eventually becoming COLOR4) and RED5 - BG13 - IR11 (eventually becoming COLOR5) balance cubes.

• The ISIS program getkey obtains the number of lines and samples, binning, and TDI from the labels of the products
• The ISIS programs reduce or enlarge (whichever is needed) are used to re-scale the BG and IR products to match the RED, and to correct for differences in binning, TDI and optics. For instance, if the binning ratio is 4 (i.e. RED=1, IR=4), then IR product is enlarged by a factor of 4. We account for optical distortion by multiplying the enlargement factor for BG by 1.0006, and dividing the enlargement factor for IR by 1.0006.
• The ISIS program handmos creates properly-scaled BG, IR, and RED cubes corrected for relative differences in line offset (extension .precolor.cub)
• The ISIS program editlab edits the label of the re-scaled cubes to reflect the new binning.

HiJitReg corrects for spacecraft jitter and prepares images for coregistation.

• Uses the ISIS program hijitreg to create a reference grid of control points (extension .control.pvl) from the RED product, and then attempts to locate those points within the BG and IR products.

HiSlither does a "rubber-sheet stretch" of the IR and BG to correct for jitter and match the RED based on the control net output (extension .control.pvl) of HiJitReg. It then stacks the IR, RED, and BG and on top of one another (in IR-RED-BG order).

• The ISIS program slither computes an image transformation that shifts lines and samples as needed according to the control net file (extension .control.pvl) created by HiJitReg. It also creates a text file (extension .slither.txt) containing the transformation statistics, and a text file (extension .control.csv) from the smoothing algorithm that checks for "bad" (those that may cause misregistration) control points. The transformation for each of the valid control points in a row is averaged together to arrive at a transformation for the entire row (line). Between rows, the transformation is interpolated.
• The ISIS program hicubeit merges the IR, RED, and BG cubes on top of one another to create two separate 3-band color products (extension _COLOR4.cub and _COLOR5.cub).
• The ISIS program trim removes the inner overlap from the color halves.

HiColorNorm normalizes the BG and IR color across the left and right COLOR4 and COLOR5 halves.

• The ISIS program ratio
• The ISIS program crop
• The ISIS program handmos
• The ISIS program cubenorm
• The ISIS program crop is used again...
• The ISIS program lowpass applies a lowpass filter to the cube...
• The ISIS program algebra
• The ISIS program handmos is used again...

COLOR4 and COLOR5 are then sent on to geometry processing. I'll include those steps as well below.

HiGeomInit prepares files for geometry processing.

• The ISIS program spiceinit injects SPICE kernel data into the HiColorNorm COLOR4 and COLOR5 balance cubes.
• The ISIS programs campt and camrange extract viewing geometry parameters for each image to be recorded in our database catalog.

RedGeom runs the ISIS program cam2map to create geometrically-projected RedGeom cube files of COLOR4 and COLOR5.

RedMosaic runs the ISIS program himos to create a geometrically-projected COLOR mosaic from COLOR4 and COLOR5.

Once we have COLOR and RED mosaics, then we can merge them with HiMosMerge. Two different stretches are used to result in two different merged products. There's a lot going on in this pipeline and I don't have a good summary like I do for the pipelines above, but a quick check of the code reveals:

• A three-band RED cube is created from the RED mosaic cube.
• ISIS tools including mapmos manage the stretches and colors and merge various bands into the final products.

I think mapmos might be important here because it's used to merge the RED and COLOR bands into the final products. The bands from COLOR and RED should line up well, but they are mismatched between a RED mosaic created by ISIS 3.1.18 and a COLOR mosaic created by ISIS 3.4.13. They match if the RED and COLOR mosaics are both created by ISIS 3.4.13, but the new center and corner latitudes and longitudes don't match the old values we recorded in 2010 from ISIS 3.1.18.

I hope this helps, but let me know if you need more information.

[jlaura]

@richardleis Thank you for the detailed information.

As we look into this, we are going to need help in tracking down where the difference initially occurs as reproducing the pipeline as a whole is not the most effective way for our devs to try and identify a problem. Two questions to try and target this a bit more:

1. Where in the above pipeline do differences start to occur? Is will help us understand which app/underlying code to take a more detailed look at.
2. Is it possible to get an end-to-end reproducible example that we can run locally? Preferably, this would be a minimal example that reproduces the error with the lowest complexity possible. This will allow us the ability to fully reproduce locally.

As it stands, I am concerned that the scope of trying to just reproduce this locally is quite large.

[rbeyer]

HiRISE observations reprocessed prior to January 08, 2019 do not have this offset. Observations reprocessed starting January 08, 2019 have this offset.

So, what happened on January 08, 2019, at HiROC? That's when you say you noticed a difference in outcome. Is that when you switched an ISIS version or something?

I went through the exercise of applying original SPICE kernels (LSK, FK, IK, SCLK) with spiceinit to the CCD balance cubes, then creating a RED Mosaic cube. Using these old SPICE kernels did not reproduce the original mapping group results, suggesting that those specific SPICE kernels are not the problem.

If using what you think are the 'original SPICE kernels' with the older version of ISIS didn't reproduce the original mapping group results in the old RED data, then that actually does seem like a problem.

[richardleis]

I will discuss this further with our team and get back to you.

We haven't been able to find anything that changed on that date at HiROC. I investigated the possibility that it wasn't related to that day but to the past when those orbit ranges were processed or reprocessed previously using older versions of ISIS. I did not find any patterns.

[acpaquette]

@richardleis Echoing what @jlaura mentioned in his previous comment, any potential issues are difficult to pin point as we would need to reconstruct the processing pipeline.

To really approach this problem, getting the ISIS application that produces a different result along with the input and output of each of the previous steps before the point where things diverge would be ideal.

[richardleis]

I think we can simplify the problem slightly to this: why does a RED RDR produced with ISIS 3.1.18 have significantly different geometry than a new RED RDR produced with ISIS 3.4.13? But there are still several steps involved in geometrically mapping CCD products and creating mosaics, involving many ISIS tools between spiceinit and himos. I understand we may need to narrow this issue down even further here at HiROC.

Asking a potentially dumb question: Can we still get access to ISIS 3.1.18 for use here at HiROC? I could produce a new RED RDR with ISIS 3.1.18 to see if I get the same geometry results we did back in 2010.

[jlaura]

@richardleis We will checkout getting 3.1.18 available via some mechanism (I am not 100% if/how we will do this as 3.1.18 is ~8+ years old and I believe only available on some old SUSE box, maybe). If you can then look at the generation of a RED RDR, that would be great. If the geometries are different, we would then appreciate information on which specific command results in a difference.

Thank you for all of your responses on this issue helping to work through trying to reproduce what is going on. I realize this is challenging as we do not have access to the pipeline that is being run and appreciate your help.

[rbeyer]

Richard, et al., you can talk more with Rod about what I've been up to, but one of the things I've been doing is disassembling the HiRISE pipelines and recreating them (with Python). Partially as an exercise to help myself understand what they're doing and how they're operating so we can get a handle on where to make changes to potentially improve the HiRISE calibration process, and partially to be able to very carefully and slowly move an image through the process, with the ability to inspect it at every step.

I think the key is to be able to reproduce the 'old' geometry. If we can do that, we can get a handle on things, and since I have this 'disassembled' pipeline, I might be able to help.

However, we could all spend a bunch of time trying to do forensic code analysis, and discover that what changed might be related to an ISIS code change that was really a bug fix (and therefore you wouldn't want to revert) or an improvement in the SPICE data (and you wouldn't want to use 'old' SPICE data anyway).

Have you considered just assuming that the 'new' mosaics are correct, and just forcibly correcting the geometry on the old REDs when you read them in?

[acpaquette]

@richardleis There is a version of isis3.1.18 available through rsync with the following command:

rsync -tpv isisdist.wr.usgs.gov::isis3_1_18/isis3.1.18.zip .

This will copy a zipped version of isis into the current working directory. You should only need to unzip the file and the binaries should be available to you. Let myself or the other ISIS devs know if you run into any issues. Hopefully this process goes smoothly but I have a feeling there will be a few problems.

[richardleis]

Ross: we're worried about what's correct: the old mosaics or the new mosaics. If it was just a hundred or so pixels, that's within expected errors, but the differences I calculated were several hundred pixels.

[richardleis]

Not having much luck. Our Systems team installed it but there are lots of missing libraries. Example with cubenorm:

pnode01% ldd ./cubenorm linux-gate.so.1 (0xf777e000) libisis3.so => /apps//opt/usgs/isis3.Linux.x86_64.3.1.18/lib/libisis3.so (0xf72ba000) libQtNetwork.so.4 => /apps//opt/usgs/isis3.Linux.x86_64.3.1.18/3rdParty/lib/libQtNetwork.so.4 (0xf71bf000) libQtSql.so.4 => /apps//opt/usgs/isis3.Linux.x86_64.3.1.18/3rdParty/lib/libQtSql.so.4 (0xf7116000) libQtGui.so.4 => /apps//opt/usgs/isis3.Linux.x86_64.3.1.18/3rdParty/lib/libQtGui.so.4 (0xf6823000) libQtCore.so.4 => /apps//opt/usgs/isis3.Linux.x86_64.3.1.18/3rdParty/lib/libQtCore.so.4 (0xf6603000) libqwt.so.5 => /apps//opt/usgs/isis3.Linux.x86_64.3.1.18/3rdParty/lib/libqwt.so.5 (0xf6550000) libxerces-c.so.27 => /apps//opt/usgs/isis3.Linux.x86_64.3.1.18/3rdParty/lib/libxerces-c.so.27 (0xf6173000) libcspice.so => /apps//opt/usgs/isis3.Linux.x86_64.3.1.18/3rdParty/lib/libcspice.so (0xf3f43000) libgeos-3.0.0.so => /apps//opt/usgs/isis3.Linux.x86_64.3.1.18/3rdParty/lib/libgeos-3.0.0.so (0xf3e09000) libgsl.so.0 => /apps//opt/usgs/isis3.Linux.x86_64.3.1.18/3rdParty/lib/libgsl.so.0 (0xf3bb1000) libgslcblas.so.0 => /apps//opt/usgs/isis3.Linux.x86_64.3.1.18/3rdParty/lib/libgslcblas.so.0 (0xf3b53000) libblas.so.3 => /apps//opt/usgs/isis3.Linux.x86_64.3.1.18/3rdParty/lib/libblas.so.3 (0xf3b02000) libgfortran.so.1 => /apps//opt/usgs/isis3.Linux.x86_64.3.1.18/3rdParty/lib/libgfortran.so.1 (0xf3a90000) libstdc++.so.6 => not found libm.so.6 => /lib32/libm.so.6 (0xf3a37000) libgcc_s.so.1 => not found libc.so.6 => /lib32/libc.so.6 (0xf388a000) libstdc++.so.6 => not found libgcc_s.so.1 => not found libz.so.1 => not found libgthread-2.0.so.0 => not found libglib-2.0.so.0 => not found librt.so.1 => /lib32/librt.so.1 (0xf387f000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf3863000) libdl.so.2 => /lib32/libdl.so.2 (0xf385e000) libstdc++.so.6 => not found libgcc_s.so.1 => not found libxslt.so.1 => not found libxml2.so.2 => not found libpam.so.0 => not found

etc...

[jlaura]

@richardleis I know that we had to dig up some third party dependencies from different sources as well. This is a super old version that is no longer being supported. Unfortunately, we do not have the bandwidth to compile these dependencies and actively support version 3.1.18 beyond making the binaries available.

[richardleis]

I narrowed this down to our HiGeomInit pipeline and spiceinit, campt, and/or camrange. Camrange reports different minimum and maximum latitudes and longitudes for each CCD depending on the version of ISIS, but there are groups of ISIS versions that report the same results. I ran several observations processed by older versions of ISIS through 3.4.13, 3.5.2, and 3.9.0 and compared the reported minimum and maximum latitudes and longitudes with those reported earlier. In summary:

• 3.1.20, 3.2.1, 3.4.3 and 3.4.12 and later ISIS versions (3.5.2 and 3.9.0) all report the same results
• 3.4.2 and 3.4.4 through 3.4.11 report different results
• 3.1.17 and 3.1.18 report different results (and different results from each other) but all of these cubes were eventually reprocessed with 3.2.1)

A couple examples (these are min and max values for the entire mapped RED mosaic, before the mosaic is created in later pipelines):

ESP_012195_1750

3.1.17: MINIMUM_LATITUDE: | -5.41812 MAXIMUM_LATITUDE: | -4.94864 MINIMUM_LONGITUDE: | 137.287 MAXIMUM_LONGITUDE: | 137.438 LAST_UPDATE: | 3/14/09

3.1.18: MINIMUM_LATITUDE: | -5.41807 MAXIMUM_LATITUDE: | -4.94859 MINIMUM_LONGITUDE: | 137.287 MAXIMUM_LONGITUDE: | 137.438 LAST_UPDATE: | 6/21/09

3.2.1: MINIMUM_LATITUDE: | -5.41831 MAXIMUM_LATITUDE: | -4.94883 MINIMUM_LONGITUDE: | 137.285 MAXIMUM_LONGITUDE: | 137.436 LAST_UPDATE: | 5/11/11 10:22

3.4.13, 3.5.2, 3.9.0 MINIMUM_LATITUDE: | -5.41831 MAXIMUM_LATITUDE: | -4.94883 MINIMUM_LONGITUDE: | 137.285 MAXIMUM_LONGITUDE: | 137.436 LAST_UPDATE: | 9/13/19 10:18

ESP_046767_1980

3.4.12, 3.4.13, 3.5.2, 3.9.0 all agree: MINIMUM_LATITUDE: | 17.5118 MAXIMUM_LATITUDE: | 17.7574 MINIMUM_LONGITUDE: | 213.889 MAXIMUM_LONGITUDE: | 214.009

[jlaura]

For each version, are you using the same data area or a different data area?

[richardleis]

For 3.4.13 I used our production data area (this is version of ISIS we're still using for public-released HiRISE image products.) For 3.5.2 and 3.9.0 I used my own sandbox because we are still testing newer versions of ISIS before we eventually upgrade.

[jlaura]

Can you check the labels on the example with differences and see if the same SPICE kernels are being loaded? I doubt the kernels are the same. When they aren't, can you post those differences? Thanks!

[richardleis]

Here's the reported spiceinit Kernel group for each version for ESP_012195_1750:

3.1.17 NaifIkCode | -74699 LeapSecond | $base/kernels/lsk/naif0009.tls TargetAttitudeShape | $base/kernels/pck/pck00008.tpc TargetPosition | $base/kernels/spk/de405.bsp InstrumentPointing | ($mro/kernels/ck/mro_sc_psp_090303_090309.bc, $mro/kernels/fk/mro_v11.tf) Instrument | Null SpacecraftClock | $mro/kernels/sclk/MRO_SCLKSCET.00028.65536.tsc InstrumentPosition | $mro/kernels/spk/mro_psp_rec.bsp InstrumentAddendum | $mro/kernels/iak/hiriseAddendum003.ti ShapeModel | /HiRISE/Data/NAIF/molaDTM/molaMarsPlanetaryRadius_HiRISE.cub

3.1.18 NaifIkCode | -74699 LeapSecond | $base/kernels/lsk/naif0009.tls TargetAttitudeShape | $base/kernels/pck/pck00008.tpc TargetPosition | $base/kernels/spk/de405.bsp InstrumentPointing | (/HiRISE/Data/NAIF/CK/mro_sc_psp_090303_090309.bc, $mro/kernels/fk/mro_v13.tf) Instrument | Null SpacecraftClock | $mro/kernels/sclk/MRO_SCLKSCET.00030.65536.tsc InstrumentPosition | /HiRISE/Data/NAIF/SPK/mro_psp10.bsp InstrumentAddendum | $mro/kernels/iak/hiriseAddendum003.ti ShapeModel | /HiRISE/Data/NAIF/molaDTM/molaMarsPlanetaryRadius_HiRISE.cub

3.2.1 NaifIkCode | -74699 LeapSecond | $base/kernels/lsk/naif0009.tls TargetAttitudeShape | $base/kernels/pck/pck00009.tpc TargetPosition | $base/kernels/spk/de405.bsp InstrumentPointing | (/HiRISE/Data/NAIF/CK/mro_sc_psp_090303_090309.bc, $mro/kernels/fk/mro_v14.tf) Instrument | $mro/kernels/ik/mro_hirise_v11.ti SpacecraftClock | $mro/kernels/sclk/MRO_SCLKSCET.00042.65536.tsc InstrumentPosition | /HiRISE/Data/NAIF/SPK/mro_psp10.bsp InstrumentAddendum | $mro/kernels/iak/hiriseAddendum006.ti ShapeModel | /HiRISE/Data/NAIF/molaDTM/molaMarsPlanetaryRadius_HiRISE_v2.cub InstrumentPositionQuality | Reconstructed InstrumentPointingQuality | Reconstructed CameraVersion | 1

3.4.13 NaifIkCode | -74699 LeapSecond | $base/kernels/lsk/naif0012.tls TargetAttitudeShape | $base/kernels/pck/pck00009.tpc TargetPosition | $base/kernels/spk/de405.bsp InstrumentPointing | (/HiRISE/Data/NAIF/CK/mro_sc_psp_090303_090309.bc, $mro/kernels/fk/mro_v15.tf) Instrument | $mro/kernels/ik/mro_hirise_v12.ti SpacecraftClock | $mro/kernels/sclk/MRO_SCLKSCET.00082.65536.tsc InstrumentPosition | /HiRISE/Data/NAIF/SPK/mro_psp10.bsp InstrumentAddendum | $mro/kernels/iak/hiriseAddendum006.ti ShapeModel | /HiRISE/Data/NAIF/molaDTM/molaMarsPlanetaryRadius_HiRISE_v2.cub InstrumentPositionQuality | Reconstructed InstrumentPointingQuality | Reconstructed CameraVersion | 1

[jlaura]

@richardleis Closing as I believe we determined during a Dec. telecon. If not, please reopen!