From minc-development@bic.mni.mcgill.ca Thu May 1 15:03:15 2003 From: minc-development@bic.mni.mcgill.ca (Jason Lerch) Date: 01 May 2003 10:03:15 -0400 Subject: [MINC-development] me, I'm stumped In-Reply-To: <20030430173726.E6471@sickkids.ca> References: <1051734185.11034.11.camel@mephostopheles> <20030430173726.E6471@sickkids.ca> Message-ID: <1051797795.1067.8.camel@mephostopheles> Hello again, there is no documentation that I could find about IRIX and large files, so I tried John's solution. Turns out you also have to add the NDEBUG symbol. Nevertheless, it still crashes at the same place with the same error, so no luck here. I guess it is time to start searching for bugs in the minc library source code ... Jason On Wed, 2003-04-30 at 17:37, John G. Sled wrote: > Hi Jason, > > Under 32-bit linux I was able to get commands such as the following to > work > > rawtominc -short /tmp/junk.mnc 2048 1024 1024 < /dev/zero > > Under linux I had to build minc and netcdf with the options > > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > > Is there something similar for IRIX? > > John > > On Wed, Apr 30, 2003 at 04:23:05PM -0400, Jason Lerch wrote: > > Hi all, > > > > OK, I'm officially stumped: > > > > I'm trying to create a large minc file with the following dimensions: > > 470*2800*2400 > > > > The source is 470 images, each with the dimensions of 2800*2400. So, > > naturally, I'm using a 64-bit compiled version of rawtominc. This is the > > call: > > > > cat *.raw | > > /home/bic/jason/seconddir/minc64/src/minc/progs/rawtominc/rawtominc > > -clobber -yzx -xstep -0.01 -ystep 0.1 -zstep -0.01 test.mnc 470 2400 > > 2800 > > > > This, however, crashes with the following message: > > > > ncendef: ncid 3: Invalid argument > > > > At the time of the crash, the file has the following size: > > > > 2147450880 > > > > If I resize the input files so that the final output is less than that > > magical 2GB limit (and adjust the size options for rawtominc > > accordingly), it works just fine. So this appears to be something to do > > with files over the 2GB limit. The point of the crash in rawtominc is > > here: > > > > (void) miattputstr(cdfid, imgid, MIsigntype, osign); > > if (ovrange_set) > > (void) miset_valid_range(cdfid, imgid, ovalid_range); > > > > /* End definition mode */ > > (void) ncendef(cdfid); > > > > It gets to the ncendef call, but does not progress past it. > > > > I've spent a good part of today trying to figure out why this would be > > the case, but have come up with nothing obvious (and certainly no fix). > > So any help/suggestions would be greatly appreciated! > > > > Jason > > > > P.S. I also tried the 64-bit version of rawtominc that John sent to the > > geeks list a few months ago, but with the same results. > > > > P.P.S If anybody wants the input files to play with, look here: > > > > /data/rome/temp/jason/histo > > > > the files there are in raw byte format, as generated by convert file.png > > GRAY:file.raw > > > > _______________________________________________ > > MINC-development mailing list > > MINC-development@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > > > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development From minc-development@bic.mni.mcgill.ca Thu May 1 16:44:28 2003 From: minc-development@bic.mni.mcgill.ca (Jason Lerch) Date: 01 May 2003 11:44:28 -0400 Subject: [MINC-development] me, I'm stumped In-Reply-To: <1051797795.1067.8.camel@mephostopheles> References: <1051734185.11034.11.camel@mephostopheles> <20030430173726.E6471@sickkids.ca> <1051797795.1067.8.camel@mephostopheles> Message-ID: <1051803868.1067.16.camel@mephostopheles> Ok, this is even more messed up than I first expected: this works: rawtominc -byte -clobber -input /dev/null /tmp/junk.mnc 470 2400 2800 this does not: rawtominc -byte -clobber -input /dev/null /data/rome/temp/jason/test.mnc 470 2400 2800 So ... on a local filesystem everything appears to be OK (I have not yet waited long enough to check whether the file actually holds sensible values when I do this with real data - it is running now, but will take a while), but over NFS it fails at 2GB. I'm running the commands on yorick. So I've cc-ed this to the trinity (are any of you on this list) - any ideas why? Jason On Thu, 2003-05-01 at 10:03, Jason Lerch wrote: > Hello again, > > there is no documentation that I could find about IRIX and large files, > so I tried John's solution. Turns out you also have to add the NDEBUG > symbol. Nevertheless, it still crashes at the same place with the same > error, so no luck here. > > I guess it is time to start searching for bugs in the minc library > source code ... > > Jason > > On Wed, 2003-04-30 at 17:37, John G. Sled wrote: > > Hi Jason, > > > > Under 32-bit linux I was able to get commands such as the following to > > work > > > > rawtominc -short /tmp/junk.mnc 2048 1024 1024 < /dev/zero > > > > Under linux I had to build minc and netcdf with the options > > > > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > > > > Is there something similar for IRIX? > > > > John > > > > On Wed, Apr 30, 2003 at 04:23:05PM -0400, Jason Lerch wrote: > > > Hi all, > > > > > > OK, I'm officially stumped: > > > > > > I'm trying to create a large minc file with the following dimensions: > > > 470*2800*2400 > > > > > > The source is 470 images, each with the dimensions of 2800*2400. So, > > > naturally, I'm using a 64-bit compiled version of rawtominc. This is the > > > call: > > > > > > cat *.raw | > > > /home/bic/jason/seconddir/minc64/src/minc/progs/rawtominc/rawtominc > > > -clobber -yzx -xstep -0.01 -ystep 0.1 -zstep -0.01 test.mnc 470 2400 > > > 2800 > > > > > > This, however, crashes with the following message: > > > > > > ncendef: ncid 3: Invalid argument > > > > > > At the time of the crash, the file has the following size: > > > > > > 2147450880 > > > > > > If I resize the input files so that the final output is less than that > > > magical 2GB limit (and adjust the size options for rawtominc > > > accordingly), it works just fine. So this appears to be something to do > > > with files over the 2GB limit. The point of the crash in rawtominc is > > > here: > > > > > > (void) miattputstr(cdfid, imgid, MIsigntype, osign); > > > if (ovrange_set) > > > (void) miset_valid_range(cdfid, imgid, ovalid_range); > > > > > > /* End definition mode */ > > > (void) ncendef(cdfid); > > > > > > It gets to the ncendef call, but does not progress past it. > > > > > > I've spent a good part of today trying to figure out why this would be > > > the case, but have come up with nothing obvious (and certainly no fix). > > > So any help/suggestions would be greatly appreciated! > > > > > > Jason > > > > > > P.S. I also tried the 64-bit version of rawtominc that John sent to the > > > geeks list a few months ago, but with the same results. > > > > > > P.P.S If anybody wants the input files to play with, look here: > > > > > > /data/rome/temp/jason/histo > > > > > > the files there are in raw byte format, as generated by convert file.png > > > GRAY:file.raw > > > > > > _______________________________________________ > > > MINC-development mailing list > > > MINC-development@bic.mni.mcgill.ca > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > > > > > _______________________________________________ > > MINC-development mailing list > > MINC-development@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development From minc-development@bic.mni.mcgill.ca Thu May 1 16:47:32 2003 From: minc-development@bic.mni.mcgill.ca (Jason Lerch) Date: 01 May 2003 11:47:32 -0400 Subject: [MINC-development] me, I'm stumped In-Reply-To: <1051797795.1067.8.camel@mephostopheles> References: <1051734185.11034.11.camel@mephostopheles> <20030430173726.E6471@sickkids.ca> <1051797795.1067.8.camel@mephostopheles> Message-ID: <1051804051.1077.18.camel@mephostopheles> And before anyone asks, there are 8GB available on that filesystem, so this is not just me being stupid (well, not in that regard at least). Jason On Thu, 2003-05-01 at 10:03, Jason Lerch wrote: > Hello again, > > there is no documentation that I could find about IRIX and large files, > so I tried John's solution. Turns out you also have to add the NDEBUG > symbol. Nevertheless, it still crashes at the same place with the same > error, so no luck here. > > I guess it is time to start searching for bugs in the minc library > source code ... > > Jason > > On Wed, 2003-04-30 at 17:37, John G. Sled wrote: > > Hi Jason, > > > > Under 32-bit linux I was able to get commands such as the following to > > work > > > > rawtominc -short /tmp/junk.mnc 2048 1024 1024 < /dev/zero > > > > Under linux I had to build minc and netcdf with the options > > > > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > > > > Is there something similar for IRIX? > > > > John > > > > On Wed, Apr 30, 2003 at 04:23:05PM -0400, Jason Lerch wrote: > > > Hi all, > > > > > > OK, I'm officially stumped: > > > > > > I'm trying to create a large minc file with the following dimensions: > > > 470*2800*2400 > > > > > > The source is 470 images, each with the dimensions of 2800*2400. So, > > > naturally, I'm using a 64-bit compiled version of rawtominc. This is the > > > call: > > > > > > cat *.raw | > > > /home/bic/jason/seconddir/minc64/src/minc/progs/rawtominc/rawtominc > > > -clobber -yzx -xstep -0.01 -ystep 0.1 -zstep -0.01 test.mnc 470 2400 > > > 2800 > > > > > > This, however, crashes with the following message: > > > > > > ncendef: ncid 3: Invalid argument > > > > > > At the time of the crash, the file has the following size: > > > > > > 2147450880 > > > > > > If I resize the input files so that the final output is less than that > > > magical 2GB limit (and adjust the size options for rawtominc > > > accordingly), it works just fine. So this appears to be something to do > > > with files over the 2GB limit. The point of the crash in rawtominc is > > > here: > > > > > > (void) miattputstr(cdfid, imgid, MIsigntype, osign); > > > if (ovrange_set) > > > (void) miset_valid_range(cdfid, imgid, ovalid_range); > > > > > > /* End definition mode */ > > > (void) ncendef(cdfid); > > > > > > It gets to the ncendef call, but does not progress past it. > > > > > > I've spent a good part of today trying to figure out why this would be > > > the case, but have come up with nothing obvious (and certainly no fix). > > > So any help/suggestions would be greatly appreciated! > > > > > > Jason > > > > > > P.S. I also tried the 64-bit version of rawtominc that John sent to the > > > geeks list a few months ago, but with the same results. > > > > > > P.P.S If anybody wants the input files to play with, look here: > > > > > > /data/rome/temp/jason/histo > > > > > > the files there are in raw byte format, as generated by convert file.png > > > GRAY:file.raw > > > > > > _______________________________________________ > > > MINC-development mailing list > > > MINC-development@bic.mni.mcgill.ca > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > > > > > _______________________________________________ > > MINC-development mailing list > > MINC-development@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development From minc-development@bic.mni.mcgill.ca Thu May 1 16:55:20 2003 From: minc-development@bic.mni.mcgill.ca (Jean-Francois Malouin) Date: Thu, 1 May 2003 11:55:20 -0400 Subject: [MINC-development] me, I'm stumped In-Reply-To: <1051803868.1067.16.camel@mephostopheles>; from jason@bic.mni.mcgill.ca on Thu, May 01, 2003 at 11:44:28AM -0400 References: <1051734185.11034.11.camel@mephostopheles> <20030430173726.E6471@sickkids.ca> <1051797795.1067.8.camel@mephostopheles> <1051803868.1067.16.camel@mephostopheles> Message-ID: <20030501115519.A1452318@shadow.bic.mni.mcgill.ca> * Jason Lerch (jason@bic.mni.mcgill.ca) [20030501 11:44] thus spake: > Ok, this is even more messed up than I first expected: > > this works: > > rawtominc -byte -clobber -input /dev/null /tmp/junk.mnc 470 2400 2800 > > this does not: > > rawtominc -byte -clobber -input /dev/null /data/rome/temp/jason/test.mnc > 470 2400 2800 > > So ... on a local filesystem everything appears to be OK (I have not yet > waited long enough to check whether the file actually holds sensible > values when I do this with real data - it is running now, but will take > a while), but over NFS it fails at 2GB. I'm running the commands on > yorick. > > So I've cc-ed this to the trinity (are any of you on this list) - any > ideas why? yes. I knew it right away but I've been busy with bullcalf and bottom. XFS NFS filesystems are exported 32bits to all clients. We could try 64bits exports but there have been numerous problems before... jf > > Jason > [snip!] -- Their names come to his lips and he smiles as he tastes them, thinking he knows them in the naming. From minc-development@bic.mni.mcgill.ca Thu May 1 16:59:20 2003 From: minc-development@bic.mni.mcgill.ca (Steve ROBBINS) Date: Thu, 1 May 2003 11:59:20 -0400 Subject: [MINC-development] me, I'm stumped In-Reply-To: <20030501115519.A1452318@shadow.bic.mni.mcgill.ca>; from Jean-Francois.Malouin@bic.mni.mcgill.ca on Thu, May 01, 2003 at 11:55:20AM -0400 References: <1051734185.11034.11.camel@mephostopheles> <20030430173726.E6471@sickkids.ca> <1051797795.1067.8.camel@mephostopheles> <1051803868.1067.16.camel@mephostopheles> <20030501115519.A1452318@shadow.bic.mni.mcgill.ca> Message-ID: <20030501115920.A1410358@shadow.bic.mni.mcgill.ca> On Thu, May 01, 2003 at 11:55:20AM -0400, Jean-Francois Malouin wrote: > * Jason Lerch (jason@bic.mni.mcgill.ca) [20030501 11:44] thus spake: > > Ok, this is even more messed up than I first expected: > > > > this works: > > > > rawtominc -byte -clobber -input /dev/null /tmp/junk.mnc 470 2400 2800 > > > > this does not: > > > > rawtominc -byte -clobber -input /dev/null /data/rome/temp/jason/test.mnc > > 470 2400 2800 > > > > So ... on a local filesystem everything appears to be OK (I have not yet > > waited long enough to check whether the file actually holds sensible > > values when I do this with real data - it is running now, but will take > > a while), but over NFS it fails at 2GB. I'm running the commands on > > yorick. > > > > So I've cc-ed this to the trinity (are any of you on this list) - any > > ideas why? > > yes. I knew it right away but I've been busy with bullcalf and bottom. > XFS NFS filesystems are exported 32bits to all clients. > We could try 64bits exports but there have been numerous problems > before... The nfs faq claims that the problems can be solved if you use naming version 2. Have you tried that? http://nfs.sourceforge.net/nfs-howto/interop.html#IRIX -S From minc-development@bic.mni.mcgill.ca Thu May 1 17:26:58 2003 From: minc-development@bic.mni.mcgill.ca (Colin Holmes) Date: Thu, 1 May 2003 09:26:58 -0700 Subject: [MINC-development] me, I'm stumped Message-ID: Hi, If there are problems with 64bit export under IRIX please let me know, I'll walk down the hall and see who can fix it... FWIW... I had no problems with doing that at LONI, under IRIX 6.5.11 and up, with data/extents up to 12GB. Colin. -----Original Message----- From: Jean-Francois Malouin [mailto:Jean-Francois.Malouin@bic.mni.mcgill.ca] Sent: Thursday, May 01, 2003 8:55 AM To: Jason Lerch Cc: MINC-development@bic.mni.mcgill.ca; god@bic.mni.mcgill.ca Subject: Re: [MINC-development] me, I'm stumped * Jason Lerch (jason@bic.mni.mcgill.ca) [20030501 11:44] thus spake: > Ok, this is even more messed up than I first expected: > > this works: > > rawtominc -byte -clobber -input /dev/null /tmp/junk.mnc 470 2400 2800 > > this does not: > > rawtominc -byte -clobber -input /dev/null /data/rome/temp/jason/test.mnc > 470 2400 2800 > > So ... on a local filesystem everything appears to be OK (I have not yet > waited long enough to check whether the file actually holds sensible > values when I do this with real data - it is running now, but will take > a while), but over NFS it fails at 2GB. I'm running the commands on > yorick. > > So I've cc-ed this to the trinity (are any of you on this list) - any > ideas why? yes. I knew it right away but I've been busy with bullcalf and bottom. XFS NFS filesystems are exported 32bits to all clients. We could try 64bits exports but there have been numerous problems before... jf > > Jason > [snip!] -- Their names come to his lips and he smiles as he tastes them, thinking he knows them in the naming. _______________________________________________ MINC-development mailing list MINC-development@bic.mni.mcgill.ca http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development From minc-development@bic.mni.mcgill.ca Fri May 2 02:53:20 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Fri, 2 May 2003 11:53:20 +1000 Subject: [MINC-development] MINC API In-Reply-To: <20030430175644.F6471@sickkids.ca> References: <20030430175644.F6471@sickkids.ca> Message-ID: On Wed, 30 Apr 2003, John G. Sled wrote: > I am looking for some feedback with respect to the API of MINC 2.0. > ... > The distinction made at the time was that the new libminc would be used in > applications that managed their own memory whereas libvolume_io would continue > to offer memory management and caching. Sounds like a good plan. > My question for the list is how much functionality that is currently > in other libraries should be put into libminc? Myself I think that a lot of the functionality of volume_io should be removed. This is WRT to functions such as file_exists() and the vast amount of name-space pollution. This can easily be fixed by adding a VOLIO_/MINC_ prefix to the start of all #defines of course, but a lot of them we'd be better of just removing (SQR, PI, for_less, for_up, etc etc). There is no reason why they should be completely removed, just moved to a separate header file like minc_def.h Reason being that the current volume_io is often difficult to link with other libraries due to name-space clashes. > What about general transformations that are represented as MINC files? Any > comments would be appreciated. I think that xfm's should most definitely be included in the MINC API along with the tag's type files that are exported from register. (And change '%MNI transform file' to '%MINC transform file' while you're at it! :) Just my 2c. a From minc-development@bic.mni.mcgill.ca Mon May 5 13:25:19 2003 From: minc-development@bic.mni.mcgill.ca (Rick Hoge) Date: Mon, 5 May 2003 08:25:19 -0400 Subject: [MINC-development] MINC API In-Reply-To: <20030430175644.F6471@sickkids.ca> Message-ID: Hi John, I would tend to agree that it's time to rethink the role of volume_io. I hear frequently from people and groups in the Boston area who are trying to do MINC development but find the current layering quite confusing. I think integration of the xfm and tag file support would be a good thing too - I assume that by general transformations stored as minc files you mean deformation fields for non-linear transformations. We currently do a lot of non-linear gradient unwarping, particularly for our Allegra but also for other systems, and anything that would facilitate this would be nice! Rick On Wednesday, April 30, 2003, at 05:56 PM, John G. Sled wrote: > > I am looking for some feedback with respect to the API of MINC 2.0. > An idea that came out of the MINC meeting earlier this year is that > the libminc 2 API should have much more functionality than libminc 1, > such that it would be an attractive alternative to the libvolume_io > API for many applications. The distinction made at the time was > that the new libminc would be used in applications that managed > their own memory whereas libvolume_io would continue to offer > memory management and caching. > > My question for the list is how much functionality that is currently > in other libraries should be put into libminc? I think it is clear > that libminc should have various function for setting all of the > header attributes related coordinate systems, but what about the > code for working with xfm files or tag files? What about general > transformations that are represented as MINC files? Any comments > would be appreciated. > > > > John > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > ______________________________________ Richard D. Hoge, Ph.D. Instructor, HMS Department of Radiology A. A. Martinos Center for Biomedical Imaging 149 13th St. Charlestown MA 02129 phone 617-726-6598 fax 617-726-7422 ______________________________________ From minc-development@bic.mni.mcgill.ca Wed May 21 16:19:30 2003 From: minc-development@bic.mni.mcgill.ca (Vicka Corey) Date: Wed, 21 May 2003 11:19:30 -0400 Subject: [MINC-development] nu_correct ? Message-ID: <20030521111930.A2199@gate.nmr.mgh.harvard.edu> One of our users here says he is having problems with nu_correct: nu_correct seems to make the volume darker each time it is applied (that is, the output grayscales are smaller than the input ones [....] If, for example, the mean of the white matter is 120 before correction, after involking it 3 or 4 times it will be 80, and I would like it to stay constant (or about constant). ...can anyone here shed any light on this? thanks much, --vicka Vicka Rael Corey, Ph.D. vicka@nmr.mgh.harvard.edu "More fun than a barrel of monkey wrenches!" From minc-development@bic.mni.mcgill.ca Wed May 21 16:26:38 2003 From: minc-development@bic.mni.mcgill.ca (John G. Sled) Date: Wed, 21 May 2003 11:26:38 -0400 Subject: [MINC-development] nu_correct ? In-Reply-To: <20030521111930.A2199@gate.nmr.mgh.harvard.edu>; from vicka@nmr.mgh.harvard.edu on Wed, May 21, 2003 at 11:19:30AM -0400 References: <20030521111930.A2199@gate.nmr.mgh.harvard.edu> Message-ID: <20030521112638.D27986@sickkids.ca> Dear Vicka, nu_correct has a -normalize_field option which forces the field within the mask region to have mean 1.0. This is a bit arbitrary, but makes visualization easier in some circumstances. Also, if you find that the results continue to improve by rerunning nu_correct, then the -iterations and -stop options may be used to get the same result in a single step. with regards, John Hospital for Sick Children Mouse Imaging Centre 555 University Ave. Toronto, Ontario M5G 1X8 Canada Phone: 416 813-7654 x1438 Fax: 416 813-2208 On Wed, May 21, 2003 at 11:19:30AM -0400, Vicka Corey wrote: > One of our users here says he is having problems with nu_correct: > > nu_correct seems to > make the volume darker each time it is applied (that is, the output > grayscales are smaller than the input ones [....] > If, for example, the mean of the white matter is 120 before > correction, after involking it 3 or 4 times it will be 80, and I would like > it to stay constant (or about constant). > > ...can anyone here shed any light on this? > > thanks much, > --vicka > > Vicka Rael Corey, Ph.D. vicka@nmr.mgh.harvard.edu > "More fun than a barrel of monkey wrenches!" > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development >