- User Since
- Aug 1 2016, 12:10 PM (239 w, 6 d)
Tue, Mar 2
Since you also mentioned different editora: Not sure if this is also related but one of the terminal outputs of the testers was:
Mon, Mar 1
With the modelfit inspector it most often crashed, if the user clicked on a datanode in the datastorage
Thu, Feb 18
Wed, Feb 10
Feb 4 2021
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 :)
Feb 2 2021
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
Jan 29 2021
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:
Jan 27 2021
probably related to T28206
However, checking "Show Subchart" always invokes an update and then you can see it
Jan 4 2021
The scene is created successfully if following (deprecated) properties are disabled in mitkDICOMImageBlockDescriptor.cpp:
Dec 16 2020
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.
Dec 15 2020
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
Dec 14 2020
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.
Dec 10 2020
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.
Dec 8 2020
Might be related to T25305
Nov 25 2020
Nov 24 2020
apparently a vtkLoopUpTable is set automatically so the property as such cannot be used to handle custom vtkLookUpTables
Oct 22 2020
In T26382 the recent developments are summarized.
Oct 6 2020
Oct 5 2020
-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
-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.
Sep 25 2020
Request discussion result:
Sep 18 2020
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)
Sep 16 2020
I agree :)
just started to have a look.
Sep 4 2020
Sep 3 2020
@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.
Sep 2 2020
should work now