Currently, no calculations/compensation/corrections are applied to the readings from the thermal sensor. Only the raw data is output.
Implement calculation of To per Melexis datasheet sec 7.3.3

• calculate Ta
• calculate To

The available demos currently just display pixels onscreen 1:1 with the sensor pixels. Add some interpolation to the display to fill "in-between" pixels with averages of their neighboring pixels.

...and possibly inaccurate.
PTAT calculation, as well as probably other pre-calculated values, are currently calculated using integer only math because SPIN has no floating point support, so things like offsets are imprecise, and possibly inaccurate. For reference, the example calculations in the Melexis datasheet have 8 decimal places!!!

Using fixed-point math would normally be an option, by scaling everything up by some static factor, but some numbers involved end up overflowing even the largest storage size (long). Kt1 is a good example of this, when using a scaling factor of 1000. 100 is within bounds, but offers no precision when used on, for example, Kt2.

I'm reluctant to integrate something like Float32 into the driver/object, as it just seems too much of a burden (here's wishing SPIN had better support for fractional numbers).

It doesn't perform a hard/soft-reset, as in other drivers, and it also has a parameter.

The user needn't worry about this. Redefine as a private method and maybe call it on driver startup with a parameter appropriate to the I2C bus speed chosen.

Leverage some of EVE's accelerated graphics primitives to create a better, faster demo.

Currently, this will silently fail as there's no error/failure code returned if the EE doesn't respond or if there's some other problem. Add some sort of operation check and some error code(s).

Calculate it arithmetically (base2 log, add/sub 5) instead of using the more memory hungry tables.