I think the points are wrong ordered. First we should clarify (management decission) that it should go into a release/open-source and if tobi has the time to backing the process.
If this is cleare, the technical assesement of what has to be done to have it in master and under CI/testing can be evaluated/quantified.

@norajitr maybe a bit more background on the ticket for you:

On the Kaapana / JIP side there were issues with keeping shapemodel-based segmentation "alive" with newer versions. In addition, it was unclear how we could distribute it and what may be concerns or obstacles to putting it in the public version. Since we advertise it at the same time, and also use it often in demos etc. ideally it would be integrated in some automated build process for publicly accesible code, but of course non-public would be possible as well, but otherwise it will be difficult to maintain. Also the question oft trained models / weights, which "license" exists etc. would be something we have to resolve.

As @floca said at some point we will have do decide if we want it and how much to invest, but maybe you could also comment on your perspective, at least for open sourcing the code and the availability of models that could potentially be shared as well.

I like the idea of open sourcing the code and making models available as well. If we can roughly clarify how the workload/hurdles would look like in reality, I can also imagine to back the process. Licensing and publication of trained models arises more often lately, thus any solution here can probably also be fruitful for similar endeavors.

The topic came up in the Kaapana tech meeting again, because the current situation is causing problems there.

The shape model code is not open source, and the code to build the shape model container is not properly available in the non-open source internal Kaapana repo as well.

Kaapana is open-source, the shape models are not open source, so Kaapana can't be built properly from scratch. Moving the shape models to the non-open source part (e.g. just for JIP partners) is no solution as well since the model container doesn't build.

Three solutions came up, and we should decide soon:

1. Shape models are made open source, Kaapana integrates them
2. Shape models are moved to "internal" Kaapana and the build is fixed soon'ish so we can keep them for partners
3. Shape models are removed completely from Kaapana integration for now

I think 2. would be a good intermediate step but it would also require work from @norajitr to help getting a stable build of the shape mode code (internal) and a way of providing the models to the build system

@k656s could you please add/correct if necessary and maybe link this to relevant Kaapana tickets if any

Is this ticket then realy priority "wishlist"? (Stefan put it there because it was not triaged at all) A solution (what ever it maybe) seems to be more relevant to Kaapana then just wishlist.

After talking with Marco, I have looked for the whereabouts of dockerfiles (liver-mri and multiorgan-seg), working commits for MITK (a0dedffb74d) and for MBI-builds (56ad5bf7064) and trained models. @schererj: I sent you this information via email in October 2020, and shared the trained models on the network drives. Can you confirm? What information do you need to keep the shape models operational?

@norajitr thanks for the follow up. Could you attach the two (?) Dockerfiles here and post the network drive path? Maybe someone else from Kaapana (internal) could have a look then, too.

@schererj : any comments from you are still appreciated of course ;)

The problem is the MBI branch, which is afaik not public.
If there is a working Dockerfile, which can be publicly build, I'm happy to include it.
Additionally the models need to be put somewhere to be downloaded (also public in this case).
Hope this helps.

Thanks @schererj , maybe one information was missing: as a first step we thought about making this build-able internally, so as part of the Kaapana/Dcipher-internal repo (option 2 in my comment above from March 25th)

Ok, but this makes not a big difference, right?
Here's what I think would be good for us:

• A single Dockerfile build-able without any local files
• The needed source-code should be downloaded via a direct git clone within the Dockerfile
• Internal usage would allow to pass credentials as build-args to git
• Models should be downloaded via curl during the build-process as well
• There should be two stages:
  1. Download and build source-code + download and unzip models
  2. Execution environment (incl. the models) - but without build dependencies, build tree etc

So for me the only difference between "internal" and "public" would be restricted access to the models and the git source code (by providing credentials during the build-process).

Thanks. I think restricted access to code and models makes a big difference in the sense of preparatory work, code cleaning. model licensing etc.. ;) So that's why we thought it would be good first step to resolve all technical issues. Moving code and models to a public location would be another thing then.

@norajitr could you attach the current Dockerfile here and post a network drive path to the models please?

Hey Marco, I had uploaded the models there back in the days:

E132-Projekte\Old\For_JIP_from_Tobi\shapemodels

+ let's try with the attached Dockerfile.