@thomass OK. Thats enough info, thanks. No further testing for now. We do it in context of a release branch or/and explizit fixes.

In T27507#211659, @floca wrote:

In T27507#211583, @thomass wrote:

In T27507#211505, @floca wrote:

@thomass Thanks.
Now I might be nasty. Have you also checked everything wenn loading to 4D images with different time geometry? E.G. So that the selected time step in the navigator must not correspond to the same time step of the image you segment on?

With two 4D images 3D+t-Heart and US4Dcyl it crashes indeed when

• using the Add tool on the static 3D+t Heart on timestep 0
• changing the timestep and then use the Add tool again

I couldn't reproduce the crash when combining 4D_TEE_Data_MV and US4Dcyl (yet)

Could you please check (if not done already), if this scenario also crashes if you do it with a static segmentation?
This info is important for the decission, if we have to fix it directly or just partialy deactivate the dynamic option for this cycle. (Curently static segs on 4D images are more relevant then dynamic segs).

In T27507#211583, @thomass wrote:

In T27507#211505, @floca wrote:

@thomass Thanks.
Now I might be nasty. Have you also checked everything wenn loading to 4D images with different time geometry? E.G. So that the selected time step in the navigator must not correspond to the same time step of the image you segment on?

With two 4D images 3D+t-Heart and US4Dcyl it crashes indeed when

• using the Add tool on the static 3D+t Heart on timestep 0
• changing the timestep and then use the Add tool again

I couldn't reproduce the crash when combining 4D_TEE_Data_MV and US4Dcyl (yet)

In T27507#211505, @floca wrote:

@thomass Thanks.
Now I might be nasty. Have you also checked everything wenn loading to 4D images with different time geometry? E.G. So that the selected time step in the navigator must not correspond to the same time step of the image you segment on?

In T27507#211481, @thomass wrote:

It really suprises me that FastMarching2D crashes now since I explictly played with timesteps in T26975. But maybe I truly overlooked something, then I am sorry.

@thomass Thanks.
Now I might be nasty. Have you also checked everything wenn loading to 4D images with different time geometry? E.G. So that the selected time step in the navigator must not correspond to the same time step of the image you segment on?

Static Segmentation:
-ADD: A segmentation is drawn on timestep 0, if I change the timestep, the segmentation remains and I can add a new segmentation on timestep !=0, both segmentations are visible since I only have one timestep --> As axpected
-SUBSTRACT: The drawn segmentation can be removed independent from the timestep 0 and timestep !=0 --> As expected
-CORRECTION: The drawn segmentation is removed independent from the timestep 0 and timestep !=0 --> As expected
-PAINT: Painted segmentation occurs on timestep 0. When changing the timestep, the painted segmentation is added to the static segmentation --> As expected
-WIPE: Segmentation is wiped on timestep 0 and wiped on timestep !=0 --> As expected
-RegionGrowing2D: Region Growing is applied on timestep 0 (fits to the image). When changing the timestep, the region growing result fits to the timestep. No crash. Quite slow updates. --> As expected
-FILL: Different timesteps can be filled. When changing the timestep, the segmentation remains --> As expected
-ERASE: Different timesteps can be erased. --> As expected
-LiveWire: T27800
-2D FastMarching: T27721

It really suprises me that FastMarching2D crashes now since I explictly played with timesteps in T26975. But maybe I truly overlooked something, then I am sorry.

It seems (see @kalali latest findings T27721 T27800) that there are more problems in the 2D tools then thought.

In T27800#211261, @kalali wrote:

2. There is a basic flaw in the design which should be discussed instead of just fixing the symptoms with the suggested fix

You are right. I have looked into the Tool2D code base. And I think the only proper solution is to make an complete overhaul and refactoring like I did for the AutoTools (3D). Meaning to check all implicit or explicite usages of time(points) and also clean up and generalize code, as also several 2D tools do a lot of same stuff but just a little bit different, may be due to different developers. But thats not good for maintenance an so on...

In T27800#211261, @kalali wrote:

2. There is a basic flaw in the design which should be discussed instead of just fixing the symptoms with the suggested fix

You are right. I have looked into the Tool2D code base. And I think the only proper solution is to make an complete overhaul and refactoring like I did for the AutoTools (3D). Meaning to check all implicit or explicite usages of time(points) and also clean up and generalize code, as also several 2D tools do a lot of same stuff but just a little bit different, may be due to different developers. But thats not good for maintenance an so on...

redundant

Is this a feature that is widely used? Typically the position nodes are not visible, only if they are explicitly shown by changing the data manager's preferences.
But I like the idea of being able to jump to different slices of a segmentation, regardless of the interpolation. I see this as a possibility to check the different parts of a segmentation easily and quickly being able to switch between different "parts" of a segmentation.

I removed T27060: [Segmentation] Rework InterpolationWidget to not depend on data manager view directly as subtask and now this can be closed!

Many years ago it was decided that we handle 2d images as 3d images with a single slice. While not correct as the pixel spacing in z-direction is completely made up, it reduced some code and edge cases and was found to be an okay-ish simplification. On the other hand it rarely leads to issues that were found to be worth having them as the reduced code and edge cases gave way more benefits in comparison. One reason for this discussion in the first place was the segmentation btw as additional 2d cases regularily broke even more code than all the 4d cases. So eventually it was said, that it will be kind of guaranteed that loaded images will be presented at least as 3d images. It is still possible to generate 2d images in code and that's why there still should be checks if an image has less than 3 dimensions.