ParaQ v1.0 Features: Difference between revisions
From ParaQ Wiki
Jump to navigationJump to search
| Line 22: | Line 22: | ||
| 1 | | 1 | ||
| Grouping of pipeline elements. I would like to be able to 'group' filters together, and treat them as a single entity. A known use of this would be in creating 'parts', which would be groups of cells from the input data set. A user might want to create other logical gropus that are not represented in the data, and controls these things together. Also, other operations make sense on grouped items. If I want to look at a dataset and see the cell edges at the same time I see the cells, I'll connect dataset->ExtractEdges. Now, if I want to clip both of those things, I want to create a 'group' for both filters, then operate on that group. I should be able to do this with a single cut plane widget. Certainly, the user could clip the dataset, and then the ExtrctEdges would naturally be clipped as well, but the 'logical' step is to slice through 'all the stuff at once', and I believe that the group might make more sense than the 'slice the input and the rest will follow' approach. | | Grouping of pipeline elements. I would like to be able to 'group' filters together, and treat them as a single entity. A known use of this would be in creating 'parts', which would be groups of cells from the input data set. A user might want to create other logical gropus that are not represented in the data, and controls these things together. Also, other operations make sense on grouped items. If I want to look at a dataset and see the cell edges at the same time I see the cells, I'll connect dataset->ExtractEdges. Now, if I want to clip both of those things, I want to create a 'group' for both filters, then operate on that group. I should be able to do this with a single cut plane widget. Certainly, the user could clip the dataset, and then the ExtrctEdges would naturally be clipped as well, but the 'logical' step is to slice through 'all the stuff at once', and I believe that the group might make more sense than the 'slice the input and the rest will follow' approach. | ||
|- | |||
|- | |||
| 004 | |||
| 1 | |||
| Filter On/Off switch. As we expand the capabilities of compound filters, we will need the ability to turn filters on and off, while still having them connected in a graph. A filter that is 'on' performs its normal function. A filter that is 'off' passes its data through (the filter may have to perform some default transformation) The reason for this is that PQ must support a compound filter that encapsulates these filters: InputData->Clip->Threshold->Glyph. In the object inspector for this compound filter, the designer (of the compound filter) may want to give the user the ability to (Clip AND Threshold), Clip, or Threshold. PQ should not be responsible for unhooking and re-hooking the pipelines - the simple solution is to turn off the appropriate filters without re-arranging the pipeline. | |||
|- | |- | ||
|} | |} | ||
Revision as of 17:11, 26 January 2006
List of features we'll need in future versions (no matter how outlandish they seem ... we can prioritize anything :) ) - things that occur to you as you're testing, coding, or using ParaQ.
Features
| ID | Prority | Description |
|---|---|---|
| 001 | 1 | View/Application snapshot. This should include useful tags in image formats that support them. |
| 002 | 1 | Applicatin/User settings hierarchy, including entries for 1) last data file directory, 2) last place images were saved |
| 003 | 1 | Grouping of pipeline elements. I would like to be able to 'group' filters together, and treat them as a single entity. A known use of this would be in creating 'parts', which would be groups of cells from the input data set. A user might want to create other logical gropus that are not represented in the data, and controls these things together. Also, other operations make sense on grouped items. If I want to look at a dataset and see the cell edges at the same time I see the cells, I'll connect dataset->ExtractEdges. Now, if I want to clip both of those things, I want to create a 'group' for both filters, then operate on that group. I should be able to do this with a single cut plane widget. Certainly, the user could clip the dataset, and then the ExtrctEdges would naturally be clipped as well, but the 'logical' step is to slice through 'all the stuff at once', and I believe that the group might make more sense than the 'slice the input and the rest will follow' approach. |
| 004 | 1 | Filter On/Off switch. As we expand the capabilities of compound filters, we will need the ability to turn filters on and off, while still having them connected in a graph. A filter that is 'on' performs its normal function. A filter that is 'off' passes its data through (the filter may have to perform some default transformation) The reason for this is that PQ must support a compound filter that encapsulates these filters: InputData->Clip->Threshold->Glyph. In the object inspector for this compound filter, the designer (of the compound filter) may want to give the user the ability to (Clip AND Threshold), Clip, or Threshold. PQ should not be responsible for unhooking and re-hooking the pipelines - the simple solution is to turn off the appropriate filters without re-arranging the pipeline. |
Requirements
| ID | Prority | Description |
|---|---|---|
| 001 | 1 | ParaQ should be able to automatically generate a complete object inspector UI for each filter. Currently, the inspector generated for the Clip filter is insufficient - there is no UI to control the implicit function object it needs to work. The Glyph filter is another one like this - it needs an input glyph object. |
