# Meetings CEMRG-Dev

## 8/05/24
Louise
+ running it all from within Docker
+ Just need to get the GUI running
+ Other works to help automated builds and local builds
+ Alter the MITK-superbuild
+ Building ITK and Eigen on their own
+ Extra instructions should be the same on mac and linux

Jost
+ Worked on the other project - Release
+ Has been working to Qt5.15
+ 5.15 pre declares classes instead of importing them
+ build on top of MITK 2018 was painful to get running
+ Would require to upgrade to MITK2021 (or higher)
+ Do not use Jost's time patching for MITK 2018
+ Instead, start working on the upgrade
+ Check the few commits on the 2021 branch - Start here!
+ Start through 2022 branch
+ Jost will start with the commits from the OpenHeartDev feature/mitk-upgrade branch
+ JA will check for commits on his forked repo and try to lay a foundation for them for Jost

Jost - post call
Jost and I discovered a bunch of things about the feature/mitk-upgrade branch in both the official repository and in my fork. Here's the details:
+ The OpenHeartDevelopers (OHDev) branch is to build under MITK 2021.02 and mine is for MITK 2022.10
+ The OHDev branch differs from the master branch in a few spots (like 13 commits), these look mostly straigtforward to go through manually and make them fit
+ My fork of the branch has some issues in later commits, as I merged the development branch and took out a lot of the changes necessary for the compilation with MITK 2022.

The tasks:
+ Merge main branch into feature/mitk-upgrade
+ Looks like it's mostly straightforward
+ Compare the OHD/feature/mitk-upgrade with my commit 7476481

### Rebasing feature/mitk-upgrade

+ Gone through rebasing with Jost, which looked pretty straightforward.
+ We chose the rebase option, where the `feature/mitk-upgrades` branch was updated to contain the newest development changes **and** the upgrade bits we had from the #7476481 commit
+ Most changes were straightforward. The problems will come with the atrial fibres and newer things

## 15/05/24

### Jost's summary:
+ PR in draft mode in github.
+ Added a few more commits to fix deprecation warnings
+ Arm Mac issues:
+ VTK hdf5
+ VMTK remove tests - it's logged as an issue on gihtub
+ Another

### Louise
+ Louise's manual downloading of libraries did not work
+ Docker takes a long time, which is promising...
+ Got an out of memory issue on Monday
+ I will try to run it on my machine at work

### MIRTK
Some questions should be answered to outline the needs for this part of the project:
+ Where is it used? - Find a list of all the functions in the `CemrgCommandLine` class and then a list of where are those used in the plugins.
+ Do we have a clear replacement for each of the functionalities?
+ Is there anything that is going to be particularlly difficult.
+ Do we have test cases for all these things we'll be replacing?
+ Is there a paper where we could have on this thing? - Maybe the videos?

Jost - it would be good to get the giant MITK upgrade PR first.
PR works on intel mac, I'll test it on linux and windows.

#### Tasks
- [ ] MIRTK questions (above)
- [ ] Install upgraded branch on Windows (use Qt 5.15.13)
- Moved up
- [X] Get the Dockerfile from Louise and run it
- Managed to run and share it before
- [X] Support Jost's arm mac problem
- Was not able to help

# 30/05/24

## MIRTK

- [X] Where is it used (at the bottom).
- Registration (rigid, affine, freeform)
- Transformation (images)
- Transformation (points)
- Creating surface meshes
- Opening
- Meshing
- Smooth mesh
- info - not actually used
- init-dof `CemrgCommandLine::ExecuteSimpleTranslation`
- resample-image `CemrgCommandLine::ExecuteResamplingOnNifti`
- Do we have a clear replacement?
- Registration and transformation - search in MITK
- MITK should have the image registration and transformation. It is not clear transforming pointsets will be that easy.
- Surface meshes - We have it `CemrgCommonUtils::ExtractSurfaceFromSegmentation`
- Slight problem MIRTK produces meshes where the points are _flipped_ to [-x, -y, z]. We use a snippet of code to flip them back to the right coordinates. (List them).
- Info is not needed, we can cut it out
- `init-dof` - not needed, as it is used to translate a mesh to align with another. This can be achieved by more straightforward code.
- `resample-image` - We do use it, we have `CemrgCommonUtils::IsoImageResampleReorient`, which might be a good candidate for replacing it.

