ITK/Examples/Goals: Difference between revisions
From KitwarePublic
Jump to navigationJump to search
No edit summary |
No edit summary |
||
| Line 3: | Line 3: | ||
* Efficient "power user" access. It is very tedious to make changes to hundreds of wiki pages. The wiki should therefore have an alternative access method where users can operate directly on files and then "push" the changes to the wiki. | * Efficient "power user" access. It is very tedious to make changes to hundreds of wiki pages. The wiki should therefore have an alternative access method where users can operate directly on files and then "push" the changes to the wiki. | ||
* Revision control/backup - the wiki itself provides a means of revision control, but additionally the wiki should be backed by a repository in a separate location. Currently the wiki is scraped nightly and pushed to a | * Revision control/backup - the wiki itself provides a means of revision control, but additionally the wiki should be backed by a repository in a separate location. Currently the wiki is scraped nightly and pushed to a [https://github.com/InsightSoftwareConsortium/ITKWikiExamples github repository]. | ||
* Testing/dashboard - to prevent the examples from getting too messy, a dashboard should be run at least daily to indicate at least the compilabilty of the examples. | * Testing/dashboard - to prevent the examples from getting too messy, a dashboard should be run at least daily to indicate at least the compilabilty of the examples. | ||
Latest revision as of 15:07, 26 July 2013
- Low barrier of entry - even the most casual user should be able to create or edit an example. No git experience should be required.
- Efficient "power user" access. It is very tedious to make changes to hundreds of wiki pages. The wiki should therefore have an alternative access method where users can operate directly on files and then "push" the changes to the wiki.
- Revision control/backup - the wiki itself provides a means of revision control, but additionally the wiki should be backed by a repository in a separate location. Currently the wiki is scraped nightly and pushed to a github repository.
- Testing/dashboard - to prevent the examples from getting too messy, a dashboard should be run at least daily to indicate at least the compilabilty of the examples.
- Easy to try - all examples must be accompanied by a CMakeLists.txt file. Tarballs exist for each example. The tarball contains the c++ code and CMakeLists.txt file.
- Self contained - examples should be fully self contained if at all possible. If it is possible to demonstrate a concept by programmatically generating an image, this should be preferred over using a provided Data/ style image. Additionally, examples should allow users to specify an input image if they wish to see the results on their own data.
- ND - most current examples have image dimension <2> hard coded. We should decide on a tradeoff between complexity of the c++ (don't want to overwhelm non-template-programmers) while still allowing examples to be easily extended to ND.
- Uniformity - Examples that do "image to image" filtering should provide a standard interface so users do not have to think when attempting to provide their own data to many examples.
- Searchable - the examples should allow you to easily find what you are looking for. Effective search box. Easy to use tagging system that results in a category list.
- Image processing concept -> ITK concept mapping - A user should not be required to already be familiar with ITK terminology to find out how to do something in ITK. Glossary.
