Deleted branch from rMITK MITK: bugfix/T29305-FixGDCMIssues.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Sep 20 2022
Sep 19 2022
Pushed new branch to rMITK MITK: bugfix/T29305-FixGDCMIssues.
I added the PR (https://github.com/MITK/MITK/pull/262/) as a differential.
Sep 18 2022
Pushed new branch to rMITK MITK: feature/T29206-MVC_pattern_for_labelsets.
Sep 16 2022
Sep 15 2022
Sep 14 2022
I quickly looked into this using the experimental state of the mxnMultiWidget but I get a Workbench crash. This might be unrelated so I tested something else:
I used the StdMultiWidget, loaded Pic3D but then I used the Render Window Manager to change the Mapper of the axial render window from 2D Mapper to 3D Mapper.
I get the following crash:
I will close it. For the reasons noted above.
Should not be address directly now. Reason: With the new Segementation class, there will be a hard upper limit for the number of labels anyways. In this corner case we also would have to show a error message then, just telling that we cannot cover more then 2^16 labels. So that the provided image cannot be converted into a label image.
Could be the same issue like in T28816: [Segmentation] "New Segmentation" dialog to small
We have to check if the property is applied or the reason for no difference is that the rate is to small.
Stefan is right that, from the medical perspective, there is no need for these pixel types. And urgently needed not they are. We can easily convert all the files with strange pixel types to files with 'normal' ones. The issue here is simply from a usability/user experience perspective. It is uncommon to me (and probably other as well) to load an image and then get told the pixel type is not supported
I tested the fixed installer in a Fedora VM and it worked as expected.
Deleted branch from rMITK MITK: bugfix/T27578-RemoveTCPWrappersDependency.
@kalali Do you have a use case with the mxn widget where you could check this pull request with multiple 3d render windows?
Sep 13 2022
I wouldn't care for the extra size (if it stays reasonable), if users need the pixel type.
Deleted branch from rMITK MITK: feature/T28851-AddITKGrowCutTool.
Deleted branch from rMITK MITK: bugfix/T29296-FixCrashWhenClearingTaskListSelection.
Pushed new branch to rMITK MITK: bugfix/T29296-FixCrashWhenClearingTaskListSelection.
Pushed new branch to rMITK MITK: feature/T29295-monai-segmentation-tool.
Sep 12 2022
I sent the file to you via slack.
Not supporting some pixel types can be very frustrating for users, so it might make sense to extend this list (I would certainly appreciate it and a 200MB standalone is really not large by 2022 standards so there is some headroom imo ;-) ). This is not the first time I ran into this issue :-/
Pushed new branch to rMITK MITK: bugfix/T27578-RemoveTCPWrappersDependency.
Looking closer into the issue I wonder why it should not work without TCP Wrappers. It is an optional dependency of DCMTK which, regarding to storescp, adds two access control cmd-line arguments that we are not using anyway as far as I can see. So maybe it is just an issue since we so an explicit requirement check and then of course DO link against it. If we would explicitly disable it in DCMTK and remove the check in our CMake script, it should probably work already,
I would recommend to file a ticket in the DCMTK bug tracker since it is a dependency of dcmnet.