+ Is there anything that is going to be particularlly difficult. From easiest to hardest:
1. Creating surface meshes - should be easiest because the code is already there. Options
2. `resample-image` - Seems to have a good candidate for replacement already in the code.
3. Registration/transformation of images - need to dig a bit into MITK's code.
4. Transformation of meshes.
+ Do we have test cases for all these things we'll be replacing?
+ List of tests we have at the moment (describe each one)
+ ExecuteSurf
+ ExecuteRegistration
+ ExecuteTransformation
+ ExecuteSimpleTranslation
+ ExecuteTracking
+ ExecuteApplying
+ Is it worth throwing some real data cases (integration cases)?
+ Consider data that can be put publicly available
+ Is is worth having a separate repository for all these test cases?
+ Is there a paper where we could have on this thing? - Maybe the videos?
+ Is there like a real use case for these, so we can follow through the steps and make sure things do a good job?
+ **Share SOPs and youtube videos.**
+ **CemrgApp paper**
+ Technical paper on MIRTK registration code?

#

## Updates on current building work
+ PR for `feature/upgrade-mitk` branch.
+ Our VMTK is a fork not of the original VMTK. Should we try to reconcile with the original VMTK.
+ VMTK have not released but has been getting commits and changes.
+ Definitely been active.

| File | Lines | Function | Description |
| -------- | -------- | -------- | -------- |
| `AtrialFibresView.cpp` | `476, 677, 732` | `ExecuteSurf` | Create Mesh |
| `AtrialFibresView.cpp` | `2337` | `ExecuteRegistration` | Registration |
| `AtrialFibresView.cpp` | `2338` | `ExecuteTransformation` | Transform Image |
| `MmcwView.cpp` | `585` | `ExecuteSurf` | Create Mesh |
| `MmcwView.cpp` | `729` | `ExecuteTracking` | Registration over many frames |
| `MmcwView.cpp` | `815` | `ExecuteApplying` | Transformation over many frames |
| `MmeasurementView.cpp` | `570` | `ExecuteTracking` | Registration over many frames |
| `MmeasurementView.cpp` | `674` | `ExecuteApplying` | Transformation over many frames |
| `AtrialScarClipperView.cpp` | `213` | `ExecuteSurf` | Create Meshes |
| `AtrialScarView.cpp` | `507, 1021` | `ExecuteRegistration` | Registration |
| `AtrialScarView.cpp` | `508, 1085` | `ExecuteTransformation` | Transform Image |
| `AtrialScarView.cpp` | `543, 665, 696, 1200` | `ExecuteSurf` | Create Meshes |
| `AtrialScarView.cpp` | `543, 665, 696` | `ExecuteSurf` | Create Meshes |
| `ScarCalculationsView.cpp` | `1058` | `ExecuteSimpleTranslation` | Get Translation between meshes |
| `ScarCalculationsView.cpp` | `1064` | `ExecuteTransformationOnPoints` | Transformation on Points |

# 12/06/24 - Updates

