Dear all,

Has anyone succesfully installed the bioimage30 suite on the Neurodebian VM? Any help (see below) is greatly appreciated!


I would like to use the newly-published motion correction for doing RtfMRI, and am testing whether I can get it to run in my lab. When I try to do the instruction however, it fails because all the paths in setpaths.sh need to be fixed (they are still according to some older settings), and I seem to miss several packages (and nowhere is there a list of what I need to install to get it running). But maybe BioImageSuite is totally self-contained and I am doing something wrong.

After fixing the setpaths.sh, and installing tcl, tcllib, cmake and some other packages, when I try to run bis.tcl, I now get  this:
Error in startup script: couldn't load file
"/usr/local/bioimagesuite30/lib/libvtkpxCommonTCL.so":
/usr/local/bioimagesuite30/lib/libvtkpxCommonTCL.so: wrong ELF class:
ELFCLASS32
while executing
"load $libname  "
(procedure "LoadLibrary" line 54)
invoked from within
"LoadLibrary [ lindex $librarylist $i ] "" 0"
(procedure "LoadLibraries" line 4)
invoked from within
"LoadLibraries $vtkpxlibrarylist"
(procedure "::pxtclvtkpxcontrib::LoadAll" line 7)
invoked from within
"::pxtclvtkpxcontrib::LoadAll"
invoked from within
"if { $doload == 1 } {
::pxtclvtkpxcontrib::LoadAll
}"
(file "/usr/local/bioimagesuite30/main/../base/vtkpxcontrib.tcl" line 501)
invoked from within
"source /usr/local/bioimagesuite30/main/../base/vtkpxcontrib.tcl"
("package ifneeded vtkpxcontrib 1.2" script)
invoked from within
"package.orig require vtkpxcontrib 1.0"
("eval" body line 1)
invoked from within
"eval package.orig $args"
(procedure "package" line 2)
invoked from within
"package require vtkpxcontrib 1.0"
(file "/usr/local/bioimagesuite30/main/bis.tcl" line 35)

Johan,

This is going to be a bit messy though should be doable. Let's take the discussion offline and then once we have a recipe we can post this online. We have only tested this on CentOS. Please sent me a direct e-mail (xenophon dot Papademetris at yale dot edu) and I will put you in touch with the person who did most of this work. We have done installations of this at a couple of sites outside of Yale and it takes a little work to get done right.

Thanks

Xenios

I would appreciate if indeed such a recipe was cooked and shared -- it could become feasible to work out a proper packaging to be distributed from neuroDebian and possibly Debian proper ;-)

on my quick attempt to build from sources I have ran into missing source files (from provided half-year old bioimagesuite-32_0b1_13_Jun_2012_src.zip):

novo:~/deb/perspect/bioimagesuite/bioimagesuite32_0b1_src
$> find -iname vtkbisMySQLDatabase.cpp
$> grep -r vtkbisMySQLDatabase.cpp
database/CMakeLists.txt:vtkbisMySQLDatabase.cpp
build/cppfilelist.tcl:database/vtkbisMySQLDatabase.cpp

is there a newer sources snapshot? or may be some public VCS?

just for a reference: filed another related bug in Debian: http://bugs.debian.org/cgi-bin/bugreport...

We will create a neurodebian vm and get this figured out in the next few days.

Xenios

Dear all,

I downloaded all the binaries for linux, for 64-bit and for 32-bit, from 2011 and 2012:

bioimagesuite-30_1_17_Mar_2011-Linux-g++34-i386-complete.sh
bioimagesuite-30_1_17_Mar_2011-Linux-g++-x86_64-complete.sh
bioimagesuite-32_0b1_13_Jun_2012-Linux-g++34-i386-complete.sh
bioimagesuite-32_0b1_13_Jun_2012-Linux-g++-x86_64-complete.sh

This last package is 281 megs, while the other three packages are all about 100 megs. What's the difference between the latest 64-bit version and the previous one?

Also, I tried to install the 32-bit 2011 and 2012 version on the 32-bit Neurodebian BM, and the same for the 64-bit version as well. Installing 32-bit versions of Bioimagesuite on 64-bit VM machines doesn't work.

BIS 2011 32-bit on the 32-bit Debian VM works well, you just need to link the libhistory.so
BIS 2011 64-bit on the 64-bit Debian VM works well, you just need to link the libhistory.so
BIS 2012 32-bit on the 32-bit Debian VM works well, you just need to link the libhistory.so

BIS 2012 64-bit on the 64-bit Debian WM doesn't work, on running bis.tcl it gives the following (an IWidgets issue):

Application initialization failed: Can't find a usable init.tcl in the following directories:
/usr/local/bioimagesuite3_base64/tcl84/lib/tcl8.4 /usr/share/bioimagesuite3_base64/vtk52/lib/tcl8.4 /usr/share/bioimagesuite3_base64/lib/tcl8.4 /usr/share/bioimagesuite3_base64/vtk52/library /usr/share/bioimagesuite3_base64/library /usr/share/bioimagesuite3_base64/tcl8.4.19/library /usr/share/tcl8.4.19/library /usr/local/bioimagesuite3_base64/tcl84/lib/tcl8.4

