From mishkind at gmail.com  Tue Jun  2 13:47:27 2009
From: mishkind at gmail.com (Mishkin Derakhshan)
Date: Tue, 2 Jun 2009 13:47:27 -0400
Subject: [MINC-users] jaunty problems
Message-ID: <9c5abb60906021047q34a41365t4e15721db40a64c0@mail.gmail.com>

Hi,
I'm not sure if I'm the only crash test dummy for the jaunty (32bit)
packages but I've ran into a problem. When I load a volume with
register or Display, the image is restricted to the upper left
quadrant of each window. No amount of resizing, or zooming changes
this.

Screenshots here:
http://www.bic.mni.mcgill.ca/users/mishkin/register.png
http://www.bic.mni.mcgill.ca/users/mishkin/Display.png

When I quit register, or when I load the image in Dispaly, I get this
message in the terminal:

thinkpad[~/test]$ register mtON.mnc.gz
get fences failed: -1
param: 6, val: 0
thinkpad[~/test]$

any ideas?
mishkin

From a.janke at gmail.com  Tue Jun  2 19:22:34 2009
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 3 Jun 2009 09:22:34 +1000
Subject: [MINC-users] jaunty problems
In-Reply-To: <9c5abb60906021047q34a41365t4e15721db40a64c0@mail.gmail.com>
References: <9c5abb60906021047q34a41365t4e15721db40a64c0@mail.gmail.com>
Message-ID: <d747ed50906021622q1062f5f7ha208f346d1b4a05d@mail.gmail.com>

> I'm not sure if I'm the only crash test dummy for the jaunty (32bit)
> packages but I've ran into a problem.

Well I run 32bit at home.

> When I load a volume with
> register or Display, the image is restricted to the upper left
> quadrant of each window. No amount of resizing, or zooming changes
> this.

Very "interesting"... Is your video card a radeon based ATI perchance?
There are some unresolved issues with these that have bitten me too.
If so perhaps try adding this to your xorg.conf:

   Option "AccelMethod"	"xaa"

In the Device section.

There are multiple threads and bugs in launchpad regarding this:

   https://bugs.launchpad.net/ubuntu/+source/linux/+bug/348332

--
Andrew Janke
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883

From fling at pet.rh.dk  Wed Jun  3 03:46:21 2009
From: fling at pet.rh.dk (Flemming Andersen)
Date: Wed, 3 Jun 2009 09:46:21 +0200
Subject: [MINC-users] jaunty problems
In-Reply-To: <9c5abb60906021047q34a41365t4e15721db40a64c0@mail.gmail.com>
References: <9c5abb60906021047q34a41365t4e15721db40a64c0@mail.gmail.com>
Message-ID: <cf9a3dff0906030046w258ce78bu2eda0f67d67c90c7@mail.gmail.com>

Hi, your not the only one...

I get the exact same problem on two machines using the januty packages. One
is the Lenovo Ideapad s10, and the other my desktop running on an Intel
82Q35.

