Page MenuHomePhabricator

Enhance TemporoSpatialStringProperty to represent and store information more compact
Closed, ResolvedPublic

Description

Currently the TemporoSpatialStringProperty always generates a large "matrix" (by slice and timpoint) to represent all values. This is even the case if the value is the same for all slices (and timepoints).

It would be great to offer the possibility to store/load TemporoSpatialStringProperties in such a way that the can express that all values in a timepoint are the same or that all timepoints have the same values. Aim is to achive a serialized representation (e.g. in a NRRD file) that is as compact as possible.

The choosen solution should be backwards compatible to still allow the loading of old data correctly.

Revisions and Commits

rMITK MITK
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision

Event Timeline

floca triaged this task as Normal priority.Sep 21 2018, 2:55 PM
floca created this task.
floca added a project: Noteworthy.

This task will focuse on the ability to condense the TemperoSpatialStringProperty, if possible when it is serialzed by serializeTemporoSpatialStringPropertyToJSON().
As this is the most important aspect of the task to ensure compact storing of properties into files.

For that we introduce the additional keys "tmax" and "zmax" which together with "t" and "z" can encode if a value spans over several "cells" of the time-x-zslice-matrix.
It will be implemented in a backwords compatible manner.

The memory representation is kept untouched. We can optimize it if we identify the need. I want to avoid premature optimization.

floca added a revision: Restricted Differential Revision.Apr 27 2020, 9:11 PM
floca added a revision: Restricted Differential Revision.Apr 27 2020, 9:21 PM
floca moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Apr 29 2020, 10:37 AM