Wikia

CHDK Wiki

Changes: Testing

Edit

Back to page

(multiple raw buffers note)
(remove trac links)
 
(12 intermediate revisions by 2 users not shown)
Line 16: Line 16:
 
=Testing overrides=
 
=Testing overrides=
 
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.
 
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.
  +
  +
You should also verify that overrides are applied correctly when you press the shutter quickly without waiting for auto-focus.
   
 
=Testing RAW/DNG=
 
=Testing RAW/DNG=
Line 21: Line 23:
   
 
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 series of shots and verify that each DNG contains the correct image data, to ensure raw buffers are all identified correctly.
  +
  +
Verify that a DNG is saved when you press the shutter quickly without waiting for auto-focus.
  +
  +
==File counter==
  +
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.
  +
  +
==File folders==
  +
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.
  +
  +
=Free RAM=
  +
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 - enabling and loading CHDK into extended memory.|EXMEM]] to gain additional memory.
  +
  +
=Viewport buffers=
  +
To verify that the "viewport" is identified correctly, you can use the zebra, edge overlay and PTP live view functions
  +
  +
==Zebra test==
  +
* 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.
  +
  +
=USB Remote=
  +
See [[USB Remote]] for details of this feature. A basic functionality test can be done using the standard USB cable and a PC:
  +
* Start the camera without USB connected
  +
* In CHDK Settings->Remote parameters set
  +
** Enable remote
  +
** Switch Type: One push
  +
** Control mode: Normal
  +
* Switch the camera to shooting mode, and select a still capture mode such as P
  +
* Plug in the USB cable. The camera should act as if the shutter was pressed half way
  +
* Unplug the USB cable. The camera should shoot.
  +
* Enable remote sync
  +
* Plug in the USB cable. The screen should go dark, and a status LED may blink.
  +
* Unplug the USB cable. The camera should shoot.
  +
  +
Don't forget to disable the remote if you want to use regular USB file transfer or CHDK PTP.
   
 
=Testing with scripts=
 
=Testing with scripts=
There are some scripts which exercise various CHDK capabilities
+
There are some scripts which exercise various CHDK capabilities.
  +
  +
The scripts listed below are included with a "full" CHDK install, usually in the CHDK/SCRIPTS/TEST directory.
  +
  +
==mftest.lua==
  +
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.
   
 
==llibtst.lua==
 
==llibtst.lua==
 
Tests the lua standard libraries. This also exercises many C library functions.
 
Tests the lua standard libraries. This also exercises many C library functions.
   
* Download: [http://tools.assembla.com/chdk/browser/trunk/CHDK/SCRIPTS/TEST/llibtst.lua] (also included in "full" install)
 
 
* Documentation: [[Lua#Lua_library_test]]
 
* Documentation: [[Lua#Lua_library_test]]
   
Line 37: Line 73:
   
 
==setmode.lua==
 
==setmode.lua==
Tests the capture mode switching functions and mode map.
+
Tests the capture mode switching functions and mode map. This script is included with a "full" CHDK install.
   
*Download: [http://tools.assembla.com/chdk/browser/trunk/CHDK/SCRIPTS/TEST/setmode.lua] (also included in "full" install)
 
 
*Documentation: [[Lua/Scripts:Standard/Test/Setmode]]
 
*Documentation: [[Lua/Scripts:Standard/Test/Setmode]]
   
 
===Test procedure===
 
===Test procedure===
 
* start the camera in play mode
 
* start the camera in play mode
* run the script with all options set to zero
+
* run the script with all options except "mode change delay" set to zero
 
* the camera should switch to record, and switch rapidly between each known shooting mode
 
* the camera should switch to record, and switch rapidly between each known shooting mode
 
* If everything was OK, it will print pass
 
* If everything was OK, it will print pass
 
* If something failed, examine A/setmode.log
 
* If something failed, examine A/setmode.log
  +
 
==ubtest.bas==
 
==ubtest.bas==
 
General purpose ubasic test.
 
General purpose ubasic test.
   
*Download: [http://tools.assembla.com/chdk/browser/trunk/CHDK/SCRIPTS/TEST/ubtest.bas ubtest.bas] (also included in "full" install)
 
 
*Documentation: http://chdk.setepontos.com/index.php?topic=6592.0
 
*Documentation: http://chdk.setepontos.com/index.php?topic=6592.0
   
Line 69: Line 104:
 
* If no failures were identified, prints "ok", otherwise failed.
 
* 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.
 
* 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.
  +
  +
==MD_tune.bas==
  +
Tests the reaction speed of motion detection. This can be used find the optimal implementation of vid_get_viewport_live_fb()
  +
  +
*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)
  +
===Prerequisites===
  +
* 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
  +
  +
===Test procedure===
  +
* 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.
 
[[Category:Development]]
 
[[Category:Development]]

Latest revision as of 22:47, November 30, 2014

IntroductionEdit

This page collects resources and techniques for testing a CHDK build or port. See also Debugging

this is a work in progress, please expand!


General guidelinesEdit

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.


Testing overridesEdit

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.

You should also verify that overrides are applied correctly when you press the shutter quickly without waiting for auto-focus.

Testing RAW/DNGEdit

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.

Verify that a DNG is saved when you press the shutter quickly without waiting for auto-focus.

File counterEdit

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.

File foldersEdit

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.

Free RAMEdit

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.

Viewport buffersEdit

To verify that the "viewport" is identified correctly, you can use the zebra, edge overlay and PTP live view functions

Zebra testEdit

  • 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.

USB RemoteEdit

See USB Remote for details of this feature. A basic functionality test can be done using the standard USB cable and a PC:

  • Start the camera without USB connected
  • In CHDK Settings->Remote parameters set
    • Enable remote
    • Switch Type: One push
    • Control mode: Normal
  • Switch the camera to shooting mode, and select a still capture mode such as P
  • Plug in the USB cable. The camera should act as if the shutter was pressed half way
  • Unplug the USB cable. The camera should shoot.
  • Enable remote sync
  • Plug in the USB cable. The screen should go dark, and a status LED may blink.
  • Unplug the USB cable. The camera should shoot.

Don't forget to disable the remote if you want to use regular USB file transfer or CHDK PTP.

Testing with scriptsEdit

There are some scripts which exercise various CHDK capabilities.

The scripts listed below are included with a "full" CHDK install, usually in the CHDK/SCRIPTS/TEST directory.

mftest.luaEdit

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 portsEdit

  • 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.

llibtst.luaEdit

Tests the lua standard libraries. This also exercises many C library functions.

Test procedureEdit

  • 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

setmode.luaEdit

Tests the capture mode switching functions and mode map. This script is included with a "full" CHDK install.

Test procedureEdit

  • start the camera in play mode
  • run the script with all options except "mode change delay" 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

ubtest.basEdit

General purpose ubasic test.

Test procedureEdit

  • 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.

MD_tune.basEdit

Tests the reaction speed of motion detection. This can be used find the optimal implementation of vid_get_viewport_live_fb()

PrerequisitesEdit

  • 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

Test procedureEdit

  • 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.

Around Wikia's network

Random Wiki