I then compiled the packaged myself for testing with no change :(

Best,
Flemming

On Tue, Jun 2, 2009 at 7:47 PM, Mishkin Derakhshan <mishkind at gmail.com>wrote:

> Hi,
> I'm not sure if I'm the only crash test dummy for the jaunty (32bit)
> packages but I've ran into a problem. When I load a volume with
> register or Display, the image is restricted to the upper left
> quadrant of each window. No amount of resizing, or zooming changes
> this.
>
> Screenshots here:
> http://www.bic.mni.mcgill.ca/users/mishkin/register.png
> http://www.bic.mni.mcgill.ca/users/mishkin/Display.png
>
> When I quit register, or when I load the image in Dispaly, I get this
> message in the terminal:
>
> thinkpad[~/test]$ register mtON.mnc.gz
> get fences failed: -1
> param: 6, val: 0
> thinkpad[~/test]$
>
> any ideas?
> mishkin
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>


-- 
Flemming Andersen, Ph.D
Rigshospitalet Copenhagen, Dep. PET-3982
Phone: +45 3545-8143
Mobile: +45 2615-7368

From a.janke at gmail.com  Wed Jun  3 04:11:49 2009
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 3 Jun 2009 18:11:49 +1000
Subject: [MINC-users] jaunty problems
In-Reply-To: <cf9a3dff0906030046w258ce78bu2eda0f67d67c90c7@mail.gmail.com>
References: <9c5abb60906021047q34a41365t4e15721db40a64c0@mail.gmail.com> 
	<cf9a3dff0906030046w258ce78bu2eda0f67d67c90c7@mail.gmail.com>
Message-ID: <d747ed50906030111u6b5970c6yc473c0f63d980f19@mail.gmail.com>

> I get the exact same problem on two machines using the januty packages. One
> is the Lenovo Ideapad s10, and the other my desktop running on an Intel
> 82Q35.

So both Intel Video Chipsets? Are you running compiz or metacity?  I
am guessing that these problems stem from the aging implementation of
GLUT that register/Display depend on. Out of interest, does the
addition of -single or -rgb make things worse/different?

I know that Slicer for example must be run without compiz
(System->Preferences->Appearance->Visual Effects->None)



--
Andrew Janke
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883

From fling at pet.rh.dk  Wed Jun  3 05:57:16 2009
From: fling at pet.rh.dk (Flemming Andersen)
Date: Wed, 3 Jun 2009 11:57:16 +0200
Subject: [MINC-users] jaunty problems
In-Reply-To: <d747ed50906030111u6b5970c6yc473c0f63d980f19@mail.gmail.com>
References: <9c5abb60906021047q34a41365t4e15721db40a64c0@mail.gmail.com>
	<cf9a3dff0906030046w258ce78bu2eda0f67d67c90c7@mail.gmail.com>
	<d747ed50906030111u6b5970c6yc473c0f63d980f19@mail.gmail.com>
Message-ID: <cf9a3dff0906030257u2a56a776ld33e6e3377700a71@mail.gmail.com>

Yes both intel. I tried both with and without compiz (just metacity) and no
change.. same with -single and -rgb on register, no change.

I have my eyes on freeglut too...

/Flemming

On Wed, Jun 3, 2009 at 10:11 AM, Andrew Janke <a.janke at gmail.com> wrote:

> > I get the exact same problem on two machines using the januty packages.
> One
> > is the Lenovo Ideapad s10, and the other my desktop running on an Intel
> > 82Q35.
>
> So both Intel Video Chipsets? Are you running compiz or metacity?  I
> am guessing that these problems stem from the aging implementation of
> GLUT that register/Display depend on. Out of interest, does the
> addition of -single or -rgb make things worse/different?
>
> I know that Slicer for example must be run without compiz
> (System->Preferences->Appearance->Visual Effects->None)
>
>
>
> --
> Andrew Janke
> (a.janke at gmail.com || http://a.janke.googlepages.com/)
> Canberra->Australia    +61 (402) 700 883
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>


-- 
Flemming Andersen, Ph.D
Rigshospitalet Copenhagen, Dep. PET-3982
Phone: +45 3545-8143
Mobile: +45 2615-7368

From a.janke at gmail.com  Wed Jun  3 06:02:12 2009
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 3 Jun 2009 20:02:12 +1000
Subject: [MINC-users] jaunty problems
In-Reply-To: <cf9a3dff0906030257u2a56a776ld33e6e3377700a71@mail.gmail.com>
References: <9c5abb60906021047q34a41365t4e15721db40a64c0@mail.gmail.com> 
	<cf9a3dff0906030046w258ce78bu2eda0f67d67c90c7@mail.gmail.com> 
	<d747ed50906030111u6b5970c6yc473c0f63d980f19@mail.gmail.com> 
	<cf9a3dff0906030257u2a56a776ld33e6e3377700a71@mail.gmail.com>
Message-ID: <d747ed50906030302q211961bdkb12014e73b59f7c8@mail.gmail.com>

On Wed, Jun 3, 2009 at 19:57, Flemming Andersen <fling at pet.rh.dk> wrote:
> Yes both intel. I tried both with and without compiz (just metacity) and no
> change.. same with -single and -rgb on register, no change.

> I have my eyes on freeglut too...

I have this:

localhost:~$ dpkg --list | grep glut
ii  freeglut3
2.4.0-6.1ubuntu1                                           OpenGL
Utility Toolkit
ii  freeglut3-dev
2.4.0-6.1ubuntu1                                           OpenGL
Utility Toolkit development files
ii  glutg3                                                   3.7-25
                                                 the OpenGL Utility
Toolkit
ii  glutg3-dev                                               3.7-25
                                                 the OpenGL Utility
Toolkit development files
ii  libglut3                                                 3.7-25
                                                 the OpenGL Utility
Toolkit

Note that it is possible to compile register/Display against the
software rendering versions of GLUT which can have interesting
effects...


a

From a.janke at gmail.com  Wed Jun  3 06:14:17 2009
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 3 Jun 2009 20:14:17 +1000
Subject: [MINC-users] 2D-3D registration
In-Reply-To: <Pine.LNX.4.64.0905281043100.14556@grumio.bic.mni.mcgill.ca>
References: <Pine.LNX.4.64.0905281043100.14556@grumio.bic.mni.mcgill.ca>
Message-ID: <d747ed50906030314o2c5d650aq4ff477f798b2e159@mail.gmail.com>

Hi Laurence,

On Fri, May 29, 2009 at 00:48, Laurence MERCIER
<laurence at bic.mni.mcgill.ca> wrote:
> I have a bunch of 2D minc images (ultrasound) that I would like to
> register to a 3D minc volume (MR). I can obviously reconstruct a 3D
> volumes from my ultrasound slices and then register volume to volume, but
> I would like to know if there is a way to directly register the 2D images.

Well no-one else seems to have replied to this yet so I will take a
hack. I was hoping that the likes of Mallar might have something to
add in here..

I do know that direct registration of 2D to 3D using minctracc can be
somewhat problematic as the rotations out of plane tend to go haywire
very fast. That said there are a few little hacks I have had success
with in the past (no doubt louis has some too).

1. Expand the data in the out of plane direction before registration.
If you have a single Z slice, duplicate the slice (mincconcat can do
this) about 10 times first and then attempt registration, if you
slowly blur the slices out towards the edge things also sometimes work
better.  ie:

top - multiply center by 0.1
next - multiply by 0.2
...
Center (original) slice - multiply bu 1.0
...
next - multiply by 0.2
bottom - multiply center by 0.1

2. reduce the w_rotations parameter for the out of plane rotation
directions to ensure that only small out of place rotations are
attempted. Also be sure to start with -identity and -lsq9  to start
with as the PAT will definitely go awry when it aligns the COG's of
the two. Note that this will only work if you have a fairly good idea
of where the slice is to start with.  Perhaps there are some
heuristics in the ultrasound slice that you can take advantage of.

have fun.


--
Andrew Janke
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883

From gilles.plourde at mcgill.ca  Thu Jun 11 15:40:28 2009
From: gilles.plourde at mcgill.ca (Gilles Plourde)
Date: Thu, 11 Jun 2009 15:40:28 -0400
Subject: [MINC-users] Register for Macintosh - error message
Message-ID: <C656D5EC.66D2%gilles.plourde@mcgill.ca>

I have  installed Register  from the register-1.3.6.pkg (downloaded from the
osx-10.5 folder on the BIC software ) on an Intel Mac (OS 10.5.5 and X
Window 2.5.1). The installation was successful but I get the following error
when invoking register:


dyld: Library not loaded: /usr/local/lib/libhdf5.0.dylib
Referenced from: /usr/local/bic/bin/register
Reason: image not found
Trace/BPT trap

Suggestions?

Thanks!
Gilles




From a.janke at gmail.com  Mon Jun 22 10:23:52 2009
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 23 Jun 2009 00:23:52 +1000
Subject: [MINC-users] Register for Macintosh - error message
In-Reply-To: <C656D5EC.66D2%gilles.plourde@mcgill.ca>
References: <C656D5EC.66D2%gilles.plourde@mcgill.ca>
Message-ID: <d747ed50906220723n1e4bc1fdvbfea4dd69f2e81fb@mail.gmail.com>

Hi Gilles,

On Fri, Jun 12, 2009 at 05:40, Gilles Plourde<gilles.plourde at mcgill.ca> wrote:
> I have ?installed Register ?from the register-1.3.6.pkg (downloaded from the
> osx-10.5 folder on the BIC software ) on an Intel Mac (OS 10.5.5 and X
> Window 2.5.1). The installation was successful but I get the following error
> when invoking register:
>
> dyld: Library not loaded: /usr/local/lib/libhdf5.0.dylib
> Referenced from: /usr/local/bic/bin/register
> Reason: image not found
> Trace/BPT trap

HDF is a library that MINC2 needs to run. In this case it is looking
for a Darwinports? version of this library I think.  Anyhow, if you
get Alex's binary OSX package from here:

   http://packages.bic.mni.mcgill.ca/osx-10.5-x86_64-alex/

It will include this library.  See the README in that folder for more details.


--
Andrew Janke
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883


From sorench at gmail.com  Tue Jun 23 01:41:10 2009
From: sorench at gmail.com (Soren Christensen)
Date: Tue, 23 Jun 2009 15:41:10 +1000
Subject: [MINC-users] dcm2mnc and long attribute fields
Message-ID: <d6e2d6550906222241l54b6c9fl4ad60adda2725e5b@mail.gmail.com>

Hi,
 Someone at the department here had a problem that seems to be related
to dcm2mnc behaviour.
When dcm2mnc is run on a large number of dicom files, the parsed files
contain attribute with all the names of the files used as argument.

It seems minc_modify_header can have problems with long attribute fields.
Here's output from an mritoself on a couple of files:

Copying
chunks:..............................................................................................................................................................................................Done.
spawn: exec of minc_modify_header failed: Argument list too long
autocrop: crashed while running minc_modify_header (termination
status=65280)
mritoself: crashed while running autocrop (termination status=65280)

A workaround is to call dcm2mnc on a subset provided sorted by other means,
but I am just mentioning it here in case anyone wants to address the issue.

Cheers
Soren

From a.janke at gmail.com  Tue Jun 23 01:55:15 2009
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 23 Jun 2009 15:55:15 +1000
Subject: [MINC-users] dcm2mnc and long attribute fields
In-Reply-To: <d6e2d6550906222241l54b6c9fl4ad60adda2725e5b@mail.gmail.com>
References: <d6e2d6550906222241l54b6c9fl4ad60adda2725e5b@mail.gmail.com>
Message-ID: <d747ed50906222255g43634a07m11972d22368439d0@mail.gmail.com>

Hi Soren

> ?Someone at the department here had a problem that seems to be related
> to dcm2mnc behaviour.
> When dcm2mnc is run on a large number of dicom files, the parsed files
> contain attribute with all the names of the files used as argument.
>
> It seems minc_modify_header can have problems with long attribute fields.
> Here's output from an mritoself on a couple of files:

Yes, this certainly is a (more general) problem with long attributes
that typically are DICOM related. Given that the root "cause" of this
is that the size of arguments on the C/L is limited you could just
increase the size of ncargs in your kernel to get around this.

My attack plan for such things is to simply strip all the dicom bits
out of the header before further processing using something like the
following (perl) script that I affectionately call
"minc_de-dicomerise".

----
#! /usr/bin/env perl
#
# Andrew Janke - rotor at cmr.uq.edu.au
# Center for Magnetic Resonance
# The University of Queensland
# http://www.cmr.uq.edu.au/~rotor
#
# USE AT OWN RISK!  THIS MAY MUNGE YOUR MINC FILES HEADER!

use warnings "all";
use File::Basename;

$me = &basename($0);
if($#ARGV == -1){
   die "\n+++WARNING: THIS SCRIPT MAY MUNGE YOUR FILE PERMANENTLY!+++\n\n".
       "Usage: $me <file1_to_clean.mnc> [<file2.mnc> [...]]\n\n";
   }

foreach $file (@ARGV){
   print " + Working on $file\n";

   (@yukky_vars) = split(' ', `mincinfo -varnames $file`);

   foreach $var (grep {/dicom/} @yukky_vars){
      foreach (split(' ', `mincinfo -varatts $var $file`)){
         print " | [$file] - removing $var:$_\n";
         system('minc_modify_header', '-delete', "$var:$_", $file) == 0 or die;
         }
      }
   }
----


--
Andrew Janke
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883


From sorench at gmail.com  Tue Jun 23 02:02:02 2009
From: sorench at gmail.com (Soren Christensen)
Date: Tue, 23 Jun 2009 16:02:02 +1000
Subject: [MINC-users] dcm2mnc and long attribute fields
In-Reply-To: <d747ed50906222255g43634a07m11972d22368439d0@mail.gmail.com>
References: <d6e2d6550906222241l54b6c9fl4ad60adda2725e5b@mail.gmail.com> 
	<d747ed50906222255g43634a07m11972d22368439d0@mail.gmail.com>
Message-ID: <d6e2d6550906222302l608a5f1aodf13f9baa951b764@mail.gmail.com>

Thanks Andrew,
 That explains it - had not thought of the command line as the problem.
We'll work around it, thanks for the script.

Cheers
Soren

On Tue, Jun 23, 2009 at 3:55 PM, Andrew Janke <a.janke at gmail.com> wrote:

> Hi Soren
>
> >  Someone at the department here had a problem that seems to be related
> > to dcm2mnc behaviour.
> > When dcm2mnc is run on a large number of dicom files, the parsed files
> > contain attribute with all the names of the files used as argument.
> >
> > It seems minc_modify_header can have problems with long attribute fields.
> > Here's output from an mritoself on a couple of files:
>
> Yes, this certainly is a (more general) problem with long attributes
> that typically are DICOM related. Given that the root "cause" of this
> is that the size of arguments on the C/L is limited you could just
> increase the size of ncargs in your kernel to get around this.
>
> My attack plan for such things is to simply strip all the dicom bits
> out of the header before further processing using something like the
> following (perl) script that I affectionately call
> "minc_de-dicomerise".
>
> ----
> #! /usr/bin/env perl
> #
> # Andrew Janke - rotor at cmr.uq.edu.au
> # Center for Magnetic Resonance
> # The University of Queensland
> # http://www.cmr.uq.edu.au/~rotor
> #
> # USE AT OWN RISK!  THIS MAY MUNGE YOUR MINC FILES HEADER!
>
> use warnings "all";
> use File::Basename;
>
> $me = &basename($0);
> if($#ARGV == -1){
>   die "\n+++WARNING: THIS SCRIPT MAY MUNGE YOUR FILE PERMANENTLY!+++\n\n".
>       "Usage: $me <file1_to_clean.mnc> [<file2.mnc> [...]]\n\n";
>   }
>
> foreach $file (@ARGV){
>   print " + Working on $file\n";
>
>   (@yukky_vars) = split(' ', `mincinfo -varnames $file`);
>
>   foreach $var (grep {/dicom/} @yukky_vars){
>      foreach (split(' ', `mincinfo -varatts $var $file`)){
>         print " | [$file] - removing $var:$_\n";
>         system('minc_modify_header', '-delete', "$var:$_", $file) == 0 or
> die;
>         }
>      }
>   }
> ----
>
>
> --
> Andrew Janke
> (a.janke at gmail.com || http://a.janke.googlepages.com/)
> Canberra->Australia    +61 (402) 700 883
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>