I have worked within the camera accessing the RAW data and it's painfully slow. All I needed was an aproximate histogram, so I was considering only one 1/1000th of the pixels and disregarding the difference in RGB (ignoring the bayer pattern in the RAW data). With all these simplifications, it takes about a second to build the histogram. If I were to process all the pixels it would take about 1.000 seconds, about a quarter of an hour.
You should be able to do much better. Reversing the order of bytes in the entire raw buffer in my a540 takes ~1/3 sec (with cache enabled and hand written asm) Applying curves to the entire raw buffer, uncached, with sub-optimal C code only takes a few seconds. Raw sum, subtract take tens of seconds, despite reading and writing the SD card.
You don't have to process the whole buffer either, you just have to distinguish one star from the noise. One way to do this would be to take a single, long exposure, and then measure the length and direction of a handful of trails. This should be doable with processing only a tiny fraction raw buffer using relatively simple code.
I do agree that tracking the stars is probably the more difficult approach. Just calculating the required shift based on user entered parameters (zoom, declination, camera orientation) would be far more straightforward.
The stuff on IS control was in
http://chdk.setepontos.com/index.php/topic,1365.0.htmlDepending on zoom, shifting tens of pixels would be enough to get the maximum 64 sec exposure without trails. OTOH, just taking shorter exposures and using software on your PC to register and stack them will probably give better results. Even at ISO 80, noise is pretty horrendous with a 64 sec exposure. Still, for the 15-64 second range, I think the idea has some merit. The IS movement doesn't actually have to be terribly smooth, because the it will still be small compared to the length of the exposure. I bet you could do one discrete step per second over a 64 sec exposure without much visible impact.
