apparently a vtkLoopUpTable is set automatically so the property as such cannot be used to handle custom vtkLookUpTables

In T26382 the recent developments are summarized.

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#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?

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.

Request discussion result:

I think the things you changed are all reasonable, the things I would add (I can not do it atm because I don't have access to the document)

I agree :)

just started to have a look.

@kislinsk @kalali I have in mind that you recently had a look at the ClippingPlane. Since the clipping plane does not show the expected behavior, does it make sense to rewrite the documentation for it? I have in mind you even considered to declare it deprecated.

Pointed out by @kislinsk in T27095 but as stated before, it belongs to this documentation task not the multi-label one ;)

should work now

I just received an E-Mail that the problem could be related to the data source (some server or network drive) so maybe no MITK issue after all :)

I would suggest that at least the plugin feedback in the GoogleDocs and the toplevel-> main page /MITKUserManual should be corrected before the Release. The rest should be corrected soon after.

@kislinsk: should we further investigate this or have a known issue section in the documentation?

The log information in the console which Jonas reported doesn't turn up. So the console doesn't show any new information after the reader is selected.
I will ask about the HDD / IO.

I am not sure if that is related but today one of my cooperation partners reported that she couldn't open an 4D image in MITK (Latest develop installer).
On my laptop it just works fine. On her laptop, however, she doesn't even get to the logging point. It doesn't show anything, it just stops (She closed the workbench after 10 Minutes).
I asked her whether it was an ancient laptop, but no ;)

1. To my knowledge it should generate a mask out of a Surface and in MITKData there should be some...I will have a look
2. That is rather a bug, because in Phenotyping there is a reference that shouldn't be there, maybe we can remove that.

Region growing task can be found here T27684

Crash fixed by D380 :)

Proposed a fix in D388, maybe there is a more elegant way but it works now

@kalali this looks like a bug introduced by the selection concept?

Oh I didn’t look into the Differential yet, only tried it with the current develop. The crash I observed in with FastMarching3D

So I have a fix for the contour problem but what is missing is that the pointset is still drawn on timestep 0 instead of the current timestep and I have to figure out why.

I also experience a crash in the tool:

File is FastMarchingTool.cpp

I can partly confirm it.

2D Segmentation tools:

Test image: 3D+t Heart

duplicate to T27641

You totally right and the reason why I oversaw this is when I double checked:

All issues have been adressed in respective subtasks.

I can reproduce the behavior for the US4DCyl but not for the heart 3D+t. But it looks exactly like the error for static segmentation and t=2 (that I showed during the telco).

duplicate of T27621

Resolved with D369

that was misleading since the statistics view is in the measurement toolkit view (actually it is quite confusing, maybe we can change that in general)

Eventually related to changes in D360