Okay, nice. Last question: You currently have both a PhenotypingRelease and a ClassificationCmdApps configuration. The apps of the latter one are also included in the former configuration. Is it fine to just go for PhenotypingRelease then at the cost of a little larger tarball as also the workbench application is included? @schererj

In T28302#220479, @gaoh wrote:

The normal WorkbenchRelease configuration should be even better suited for the future...

+1

In T28302#220475, @kislinsk wrote:

@gaoh

I noticed that the only plugins enabled in the "MitkVolume" configuration are the segmentation plugins. Do you explicitly want to have this "slim" version or is the official WorkbenchRelease configuration more sufficient?

Okay. Currently running the first test with the PhenotypingRelease configuration and tag set to v2021.02. So the file name will be automatically versioned and will appear at https://www.mitk.org/download/kaapana/phenotyping/ once the build succeeds.

I would like to have files versioned / with different names. If it's necessary to have a download link that doesn't change I can help with a script to create a "latest" link, had that for MITK nightlies back in the days

To all: Do you want to version files or do you want to simply override existing old installers when generating new ones (which happens with custom set revisions descriptions as done in a few docker files above)?

I noticed that the only plugins enabled in the "MitkVolume" configuration are the segmentation plugins. Do you explicitly want to have this "slim" version or is the official WorkbenchRelease configuration more sufficient?

In T28302#220185, @floca wrote:

And MITK volume (aka the normal workbench) uses the Release build with segmentation=ON

Maybe we should then just label it MITK Workbenches to avoid confusion and reduce (redundant) artefacts.

In T28311#220415, @gaoh wrote:

would be to give it the name of the Instance UID.

Understood, but thats not that easy yet, as the Instance UID is currently generated by DCMQI in the writing process. But that is something we should alter somewhen anyways, as we already need this UID within MITK.
So I guess we take one of the other choices as mitigation strategy.

In case of kaapana, the name is currently irrelevant: directly in the next operator, the dcm files are send to the PACs anyway and then the file is deleted.
What would make sense, regading the naming in the PACs and when downloading files, would be to give it the name of the Instance UID.

It is the "\" in the node name.

Nvidia AIAA WorkbenchRelease binaries are building or were already deployed.

It seems as if datanode->GetBoolProperty("binary", binary, renderer) inside mitkImageVtkMapper2D always results in binary being false. This might be true for our LabelSet images, but the properties view still shows the property binary as true, e.g. for segmentations created with the classic segmentation view.

so maybe a Regex is needed, or just a default file name..

Missing tags in the Seg, so it is an error in the file.

This should be resolved.

This should be resolved.

@neher is there a connection to T28053 ?

Duplicate of T28291

@neher is this still an issue? I think we have all the SEGs working now, or?

Deleted branch from rMPT MITK-ProjectTemplate: release/T28000-v2021.02.

Pushed new branch to rMPT MITK-ProjectTemplate: release/T28000-v2021.02.

Deleted branch from rMPT MITK-ProjectTemplate: release/T28000-v2021.01.

Deleted branch from rMITK MITK: bugfix/T28000-BumpDevelVersion.

Pushed new branch to rMITK MITK: bugfix/T28000-BumpDevelVersion.

Deleted branch from rMITK MITK: bugfix/T28000-BumpDevelVersion.

Deleted branch from rMITK MITK: release/T28000-v2021.02.

Pushed new branch to rMITK MITK: bugfix/T28000-BumpDevelVersion.

And MITK volume (aka the normal workbench) uses the Release build with segmentation=ON

Maybe we should then just label it MITK Workbenches to avoid confusion and reduce (redundant) artefacts.

In T28302#220080, @kalali wrote:

Following this, are there some requirements that need to be specified here T28280?

Ah so the idea is not to build it, but to directly use a CI binary.
So MITK flow uses:

# Generate Ninja build script for MITK to build a minimum configuration with apps in Release mode into MITK-superbuild directory
RUN cmake -G Ninja -S MITK -B MITK-superbuild
RUN cmake -S MITK -B MITK-superbuild -D CMAKE_BUILD_TYPE:STRING=Release -D BUILD_TESTING:BOOL=OFF -D MITK_BUILD_CONFIGURATION:STRING=FlowBenchSegmentationRelease -D MITK_CUSTOM_REVISION_DESC:STRING=MitkFlow
RUN cmake --build MITK-superbuild
RUN cmake --build MITK-superbuild/MITK-build --target package 
RUN mkdir /opt/final_package
RUN cp /opt/MITK-superbuild/MITK-build/MITK-MitkFlow-linux-x86_64.tar.gz /opt/final_package/MITK-MitkFlow-linux-x86_64.tar.gz

And MITK volume (aka the normal workbench) uses the Release build with segmentation=ON

For MITK-flow and MITK-volume I will switch to the new release (release/T28000-v2021.02). It was only on a develop branch, because there were some bug fixes, not yet in a master branch.
But now with the new release...