In T24398#244802, @floca wrote:

Have you pushed your clean ups? Not that your efforts get lost. 😉

In T24398#242008, @kislinsk wrote:

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.

Only looked into our side so far. I'll create a separate task and push my clean-up that I already did so far.

Without a data sample we are not able to reproduce this issue. Can you upload one of these nrrd files? Please make sure that the data does not contain any personal information. You can also restrict access to uploaded files to certain users like me.

Unfortunately, it is all nrrd files. I updated my nvidia drivers and it seems to have improved slightly in that it doesn't crash within moments of loading a base nrrd file, but after I create, save and remove a segmentation nrrd, MITK Workbench crashes when I try to reload (open) the segmentation nrrd.

Thanks for reporting. We are not aware of any crash like this with valid nrrd files. Since ITK snap crashes as well it could be a strong indicator that the crash is happening in the ITK reader that we use as well. It could be probably related to a corrupt nrrd file, or, in case it is a huge file, it could be simply related to running out of memory. Anyway, without the data we are not able to reproduce this issue.

Example data

Which data has been used to provoke the problem.

Unfortunately not solved. Same error.

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

We discussed this and we decided to remove the options from the preferences completely. That means, that

• the user cannot change the smoothing hint / value
• the user cannot change the decimation rate
• the checklists don't need to ask for changing these values
• the smoothing will use the default values (set inside QmitkCreatePolygonModelAction::Run)
  • "smoothing hint" = true (will always use image spacing as hint)
  • "smoothing value" = 1.0
  • "decimation rate" = 0.5
  • "closing ratio" was not used at all
  • note that different default values are given in ShowSegmentationAsSurface::Initialize (and other functions of this class), but are overwritten / reset by the polygon action.

I think it actually is an issue or at least unexpected. The level window seems to have trouble with color images in general.

I looked into this and can verify that there is no visible effect when changing the decimation rate. The property "Decimation rate" is correctly used inside ShowSegmentationAsSurface::ConvertBinaryImageToSurface as reductionRate. It is then used as an argument for ImageToSurfaceFilter::SetTargetReduction. The brief description of this parameter is:

Same for Windows 10, Ubuntu 20.04, and Ubuntu 22.04.

On MacOS Monterey, the level window default values for the image are 83, 226.

As far as I can tell, this is the expected behavior. Any voxel that has a (greyscale) value above the level-window range is shown completely white. The colors only extend this to multiple channels, but the behavior is still the same. So with very low level-window, the colors are expected to stay visible very strongly

We need information of the minimal setup to reproduce the problem.

Needs more investigation, how and why the values are different. Naive assumption would be that they should be the same.

Verify if it is a code or a teaching problem

We should double-check if there's really a bug as there's a good chance that it was just misunderstood how it works. Everything that's not covered by the level window is supposed to be transparent. We should probably improve the checklist to be more clear.

Please double check, if there is realy an error with Jet Transparent (or with the checklist). And on which systems.

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?

To make our live a bit easier. I would say it is a data problem ;).