This task is invalid since we moved the functionality of the render window manager to render window specific drop-down menus. More discussion about the concept will happen in T29297: [mxn multi widget] Optimize data accessibility inside render windows.

In T29388#243635, @floca wrote:

The seg predicate of the view is wrong. Should not be able to select the nifti at all.

Also seg in nifti form have to be converted into label image currently via context menu "convert to segmentation".

Is this reason for a patch release?

That would also help to avoid problems like T29388

The seg predicate of the view is wrong. Should not be able to select the nifti at all.

I added a first fix to avoid crashes. More changes are required:
Inside QmitkSegmentationView::UpdateGUI() the two functions m_Controls->layersWidget->UpdateGUI() and m_Controls->labelsWidget->UpdateGUI() are called. They both require the working image to be a LabelSetImage, otherwise the GUI elements will stay deactivated. Also, since no layer is available the toolselectionboxes stay deactivated.

In T28989#233817, @kalali wrote:

mitk::Tool::CanHandle:

In T28989, @kalali wrote:

The basic mitk::Tool restricts the data that can be handled to reference-data - working-data pairs, where

• the reference-data is valid

Why is it not required for the working-data to be valid? This is a requirement for all following CanHandle-functions (working data needs to be an mitk::LabelSetImage or an mitk::Image) that override the basic function, so why not put it in the basic class function?

It seems as if there is a mapping between the SliceNavigationController::ViewDirection and PlaneGeometry::PlaneOrientation, which makes it unnecessary to keep the direction / orientation in both classes.

All related tasks have been resolved so we can close this task as well. The "issue" still remains but we are exploiting it on purpose now using the changes made in {D686}, to show pixel information dynamically (position under the mouse cursor) in the status bar.
With the changes made in {D749} we now have the possibility to explicitly show image pixel information for the crosshair position in the newly introduced pixel value view.

In T29025#243469, @kislinsk wrote:

In T29025#243461, @kalali wrote:

I stumbled upon this while working on T28752: [Segmentation] Move Segmentation utilities widgets to SegmentationUI module. I would like to tackle this issue and already started looking into this. Do you already have an idea how to approach it or do we want to discuss it next week?

I already implemented most of it as core service a while ago but then was interrupted by something else. As far as I remember it is nearly complete except for the equivalent of BlueBerry's preference storage. I will look for the branch the upcoming week and push it. Never assigned the task, sorry.

In T29025#243461, @kalali wrote:

I stumbled upon this while working on T28752: [Segmentation] Move Segmentation utilities widgets to SegmentationUI module. I would like to tackle this issue and already started looking into this. Do you already have an idea how to approach it or do we want to discuss it next week?

I stumbled upon this while working on T28752: [Segmentation] Move Segmentation utilities widgets to SegmentationUI module. I would like to tackle this issue and already started looking into this. Do you already have an idea how to approach it or do we want to discuss it next week?

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.

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.

If D744 is landed, we can close this task. The issue will be addressed here: T29369: [Segmentation Utilities] Handle / select different labels independently.

With {D744} we only have a single Segmentation Utilities view. Labels operation should be added to this and then the issue of this task needs to be considered.

Test the switch to TransferLabelContent. It makes it faster, but not fast enough for a good UX. I think the only scalable way is to only process the boundingbox region of the image that (potentialy) altered instead of always the whole image.

@isensee could you provide such a large image?
P.S.: not needed any more. found one.

Thank you 🙏

In T24398#241998, @floca wrote:

Our side or also the CTK part.

Hm, lets put it as known issue and discuss its priority when we plan the spring release.

thank you for looking into that matter.

In T24398#241991, @kislinsk wrote:

I noticed that the whole plugin is a complete mess BTW and urgently needs at least some clean up to see all the potentials for improvements and bug fixes. :/

Our side or also the CTK part.

I looked into the dicombrowser plugin and found out that the directory on Windows is something like %APPDATA%/../Local/Temp/TmpDicomFolder.************. However I didn't see pop up any files after retrieve.

I just tried to retrieve data from dicomserver.co.uk and I am able to query and kind of retrieve data. A repeated retrieve even tells me that existing files are overriden. At least that is what the console output tells me. But where are the retrieved images supposed to be stored? And shouldn't the retrieved images appear somewhere in the DICOM editor?

I added the PR (https://github.com/MITK/MITK/pull/262/) as a differential.

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 wouldn't care for the extra size (if it stays reasonable), if users need the pixel type.

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 :-/

We cannot see the files. Their view policy is too restricted.

In T29219#240453, @kalali wrote:

This could be related: https://github.com/MITK/MITK/pull/262/