This page collects resources and techniques for testing a CHDK build or port. See also Debugging
this is a work in progress, please expand!
The CHDK User Manual gives an good overview of many features. Working through this list and verifying that your port matches the documented behavior.
Note that many CHDK features are poorly documented or poorly defined. When in doubt, consult the source.
When testing overrides from script or the override menu, it is important to know Canon firmware displays and EXIF information may not reflect the actual value used. The functionality of the override should be determined from the image.
Verify DNGs validate with Adobe's DNG validator. dng_validate is included with the DNG SDK http://www.adobe.com/support/downloads/dng/dng_sdk.html
Take a series of shots and verify that each DNG contains the correct image data, to ensure raw buffers are all identified correctly.
Take a several of raw or DNG and make sure that the file numbers match the jpeg, and that no raws are skipped. Try both continuous mode and individual shots.
In the raw menu, set "RAW File in Dir with JPEG" and make sure the file is saved in the same directory as the corresponding jpeg.
Use Miscellaneous-> Show Memory info in the CHDK menu. If the Free Memory value is less than 400kb or so, there is a high risk of running out of memory. The port developer may be able to enable ARAM or EXMEM to gain additional memory.
To verify that the "viewport" is identified correctly, you can use the zebra, edge overlay and PTP live view functions
- Aim the camera at a bright light. The over exposed indicator should match the light, regardless of where the light appears on the screen.
- If it is offset, the viewport dimensions are probably wrong.
- If the zebra has no obvious relationship to the scene, the viewport address is probably wrong.
Testing with scripts
There are some scripts which exercise various CHDK capabilities.
This script tests focus (subject distance) override capabilities for CHDK 1.3 and later. This script should be used on every new port to determine the which override methods work. The script is included in full builds as CHDK/SCRIPTS/TEST/MFTEST.LUA
Test procedure for new ports
- Set the camera to P mode
- Make sure Canon firmware MF and AF lock are not enabled
- Make sure AF and Servo AF are disabled in the Canon firmware shooting menu, if present.
- Enable all test methods and set "Bypass Interlocks?" to Yes in the script options.
- Run the script.
- If the camera crashes on a test, disable that test and repeat
A detailed log is recored in mf_<cameraname>.csv (the name may be truncated on dryos cameras).
The log is appended on each run, so a full record will be present if you have to run it multiple times.
If a test is listed as passed, the method works.
If a test is listed as failed, the method either doesn't work, or the difference between the requested value and the value the camera set exceeded the tolerance in the script. It should be possible to distinguish this in the log.
Working methods should be enabled in the port's platform_camera.h using the CAM_SD_OVER_IN_* defines.
Tests the lua standard libraries. This also exercises many C library functions.
- run the script, with all of the 'skip' options set to zero.
- If all test succeeded, it will print "end ... OK" for each item.
- If any tests failed, examine A/llibtst.log
Tests the capture mode switching functions and mode map.
- start the camera in play mode
- run the script with all options set to zero
- the camera should switch to record, and switch rapidly between each known shooting mode
- If everything was OK, it will print pass
- If something failed, examine A/setmode.log
General purpose ubasic test.
- Download: ubtest.bas (also included in "full" install)
- Documentation: http://chdk.setepontos.com/index.php?topic=6592.0
- Start the camera in play mode
- Start the script with interactive = 1 and sleep between tests = 5
- The message "key test - set to end" will appear
- If you press up/down/left/right/menu/erase the corresponding key name should be printed.
- Press set to go to the next test
- The canon menu should open and selection change a couple times
- The camera will switch to record mode, and switch to P mode
- The camera will take shots as follows:
- auto exposure, using get_shooting, press shoot_half, press shoot_full etc
- auto exposure + or - 2 stops Tv, using shoot
- auto exposure + or - 2 stops Sv, using shoot
- If ND filter is present, one shot each with ND forced in and out, using shoot
- If no failures were identified, prints "ok", otherwise failed.
- Output is logged to CHDK/LOGS/LOG_0001.TXT. The log will indicate whether the shots above were + or -, with the corresponding exposure number. Compare the jpegs to ensure the images show the expected variation in exposure.
Tests the reaction speed of motion detection. This can be used find the optimal implementation of vid_get_viewport_live_fb()
- Download: MD_Tune.bas (also included in "full" install)
- Documentation http://chdk.setepontos.com/index.php?topic=9366.msg96633#msg96633 (note the scripts, patches and defines in the thread are no longer needed, you should use the script included with the CHDK source above)
- Live view buffers functions return pointers to valid data (see other frame viewport buffers above)
- CAM_AF_LED is defined as camera_set_led identifier for AF in platform_camera.h
- camera_set_led is implemented and supports trigger AF
- Put the camera in record mode, aimed at a nearby subject in an environment dark enough for the AF led to show up well
- Run the script
- Check that MD is triggering reliably when the AF blinks and note the min/max/and average values at the top of the screen. These values may be obscured by the CHDK OSD, turn the OSD off to avoid this.
- If alternative implementations of vid_get_viewport_live_fb are available (i.e. using active_viewport_buffer as the current, next or previous frame), try each one and use the one that gives the best results.
Note - statistics are cleared only on reboot.