Since you also mentioned different editora: Not sure if this is also related but one of the terminal outputs of the testers was:

With the modelfit inspector it most often crashed, if the user clicked on a datanode in the datastorage

Probably it would just help to replace the MITK Error by a warning? This is also done when there is no point set at all.

I couldn't reproduce this bug in the latest Release installer on Windows. However, there is no volume visualization shown at all (no matter which timestep or which histogram I select).
If the crash does not occur anymore on Ubuntu etc. we can resolve the crash bug.

Most likely something for the next release IMO, but please decide @kislinsk :)

Since the default colormaps are overwritten by the levelwindow I added a Boolean property to give the user a possibility to prevent the custom colormap from being overwritten

Sorry this was already mentioned in T27507. But I think we never discussed / decided what the purpose of picking on 4D tools should be. But not necessarily important for the release though.

Watershed tool also has very weird rendering flickers, whenever there is more than one image visible in the 2D view. Whenever the rendering bug is solved, the segmentation tools should be checked again.

IMO not severe for the upcoming release since Otsu is not often used and it is not a show stopper...

Since you are already working on the histogram anyways, can you check the following:

probably related to T28206

However, checking "Show Subchart" always invokes an update and then you can see it

The scene is created successfully if following (deprecated) properties are disabled in mitkDICOMImageBlockDescriptor.cpp:

as name property, the name of the RT node is provided correctly.
I created a working example with Pic3D for comparison.
Looking at both caaaaa.xml files, the only difference I notice is that the corrupted one is encoded with UTF-8 but otherwise it looks similar (as far as I see).

<?xml version="1.0" encoding="UTF-8"?>
<Version Writer="C:\Development\MITK-dev\src\Modules\SceneSerialization\src\mitkSceneIO.cpp" Revision="$Revision: 17055 $" FileVersion="1"/>

sorry just saw the message. I put it in the shared folder.

As Ralf pointed out, it is actually not related to the GenericProperty as such but it seems that the scene does not even contain any nrrd files after saving and that is why it breaks

GenericProperty associated to key 'MITK.IO.reader.DICOM.PixelSpacingInterpretation'
GenericProperty associated to key 'MITK.IO.reader.DICOM.ReaderImplementationLevel'
GenericProperty associated to key 'dicomseriesreader.PixelSpacingInterpretation'
GenericProperty associated to key 'dicomseriesreader.ReaderImplementationLevel' still need to be changed

Since solution 1 worked well for me and seems to be more generic, I would vote for 1.

I tried it with my current develop (not the latest due to ongoing QT issues - wip) and it resolves the last warning (predescibed dose) but not the others. According to the D449 this is the one you changed, so as expected I suppose :) As soon as I get the latest develop up and running I will check the diff further.

Might be related to T25305

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