We read some temporal data and in the visualization pipeline, we choose an array and we want to setup a lookup table with the union of all the data ranges over time (i.e. from the absolute min over time to absolute max).
For now each timestep is read successively and ranges are aggregate to get the union.
In the specific case where the reader knows about this data range over time, we would like to avoid this loop over timesteps to save a lot of time and resources.
Proposal
Using an InformationKey to store this information and reuse it later in the pipeline.
Details
We could add a new vtkInformationInformationVectorKey inside vtkDataObject. We can create different container for different Attributes and Arrays, but finally a vtkInformationDoubleVectorKey can contain the DataRangeOverTime for a given array.
Then a Reader can set those key during the RequestInformation pass.
Does it seem to be the right way to go ? Any drawback or alternative to this method ?
Well, this information key should describe all there the metadata of the arrays, name, type, data range and data range over time for this to make sense.
I am not sure this should be a VTK pipeline thing. For one, apply any filter and this meta-data will almost always become incomplete. For example, apply a complex filter like streamtracer. It generates many new arrays that it cannot provide any temporal range information for. Apply simple filter like Calculator, and it too cannot provide temporal range for the newly added array. Thus extended data model to support this use-case doesn’t seem reasonable to me.
Maybe it’s a reader API. Readers can provide this meta-data in a special information object or something and applications can look for it and use it as needed. Note, even then, this gets complicated. In ParaView, say I have temporal dataset, I contour it and then color by the contour scalar. When I reset to temporal range, I am resetting to temporal range of the contour not the original dataset. So unless explicitly resetting to temporal range for data directly produced by the reader, relying on such metadata is tricky.
I agree that adding this to data model was not a very satisfying proposition. I will investigate on the reader API side and see what can be done here (final purpose is in ParaView).
Agreed too, but I feel this still may be a good improvement.