Interesting project.
There is some interest in being able to use consumer grade cameras instead of the very expensive regular cameras. I wonder if I should build this on chdkptp or not? Can it be used as a library from my C code, or would you agree if we make it such that it can be used both as a library, and a CLI/GUI?
It currently isn't a library, but it has always been my intention split out the PTP code into a one. It's pretty modular already, the C code just provides a low level API and all of the cli and gui code is in Lua. The lua code is broken into modules that provide higher level functions for dealing with the camera, handling the CLI, GUI and so on.
If you only want to use the C code, you might find yourself re-implementing some of the higher level stuff that is done in Lua. However, there's no reason you couldn't build a library that used the lua code, either from external files or included in the binary.
You should be aware that the current code is in a pretty rough state, and I don't have a whole lot of time to work on it. It's functional for the things it does, but there's a lot of stuff that was just thrown together to get something working.
Our requirements are very specific - we want to have a well-performing live view,
This would depend on what you mean by "well performing". There's a few things to consider:
1) Resolution: the camera live view resolution is quite low, generally 240 or 480 lines (width depends how you count it, but you could say 720-960). You can capture and download stills at much higher resolution of course, but lower frame rate.
2) Frame rate: On a modern PC, without spending a lot of effort optimizing, 10 FPS is easy, much over 20 is unlikely. I'm not sure how fast the live view itself updates, I doubt it's over 30 in most cases.
3) Visual artifacts: Transmitting the frames isn't synchronized with viewport updates, so you can get tearing. This might be fixable, with some frame rate cost.
with the ability to change camera settings now and then.
Camera control is done by sending Lua code (or messages to an already running script) to the camera, meaning that all the exposure parameters that normal CHDK scripts can control are available. This gives you pretty complete control over shooting. Camera side scripts can also send arbitrary data to the PC side, so the PC code can get any values that are available to camera side scripts.
All the storage and processing will be on the computer side. How optimized is the library for this currently e.g. is it possible to download one frame while capturing the next? (is this possible to implement at all otherwise?)
I'm not sure exactly what you are asking.
The live view is separate from still image capture. The actual process of shooting a still will briefly disrupt the live view: on many cameras, the full frame raw buffer overlaps the viewport framebuffer, so you will see "snow" in the live view. At a minimum, the live view will not get updated with valid data while shooting is in progress.
Currently, we can't capture stills directly over USB, you'd have to let the still capture process save it on the camera card and then download it. Getting the raw data out of RAM is doable, but would only make sense if you want to work with raw, otherwise you'd be better of letting the camera save a jpeg and then download it as a file. Getting jpeg data from the camera is also probably possible, but would require some reverse engineering.
If you are talking about downloading a still while the next one is capturing, that's probably doable (assuming you are downloading files, probably not if you are getting raw from RAM) I tried running live view at 20 fps (~9 mbyte/sec) while doing some long exposures, and didn't see any problems or significant drop in throughput. I also tried shooting in continuous mode, and surprisingly that didn't seem to hurt anything or affect throughput much either.
The current code is single threaded, so long running USB operations like downloads block the rest of the application. However, having the USB stuff in a separate thread or process should be fine, and is on my TODO list.