This probably means that Tcl wasn't installed properly.
Error in startup script: can't find package Iwidgets
while executing
"package require Iwidgets "
(file "/usr/share/bioimagesuite32/main/bis.tcl" line 45)
So there is probably something

I haven't tried compiling from source yet!

Johan,

I am beginning to install neurodebian on a virtual machine here ... I should be able to generate a neurodebian package for you in the next day or so. Do you have a preference for 64-bit vs 32-bit (I am assuming 64-bit unless I hear otherwise).

Xenios

Johan,

OK. I have a compiled 64-bit version on Neurodebian 64 vm. The only catch that I had to go through (other than install things like vtk-devel, gdcm-devel insighttoolkit3 etc.) was compiling openigtlink from source as the Debian package does not include the header files (In any event we use a "weird" version of this that we checked out from the source repo at some point and never tested an update). On Debian/Ubuntu BioImage Suite will compile just fine with the debian versions of all these packages so (other than for OpenIGTLink) we don't need to use the bioimagesuite3_base stuff. (I can also make available the source that we used for openigtlink if anybody wants it but since we compile this static it is not really needed to run the binary package.)

I have a package done for you to install and will sent you a link via private message to debug this before making it publicly available,

Xenios

FWIW we are providing pre-created virtual appliances for both 32bit and 64bit: http://neuro.debian.net/vm.html  so they just need to be imported -- nothing to install per se ;-)

I am a bit confused about OpenIGTLink ... since headers seems to be provided by libopenigtlink1-dev just fine (or is something missing). what version were you aiming of that library?

would you happen to have a log of such a build ? (e.g. I usually for such cases either run screen with logging on, or this little wrapper around "script" command: http://git.onerussian.com/?p=etc/zsh.git... )

have you ever considered wrapping up a proper Debian source package?? if build works for you just fine with existing versions and since you are using cmake -- it should be quite easy.  Here are few examples of different levels of "customization" which rely on cmake -- look at rules and controls files in particular

http://anonscm.debian.org/gitweb/?p=pkg-...
http://anonscm.debian.org/gitweb/?p=pkg-...
http://anonscm.debian.org/gitweb/?p=pkg-...

you could even start just by taking debian/ directory of any of those, copying into yours and then just doing renames and customizations as fits ;-)

Yaroslav,

I did use the VM actually to compile. W.r.t. to OpenIGTLink -- I probably missed the dev package on my vm. In any event we have only tested a "repository" version of this against BioImage Suite in the operating room so I am a little scared to use a newer version, it might break something and the testing needed is far from trivial.

We are trying to see if we can use Neurodebian as a basis to release the CUDA-version of BioImage Suite as a binary, right now we provide the source but no CUDA binaries. What's the best way to do this on actual hardware in terms of installing NVIDIA drivers etc.?
This will allows us to distribute the realtime biofeedback fMRI setup (incl realtime motion correction) that was described in a recent Neuroinformatics paper (Scheinost is the first author).

Thanks

Xenios

> I did use the VM actually to compile.

cool -- which one was it ? based on squeeze (6.0.6) or wheezy (I gave
6.999.b4.20121231 version)

> In any event we have only tested a
> "repository" version of this against BioImage Suite in the operating room
> so I am a little scared to use a newer version, it might break something
> and the testing needed is far from trivial.

Fair enough! So if someone to look at building it, better to use
released source tarballs, right?

> We are trying to see if we can use Neurodebian as a basis to release the
> CUDA-version of BioImage Suite as a binary, right now we provide the
> source but no CUDA binaries.

good ;)

I would recommend though not to target "binary releases" but proper
source debian packages from which binary packages (.deb) would be
produced. Then probably the same source package could be used to
produce two differing builds (with and without CUDA support) virtually
without any additional work to be done ;)

> What's the best way to do this on actual
> hardware in terms of installing NVIDIA drivers etc.?

to say the truth I haven't had pleasure/pain of dealing with GPUs. But
my guess that if you base on wheezy where those should be much better
supported than in almost 3 year old squeeze then non-free portion of
Debian provides all those development libraries
http://packages.debian.org/wheezy/nvidia...
and stock nvidia kernel drivers.

what libraries in particular would you need?

> This will allows us to distribute the realtime biofeedback fMRI setup
> (incl realtime motion correction) that was described in a recent
> Neuroinformatics paper (Scheinost is the first author).

I am yet to read it ;-)

How far is wheezy from "stable" status? 6.999 feels pretty close.

Xenios

Oops ... these are ancient and not really used -- they are more for a specific in-house database. Just disable the BIOIMAGESUITE3_USE_MYSQL flag and it should be fine. If you e-mail me directly I will be happy to send you the files but I think you should not need them.

We will create a newer snapshot in the next few days now that some other deadlines are passed (plus we had 3 feet of snow here last week which slowed everything down).

Xenios

that is pathetic -- can't post replies to you -- NITRC considers them to be spam

5th attempt:
regarding Debian 6.999 - yes - very close
new release soon -- cool -- it would be great if you also caught your session where you build it -- it would really help in trying to replicate build process

since this timeworked -- here was my reply on Debian: http://paste.debian.net/235968/