ITK/Examples/Goals: Difference between revisions
From KitwarePublic
Jump to navigationJump to search
Daviddoria (talk | contribs) (Created page with "* 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...") |
Daviddoria (talk | contribs) No edit summary |
||
| Line 10: | Line 10: | ||
* 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. | * 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. | * 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. | ||
Revision as of 18:18, 18 December 2011
- 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 gitorious 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. The c++ and CMakeLists.txt files are currently copy/paste-able, but it would be better to provide a button that would download both files together as a zip or something like that. Users have complained that manually copy/pasting is awkward.
- 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.
- 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.
