Change Details

Status: # Currently the documentation of TimeGeometry states that GetMinumumTimePoint() and GetMaximumTimePoint() are the valid bounds. So time geometry bounds for the whole time geometry and its steps are closed intervals [GetMinumumTimePoint, GetMaximumTimePoint]. That makes sense as it follows the principle of minimal surprise, because the itk::BoundingBox (used for the spatial bounds, does it the same way. # The implementation of PropertionalTimeGeometry instead handles the bounds as a semiclosed interval [GetMinumumTimePoint, GetMaximumTimePoint). So MaximumTimePoint is the first first point not inside the time bounds # The implementation of ArbitraryTimeGeometry instead handles the bounds mostly as a semiclosed interval [GetMinumumTimePoint, GetMaximumTimePoint). So MaximumTimePoint is the first first point not inside the time bounds. The only exception is for colapse final time points as the happen in DICOM images. This problem becomes obvious now e.g. in T27883 when you work in the last time step of a collapsed ArbitraryTimeGeometry (basically any dynamic DICOM image). Then we have different interval checks and there for inconsistencies and errors. Discussion point: a. A work arround could be to change the handling of collapsed final time steps in ArbitraryTimeGeometry and define that this indicates a coverage up to positive max. So if a final timestep as no defined extend and would therefore infitesimal small, we treat him as he covers the whole rest of the time. It should work, but not tested yet and it might have other implications that I currently do not see. We had this discussion multiple time in the past and so far we always were reluctant to go that way: a) because we would alter/generate information we do not have; b) because we did not know if this might not break any code. (see e.g. discussion in T24766 i.a.) b. Even though a) might make sense, I think we should take care of this inconsistency. The only question is, if it should/must be before the release. I would depend it on the fact if the work arround a) is not just a work arround but we always want to handle it that way. But the arguments we had against a) still hold I think. And we cannot completly forsee the implications for both options. So it is between a rock and a hard place... 😒

Status: # Currently the documentation of TimeGeometry states that GetMinumumTimePoint() and GetMaximumTimePoint() are the valid bounds. So time geometry bounds for the whole time geometry and its steps are closed intervals [GetMinumumTimePoint, GetMaximumTimePoint]. That makes sense as it follows the principle of minimal surprise, because the itk::BoundingBox (used for the spatial bounds, does it the same way. # The implementation of PropertionalTimeGeometry instead handles the bounds as a semiclosed interval [GetMinumumTimePoint, GetMaximumTimePoint). So MaximumTimePoint is the first first point not inside the time bounds # The implementation of ArbitraryTimeGeometry instead handles the bounds mostly as a semiclosed interval [GetMinumumTimePoint, GetMaximumTimePoint). So MaximumTimePoint is the first first point not inside the time bounds. The only exception is for colapse final time points as the happen in DICOM images. This problem becomes obvious now e.g. in T27883 when you work in the last time step of a collapsed ArbitraryTimeGeometry (basically any dynamic DICOM image). Then we have different interval checks and there for inconsistencies and errors. Discussion point: a. A work arround could be to change the handling of collapsed final time steps in ArbitraryTimeGeometry and define that this indicates a coverage up to positive max. So if a final timestep as no defined extend and would therefore infitesimal small, we treat him as he covers the whole rest of the time. It should work, but not tested yet and it might have other implications that I currently do not see. We had this discussion multiple time in the past and so far we always were reluctant to go that way: a) because we would alter/generate information we do not have; b) because we did not know if this might not break any code. (see e.g. discussion in T24766 i.a.) b. Even though a) might make sense, I think we should take care of this inconsistency. The only question is, if it should/must be before the release. I would depend it on the fact if the work arround a) is not just a work arround but we always want to handle it that way. But the arguments we had against a) still hold I think. And we cannot completly forsee the implications for both options. So it is between a rock and a hard place... 😒 IMPORTANT: If this issue is handled the workarround introduced for/by T27883 have to be removed. To find the workarrounds search for the following text in the code base: "`Workarround T27883.`"

Status: # Currently the documentation of TimeGeometry states that GetMinumumTimePoint() and GetMaximumTimePoint() are the valid bounds. So time geometry bounds for the whole time geometry and its steps are closed intervals [GetMinumumTimePoint, GetMaximumTimePoint]. That makes sense as it follows the principle of minimal surprise, because the itk::BoundingBox (used for the spatial bounds, does it the same way. # The implementation of PropertionalTimeGeometry instead handles the bounds as a semiclosed interval [GetMinumumTimePoint, GetMaximumTimePoint). So MaximumTimePoint is the first first point not inside the time bounds # The implementation of ArbitraryTimeGeometry instead handles the bounds mostly as a semiclosed interval [GetMinumumTimePoint, GetMaximumTimePoint). So MaximumTimePoint is the first first point not inside the time bounds. The only exception is for colapse final time points as the happen in DICOM images. This problem becomes obvious now e.g. in T27883 when you work in the last time step of a collapsed ArbitraryTimeGeometry (basically any dynamic DICOM image). Then we have different interval checks and there for inconsistencies and errors. Discussion point: a. A work arround could be to change the handling of collapsed final time steps in ArbitraryTimeGeometry and define that this indicates a coverage up to positive max. So if a final timestep as no defined extend and would therefore infitesimal small, we treat him as he covers the whole rest of the time. It should work, but not tested yet and it might have other implications that I currently do not see. We had this discussion multiple time in the past and so far we always were reluctant to go that way: a) because we would alter/generate information we do not have; b) because we did not know if this might not break any code. (see e.g. discussion in T24766 i.a.) b. Even though a) might make sense, I think we should take care of this inconsistency. The only question is, if it should/must be before the release. I would depend it on the fact if the work arround a) is not just a work arround but we always want to handle it that way. But the arguments we had against a) still hold I think. And we cannot completly forsee the implications for both options. So it is between a rock and a hard place... 😒 IMPORTANT: If this issue is handled the workarround introduced for/by T27883 have to be removed. To find the workarrounds search for the following text in the code base: "`Workarround T27883.`"