Make it do something #1

Closed thompson318 closed 4 years ago

In GitLab by @StephenThompson on Jan 24, 2019, 14:50

In GitLab by @StephenThompson on Jan 24, 2019, 15:10

mentioned in commit 272dc5d7ac89744548e73dd12f1b910491631f77

In GitLab by @StephenThompson on Jan 24, 2019, 17:04

mentioned in commit a7c41a01a56413b1ce1e14fc74bb3ca7d15763d1

In GitLab by @StephenThompson on Jan 25, 2019, 09:26

mentioned in commit 25be6cdbad1a81f59317b1e6a05eae8aac727255

In GitLab by @StephenThompson on Jan 25, 2019, 09:46

@ThomasDowrick @MattClarkson @MianAhmad On branch 1, there is ardavin01, which does what I want the demo to do. It tracks an Aruco tag and moves a VTK model around on it (nb. it needs branch 28 of ardavin to read vtp, I've just done a separate merge request for that). I think the demo shows a basic AR application coded with SNAPPY, but it is a mess. To do: Rewrite to use scikit-surgeryvtk? I only used ardavin because it was slightly easier to get running straight away, the demo should not really be based on hacking another application. Make a nicer 3D model for demo. Slides Order tea / coffee / biscuits

Anything else?

In GitLab by @MattClarkson on Jan 25, 2019, 09:55

Most important = cake and biscuits, as Sodexo sometimes complain of late orders.

Tom is refactoring Ardavin to use SNAPPY underneath. We had discussed whether Ardavin should ultimately become part of SmartLiver. While I think SmartLiver could support Ardavin use-cases, there will always be cases where each individual researchers needs their own UI in their own project. So, the UI layer will be project specific. For example, Eddie wanted to use Ardavin, but wants something simpler, and doesn't want to wait until SmartLiver is reworked.

In parallel, BARD will be re-written, and have specific use-cases for students, and could be a general purpose demo thingy.

So, SNAPPY demos could live in all of the above, or in its own dedicated project, as you have done here.

So, in the long run, Id have thought the idea was to end up with lots of lively active projects, and using SNAPPY underneath. There is a risk that each end-user project will tend to diverge, or just hack away on their own, without contributing code back to SNAPPY. But maybe we just need to evangelise more, and use the Slack Channel so people know what we do across each project.

In GitLab by @ThomasDowrick on Jan 29, 2019, 08:47

I've done some refactoring to get the aruco demo to work with sksurgery, in branch https://weisslab.cs.ucl.ac.uk/WEISS/SoftwareRepositories/SNAPPY/SNAPPYTutorial01/tree/2-tom. _arucoapp.py will run the app.

I have implemented a OverlayBaseApp class in scikit-surgeryvtk.widgets. This is itself a refactor of the MonoViewer class from ardavin. Basically, OverlayBaseApp can set up the vtk_overlay_window, model overlay, and a QTimer to update the window.

When a user inherits from OverlayBaseApp, they implement their own update() function to do whatever they want. For ardavin, this is just re-rendering the screen; for the Aruco app it scans for tags, then re renders.

I'm waiting for CI to pass, then I will tag a new release. @StephenThompson we should meet today to check if there is anything else we need to prepare for Thursday.

In GitLab by @MattClarkson on Jan 29, 2019, 08:54

So, I appreciate the short-term goal to deliver the tutorial, but after tutorial, will such a demo app liver in scikit-surgeryutils? We will also have the scikit-surgeryardavinci project. Both can use SNAPPY underneath, as will SmartLiver, but will we neeed to merge anything?

In GitLab by @MattClarkson on Jan 29, 2019, 08:57

Or will this project live-on, and become its own thing in its own right?

In GitLab by @ThomasDowrick on Jan 29, 2019, 09:02

I imagine we can move this demo to surgeryutils once we're happy it works well. We already have BARD as a standalone project, so probably not necessary to make this standalone too.