Hi all,
I have an SX220HS (firmware 1.01C, CHDK sx220hs-101c-1.1.0-1868-full_BETA) mounted on a microscope.
---not so relevant details, maybe continue below ---
I have been using an IXUS70 so far but changed to the SX220HS to record videos at higher resolution. I mostly control the camera through the "ptpcam --chdk" client on linux. There is a major advantage of the SX220HS over the IXUS70 as ptp communication still reacts while recording a video sequence, enabling me to stop recording once the microscope has performed its job. On the IXUS70 I had to submit a lua script that would press "stop", i.e. click("shoot") after a predefined amount of sleep(). On the SX220HS, click("video") just works fine over ptp.
--- here's the thing ---
There are a couple of things that I believe are "bugs" or rather unfinished porting issues. I have set up a compiler CHDK, but I don't see myself capable of usefully altering the source code so that the community could profit. In the end, I would have to try, but I am for now listing the issues that don't work with the above-mentioned camera-FW-CHDK combination. All of these issues occur when controlling the camera via ptp. I am not using the camera's "keyboard".
1. wheel_left(), wheel_right(): no effect in various capturing modes, which is mostly impairing in manual mode.
2. crash after zooming unless "mode selector wheel" is in P position:
-When booting the camera in P position, CHDK boots with a white-on-red startup text. When booting in other modes, e.g. auto, video, it's white-on-organge. Well, this does not really impair functionality, but might help figuring out what's going wrong. As soon as the camera is not booted in P position, switching to record mode still works. However, executing a "set_zoom()" will crash the camera. Thus, to get to manual mode via ptp, I have to send and run the following script:
send "mode 1" via ptpcam
sleep(3000)
set_zoom(115)
capmode=require("capmode")
print("started")
capmode.set(capmode.name_to_mode["M"])Once this is set (I need a zoom of 115 due to the optics of my microscope), any further zoom change in this mode mostly results in a camera crash.
3. I have been looking through the RAM of the camera and identified some potentially interesting "regions". One might have to do with the image stabilizer. If you dump the RAM from 0x9A32DD with a size of 68215 bytes using ptpcam (with a tiny modification I could post if anyone wants it), one gets a BW-image (320x ca.200), every 4 bytes are in reverse row order. This image is frequently updated and changes size (crops away information from the edges) as soon as the object in focus is moving. Maybe this RAM location could be of interest to someone.
4. viewport size via "video out": The viewport size via video out is not the same as on the display, it's sort of 4:3. I have connected the camera via one of those dual usb/video-out plugs (can post the pinout) to have usb and video simultaneously. Two of the video pins are short-circuited by the original video plug, telling the camera to change the viewport size. I did not yet figure out how this affects RAM locations. However, all the menus and the viewfinder "bitmap" overlay are changed by the original firmware while CHDK ignores the change and gets clipped off on the right side of the image. This, in turn, would suggest that the viewport RAM locations don't change. All this, however, seems to cause some disturbance in "md_detect_motion()" as the coordinates of the definable viewport regions are not following original conventions. As I need access to the viewport data (with as high framerate as possible), either on the camera or via ptp, I would like to ask whether anyone figured out where to grab the YUV image from the viewport while in "video out display mode". Here are the approximate potential regions within the RAM that I dumped and that seem to contain some relevant data:
| start byte h | 9A32DD | 1A9B81F | 1AD23A6 | 1B0B53E | 1B446D6 | 1B7B25D | 2001CB4 | 29436D8 | 4001357 |
| size to read | 68215 | 155920 | 165665 | 155920 | 155920 | 165665 | 321585 | 487250 | 331330 |
Any suggestion which buffer I should dump?
5. Does anyone know how to extract the coordinates determined by the "tracking AF"? This feature would be neat in my setup as it could help me track some changes in my specimens. I get a rather high contrast image on the microscope which is "easy" for the canon tracking af.
If anyone would be willing to resolve the above mentioned issues I would do the testing of the code and give feedback. I am working in a scientific setting so I am mostly interested in getting my system to work where the camera is just a part but plays an essential role. I am glad there is CHDK and it already helped me a lot so far. I could compile the code here, set up a svn client to fetch changes but could also test built versions. Ideally, the achievements would find their way into both CHDK and "chdkptp" so that we all could profit.
