Well, an image is an array of int values. So you can use values up to some 2 billions...
Of course, to display it, you have to map these values back to the 0-255 range. Most graphics card can display only 16 millions of colors, anyway.

I am not interested in the display, the values are used to pick frames - they don't reflect color.

Well, I suppose you have specific image formats for HDR. So you need a Java library able to read these formats.

Perhaps this function can help a little?
http://processing.org/reference/brightness_.html

That function actually simplifies my code a bit, but doesn't remove the core problem.

I cant find out anything to tell me if  PImage() supports higher color depths then 0-255.

There's also colorMode(): http://processing.org/reference/colorMode_.html
Internally however, Processing would still continue to use 32-bit ARGB though.

Indeed....which is the problem ;)
(confused me for a bit that did too)

I also briefly considered doing some "trick" to work around the limitation.
As its 0-255 for each of the channels, I could do some maths to store large numbers and retrieve them by using more then just the brightness.
But then, making the timemap image to start with would would become crazy complex. The whole point of using an normal image was to be able to "paint" or even animate time distortions using other bits of software and then load it in.