As discussed with @s434n, I will discard my diff D466 for now, because it caused some unwanted interactions with the LayoutAnnotationRenderer. The quick fix of D506 solves the problem that in Geldosimetry and OverlayManager the colorbarAnnotation is not displayed on the right at the center (placed too heigh and is cutoff in the render window).

I am indeed still reading since I still have tasks to do (I will not leave beforehand just as promised :-)). I think you are referring to T28383 / D477 ... maybe it didn’t fully do the trick.

The task as such is resolved. Another task with open questions from D279 is created with T28466

Could be solved by @kislinsk suggestion to change rendering mode to LOOKUPTABLE_COLOR to not envoke the levelwindow to overwrite the range

Unassign myself because we removed the clipping plane from the release and have not discussed yet how to further proceed.

The first user feedback of the patch above was positive, the users liked the behavior.
However, the patch did not work correctly in terms of modifying the points afterwards (users were warned before).

Pushed new branch to rMITK MITK: feature/T28406-PatchForTestingLiveWireBehavior.

First patch to change following behavior (for user testing only):

• The linesegments are added with each mouseclick of the users without the cost function but by connecting start and endpoint
• If the user double-clicks on the image, the last point is connected with the first adding an additional segment.

On a first glance, the interpolation seems to affect the result.

1. Create the segmentation with interpolation -> save it -> reload segmentation -> erosion = no crash
2. Create the segmentation with interpolation -> erosion = crash

The issue can indeed be solved by a mitk::RenderingManager::GetInstance()->RequestUpdateAll(); in QmitkLabelsetWidget function OnVisibleButtonClicked() but there seems to be something wrong with the lock logic when "Lock All" "Unlock All" is clicked

Since you also mentioned different editors: 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?