This is really nice to read your message and your idea of wrapping Stone in Go.
The code and comments looks well organised.
Thanks! Note that we are currently working on providing much more documentation (notably a high-level guide of the architecture, and Doxygen documentation for each class).
Here are my assumptions / questions. It woudl be great if someone can tell me if i am on the wrong track here.
- We dont need the web UI at all
This assumption is clearly OK if you are focusing on scientific computations on the top of MRI/fMRI images. In such a context, you probably need a local, high-performance application running on a dedicated computer (and not teleradiology solutions). Such desktop applications are clearly the field of applications of both VTK and the Stone of Orthanc.
- There are various manufacturers because we get images from all over the world.
The answer to this part of the problem is the fact that Stone is built on the top of Orthanc. But, Orthanc is free and open-source software, making it freely available to any hospital/manufacturer in the world. This means that Stone will bring native integration with a professional DICOM server (Orthanc) that can be tuned/fixed for any setup, providing good compatibility with any proprietary imaging ecosystem.
- Has anyone started a golang wrapper ? i realyl doubt it.
To the best of my knowledge, this is indeed not the case.
I’m afraid I personnally don’t know much about golang, but note that wrapping a C++ library such as Stone in Go seems to be challenging:
You essentially have two possibilities of achieving this goal:
- The SWIG project seems to provide C++ wrappers for Go, so you could try and wrap Stone using SWIG. As the API of Stone does not make use of the complex constructions of C++, this should be definitely possible (though I have not tried it by myself). We would of course love to hear your feedback if you follow this path.
- As an alternative, you could write a plain C library over Stone that selects the primitives you need for your application. In contrast to C++, golang indeed provides built-in support for such C libraries.
- Lots of the framework sems to have a focus on widgets, etc, which we dont need at all.
This will be made clearer in the high-level documentation, but the “IWidget” concept of Stone does not currently provide high-level GUI components (such as buttons, scrollbars or text editing zones). Such GUI components must be provided by the windowing environment (e.g. Qt, Windows Forms, wxWidgets, cocoa…).
A “IWidget” is simply a rectangular area over the rendering buffer. In turn, this rendering buffer (known as a “IViewport” in Stone) can be embedded into any windowing environment. Currently, Stone of Orthanc only uses this “IWidget” concept to create horizontal or vertical layouts of 2D/3D scenes. One could use this concept to create higher-level GUI components, but this is definitely not the topic of Stone at the time being.
I hope this answers at least some of your questions,