I agree, OpenIGTLink as extension name sounds good (maybe SlicerOpenIGTLink? but I think OpenIGTLink is enough). Repository name should be SlicerOpenIGTLink to make it clear in GitHub that this is a Slicer extension.
It would build OpenIGTLink and OpenIGTLinkIO libraries using superbuild.
I will make a repo in https://github.com/openigtlink, which i am currently maintaining and have full access to it.
Once the video codec is added into the Slicer core, OpenIGTLink library will be able to link to the codec libraries and video streaming would be available in Slicer.
SlicerVideoCodec could be a solution. The OpenH264 codec provides a link for binary download:
So we should be able to trigger the download in the SlicerVideoCodec extension.
Regarding the other codecs, i am not sure what would be the best method to integrate into slicer.
We should probably add an abstract interface for video compression (and maybe also a trivial uncompressed storage class) into Slicer core and implement interface to register/unregister codecs, similarly to displayable managers.
From a user perspective I think there may be situations where OpenIGTLink is essential and expected despite access to the extension server being limited. Would it make sense to package a Slicer binary with “core extensions” along with a Slicer “Lite” without any?
There are two sides of this issue. If we don’t put OpenIGTLinkIF into an extension, it would be hard to add compressed video support. Not having compressed video is a blocking issue in many projects. On the other hand installing OpenIGTLinkIF from the extension manager or building a custom Slicer packaged with it already is not a impossible thing to do. For the sake of compressed video, I think we should go ahead with the extension plan.
I just create a pull request for SlicerOpenIGTLink extension.
As the codec is not available in the Slicer core yet, in the extension, VP9 codec is super-built for linux/Mac, however, it is not easy to superbuild VP9 in windows platform, so i trigger the download of binary file from this repository for the window platform:
Currently i only uploaded the binary file compiled with “Visual Studio 14 2015”. I think Slicer nightly build is using “Visual Studio 12 2013”, am i right? So in windows build Slicer, video streaming will not be available.
unfortunately, i didn’t find binary distributions from webmproject, would be nice if you guys find binary distrubution for other compilers.
I just pull another request to remove the OpenIGTLink from the core. I test the build on my Mac machine, it seems working, would be great if you have a double check.
The build of OpenIGTLinkIF extension failed unfortunately: http://slicer.cdash.org/viewBuildError.php?buildid=1181930
The reason is the version of python interpreter. To build VP9, i current set the python version to be 2.7, however, the slicer build system only have 2.6.5 installed. Please refer the above link for more information.
Regarding the windows build, the Slicer is building the extension using “Visual Studio 12 2013 Win64”, http://slicer.cdash.org/buildSummary.php?buildid=1181801
So I think once we have the VP9 library available, we should able to make the build successful. I am working with Andras in this issue. Hopefully will fix it soon.
the build of YASM was successful. however, when i use the yasm to build VP9, the following error occurred: yasm: FATAL: could not load standard modules
Do you possible know the solution to this problem?
I just checked the Slicer nightly build of OpenIGTLinkIF module.
It failed on building vp9 codec. the reason is the compiler “Clang 3.1.0” is too old, do you guys have any suggestion?
I know that the compiler will be updated on Windows from VS2013 to VS2015 for nightly builds within a couple of days. I’m not sure if compiler update is planned for MacOSX as well (we used an old build toolset for compatibility with old systems).
Great!
I made the vp9 binaries under vs 2015 for 32 bit and 64 bit already. So in the next days we could have the new OpenIGTLink in the nightly build slicer for windows system.
Also the clang version in MacOSX is sufficient for VP9 built. I am looking forward to see the build result!