Page MenuHomePhabricator

Trivial: correct behavior for data with invalid time steps?
Closed, WontfixPublic

Description

During rendering, the integer time step of a data object is calculated in mitk::Mapper::Update(). The time step is set to "-1" (invalid), if either

  • the current global time is out-of-range for the data object or
  • the data object is not initialized or NULL

For invalid time-steps, the data object should not be displayed at all, and the respective render methods (GenerateData()) of concrete mapper subclasses should not be called.

A quick fix is to check the validity of the time step in mitk::Mapper::Update() and to return without calling GenerateData() if it is invalid. Moreover, it should be verified that

  • previously displayed data are no longer displayed when the time step temporarily becomes invalid
  • sub-classes do not check time step validity themselves, and everything necessary is handled in the base class Mapper

Event Timeline

A check if the time step is valid has already been implemented with r18031 (in mitkMapper.cpp). This has been tested by opening two datasets with different numbers of time steps: when at a given time step only one of the two datasets is valid, only this dataset is displayed.

However, most mappers still check for time step validity themselves. This redundancy should be removed. In most mappers, the validty check is done with

int timeStep=0;
if ( time > ScalarTypeNumericTraits::NonpositiveMin() )
  timeStep = inputTimeGeometry->MSToTimeStep( time );
if ( inputTimeGeometry->IsValidTime( timeStep ) == false )
{
  return;
}

Question: Is it necessary to check if

time > NonpositiveMin() ?

Is this not already handled by

inputTimeGeometry->IsValidTime( timeStep ) ?

Removing MITK 1.0 relevant flag since the remaining work is only cosmetic.

[SVN revision 21794]
CHG (#2198): changes according to the ChangeRequest Report

[SVN revision 21797]
CHG (#2198): changes according to the ChangeRequest Report

The above code clean-up affects only ::GenerateData() methods, the same should be also done for ::Paint() methods

TODO: consider build warnigs ( "unused variable" comes from virtual void mitk::Mapper::ResetMapper(BaseRenderer*)

[SVN revision 21881]
CHG (#2198): removing explicit parameter declaration in mitk::Mapper::ResetMapper( BaseRenderer* ) to avoid warnings (in open-source part)

Jan, what is the status of this bug? Can it be closed?

the changes mentioned in Comment 4 are still not done, but since they are more 'cosmetic' then 'functional', we could consider this bug as closed.

Changing active assignee. Caspar, could you please review the bug status, particullary the need to fix the issues mentioned in Comment 4.

Resetting all bugs without active assignee flag to "CONFIRMED". Change status to IN_PROGRESS if you are working on it.

TODO: Cosmetic changes for Paint() methods.

Really low priority.

This bug could not be fixed for release 2013-06. Setting target milestone to next release

kislinsk added a project: Bulk Edit.
kislinsk removed a project: Bulk Edit.