Resolved with T30390

does it still happen?

This fitting task was applied not to many cases, therefore AVID batch processing was not required and fitting was done in MITK using the formula parser.

Conclusion: In general it makes sense, but we would want to get rid of the "locked state" of the perspective. Needs further research if the locked state can be removed easily or be made more clearly visible, e.g. by a UI element.

Hi there! 🙂

Hi there! 🙂

Hi there! 🙂

Not clear when and how it happens. Need to narrow it down more.

In T30157#253717, @fedorov wrote:

offer the feature to take an instance UID that is an int as the pixel value.

Not sure if I understand it correctly, but ... DICOM UID cannot have int as the value - this would violate VR constraints.

offer the feature to take an instance UID that is an int as the pixel value.

T29204 should be done before as we need to store the information in an appropriate way. The most important thing is that we have then a property to store the instance UID. The default UID is the pixelvalue if not overwritten by the user or another configuration. Regarding the persistance of the pixel value I see two option:
a) Leave with the fact (and document it) that DICOM Seg is not "loss less" regarding the pixel value. So after saving to and loading from DICOM Seg your label will have the same (class) name and instance UID but might have a different pixel value.
b) offer the feature to take an instance UID that is an int as the pixel value. But this is only possible if we assure in our UI that you cannot use/change into an instance UID in a Segmentation that is alrready used there by another label.
Currently I would lean to a) and generate a new ticket for b) and see if we need it in the future.

MITK v2022.10

Sounds good Ralf - happy to help!

@fedorov Thank you for your quick reply and verification for my assumption (I hoped, that I might have overlooked some broader interpretablility...)

" increase monotonically by 1" could be interpreted as "no holes allowed". We should clarify if this is the case.

The formula for the 23Na-MR data analysis is:

What is the status here?

please ask tanja before I say something wrong.

🙏

Tested on the latest MITK 2023.04 release installer for Windows 10.
Problem doesn't exist anymore. Fixed.

@a178n Could you verify if the problem still exist or if it is fixed?

Hi there! 🙂

Hi there! 🙂

Hi there! 🙂

Important as long as we do not know if it hints to a more fundamental underlying problem.

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.