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.
Wed, Sep 14
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?
Tue, Sep 13
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.
Mon, Sep 12
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 :-/
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.
Deleted branch from rMITK MITK: bugfix/T29293-FixTypos.
Sat, Sep 10
We cannot see the files. Their view policy is too restricted.
Fri, Sep 9
Deleted branch from rMITK MITK: release/T29291-2022-Week-36.
Deleted branch from rMITK MITK: feature/T28959-livewire-closure-improvements.