Is this related / the same (because the second label is automatically selected and then the second layer has no second label)? T28131: [MultiLabel Segmentation] 3D Threshold tool does not work with multiple labels / layers

Could be related: T28256: [Segmentation] Auto-selection preference was hijacked for something else

Pushed new branch T28772-ShaderIssues.

In the same line of reasoning (see discussion above). We could also remove the label name dialoge, when you add a new layer, couldn't we. In the current tests there was a remark, that when adding a new layer, you first are queried if you realy want to make a new layer and then you are asked for the label name...

Is it realy a check box element or just an action to apply?

I also think that if you realy select a preset it should be aplied, even if it is (partially) out of range. Everything else would have an impact on the visualization and would for example lead to the fact that a certain preset has for the same value different appearances in different images.

Just a ping because it was triggered by a checklist for the upcoming release.

As the widget is very narrow i think the words are to long.

Thanks for the update!

• recon_+300_00163.tif has 72 pixels/inch (which is a common default value for strange early-day web reasons)
• Grey Channel321 UBYTE0010.tif has 2540 pixels/inch or 1000 pixels/cm (which seems to be either the original value or something a program or programmer completely made up as default)

142700 happens to be exactly the original image dimension times 100. Looking at the geometry of Grey Channel321 UBYTE0010.tif I noticed that the spacing is 0.01 in all directions. As long as it is loaded as single image, our 2-d image mapper just creates a texture with the original extent but as soon as there is the other image with the same extents but a spacing of 1 in all directions the least common multiple size for a common texture is 142700x142700.

In the current setup, the transfer is handled from airflow. This is also the case in the wDB-gateway. This stress test should therefore perform the same way and work. I have also a different test with random data, that work up to a limit. The system has now different recovery possibilities and can therefore handle large (random sorted) datasets better. I guess that there are sometimes sill errors, but since the system then restarts, no-one notices it. But there are still limits (depending mainly on the server (RAM)).
So I would also say this ticket is resolved for now. On a long run, changing the whole import process could remain a valid option.

Somewhere deep in the VTK rendering pipeline the extent of an image is suddenly set to 142700x142700 which is the 20 GB of memory that can be observed.

• It works when any other 3-d data like Pic3D.nrrd or ball.stl is already opened.
• The problematic image is Grey Channel321 UBYTE0010.tif which initiates the condition
  • Loading recon_+300_00163.tif image twice works
  • Loading recon_+300_00163.tif and Png2D-bw.png works
  • Loading Grey Channel321 UBYTE0010.tif twice works
  • Loading Grey Channel321 UBYTE0010.tif and any other 2-d images crashes

@gaoh have we also tested it with our wDB stress test?

For upload process, dash-uploader library is used. This library offers built-in progress bar support. Users can see the uploading stage.

So after I switched the DICOM send from CTP to Airflow the issue should be solved.
I have sent multiple terabyte of data without any noteworthy issues.
I still think we could probably remove CTP completely (since it only is used as a DICOM receiver anyway and introduces a considerable amount of complexity to the system).
But it should work as it is right now and the removal can be handled as future work.

@isensee What exactly does not work?

• Are you not able to load the data / ML nodes in the utilities selection widgets? That is a known bug and is addressed here: T28135
• Are you not able to work with multiple labels at all? This is also a known problem, since the MultiLabel Utilities View was never correctly implemented for working with multiple labels.

yes of course

@s280a can we move this into "in progress" ?

Maybe @s349i can also say something to this: Did you test the Utilities with segmentation masks created by the "MultiLabel Segmentation View"?

I tried to create an artificial fiberbundle using Fiberfox. The result looks fine in 2D and 3D.

Original description of the issue by Nil Goyette:

Pushed new branch T28017-FinalizeCompatibilityWithMitk.

It seems there is no practical way to handle this. Dash offers loading_state property for each component. This is useable (callable) via CSS or JS codes.

Deleted branch from rMITK MITK: bugfix/T28771-FixNegInfInSerializedGeometryProps.

Pushed new branch to rMITK MITK: bugfix/T28771-FixNegInfInSerializedGeometryProps.

In T28135, @kalali wrote:

MultiLabel Segmentation View creates segmentation masks that are non-binary, rendering most of the operations useless.

Descriptions for each ranking method were added.

Yes it looks like I am running OOM. Strange stuff. Loading each image individually MITK barely uses any RAM. As soon as I load both RAM usage jumps up to 20GB (out of my 32GB ) right before it crashes. Also CPU util is high just before that.