Ephemeris times in ALE

[oleg-alexandrov]

Various drivers in ALE, such as type_sensor.py, mro_drivers.py, and nh_drivers.py have a function named ephemeris_time(self) that samples the times between the starting time and ending time with uniform spacing.

The problem is that the number of samples equals to the number of lines in the image. Those are then use to interpolate the positions and orientations.

Such a high number is usually excessive as a satellite position and orientations varies very slowly, not for every single scanned line. This also creates immensely huge CSM cameras that can take 10-20 minutes to load.

I put local fixes for this for the Chandrayaan drivers (these can have about 180k lines), but a fix to every single supported sensor would likely take a serious amount of validation and I am at the end of my time with USGS for this year.

Putting this here in case this issue shows up again with another sensor.

[acpaquette]

@oleg-alexandrov This is a bug more so than a feature. ISIS currently applies reduction methods to the ephemeris data coming from ALE.

We need to add some smarter reduction methods to the ALE ephemeris data coming directly from ALE rather than depending on ISIS to perform the reduction.

[oleg-alexandrov]

Indeed, especially that ALE is called directly by the user, via isd_generate, rather than via ISIS.

[thareUSGS]

We need to add some smarter reduction methods to the ALE ephemeris data coming directly from ALE rather than depending on ISIS to perform the reduction.

Agreed. We need to make sure the exported ISD is reduced so we don't carry around giant files. I am surprised to hear there isn't a reduction already happening though (perhaps some drivers have this already).

[Kelvinrr]

To add to this, we should reduce the sample rate in ALE, we also need to be able to aggregate when passing into calls to SpiceQL. Web calls can take 20 minutes for something like large LROC images. If we can reduce the samples enough maybe it's not necessary.

[acpaquette]

I was thinking about this more and applying something like a hermite spline carries with it the assumption that consumers of the data will need some type of interpolation. Either ALE should ship the ability to interpolate over the data, or we should use a simpler reduction method. We have the interpolation code in the C++ side of ALE so maybe that is good enough and just needs a wrapper?

I have experimented with just 10, 100, and 1000 sample rates on CTX with limited accuracy lose. You lose the most reducing to every 10th line, then the accuracy lose is marginal per magnitude step. Exposing a linear sample reduction would be fairly trivial but would carry with it an unknown accuracy penalty to the data.

[oleg-alexandrov]

applying something like a hermite spline carries with it the assumption that consumers of the data will need some type of interpolation

The consumer of the data always needs interpolation. In many camera calculations need to do operations at subpixel level.

My experience with satellite vendors is that they provide a pose sample for every 100 to 1000 image lines.

I am not sure why ALE even resamples the poses. I think it should just query SPICE, no? The data provider put some samples in there, which need to be used as is. As things are now, ALE first does one interpolation, and then USGSCSM interpolates into the interpolated data.

[acpaquette]

ALE only resamples the rotations due to frames within the chain having different sampling intervals in spice. The positions shouldn't be resampled but they are rotated from body fixed to J2000 into the ISD, then rotated again back from J2000 to body fixed in USGSCSM. We should probably just produce the position in J2000 directly from ALE rather than the superfluous back and forth