User Details
- User Since
- Apr 3 2017, 9:50 AM (409 w, 6 d)
- Roles
- Disabled
Jul 19 2019
Jul 12 2019
- Auflistung von Anforderungen!
- Check
- Dicom Derived Tag (verbinden der repräsentationen und originale) (Source)
- Dicom Surface Segmentation
- Source Entity und Image (Tags) Referenced Image and Instance Sequence
- Bei Contour Tools Contours speichern
- Mischen der Masterrepräsentationen in Anwendung und Speichern
- Komplexität bei Arbeit mit binär und fractional (Toolunterstützung)
- Wird ContourModel noch woanders verwendet? Noch aktuell?
- Complexity Plugin
- Tool defines what data works
- Wishlist GUI abstrakt toolkitunabhängig definieren (Parameterdefinition)
Jul 5 2019
Regarding the segmentation data type the PolySeg project should be kept in mind as it offers flexibility in the representation of the segments.
They also define a segmentation and a segment class although neither of them directy "is" the data. A segment keeps a list of representations (i.e. vtkDataObjects in their case) that actually hold the image / surface / contour data.
Making the segment directy inherit from Image creates a strong bond to the representation as labelmask (binary or fractional) but leaves out representation of contours and surfaces for example.
In this regard one proposal would roughly follow this class layout:
Here one segment could be represented as one label (or as contours, a surface, etc.).
In the case of a labelmap it would make sense to hold a binary image or as Stefan mentioned uint16 or unsigned short for fractional labels.
Jun 6 2019
Jun 5 2019
Feb 1 2019
Jan 28 2019
Yes, that is correct
Jan 25 2019
Sep 25 2018
Sep 12 2018
Sep 10 2018
Pushed new branch T25425-MapperAsServices.
Jul 9 2018
Using the most recent master on my laptop (my pc build failed) I couldn't reliably reproduce the issue.
Maybe it's specific to the imageStatistics branch or my machine.
Should also have mentioned that I tested this on branch T24182-newImageStatisticsPlugin.
Im building the master atm so I'll report if it has the same result
Of course, steps to reproduce:
- Load MITK-Data\3D+t-ITKIO-TestData\LinearModel_4D_arbitrary_time_geometry.nrrd
- Doing a normal press should now step 2 time steps at once
- Doing a really short press should allow you to single step
One more thing to try:
- Start MITK in Debug configuration
- Load MITK-Data\Pic2DplusT.nrrd
- Stepping should work fine
- Set a breakpoint on QmitkImageStatisticsReloadedView::OnTimeChanged
- Stepping once should now always trigger the event twice (and the slider gets moved two steps as well)
Jul 6 2018
Feb 16 2018
Feb 15 2018
Feb 9 2018
Feb 8 2018
Jan 19 2018
Concluding my findings:
Colors are defined in ...\mitk\Plugins\org.blueberry.ui.qt\resources\darkstyle.qss
The text color is indeed driven by the QWidget lines shown above.
Changing it could look like this:
Note that the color chosen is merely an example. Someone with a bit more understanding of design should decide for the final hex value to be used.
Jan 4 2018
This seems to be a stylesheet setting regarding disabled elements.
If an image is chosen and the buttons get enabled they change to the right color as seen here:
This issue isn't restricted to the Segmentation tool but seems to regard all disabled elements in other tools as well.
When checking the darkstyle.qss file it can be noted that all disabled elements get attributed a blackish color as seen for QWidget as example here:
To change the color of disabled text this stylesheet is most likely the place to modify although I couldn't figure out right away which classes are affected. Maybe someone with deepler knowledge can help out. I'll take a close look on Community Day
Jun 27 2017
May 5 2017
May 2 2017
Apr 27 2017
Originally I was planning on reviewing all of the three coverage tools and present them here. This consumes a substantial amount of time though and I could further improve the efficiency of analyzing code coverage with OpenCppCoverage. These are the reasons why the other two tools won't be discussed here as of now.
Instead I'll try to give you a detailed description of what I think is the easiest way to analyze the code coverage with OpenCppCoverage.
Analyzation toolchain
I wrote a little executable to do the hard work (i.e. searching the Test names and additional parameters in the CMakeLists files of the test folder).
Usage:
So as we see we need "only" five arguments for the tool to work.
Apr 12 2017
I looked further into OpenCppCoverage due to the fact that it is also available as a visual studio extension and thus could be integrated in the daily workflow easily.
Apr 10 2017
For this task it should be considered to look into Test Coverage / Code coverage and what Software can help us identify the parts of code that aren't tested yet.
Basic coverage criteria
With code coverage software there are several different criteria the tool can look out for. The main ones are (from "weakest" to the most strict one):
- Function coverage: Has each function in the program been called by at least one test?
- Statement coverage: Has each statement in the program been executed?
- Branch coverage: Has each branch (i.e. if, else, case, etc.) been excecuted?
- Condition coverage: Has each Boolean sub-expression evaluated both true and false at least once?
This is only a brief introduction to the different criterea. Anyone that is interested in a visual example can have a look here:
https://www.johner-institut.de/blog/iec-62304-medizinische-software/code-coverage/