Deleted branch from rMITK MITK: bugfix/T30505-OpenSSL-FindingDLLs.

Pushed new branch to rMITK MITK: bugfix/T30505-OpenSSL-FindingDLLs.

👍

This is still an issue also in combination with general UX improvement of AI tools. I suggest to have a closer look on that together in September so we have enough time for a nice design and implementation until v2024.12.

Pushed new branch to rMITK MITK: feature/T30476-Expose_DCM_block_split_reason.

If I would be them, I also wouldn't like to have another metalayer under my belt. I think we can directly go with our own publishing. We may consider to suggest something like a registry, though, for third-party metalayers. :)

I am not knowledgeable enough to have a well informed opinion. Some thoughts to consider:

I think you proposal is worth trying! Great idea.

In T30454#260087, @floca wrote:

Is there a defined anatomic coordinate system for blosc or the code that wrote the blosc images? Like LPS or RSA (https://www.slicer.org/wiki/Coordinate_systems) may be it differs form the assumption we have in MITK and therefore the memory layout of the pixels is different.

Is there a defined anatomic coordinate system for blosc or the code that wrote the blosc images? Like LPS or RSA (https://www.slicer.org/wiki/Coordinate_systems) may be it differs form the assumption we have in MITK and therefore the memory layout of the pixels is different.

First breakthrough: I was able to load and display the b2nd example image from @isensee. The orientation is unexpected, though. Probably rotated 180° (not mirrored?) around the axial axis. Trying to figure out the culprit. I use a the b2nd_to_cbuffer() function to copy the pixel data into the MITK image memory. If this orientation mismatch is systematic, we may be able to solve it by creating a geometry accordingly. At the moment the MITK image is just initialized via pixel type and image dimensions. As far as I am aware, the Blosc2 image does not contain any orientation meta data, right?

If you need additional files to test, I could give you one :)

c-blosc2 basically has 3 dependencies. We already fulfill and can/should use 2 of them: zlib (resp. zlib-ng) and lz4. The third one is zstd which is no issue, since c-blosc2 comes with an internal version of it if not provided externally.

Pushed new branch to rMITK MITK: feature/T30454-Blosc2.

Deleted branch from rMITK MITK: bugfix/T29421-RemoveCPPRestSDK.

damn. you are right. Than i will revert it and change AVID to add in front of the first '.'.

Wouldn't that break support of compressed files like foo.nii.gz for example?

Pushed new branch to rMITK MITK: bugfix/T29421-RemoveCPPRestSDK.

FYI

Deleted branch from rMITK MITK: bugfix/T29317-CleanUpDICOMBrowser.

Meanwhile a lot of code in CTK regarding the DICOM browser changed and the branch her is outdated so much that it makes sense to start from scratch again, if really necessary at all.

We weren't able to get the PR working.

Deleted branch from rMITK MITK: feature/T30255-RenderWindowUtilityWidgets.

Deleted branch from rMITK MITK: feature/T30430-python-venv-check.

Deleted branch from rMITK MITK: feature/T29295-monai-tool-httplib.

I close this task as invalid. We were not able to reproduce this issue at all and we never heard of if by anyone else. Feel free to reopen the task if there's a reliable recipe for reproduction.