John/CaretRevision

From Van Essen Lab

Jump to: navigation, search

Contents

Caret5 Changes Needed

Files

  • Revise Border and Foci files so that they support foci/borders for all structures, all projection types (xyz, barycentric, van-essen) and include colors.
  • Eliminate usage of Coordinate and Topology Files. Essentially replace Coordinate with Surface. Surface contains Coordinates and Topology.
  • Surface/Border/Foci/Label/Atlas need to include a structure.
  • Eliminate all files that are not CaretXML/NIFTI/GIFTI/CIFTI format. These include Minc, AFNI, Analyze, BrainVoyager, VTK, FreeSurfer, etc.
  • NIFTI should no longer "flip" volumes to LPI.
  • Spec File needs to be updated to support multiple structures.
  • Update SceneFile for multi-structure.
  • NIFTI should be in its own library.
  • GIFTI should be in its own library.
  • CIFTI should be in its own library and updated with random access, HTTP from Caret6.
  • Palette color mapping needs to be associated with each shape/metric/cifti data item instead of one applying to all.
  • GIFTI file reading needs mode that reads one column and a time and allows processing of it.
  • Eliminate reading of Caret ASCII/Binary formats.
  • Abstract XML parser so different parser libraries can be used. Use SAX.
    • (JKS) Switching over to the event-driven SAX model has the disadvantage of requiring CIFTI's XML parser to be rewritten, and I don't think it's as straight-forward or intuitive as QT's model. If we do abstract the interface, I would also like use to have a non-SAX version. I do however agree that abstracting XML parsing is a good idea.

Brain

  • Structure specific files (Surface, metric, shape, label, etc) need to be moved out of "Brain" into a new class "BrainStructure".
  • File reading needs to read structure specific files and place them in the correct brain structure (probably should be algorithm).
  • Surface coloring needs to be revised. Currently, colors are assigned to "surfaces" but need to be assigned to windows.
  • Connectivity data loaders are needed.
  • Topology Files needs to be removed from Brain since Topology is now contained in the surfaces (no longer shared).
  • Use OpenMP in place of QThread.
    • (JKS) This is probably a good idea, are there any known drawbacks to OpenMP? The lack of fine grained control over threads doesn't seem to be that much of an issue for us.
  • Surface/Border/Foci projectors need to support multiple structures.
  • Some DisplaySettings classes will need to support multiple structures.
  • Revise Surface Overlay and Volume Overlay systems for multi-structure.
  • Surface/Volume viewing system and transforms needs to be revised.

Caret Command

  • Commands need to operate on surface files and not coordinate/topology file pairs.
  • Many caret_commands could be eliminated (many of the volume operations).

Graphics

  • Eliminate "picking" and replace with either color id or ray-tracing.
    • (JKS) I am impressed by the performance improvement provided by color id based selection in Caret6, and vote that we use it in Caret5.
  • Use Caret6's surface volume outline.
  • Abstract into fixed pipeline (OpenGL 2) and programmable based (OpenGL 3/4/ES).

GUI

  • DisplayControl needs substantial revision for multi-structure.
  • Add All Structures Viewer.
  • Replace endless menus with operation dialogs.
    • (JKS) Another approach would be to have certain "modes" of operation that are oriented for certain tasks. Selecting a given "mode" would hide menu options that are irrelevant to the task at hand.
  • Add connectivity GUI and Chart (timewise activity for node).
  • Each mouse/keyboard processing mode should be its own class.
    • (JKS) We could have a drop-down box for changing "navigation" modes. I agree that this is a good idea.
  • (JKS) We should look into using qtcreator/qtdesigner for quick development of interfaces, and perhaps move away from defining interfaces directly in C++. Defining interfaces using qtdesigner and an xml layout is much more efficient for design and tweaking of interfaces, partly because interface changes wouldn't require caret to be recompiled. This could allow for greater customization of interfaces/work-flows by end-users, since they wouldn't necessarily need to know how to program to make interface changes. Below is a videos of QT designer in action (interface design goes much faster when once can interactively edit the interface):

http://www.youtube.com/watch?v=9E2KOphwZMg

Statistics

  • Split into statistical algorithms and statistical operations (will eliminate the few circular dependencies).
  • Incorporate updates from Caret6.
  • Which statistical operations are still needed?
  • Split operations into inference (T-Test, ANOVA) and significance (TFCE, Cluster).
  • GLM? (http://brainvis.wustl.edu/wiki/index.php/Caret:Documentation:StatisticsGLM)
  • Use OpenMP instead of threads for parallel processing.

Other

  • Revise image capture and movie making (no MPEG, mpeg_create, etc).
    • (JKS) Further integrating ffmpeg isn't a bad idea, although it may be easier for us to simply use it as a stand-alone program, and feed images to it, rather than integrating it completely into caret5. Part of the problem with ffmpeg is that it uses C99 and won't compile with Visual Studio, so our build setup would need to be a hybrid of gcc/msvc on Windows if we used it.
  • Use CMake for project configuration in place of qmake.
    • (JKS) As long as this doesn't cause things to break I am ok with this. What are the reasons for not using qmake?
  • Eliminate VTK, MINC, NETCDF, QWT.
  • Limit QT to GUI and XML.
    • (JKS) I think fixing the file IO, and then changing QFile to CWFile, QTextStream to CWTextStream, etc., would be a more sound, incremental approach to moving away from QT's File IO.
  • wstring in place of QString.
    • (JKS) Is this necessary? Are there issues and limitations with QString? As far as I know, our QT issues are confined to it's file IO. If we simply want to guarantee that QString doesn't break some time in the future, we could always copy the code into caret, and rename it to CWString. That would be easier than moving to a completely new library (at least for now).
  • Incorporate statistics (TFCE, etc.) from Caret6.
  • Add BrainTips.
  • Add Annotations.
  • Rethink Study Metadata, Foci Search, and Vector Files.
  • Add Generic Scenes.
  • What is a VectorFile?
  • Is SureFit still needed? If so, it should be a separate library that is optionally linkable.
  • 64-bit only.
  • Replace "Print/Debug" statements with a Logger.
  • Look into LLVM compilers.
    • (JKS) This isn't a bad idea, but my impression is that LLVM compilers aren't mature enough yet.

Coding Standards

  • Define a reasonable, brief, coding standard.

Mac

  • Make Mac version more "Mac-Like". For example, no "Close" buttons.

Caret7 = ((Caret5 + Caret6) / 2.0) Potential Hybrid Strategy

  • Use Caret6 parts that support file I/O, data management (multi-structure), and Model (of MVC).
    • (JKS) We should probably keep the CIFTI reader/writer.
  • Use most of common, niftilib, ciftilib, giftilb, files brain, and statistics from Caret6.
  • Use most algorithms from Caret5 and a few from Caret6
  • Use some files from Caret5.
  • GUI is mix of Caret5 and Caret6.

Caret7 GUI Design Modifications

  • When capturing images, specify only an extension in the file name or dropdown menu (do not have to do both)
  • Initialize surfaces in lateral view, not dorsal view
Personal tools
Sums Database