SimpleITK: Difference between revisions
From KitwarePublic
Jump to navigationJump to search
(→TCons) |
(→TCons) |
||
| Line 110: | Line 110: | ||
* [[ITK_Release_4/SimpleITK/Tcon 2010 08 13|8/13/2010]] | * [[ITK_Release_4/SimpleITK/Tcon 2010 08 13|8/13/2010]] | ||
* [[ITK_Release_4/SimpleITK/Tcon 2010 08 17|8/17/2010]] | |||
Revision as of 19:28, 1 September 2010
Simple ITK
Goals
- Provide an easy-access layer to ITK for non-C++ expert developers
Advisory Review Board (ARB)
- The Advisory Review Board is composed of groups and individual who are potential users of the Simple ITK Layer.
- They provide advice to ITK developers of the simple layer regarding the design and implementation of the SimpleITK API.
Examples of Other Librarires
Sandbox
- Dan's: http://github.com/dblezek/SimpleITK (This is currently the "unofficial" SimpleITK repository)
- Gabe's: http://github.com/gabehart/SimpleITK (Experiments with multi-image filters, e.g. AddImage)
- Brad's: http://github.com/blowekamp/SimpleITK (Meta-programming experiment)
Scope
Current open questions
- Internal execution mechanism
- switch statement, supported by macros
- Factory mechanism, new image types could be added at runtime
- Meta-programming
- Datatypes
- What to support "out of the box"?
- How easy/difficult to add new datatypes to a build?
- Compile times
- Templates radically extend CPU and memory requirements
- Library size / scope
- Custom SWIG files vs. automatically generated SWIG
- Automation for SimpleITK facade generation from ITK classes?
Suggested Areas to Cover
- IO
- Basic Filters
- Registration
- Basic Framework
- Deformable registration
- BSplines
- Demons
- Segmentation
- Region Growing
- Level Sets
- Classifiers
- Meshes ? (Not Yet)
Types
- Image pixel types supported
- int8_t
- int16_t
- int32_t
- float
- Image dimensions supported
- 3D
- Is 2D managed as a 3D image of 1 slice ?
- Performance penalty for neighborhood filters... ?
- Could be "2D" versions of 3D filters, i.e. RecursiveGaussianFilter2D. This would work on a slice-by-slice basis.
Languages
Wrapped languages will be any that SWIG supports, if someone is willing to write tests / any needed glue code.
- C++ Layer
- Python
- Lua
- Java
- ?
Implementation Details
- Coding Style
- Copyright Headers & License
- Const correctness (can we avoid using const's completely?)
- Testing
- C++ testing (Google Test?)
- Python tests (PyUnit?)
- Lua tests (?!?)
- Java tests (JUnit)
- ? other languages ?
- Managing basic types
- Arrays
- Regions
- Transforms
- Not so basic types (could these be enums passed as ivars?)
- Interpolators
- Optimizers
- Metrics
Plan
- Image classes
- IO
TCons
Tcon topics 8/17/2010
- Next ITKv4 Meeting - Potentially October 4-6
- Additional Conference Calls held last week
- SimpleITK
- Microscopy
- Summary: What changes to the ITK fundamentals required for large image sizes. There may be issues for video processing as well
- How to deal with time as a dimension
- Memory management (Streaming)
- Possible changes to the image structure - Luis will make proposal to handle these issues and present to the group
- Video processing may require a ring buffer structure
- Iterators may need to be updated to avoid access to the buffer pointer
- Possibility of using image adapters
- Multi-resolution Images
- Possibility of support for this at the level of the image reader (JPEG2000: support for 2D images in files)
- Query image reader for different resolution images
- Non-regular image spacing
- Potential different time point for top and bottom of image
- VTK Rectilinear grid handles this
- What filters are required to handle non-uniform spacing. Can convolution be applied and then resample to regular spacing
- Does this cause a data explosion
- File formats
- Desire for more file format support: probably would benefit from just 2-3 formats
- 64 bit TIFF reader, Vendor specific private tags
- Update to libTiff is required
- Streaming support exists for Meta, VTK, MRC. ImageSeriesReader will stream slice-by-slice
- Summary: What changes to the ITK fundamentals required for large image sizes. There may be issues for video processing as well
- WrapITK
- Sequestered reference applications
- Clean-up Releases
- Currently running behind
- Limited coverage for Windows machines on the Dashboard - Need to turn on BUILD_EXAMPLES for these machines
- Need to updated OpenJPEG (version 2) and libTiff
- DICOM
- Design for QR of PACS without writing to disk
- Currently requires to locally save a copy of the file(s) before reading as an ITK image
- How do you know what you are going to get (e.g. multi-planar scout images)
- Create a database or data structure to present to the programmer and then create an image from the bulk data
- What API is required to support this functionality
- Data structure to hold information (DOM specification - Larry Tarbox from XIP - Stephen Alyward)
- Potential to pass Metadata Dictionary
- Design for QR of PACS without writing to disk
Tcon topics 8/26/2010
- Gerrit
- What sort of work flow should we follow?
- How do we get this set up correctly with git and github?
- Interoperability with ITK
- Are we all agreed that this is a top priority?
- Flexibility w.r.t. dimensions
- Are we all agreed that no more than 2D and 3D is needed?
- Flexibility w.r.t. types
- Fixed set of types? (Just a thought)
- Everything cast to doubles? (Again, just a thought)
- Typing system
- PixelTypeID
- Instantiation
- Runtime choosing of methods
- Macros
- Not pretty
- Fairly intuitive
- Meta-Programming
- Hard to understand completely
- Adds ability for each filter to specify what types it works for
- Dynamic casting
- Should there be convenience methods to do this?
- Should the user have to do it themselves?
- User seeing templates
- Are we all agreed that the user should never see templates?
- image creation without templates?
- Documentation
- Doxygen
- Tutorial?
