Address plugin viewer mapping problem

[mairin]

(This is something we should take a look at around the end of summer based on where we are right now.)

Plugin Viewer Mapping

One of the challenges we have to address with ChRIS is the "impedence mismatch" issue, where the output from one plugin needs to map to / be compatible with the input needed for the next plugin in a pipeline. A related "impedence mismatch" issue we're running into with the UI implementation is understanding what type of viewer is most appropriate for which pieces of output each plugin is producing.

Currently, a hardcoded mapping in the UI code determines which viewers are loaded into the output window for which plugins. This should really be abstracted out so it doesn't rely on hard coding, so we need to figure out the best place for this mapping to be stored. Over time, the name and location of specific output files may change as the plugin authors release new versions. Because of this likely possibility, the backend should probably dictate the desired display per plugin to the UI.

Viewer preference / ordering

Here is an idea of how the viewer preference could work:

• The default viewer for any output produced by a plugin can be the file explorer.

• We can also load additional viewers based on the file extensions present in the output (e.g., if there are PNGs, a 2D bitmap viewer could be loaded.) This is a reasonable default, but here are two examples where simply basing the viewer on the file extension won't work:

  • Some 3D views involve series of PNG input files and we don't have a programmatic way to tell 3D is the preferred mode for those PNGs.

  • Some files that have the same file extension need different viewers. For example, the MPC plugin has a few .stat files, but only 1 or 2 of the total number of .stat files should be displayed in the custom viewer that renders a table with color dots based on z-scores.

• Plugins could optionally set rules for desired plugin per file type / file. This would be important for cases such as the MPC plugin which has custom viewers that require specific files to be loaded into specific tabs.

• ChRIS pipeline creators can override the default viewers dictated by the plugins by configuring their own desired viewers per file type / file.

• ChRIS front end users could override default viewers dictated by either a pipeline they are using or individual plugins they are using by configuring their own desired viewers per file type / file.

• If a front end user dictates a viewer, that overrides what the pipeline dictated, which overrides what the plugin dictated, which overrides any defaults.

Viewer Preference Formatting

Here is an example of the format the backend could supply this information in to the frontend:

{
displayType: zScore...,
label: "zScore Data Viewer"
source_file: [array of files]
}

Input / Output Filters

There can be over 800 files in an output directory, and not all of them will necessarily be meaningful to the UI. If we do end up implementing the concept of output and input filters on plugin output and input, this could help whittle down the number of files the UI has to process, and make the UI easier to use as the filter would hopefully limit the files displayed to end users to those that are the most relevant.

Types of Viewers

There will be some basic types of viewers, and some custom viewers that have more specific requirements.

Examples of basic viewers:

• Rev-like embedded viewer in ChRIS to view DICOM / nifty / related types of files
• 2D image viewer with jpg / png support & gallery navigation
• File explorer

Custom viewers:

• Graph views for MPC plugin
• Z-score tabular views for MPC plugin

While the basic viewers' inputs are relatively straightforward, some other viewers (eg the example custom viewers) may have complexity in the types of input data they are looking for and may have specific configuration options to edit. (For example, perhaps a Z-score tabular view could allow the user to specify the colors for different bands of Z-score differences or even to indicate the bands.)

Determining what viewers are available

We might need some kind of mechanism whether it's a directory in the ChRIS store or some kind of inventory a specific version of the ChRIS front end can return in response to a query, but plugin authors might not necessarily get involved in viewer development and may just want to know what viewers are available / loaded into in the specific version of ChRIS they are developing for, and its specifications (what formats can it open, etc.)