@gaoh PLease feel free to reopen if there is still a problem.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Dec 5 2023
Dec 4 2023
Nov 29 2023
Nov 28 2023
Nov 22 2023
MITK Workbench XL
MITK Workbench - extra
Some more name ideas:
MITK Workbench Plus
MITK Workbench - Advanced Edition
MITK Workbench - Extended Edition
MITK Deluxe (ok, too far, I'll better stop now...)
Name suggestion: MITK Workbench - Science Edition
Nov 21 2023
Nov 20 2023
Thats because 3D Tools in total do not support undo redo currently.
Sofar we havent dared due to the memory footprint (as it would mean storing copies of the volume); but also never tested it.
May be we should ceck if it is OK in conjunction with compression (introduced by @kislinsk some time ago) and if needed limitations (a max step limit, or clearing the history if the segmentation is finished), to avoid extrem memory consumption due to long undo/redo history.
Nov 9 2023
New checkbox "Allow all models" added to Preferences. Changes included in D875
Nov 7 2023
I would lean to adding a preference "allow unsupported models" (default ==false). If people activate it, they can see all models (that are not blacklisted) and not just the white listed (verified) once.
If the risk is communicated and users are willing to take it, then I would not actively prevent people from using models (as long as they don't crash MITK or so).
Oct 27 2023
Oct 26 2023
We should also have a look on eMITK plugins. Maybe not for that release, but for the next.
E.g. would the MRI tools make sense?
SUV would also be a candidate... may RT (but there we have to double check the state...
Oct 24 2023
So now we have to clarify the name for the bigger edition. And if we want to have just one extended edition or if we will in the end have it focused on topics. As we only have currently fitting stuf added.
Oct 23 2023
Oct 13 2023
Oct 11 2023
Sep 27 2023
I think in doubt I would just move but not merge it for now. If we see that it is needed or wanted we can make the effort and merge it. It would be better than not offering this feature at all.
The dicom inspector has one additional dependency to module MITKDICOM. Therefore if we merge the inspector plugins also our normal inspector could only be build if DICOM module is activated. (Which it currently is per default).
Sep 20 2023
Integrate into F1 help. Make MITK ModelFit Webpage deprecated for manual section with link to doxygen documentation.
It is a useful feature and should be part of the next release.
Open to dos:
- Checklist
- check dependencies of the view. If the view does not have more dependencies then our property inspector should be merged.
Sep 19 2023
Sep 11 2023
Sep 7 2023
In T30157#253717, @fedorov wrote:offer the feature to take an instance UID that is an int as the pixel value.
Not sure if I understand it correctly, but ... DICOM UID cannot have int as the value - this would violate VR constraints.
offer the feature to take an instance UID that is an int as the pixel value.
T29204 should be done before as we need to store the information in an appropriate way. The most important thing is that we have then a property to store the instance UID. The default UID is the pixelvalue if not overwritten by the user or another configuration. Regarding the persistance of the pixel value I see two option:
a) Live with the fact (and document it) that DICOM Seg is not "loss less" regarding the pixel value. So after saving to and loading from DICOM Seg your label will have the same (class) name and instance UID but might have a different pixel value.
b) offer the feature to take an instance UID that is an int as the pixel value. But this is only possible if we assure in our UI that you cannot use/change into an instance UID in a Segmentation that is alrready used there by another label.
Currently I would lean to a) and generate a new ticket for b) and see if we need it in the future.
- Boolean Operations
- chosen: high effort
- Can be used so that the other functions can do everything
- Work only on one image, select two labels
- Contour to Image & Surface to Image
- chosen: low effort seems more senseful. The functionality can be achieved via other tools (e.g. boolean)
- Image Masking
- chosen: low effort
- Morphological Operations
- as proposed
- Pick an image & pick a label
- Include options like in picking tool, i.e. generate a new layer when doing an operation, lock labels (to make sure other labels are not overwritten e.g. for a dilution)
- Add a new tool: Transfer Label could be used to transfer a label from one image to another (if the same image is selected twice, it's just a rename)
Aug 9 2023
Aug 8 2023
Aug 3 2023
Aug 2 2023
I had a look as well: two voxels is really an edge case, given the current method it would only give a correct result for number of bins == 1 . But setting the number of bins to at most (number of voxels - 1 ) doesn't really help, it fails e.g. for three voxels. In general thinking a bit about it I came to the conclusion that limiting the number of bins (currently it's _minimum_ 10) would still not yield a correct median.
Aug 1 2023
I just did the Pic3D/brain test mentioned above and it works with v2023.04.
We could set up a test case to check if it is still an issue in the context of segmentation task lists. A segmentation task list with two tasks, one task referencing Pic3D.nrrd, the other task referencing the tilted brain.nrrd image. If this is working with the latest release it should be a proof that is not an issue anymore.
Deleted branch from rMITK MITK: bugfix/T29649-ClassificationModuleCleanUp.
Jul 28 2023
Jul 26 2023
Pushed new branch to rMITK MITK: bugfix/T29649-ClassificationModuleCleanUp.
With the addition of the polygon tool, this is now possible.
Jul 25 2023
Yes, after commenting the 4 lines in the mitkExtractSliceFilter I am getting 3 component image.
Also, found out that the following works instead of commenting the snippet out:
Comment vectorComponentExtractor->SetComponents(m_Component); and pass on exact component needed to vectorComponentExtractor->SetComponents(0,1,2);.
Your "solution" is not a real fix. It just exploits a bug/undefined behavior. So do not do it
Oh ok. Yes, I can the see the pixel type "rgb". Also, when I save the mitk::Image object using IOUtils::Save, I can see (in python) that the written image is 3 channel.
But the issue still occurs, channel is information is ultimately lost here in mitk::SegWithPreviewTool::UpdatePreview:
Jul 24 2023
Be carefull. RGB channels of an RGB image are not stored in different mitk::Image channels currently. Every thing is stored in one channel. But the channel has the pixel type "rgba". So the channels are encoded in each pixel.
After a little debugging, I see that even DataNode::GetData() returns single channel Image.
eg. dynamic_cast<const Image *>(m_SegmentationInputNode->GetData())
SegPreviewTool class uses this image for further processing.
Jul 20 2023
Anyway after discussing with Ralf, the problem at hand - implementing levelwindow effect of input images to SAM, is solved using itk::IntensityWindowingImageFilter.
Jul 19 2023
Jul 18 2023
- I am seeing the array in python after writing it out IOUtil::Save(mitkImage, imagePath);. That's 4 channel image. ie. 32x32x4.
- I use vtkMitkLevelWindowFilter because you recommended(?) and also its used by MITK for its levelwindow processing and at few other occasions. So this data type change is widely affecting MITK. But whether its compensated somewhere else or not is not clear for me.
But for SAM tool- Thanks for the tip, I will try out vtkImageMapToColors and see.
You seem to mix a few things here.
Hi,
I finally could apply levelwindow Filter on image successfully for SAM tool.
But that seems to opened up another can of worms 😅 (?)
The vtkMitkLevelWindowFilter gives me 2D 4 channel image. But the channels are duplicate. I verified using numpy/python. Presumably. I can just take out one channel slice and that should be it.
But I observe somethings not correct:
- I convert vtk image to mitk image using the following syntax:
Jul 14 2023
I think the handling of multiple labels depends on each action and needs to be handled separately.
- Boolean Operations: I see a few options here
- low effort: only allow for segmentations with one label. If there is more than one label, show a message that this is not possible
- higher effort: completely rework the selection. Let the user select two specific labels (from the same or different segmentations) and work on these, either replacing the first label or adding a new label (or instance) to that segmentation
- Contour to Image & Surface to Image:
- low effort: leave it as is, still works at the moment
- higher effort: introduce the option to add the newly created segmentation as a new label / instance to an existing segmentation
- Image Masking:
- low effort: leave it as is, still works at the moment (using all labels of a segmentation)
- higher effort: introduce the option to select which labels/instances should be considered for masking
- Morphological Operations: Currently don't crash, but always use label 1
- I think the most senseful solution would be to let the user select a specific label for the operation to work on. Multiple at the same time probably only get in each other's way and make it unnecessarily complicated.
Jul 13 2023
nnUNet(v1) won't be removed until nnUnet v2 is introduced.
Jul 11 2023
Sounds good Ralf - happy to help!