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.