## Jost
+ Rebasing the upgrade to MITK 22.10 on top of the development branch
+ Pull request (PR) made
+ Eliminated some deprecation warnings
+ Louise + José reviewed
+ Merged on Monday -> Now on development branch!
+ Updated wiki page with the build instructions!!
+ macOS (intel) is tested and should be working
+ linux some issues - Louise's update
+ Building on ARM macs?
+ Some issue
+ Can remove in [VMTK - new branch](https://github.com/OpenHeartDevelopers/vmtk/tree/support-for-mitk-v2022.10-qt15)
+ Looking into replacing MIRTK. Difficulties:
+ Limited knowledge of where MIRTK replacements would be good
+ would be good to do some pair programming to get started
+ would be good to have a starting point

## Louise
+ Application is building but some errors.
+ CemrgApp not loading at all.
+ `free(): invalid pointer` is always present
+ `QSocketNotifier: Can only be used with threads started with QThread` MITK and Cemrg on Wayland, disappears if using xorg
+ `Preloading library "liborg_mitk_gui_qt_common"...` Cemrg but not MITK. Jose says can ignore this

+ This might be a problem that's coming from MITK
+ MITK errors:
+ might be the window management solution of windows (X11 removes one of the errors, Wayland - error)
+ Invalid pointer somewhere
+ Checking all the dependencies on it

## José questions about update
+ RE the PR: Development branches and other projects (e.g. fourch):
+ Move project slowly into the main repository (new branch, slowly move changes into it)
+ RE update on linux:
+ Louise using 22.04 - Jose try on 20.04
+ [Instructions to build CemrgApp](https://github.com/OpenHeartDevelopers/CemrgApp/wiki/Build-CemrgApp-from-Scratch)
+ Running the MitkWorkbench
+ Bei will be getting acquainted to the platform, trying to build CemrgApp on his arm mac.
+ Consider checking the release notes of newer MITKs to see which dependencies were
+ There is an updated CTK dependency in the nightly builds of MITK: https://phabricator.mitk.org/w/mitk/changelog/2024.05/ BUT:
+ it’s not yet in a release
+ that will also require a Qt6 upgrade
+ MITK changelogs: https://phabricator.mitk.org/w/mitk/changelog

### Tasks
+ Louise - continue getting as far as possible before 15/06/24 on the linux build on the develoment branch
+ Louise - send some resources to Jost re: image processing
+ Jose - build on linux 20.04
+ Jose - arrange a quick meeting (or meetings) with Jost (and Bei)
+ Bei - start from building instructions on his arm mac
+ Jost - start working on MIRTK (with help from Jose/Louise)

# 04/07/24
## Louise
+ Building development branch and runnign on linux
+ Version of Qt is slightly different than mac's
+ Tried using an older version of gcc
+ The only one working so far:
+ slightly older Qt (5.12) - working on MITK
+ but CemrgApp **does not build**
+ _we'll get where the CemrgApp build is failing_

### Notes from builds
MTIK 2022.10 - not touched
Linux:
- Qt 5.12.10 CemrgApp does not build
- Qt 5.15.2 CemrgApp does not launch
MacOS
- Qt 5.15.13 downloaded from homebrew (as per instructions)

## Jost
+ José shared some data and examples for the surface
+ Jost brought a demo showcasing MIRTK vs their method used
+ New implementation `CemrgCommmonUtils::ExtractSurfaceFromSegmentation`
+ MITK's close-image is still used, then using internal tool.
+ Surfaces do not match red areas of the segmentation (probably because of `CemrgCommonUtils::LoadVTK`)
+ Mesh gets created quite quickly!
+ Orod's comments:
+ We should have unit tests
+ Make sure the meshes are not super high-resolution (maybe check with meshtool query quality?)
+ Close image should be easily swapped for ITK methods (José can help here!)
+ Moving forward to using VTK .vtp instead of .vtk?
+ Jost will send outputs to José to check mesh quality

### RE: changing VTK outputs
+ Maybe consider this as a separate bit of work, maybe after Louise can do this after dealing with the building?
+ José can check about VTK Legacy for next week

## Keep an eye on end date!
Start wrapping things up!!!!

# 09/07/24
## Extract surface - replacing MIRTK. Decimation tests
After the tests, we would like to keep the decimation parameter at 0.0 to preserve the size of the tirangles more or less equal.

The default was set to 0.5. We will hard code that to zero.

### Current state
There is a boolean in the `CemrgCommandLine::ExecuteSurf` to switch between MIRTK and using our own `CemrgCommonUtils::ExtractSurfaceFromSegmentation`.

### Smooth/blur/threshold parameters of the extract surface
It would be a good idea for José and Bei to checkout `feature/replaceMIRTK` branch, build it and tweak values that might work for the smoothness.
+ We can check this after confirming Louise's branch works (Monday 15/07)
+ Jost can check how does the new extract surface method works **without** the `close-image` function.

### Data file format (savung in VTK Legacy 4.2)
Jost found a way to patch the `vtkDataWriter` file to save automatically to VTK Legacy 4.2. We could do this, patching this one line when building. See [this post](https://github.com/Kitware/VTK/blob/285daeedd58eb890cb90d6e907d822eea3d2d092/IO/Legacy/vtkDataWriter.cxx#L89)

## Building in Linux
It seems Louise's `feature/qt-5-12-ubuntu` branch works and can build CemrgApp under Qt 5.12.10.

Louise's changes are minimal.

+ Jost will check Louise's branch builds. If it does, then Louise will
+ make a PR from `feature/qt-5-12-ubuntu` to `development`
+ update wiki instructions to show linux=5.12, macOS=5.15
+ update github actions yaml files to reflect these changes.

### Possible next steps for Louise
Maybe Louise could move into github actions?
+ Github actions are currently running, but failing
+ Failing when downloading the precompiled build folder
+ Error seems to be 'No space left on the device' (14Gb) space on the runners, see [this comment](https://github.com/OpenHeartDevelopers/CemrgApp/pull/79#issuecomment-2157997637)
+ Build instructions might work, but we need to create the prebuilds

## Tasks and next steps
+ José:
+ Check decimation files to see if they're compatible with VTK Legacy 4.2
+ Check with Bei branch `feature/replaceMIRTK` to find values for the extract surface parameters (blur, smooth, threshold) that work well.

+ Jost:
+ Checkout and build branch `feature/qt-5-12-ubuntu`. Make sure it builds with no problem under their Qt15 build
+ Extract surface replacement:
+ Skip the `close-image` function and send over a file
+ See how hard it would be to use pointers `mitk::Image/mitk::Surface` instead of writing/reading to disk

+ Louise:
+ Once Jost confirms branch works on their setup:
+ making a PR from `feature/qt-5-12-ubuntu` to `development`
+ update wiki instructions to show versions for linux and macOS
+ It would be good to move to having github actions working again
+ First step would be to update the appropriate yaml files
+ _NOTE: There seems to be a problem when downloading the prebuilds, but we'll need to replace them anyway._
+ Create prebuild folders for linux and macOS, current ones are for MITK 2018.04.2
+ We can discuss this later

# 30/07/2024
## Mini-agenda
+ Wrapping up
+ Updates
+ Github actions

## Wrapping up stuff
+ Chat to James: There's a chance to finish off and not be super strict with the times
+ Louise happy to continue
+ Jost happy to continue
+ We would like to have an end point
+ Louise: Github actions working
+ Jost: getting one or more of the MIRTK functions gone from CemrgApp, depending on how big/involved they may be.

## MIRTK replacement
+ Perhaps we could find a way to replace the pair `ExecuteSurf (Rigid) + ExecuteTransformation`
+ Another idea would be to only create the rigid registration displacement file (DOF)
+ when a rigid registration is created, two files would be generated: MIRTK's and our new one.

#### tasks
+ Jose to show:
+ where are registrations in the code
+ how to create a registration file
+ how to read MIRTK's DOF file with the `info`

## Updates
### Jost - ExecuteSurf (feature/replaceMIRTK)
On the PR:
+ Options for checks CemrgApp crashes when wrong values are set for the surfing parameters:
+ Maybe sanitise the inputs on the Qt side?
+ We would prefer to do the input checks on the UI side.
+ Two open questions:
+ Default values are OK to use (blur/threshold/smooth)

#### Task
+ Bei+Jose: feature/replaceMIRTK - create a grid search of parameters (blur/threshold/smooth) and figure better values as they might not be the same as MIRTK!

### Louise - Github actions
+ Issues accessing KCL OneDrive - we cannot download our prebuilds from our github actions
+ Github actions caching only stays valid for ten days
+ If this is 10 days inactivity (instead of 10 days absolute age), could work around this by running a scheduled action [every 9 days](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule)
+ Something similar to the OneDrive solution.
+ James put in touch with Chris (Imperial RSE).
+ AWS solution?
+ AWS
+ Education (going through Imperial)
+ Ask Steve, but we need an estimate quote (or Imperial or Turing?)

### KCL RSE Meeting with RSE Imperial
> 1/Aug/24. Chris Cave-Ayland from IC's RSE
+ CEMRG moving to Imperial after setting up the RSE with KCL
+ Rethink how to do our github actions. Where to host part-built projects and prebuilds
+ Chris is from the equivalent RSE for Imperial.

CemrgApp project bolt on project MITK.
Before, we had pre-builds, compiled them and had it up on sharepoint.

Github caching abilities has a 10Gb for their caching.

Is there a sensible place at Imperial to keep these files and host them in there.

Imperial does not have sharing availability.
Options:
+ **Box** (like dropbox), which could dissapear after 2026
+ Supports annonimous access etc
+ Me or Steve might need access to it. Alternatively, we could try a _roll account_, which has a chain (in case the holder of the account leaves)
+ Team access to share, review and share files
+ Setup **Azure** blob storage
+ Imperial can setup a subscription agains an account code Steve might have access to, given there's resources for it.
+ Pay for Git LFS or something else
+ Access for github packages on the Imperial github account... but it might be a messy sollution.

> We agreed the best option is to get a Box role account. This might take longer, so we'll start with a personal under José's account and we'll move from there.

# 7/8/24
+ Updates
+ Louise's github actions / José update on storage
+ Jost's ExecuteSurf parameters (José checks on parameters)
+ Bei starting a new plugin, what's the best way to go about it

## Updates
### Louise
+ Set up Box account. Upload size issues for the prebuilds
+ Issues with uploading
+ Jose will try and fix the storage uploading on his side
+ Build options explored
+ MITK-Data not necessary on the prebuilds
+ MITK-Superbuild was 7Gb, Louise got it down to 1.3Gb (`CMAKE_BUILD_TYPE=Release`, `BUILD_TESTING=OFF`)
+ Release or Debug options
+ BUILD_TESTING variable relevant to us?
+ José: These two, we have to go through Onur's implementation of the tests.
+ Some of the dependencies have gotten bigger (VTK)
+ VMTK gets lost

José: Get back to Louise RE: Box storage.

### Jost
+ José to give some parameters for the threshold, blur, smooth.
+ José to review PR and sign it off.

Another open question on the PR: Small offset on the generated surface mesh
+ José to check whether offset is created by the parameters or by something else.
+ Confirm the following parameters and check offset of these compared to the original segmentation
+ threshold=0.5
+ blur=0.8
+ smooth=3
+ decimation=0
+ Check with Orod

### Bei
Bei is trying to
+ If bulk of the work is in a separate folder in the Plugins folder, this should not cause a lot of problems
+ If some work is done on the `CemrgCommonUtils` and `CemrgCommandLine`, classes that are done often:
+ Chat on slack to see if there's things to coordinate
+ If non-trivial changes need to happen, like putting a default value or adding a parameter to a function, think of making a separate, smaller PR that we can merge in the development branch.
+ Think of things that could stand on their own
+ and that would not need to wait too long
+ Bei's work will be split into
+ Core CemrgApp work
+ His own plugin

TASKS:
+ José:
+ work with Louise:
+ Get storage sorted (uploading and upload limits)
+ work with Jost:
+ Finalise parameters on ExecuteSurf
+ Finding out about the offset meshes
+ Finalising the PR
+ Plan/chat about the next function to replace in MIRTK (wait)
+ work with Bei:
+ work with the branch structure and getting Bei's plugin into CemrgApp