GSoC: Difference between revisions
(Added the auto* idea - Bill might want to check over it.) |
(Added in a few more ideas.) |
||
Line 101: | Line 101: | ||
'''Mentor:''' Berk Geveci (berk.geveci at kitware dot com). | '''Mentor:''' Berk Geveci (berk.geveci at kitware dot com). | ||
=== Project: New 2D Charts === | |||
'''Brief explanation:''' Implementation and augmentation of features in the existing 2D charts. Also exposure of these charts in the ParaView user interface. Additional features could also be added to existing charts such as error bars, mapping of more properties, enhanced interactivity features and/or performance improvements. | |||
'''Expected results:''' New chart types, improved interactivity with existing chart types and additional exposure in the ParaView GUI. | |||
'''Mentor:''' Marcus Hanwelll (marcus dot hanwell at kitware dot com). | |||
=== Project: Implementing Qt Backend for 2D API === | |||
'''Brief explanation:''' Recent work in CVS head of VTK has added a new, abstracted 2D API. It currently only has one backend (OpenGL), with a very early proof of concept using Qt. The project would involve adding a Qt backend, implementing support classes to allow both interactive and non-interactive rendering (printing, SVG, etc). This would ideally lead to the possibility of producing publication quality charts using an SVG (or similar) output backend on top of Qt's abstraction of the rendering context. | |||
'''Expected results:''' A new backend that leverages Qt's multiple backends, focused on producing high quality output using SVG. Ideally a second interactive backend that does not require OpenGL, along with additional tests and documentation of the new feature. | |||
'''Mentor:''' Marcus Hanwelll (marcus dot hanwell at kitware dot com). | |||
== ParaView == | == ParaView == |
Revision as of 18:59, 10 March 2010
Project ideas for the Google Summer of Code 2010
Guidelines
Students
These ideas were contributed by developers and users of Kitware's open source projects, including CMake, CDash, VTK and ParaView. If you wish to submit a proposal based on these ideas you may wish to contact the developers to find out more about the idea you are looking at, get to know the developers your proposal will be reviewed by and receive feedback on your ideas.
The Google Summer of Code program is competitive, and accepted students will usually have thoroughly researched the technologies of their proposed project, been in frequent contact with potential mentors and possibly have submitted a patch or two to fix bugs in the project they intend to work. Kitware makes extensive use of mailing lists, and this would be your best point of initial contact for any of the proposed projects you would like to apply to. The mailing lists can be found on the project pages linked to in the preceding paragraph.
Adding Ideas
When adding a new idea to this page, please try to include the following information:
- A brief explanation of the idea.
- Expected results/feature additions.
- Any prerequisites for working on the project.
- Links to any further information, discussions, bug reports etc.
- Any special mailing lists if not the standard mailing list for the project.
- Your name and email address for contact (if willing to mentor, or nominated mentor).
If you are not a developer for the project concerned, please contact a developer about the idea before adding it here.
CMake
Project page, mailing lists, dashboard.
Project: CMake Autoconf Compatibility
Brief explanation: One of the things that prevents some projects from migrating to CMake is their current investment and shared knowledge of the auto* family of tools. Creating improved compatibility functions matching the familiar auto* syntax for things like header checks, command line switches to cmake etc would improve this situation significantly. The student would need to assess syntax that should be replicated in both the CMake language, and common command line switches such as --prefix=... Some modules already exist that implement some of this functionality, and these could be used as a starting point.
Expected results: Improved implementation of auto* like syntax to aid projects when migrating their build systems over to CMake. Additional documentation on the migration process, and working with existing communities that have needs in this area.
Mentor: Any takers?
Project: CMake Project Generator
Brief explanation: The addition of a facility in CMake to automatically generate CMakeLists files based upon the source files present in a directory. So a developer can point CMake at a directory full of source files with a '--generate-project' argument for example, and automatically generate a project. This should detect if source files contain the QOBJECT macro, and need Qt's moc running on them, adding them to the appropriate CMake variable. This would be limited in scope to relatively simple projects wanting a single executable to be built from the source files, with some heuristics or switches to determine what toolkit etc it being used.
Expected results: A new facility added to the CMake suite of tools to generate simple CMakeLists files when supplied the path to a source directory. The user should reasonably expect to be able to run generate CMakeLists files, run CMake on these files and type make to build their project. Similar in functionality to the feature provided by qmake.
Prerequisites: Some familiarity with CMake, C++ and Qt.
Mentor: Marcus Hanwell (marcus dot hanwell at kitware dot com).
CDash
Project page, mailing lists, dashboard.
Project: CDash Bug tracker integration
Brief explanation: A disconnect between CDash and bug trackers currently exists. Developers often want to link a current bug fix with a dashboard submission and, in order to achieve this feature, they currently enter the bug number in the commit log message. Moreover, new failures appearing on the dashboard should be ultimately entered and tracked in a bug tracker either manually or automatically. The goal of this project is to tie CDash and bug trackers to allow developers to link a current submission with a bug and track its evolution. Also, a continuous report should be generated to show the different builds leading to a bug fix (or bug report).
Expected results: Support for integration of bug trackers within CDash. Mantis (www.mantisbt.org) will be the primary bug tracker target but the framework should be flexible to support any other bug trackers (via Web API or other mechanism to be defined).
Prerequisites: Some familiarity with CDash. Familiar with PHP/MySQL/PgSQL.
Mentor: Julien Jomier.
VTK
Project page, mailing lists, dashboard.
Project: Volume Rendering in O3D/WebGL
Brief explanation: Write an initial implementation of ray-cast volume rendering functionality in O3D and/or WebGL. This should allow web developers to use this library to perform volume rendering in the browser. The student should explore each technology and work on shader programs which emulate behavior implemented in the C++ VTKEdge library.
Expected results: A Javascript library that takes a 3D image data as input and produces interactive volume rendering in the browser. The student should evaluate performance and accuracy of implementations O3D and/or WebGL compared to the existing C++ implementation.
Prerequisites: Familiarity with OpenGL and Javascript, some experience with CMake and C++ preferred.
Mentor: Jeff Baumes (jeff.baumes at kitware dot com).
Project: Protovis in C++
Brief explanation: Protovis is a Javascript library that uses SVG to do information visualization in the browser. Its compact, expressive language allows developers to build complex visualizations. We would like the similar capabilities in the C++ VTK library for use in C++ applications that would scale to larger data. This effort has started in January 2010, but there are still many capabilities not offered in the C++ API. The accepted student would work to replicate several complex Protovis examples in C++, and implement new features in VTK that are missing to allow those examples to work in C++.
Expected results: The student should provide C++ examples using VTK that emulate behavior in corresponding Protovis examples, and patches to VTK that allow the new features these examples require. Depending on the interest of mentor and student, this may involve animation support, advanced interaction techniques, new mark types, performance enhancements, or other features.
Prerequisites: Some experience with CMake and C++. Javascript experience preferred but not necessary.
Mentor: Jeff Baumes (jeff.baumes at kitware dot com).
Project: Implement Select Algorithms from IEEE VisWeek 2009 in VTK
Brief explanation: VisWeek is the premier forum for visualization advances in science and engineering for academia, government, and industry. This event brings together researchers and practitioners with a shared interest in techniques, tools, and technology. During the conference, researchers present papers on advances in scientific visualization and informatics. Many of these algorithms introduce new algorithms but not necessarily release the implementations in a form usable by the larger community. Since VTK has become the ubiquitous open-source toolkit for visualization, implementing these algorithms in the VTK framework would make them available to a large group of users. The accepted student would work to implement several select algorithms from VisWeek 2009 in C++ as new VTK algorithms.
Expected results: Implementation of several leading algorithms from VisWeek 2009 in VTK. The student should also implement examples and tests that will run as part of VTK's testing system (using CMake/CTest).
Prerequisites: Experience in visualization algorithms and/or GPU programming. Experience in C++. Some experience with VTK is preferred but not necessary.
Mentor: Berk Geveci (berk.geveci at kitware dot com).
Project: AMR Volume Rendering in VTK
Brief explanation: Adaptive Mesh Refinement (AMR) has become popular in the numerical solution of shock physics, plasma physics and astrophysics problems. AMR uses a set of overlapping rectilinear grids to discretize the domain of problems that involve feature of largely varying scales. For example, in astrophysics the problem domain include whole galaxies but the mesh has to resolve individual stars. VTK has introduced native support for AMR meshes a few years ago and most of VTK's algorithms work well with this mesh type. One important algorithm that is missing and that is widely used by the AMR community is volume rendering. The accepted student will work to implement AMR volume rendering in VTK using existing building blocks include software and GPU-based volume rendering algorithms for rectilinear grids.
Expected results: Implementation of AMR volume rendering in VTK. The student should also implement examples and tests that will run as part of VTK's testing system (using CMake/CTest).
Prerequisites: Some experience in volume rendering and/or VTK is preferred but not necessary. Experience in C++.
Mentor: Berk Geveci (berk.geveci at kitware dot com).
Project: New 2D Charts
Brief explanation: Implementation and augmentation of features in the existing 2D charts. Also exposure of these charts in the ParaView user interface. Additional features could also be added to existing charts such as error bars, mapping of more properties, enhanced interactivity features and/or performance improvements.
Expected results: New chart types, improved interactivity with existing chart types and additional exposure in the ParaView GUI.
Mentor: Marcus Hanwelll (marcus dot hanwell at kitware dot com).
Project: Implementing Qt Backend for 2D API
Brief explanation: Recent work in CVS head of VTK has added a new, abstracted 2D API. It currently only has one backend (OpenGL), with a very early proof of concept using Qt. The project would involve adding a Qt backend, implementing support classes to allow both interactive and non-interactive rendering (printing, SVG, etc). This would ideally lead to the possibility of producing publication quality charts using an SVG (or similar) output backend on top of Qt's abstraction of the rendering context.
Expected results: A new backend that leverages Qt's multiple backends, focused on producing high quality output using SVG. Ideally a second interactive backend that does not require OpenGL, along with additional tests and documentation of the new feature.
Mentor: Marcus Hanwelll (marcus dot hanwell at kitware dot com).
ParaView
Project page, mailing lists, dashboard.
Project: iPhone/iPod/iPad/Droid Support for ParaView Web
Brief explanation: We have been working on developing a Web visualization framework based on ParaView. This framework has two major components: a) a Javascript API and b) Flash-based interactive 3D visualization "applet". The Flash-based applet was designed to provide interactive frame rates by keeping a persistent connection (over http) for each user session. Unfortunately, due to lack of Flash support, this applet cannot function on the widely popular iPhone/iPod Touch and the upcoming iPad. Furthermore, the Flash applet was designed for desktop use and we are not sure how well it will work on a Droid device. The accepted student will extend the ParaView Web framework to support iPod/iPhone/iPad and/or Droid.
Expected results: Interactive ParaView Web visualization applet/library for iPod/iPhone/iPad and/or Droid. Example application(s) and regression tests. Note that this applet/library does not have to be a Web applet. It is OK to provide a library for stand-alone application development as long as the communication can happen over http.
Prerequisites: Experience in iPod/iPhone development and/or experience in Droid development.
Mentor: Utkarsh Ayachit (utkarsh dot ayachit at kitware.com)
CTK / VTK / Slicer
Project page, [ctk-developers@commontk.org mailing list]
Project: DICOM browser Qt Widget
Brief explanation: The goal is to develop an easy to use Qt widget/plugin that can be dropped into a Qt UI using Qt's designer. The widget will bring up a modal window, allowing the user to traverse to any directory, support for paring the directory tree. A hierarchy pane provide a tree view of Studies -> Series -> Images in the directory. A preview pane would show an image preview of the selected image or a textual preview of a selected Structured Report. An info pane would show the public DICOM tags of the selected image or series. This widget is the equivalent of the file browser widget for medical IO. This will enable the application developer to easily identify and load a DICOM series. The project will utilize several open source libraries namely : DCMTK for DICOM IO, Qt, Common Toolkit and Visualization Toolkit. The final source code would be provided as a part of the Common Toolkit under a BSD license. (Integration with non-local file systems and SQL caching of the hierarchy would be an added plus).
Expected results: Easy plug and play DICOM browsing and IO support using Qt designer.
Prerequisites: Familiarity with DICOM and Qt.
Mentor: Any takers ?.