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

• 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.

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

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

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

In T28756#229271, @floca wrote:

Found the problem. It is not a error in the picking tool.

It is in

void mitk::LabelSetImage::ClearBuffer()

Because AccessByItk (which is used there) by default only supports 2D and 3D. -> Exception when trying to reset dynamic LabelSetImages.

So far I see the following solutions:

1. Add 4D as a CMake default (but would impact a lot of code...)
2. Add in clear buffer a check if instance is 4D and if so explizitly call it for 4D (in other cases use AccessByItk as we did so far.

@kislinsk Do you see an other option? Which one would you choose?

Deleted branch from rMITK MITK: release/T28750-2021-Week-42.

Pushed new branch to rMITK MITK: release/T28750-2021-Week-42.

Deleted branch from rMITK MITK: bugfix/T28749-libxdamage.

Pushed new branch to rMITK MITK: bugfix/T28749-libxdamage.

I already implemented something but it is not yet finished.

Thanks!

This is a good candidate for some XML parsing errors that we see in the latest develop version of the MitkWorkbench, For example, activate any 3D segmentation tool and look at the console output:

BTW I recommend to test always with the latest snapshot installer instead of the last release.

Found the bug. The lower threshold for the region growing preview is set to itk::NumericTraits<TPixel>::min() when the region growing direction is downwards. However, itk::NumericTraits<TPixel>::min() is the wrong method as it has a different meaning for floating point values than the author obviously expected (compare to min() vs. lowest() in std::numeric_limits<>). The correct method is itk::NumericTraits<TPixel>::NonpositiveMin(), which works for all cases and is the right semantic minimum of a range of values.

Workaround: (Re)open the MultiLabel Segmentation view after you converted the segmentation to make it work.

Deleted branch from rMITK MITK: bugfix/T28740-CIBuildStatusBadges.

Pushed new branch to rMITK MITK: bugfix/T28740-CIBuildStatusBadges.

Deleted branch from rMITK MITK: bugfix/T28739-UpdateSupportedTier1Platforms.