Will be resolved/obsolete with current utilitie rework-

@floca I think the issue is that it will probably be better to separately communicate server endpoint and refer to the Study/Series items in the DICOM model hierarchy via UIDs. I think adding support for DICOM should be done as part of the initial design, rather than and afterthought and replacement of file paths by URIs. But that only makes sense if DICOM is important and primary for the use case driving the development. That is why I suggest you guys proceed with your original plan, and we will try to experiment with the DICOM-centric design. But of course I may be wrong. I just think it is more expedient to experiment rather than coordinate the design at the same time as the use cases and requirements are evolving.

In T29160#246278, @fedorov wrote:

I think at this point it probably makes sense for us to explore some dynamic JSON representation for defining the task that is geared towards using DICOM, and if/when it makes sense, we can sync up to exchange thoughts and consider harmonization. The statement of the problem is very dynamic, and it is probably too early to do such coordination now.

@kislinsk @floca thank you for the feedback!

In T29160#246167, @kislinsk wrote:

In T29160#246166, @fedorov wrote:

• l think it will be important to make it possible to work with the inputs defined by DICOM UIDs and available through DICOM endpoints, instead of relying purely on file system. Would this be acceptable for your use cases?

We focused on local file paths so far indeed, driven by our requirements and Kaapana’s way of providing general resource access through local files. URIs are not off the table, though, as long as complexity lies within in the intentional KISS spirit of the file format.

I agree (to both ;). If we extend it (which makes mid term also sense for Kaapana) I would go for URIs and avoid any custom specification for different datasources and protocols. I think it is the minimal invasive and well standardized. DICOM could be covered the via DICOMWeb requests.

In T29160#246166, @fedorov wrote:

• l think it will be important to make it possible to work with the inputs defined by DICOM UIDs and available through DICOM endpoints, instead of relying purely on file system. Would this be acceptable for your use cases?

Thanks. Here are some more comments to start the discussion:

• l think it will be important to make it possible to work with the inputs defined by DICOM UIDs and available through DICOM endpoints, instead of relying purely on file system. Would this be acceptable for your use cases?
• In addition to segmentations, it would be helpful to include an option to perform the review of existing segmentations (e.g., those generated by AI that need to be QA'd by an expert, and where some kind of segmentation may or may not be generated as part of the QA process)
• I think there is potentially common needs between this task and the "MetaDashboard" initiative in kaapana (see https://projectweek.na-mic.org/PW38_2023_GranCanaria/Projects/MetaDashboard/) - should these two efforts be coordinated? In that regard, the definition of the worklist does not need to be limited to support of the segmentation task (e.g., there are other tasks already considered in the context of the MetaDashboard, such as series type classification, presence of the artifacts.

In T29160#246073, @fedorov wrote:

Did you consider using JSON Schema to formalize the definition? It is a bit hard to grasp it right now, but admittedly I probably didn't spend enough time looking over the various resources provided.

Did you consider using JSON Schema to formalize the definition? It is a bit hard to grasp it right now, but admittedly I probably didn't spend enough time looking over the various resources provided.

Hi spectators! 👋

I looked into this and although I understand the problem, the issue does not really exist, as far as I can see:

• changing the slice via scrolling will call SliceNavigationController::SelectSliceByPoint
• calling SliceNavigationController::SelectSliceByPoint will call SliceNavigationController::SendCreatedWorldGeometryUpdate
• calling SliceNavigationController::SendCreatedWorldGeometryUpdate will InvokeEvent(GeometryUpdateEvent(m_CreatedWorldGeometry, m_Slice->GetPos()))
• invoking the event will lead to a call to BaseRenderer::UpdateGeometry

-> until here I agree with the task description

I just had another look at this. I was able to reproduce the bug this time. It seems that this problem only arises if the image holds floating point values, not when all values are integers.

Deleted branch from rMITK MITK: feature/T29239-nnunet-download-without-resultsfolder.

Deleted branch from rMITK MITK: feature/T29238-nnunet-improve-validation.

Deleted branch from rMITK MITK: feature/T29227-modify-modal-label.

The warning was reverted for the StdMultiWidget. More changes (problems were already mentioned here in this task) will be further implemented using T29335: [Segmentation] Show interactive warning for uninitialized render window geometry.

Deleted branch from rMITK MITK: release/T29378-v2022.10.

Pushed new branch to rMITK MITK: release/T29378-v2022.10.

Deleted branch from rMITK MITK: feature/T29376-MakeTipsOptional.

Pushed new branch to rMITK MITK: feature/T29376-MakeTipsOptional.

Deleted branch from rMITK MITK: bugfix/T29348-ImproveWelcomePage.

Pushed new branch to rMITK MITK: bugfix/T29348-ImproveWelcomePage.

This bug is originating in Qt 5.15. It is reproducible but not really related to something in segmentation. It's just an obvious part of MITK to encounter the offset.

Ya, I tried. Both before and after annotation. Changes nothing. Bug exists.

Could you explicitly "reinit" the reference node and see if that changes anything?

Bug likely to be caused by Qt 5.15 in my local.
This may not affect this release build since official release builds use Qt 5.12.

Reworked the tools to make them faster.
Close ticket for now. If It is not fast enough we need to make more rework and need to make a in depth profiling where we loose the time.

I implemented the feature based on the shift key:

• Press Shift while clicking on the Previous/Next Task buttons to skip finished tasks
• Use Control + Shift + P/N shortcuts instead of Control + Alt + P/N shortcuts for the same behavior

Deleted branch from rMITK MITK: feature/T29372-OptionallySkipDoneTasks.

Pushed new branch to rMITK MITK: feature/T29372-OptionallySkipDoneTasks.

There are valid points. We should not confuse the user.
Correctly done, I think the new overlay style is the way to go. Besides optimized/userfriendly text (+making the overlay blocky), we could also directly add icon and btns at the overlay to allow reinit of the render window or all render windows. I think from a UX perspective it would be a huge improvment compared to all other versions.

Deleted branch from rMITK MITK: bugfix/T29373-ThemeStdDisplayIcon.

Pushed new branch to rMITK MITK: bugfix/T29373-ThemeStdDisplayIcon.

I also can't reproduce this on Windows 10, changing the theme works as expected. So probably really a Mac OS specific issue.

In T29371#243253, @kislinsk wrote:

It's not a change in iconography, just emphasizing the already present primary icons.

Yes, but I think some of the icons on there own (e.g. the = ) make no sense.
And the also have to be recoginzable in a set of view tabs or if people deactivated the captions!

It's not a change in iconography, just emphasizing the already present primary icons.

Pushed new branch to rMITK MITK: bugfix/T29371-ImproveRegistrationIcons.

There is a point that we can optimize the icons, but i would like to discuss how in beforhand.
I don't think that we have to push it for that release.

Deleted branch from rMITK MITK: bugfix/T29368-SourceFillValueFromActiveLayer.

I designed a few mouse navigation icons and put together a first HTML draft:

Okay, cool. Do you proceed and adapt the checklist to close this task?

Pushed new branch to rMITK MITK: bugfix/T29368-SourceFillValueFromActiveLayer.

The fix is trivial. The source fill label value was always sourced from layer 0 instead of the active layer.

Deleted branch from rMITK MITK: bugfix/T29363-mitk-processexecutor-bugfix.

Deleted branch from rMITK MITK: bugfix/T29342-QPixmapCannotBeInitializedBeforeQGuiApplication.

Pushed new branch to rMITK MITK: bugfix/T29342-QPixmapCannotBeInitializedBeforeQGuiApplication.

I guess the second issue is not yet fixed and will be covered in T29369: [Segmentation Utilities] Handle / select different labels independently.