From minc-development@bic.mni.mcgill.ca Thu Apr 3 00:36:47 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Thu, 3 Apr 2003 10:36:47 +1000 Subject: [MINC-development] param2xfm && xfm2param (fwd) Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2107239605-685549424-1049328700=:10949 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: On Wed, 2 Apr 2003, Robert VINCENT wrote: > I found a comment on line 594 of "make_rots.c" which specifies that all three > scale factors must be positive. I guess that even though conceptually a > negative scale factor makes sense, the actual math disallows it. It seems to > use the transform to calculate the *magnitude* of the unit vector in each > direction, and uses this as the scale factor. So negative numbers lose their > signs in the transformation. Correct, this is true for mni_autoreg. mincresample on the other hand should (and can IIRC) handle pretty much any affine matrix you throw at it. This becomes important when you consider importing volumes and using direction cosines that don't "make sense". ie: xdircos 1 0 0 ydircos 0 0 1 zdircos 0 1 0 This is commonly done by taking the columns of a "orientation" matrix such as .mat file from SPM as the direction cosines. (use the attached 'mi' as a replacement for mincinfo if you do this regularly) I then usually resample these volumes using mincresample to more "sensible" direction cosines before using them. So the problem here is that minctracc probably will do the wrong thing by these volumes. As such I usually do something like this before feeding any volumes to minctracc or any pipe for that matter.. $ mincresample -to_sensible_direction_cosines in.mnc tmp.mnc $ mincreshape +direction -dimsize xspace=-1 -dimsize yspace=-1 \ -dimsize zspace=-1 -dimorder zspace,yspace,xspace tmp.mnc out.mnc I can see however as to why louis prefers minctracc not to generate negative scales! The main reason why I do use negative scales is to flip incorrectly oriented volumes. > I'm not familiar enough with mni_autoreg to know if this is a bug or a > feature. What do you think? I think it's a fine thing to keep in minctracc (no negative scales as there should be none!) but perhaps xfm2param and param2xfm should be shifted into minc and at least a warning/check put in WRT negative scales. a > > On Mon, 31 Mar 2003, Andrew Janke wrote: > > > > > $ param2xfm -scales 1 -1 1 t2.xfm > > $ cat t2.xfm > > MNI Transform File > > %Mon Mar 31 15:08:50 2003>>> param2xfm -scales 1 -1 1 t2.xfm > > %(Package MNI AutoReg, version 0.98k, compiled by rotor@twodogs.cmr.uq.edu.au > > (mips-sgi-irix6.5) on 2002-09-06 at 12:02:54) > > > > Transform_Type = Linear; > > Linear_Transform = > > 1 0 0 0 > > 0 -1 0 0 > > 0 0 1 0; > > > > so far so good. > > > > $ xfm2param t2.xfm > > after parameter extraction > > -center 0.00000 0.00000 0.00000 > > -translation 0.00000 0.00000 0.00000 > > -rotation 0.00000 0.00000 0.00000 > > -scale 1.00000 1.00000 1.00000 > > -shear 0.00000 0.00000 0.00000 > > > > Hrm..? > > > > -- > > Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) > > Australia->University of Queensland->Centre for Magnetic Resonance > > Work: +61 7 3365 4100 || Home: +61 7 3800 4042 > > _______________________________________________ > > MINC-development mailing list > > MINC-development@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > > > -- Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance Work: +61 7 3365 4100 || Home: +61 7 3800 4042 ---2107239605-685549424-1049328700=:10949 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=mi Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME=mi IyEgL3Vzci9iaW4vZW52IHBlcmwNCg0KdXNlIHdhcm5pbmdzICJhbGwiOw0K dXNlIEZpbGU6OkJhc2VuYW1lOw0KDQokbWUgPSAmYmFzZW5hbWUoJDApOw0K aWYoJCNBUkdWIDwgMCl7DQogICBkaWUgIlVzYWdlOyAkbWUgPGluZmlsZS5t bmM+IDxpbmZpbGUyLm1uYz5cblxuIjsNCiAgIH0NCg0KZm9yZWFjaCAkZiAo QEFSR1Ypew0KDQogICBAYXJncyA9ICgnbWluY2luZm8nLCANCiAgICAgICAg ICAgICctYXR0dmFsdWUnLCAneHNwYWNlOmRpcmVjdGlvbl9jb3NpbmVzJywN CiAgICAgICAgICAgICctYXR0dmFsdWUnLCAneXNwYWNlOmRpcmVjdGlvbl9j b3NpbmVzJywNCiAgICAgICAgICAgICctYXR0dmFsdWUnLCAnenNwYWNlOmRp cmVjdGlvbl9jb3NpbmVzJywNCiAgICAgICAgICAgICRmKTsNCg0KICAgQGRp cmNvcyA9IHNwbGl0KC9cbi8sIGBAYXJnc2ApOw0KICAgDQogICAkZmxhZyA9 IDA7DQogICBmb3JlYWNoIChzcGxpdCgvXG4vLCBgbWluY2luZm8gJGZgKSl7 DQogICAgICBjaG9tcDsNCiAgICAgIA0KICAgICAgcHJpbnQgIiRfIjsNCiAg ICAgIA0KICAgICAgaWYobS9kaW1lbnNpb25cIG5hbWUvKXsNCiAgICAgICAg IHByaW50ICIgICAgIGRpcmNvcyI7DQogICAgICAgICAkZmxhZyA9IDE7DQog ICAgICAgICB9DQogICAgICANCiAgICAgIGVsc2lmKG0vLS0tLS0tLS0tLS0t LS0vKXsNCiAgICAgICAgIHByaW50ICIgICAgIC0tLS0tLSI7DQogICAgICAg ICB9DQogICAgICANCiAgICAgIGVsc2lmKCRmbGFnICYmIG0veHNwYWNlLyl7 DQogICAgICAgICBwcmludCAiICAgICAkZGlyY29zWzBdIjsNCiAgICAgICAg IH0NCiAgICAgIGVsc2lmKCRmbGFnICYmIG0veXNwYWNlLyl7DQogICAgICAg ICBwcmludCAiICAgICAkZGlyY29zWzFdIjsNCiAgICAgICAgIH0NCiAgICAg IGVsc2lmKCRmbGFnICYmIG0venNwYWNlLyl7DQogICAgICAgICBwcmludCAi ICAgICAkZGlyY29zWzJdIjsNCiAgICAgICAgIH0NCiAgICAgICAgIA0KICAg ICAgcHJpbnQgIlxuIjsNCiAgICAgIH0NCiAgIH0NCg== ---2107239605-685549424-1049328700=:10949-- From minc-development@bic.mni.mcgill.ca Thu Apr 3 01:54:13 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Thu, 3 Apr 2003 11:54:13 +1000 Subject: [MINC-development] param2xfm && xfm2param (fwd) In-Reply-To: References: Message-ID: On Thu, 3 Apr 2003, Andrew Janke wrote: > On Wed, 2 Apr 2003, Robert VINCENT wrote: > > > I found a comment on line 594 of "make_rots.c" which specifies that all three > > scale factors must be positive. I guess that even though conceptually a > > negative scale factor makes sense, the actual math disallows it. It seems to > > use the transform to calculate the *magnitude* of the unit vector in each > > direction, and uses this as the scale factor. So negative numbers lose their > > signs in the transformation. > > Correct, this is true for mni_autoreg. mincresample on the other hand should > (and can IIRC) handle pretty much any affine matrix you throw at it. This > becomes important when you consider importing volumes and using direction > cosines that don't "make sense". Oh and while we are at it, for an alternative way of decomposing an affine matrix (with rotations of more than pi/2) and negative scales see: /s/s/minc/cvsroot/conversion/ana2mnc/ana2mnc_xfm_reduce.pl In perl mind you... ;) a From minc-development@bic.mni.mcgill.ca Thu Apr 3 11:12:40 2003 From: minc-development@bic.mni.mcgill.ca (Rick Hoge) Date: Thu, 3 Apr 2003 06:12:40 -0500 Subject: [MINC-development] MI_ICV_DO_DIM_CONV and slice dimension Message-ID: <2EF23C38-65C5-11D7-94C3-000393B3ACC6@nmr.mgh.harvard.edu> I've been working with the minc ICV functions, and have noticed what to me seemed counterintuitive behaviour associated with the MI_ICV_DO_DIM_CONV parameter. My understanding from the documentation is that a value of TRUE should flip any dimensions that have a negative step size. However I have noticed that while in-plane dimensions are flipped to put the posterior-left corner of a transverse slice at the beginning of the buffer, slices are not flipped. Is this consistent with what other people have seen or expect? Maybe I am misunderstanding the docs but I'd expect the forced consistency with positive step sizes to be all-or-none. For us a typical case would be a transverse EPI scan from one of our Siemens Numaris 4 systems with negative steps in all of x, y, and z (pixeldata buffer starts at front right corner of top slice), all dims need to be flipped to achieve positive step sizes. This may explain some other confusing behaviour we've seen in the past, and I'd appreciate it if anyone could confirm how this is supposed to work. Rick ______________________________________ 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 Fri Apr 4 02:36:44 2003 From: minc-development@bic.mni.mcgill.ca (Peter NEELIN) Date: Thu, 3 Apr 2003 21:36:44 -0500 Subject: [MINC-development] MI_ICV_DO_DIM_CONV and slice dimension In-Reply-To: <2EF23C38-65C5-11D7-94C3-000393B3ACC6@nmr.mgh.harvard.edu> Message-ID: On Thu, 3 Apr 2003, Rick Hoge wrote: > I've been working with the minc ICV functions, and have noticed what to > me seemed counterintuitive behaviour associated with the > MI_ICV_DO_DIM_CONV parameter. My understanding from the documentation > is that a value of TRUE should flip any dimensions that have a negative > step size. However I have noticed that while in-plane dimensions are > flipped to put the posterior-left corner of a transverse slice at the > beginning of the buffer, slices are not flipped. >From the Programmer's Guide: It can sometimes be useful for a program to perform dimension conversions on three (or perhaps more) dimensions, not just the two standard image dimensions. To perform dimension flipping and/or resizing on dimensions beyond the usual two, the property MI_ICV_NUM_IMGDIMS can be set to an integer value between one and MI_MAX_IMGDIMS. Note that I really wrote this dimension conversion code for pre-MINC programs that were not aware that one could store images in more than one way. At the time, the emphasis was on helping in the MINC transition for existing 2D programs. I did add the pseudo-N-dimensional stuff, and put some support in mincreshape to allow command-line access to this functionality, but now I'm rather inclined to believe that it is broken in some cases (at least where N>2) and rather regret putting the options in mincreshape. Furthermore, that particular bit of code tries to be too clever and just ends up being unmaintainable. But feel free to use it if you find that it works (!). Peter ---- Peter Neelin (neelin@bic.mni.mcgill.ca) From minc-development@bic.mni.mcgill.ca Fri Apr 4 02:41:14 2003 From: minc-development@bic.mni.mcgill.ca (Rick Hoge) Date: Thu, 3 Apr 2003 21:41:14 -0500 Subject: [MINC-development] MI_ICV_DO_DIM_CONV and slice dimension In-Reply-To: Message-ID: Thanks Peter, I ended up turning MI_ICV_DO_DIM_CONV off, which made it simpler to just base things on step signs in the rest of my code. It also leads to much faster file loading. The reason this came up is that I was looking over some Emma (matlab) stuff, and noticed the behaviour described (image bytes were always ordered as if positive steps, but if slice dim was negative it still needed adjustment). Anyone still using Emma may find this useful to know. Cheers, Rick On Thursday, April 3, 2003, at 09:36 PM, Peter NEELIN wrote: > On Thu, 3 Apr 2003, Rick Hoge wrote: > >> I've been working with the minc ICV functions, and have noticed what >> to >> me seemed counterintuitive behaviour associated with the >> MI_ICV_DO_DIM_CONV parameter. My understanding from the documentation >> is that a value of TRUE should flip any dimensions that have a >> negative >> step size. However I have noticed that while in-plane dimensions are >> flipped to put the posterior-left corner of a transverse slice at the >> beginning of the buffer, slices are not flipped. > >> From the Programmer's Guide: > > It can sometimes be useful for a program to perform dimension > conversions on three (or perhaps more) dimensions, not just the two > standard image dimensions. To perform dimension flipping and/or > resizing > on dimensions beyond the usual two, the property MI_ICV_NUM_IMGDIMS > can > be set to an integer value between one and MI_MAX_IMGDIMS. > > Note that I really wrote this dimension conversion code for pre-MINC > programs that were not aware that one could store images in more than > one > way. At the time, the emphasis was on helping in the MINC transition > for > existing 2D programs. I did add the pseudo-N-dimensional stuff, and put > some support in mincreshape to allow command-line access to this > functionality, but now I'm rather inclined to believe that it is > broken in > some cases (at least where N>2) and rather regret putting the options > in > mincreshape. Furthermore, that particular bit of code tries to be too > clever and just ends up being unmaintainable. But feel free to use it > if > you find that it works (!). > > Peter > ---- > Peter Neelin (neelin@bic.mni.mcgill.ca) > > _______________________________________________ > 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 Thu Apr 17 06:25:51 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Thu, 17 Apr 2003 15:25:51 +1000 Subject: [MINC-development] reversedef and other things. Message-ID: First and foremost I have added another directory to /s/s/minc_dev whilst in the process of getting an old proggie (reversedef) that was part of mni-autoreg up to date. The directory is /s/s/minc_dev/xfmtools and contains the following goodies. xfmavg: Averages (lin or non-linear) a series of .xfms to a single transform (done via fork to matlab! unless someone can can tell me how to do matrix logs and exponents in perl. This is usefull for determining if you have a bias in a series (time) of xfms. Ie: you can then divide out the commonality in all your transforms. Most usefull when building models. xfmflip: Flips a transform in a specified plane. (used when creating symmetric averages). reversedef: This is actually done as part of mincresample using the -invert C/L option but louis write this long ago should you have a large number of these to do and want to compute a numerical inverse for the purposes of speed. I haven't finished updating reversedef yet but most of the way. The reason being I'm starting to wonder if it's logic should be jsut added to xfminvert in /s/s/m/cvs/m/progs/xfm/ as an option? ie: xfminvert -numerical ? thoughts? This should work for both linear and non-linear transforms even though louis originally intended it to work for def grid transforms only. This may require some extra code to be added to volume_io (I think this is where the invert_general_transform_point stuff is...) but I don't think so. While on this note, I guess the guts of xfmflip could be re-written into xfmtool or as a separate thingo in C such that it can go "into" minc proper. But that would require me to re-write my lovely hacky perl code... :) And then if I did that I'd probably code up a mexp and mlog function whilst at it and C'erise xfmavg... Hrm. -- Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance Work: +61 7 3365 4100 || Home: +61 7 3800 4042 From minc-development@bic.mni.mcgill.ca Thu Apr 24 16:46:49 2003 From: minc-development@bic.mni.mcgill.ca (Mark GRIFFIN) Date: Thu, 24 Apr 2003 11:46:49 -0400 Subject: [MINC-development] Can anyone help me with four-dimensional datasets Message-ID: I'm trying to create a four-dimensional dataset to store fMRI data and get the following results for mincinfo on my minc file shadow:minc_create_data$ mincinfo temp.mnc file: temp.mnc image: signed__ short 0 to 19 image dimensions: time zspace yspace xspace dimension name length step start -------------- ------ ---- ----- time 2 unknown unknown zspace 19 5.5 0 yspace 256 1 0 xspace 256 1 0 The dimension names are set as the variables MItime for example. But I can't understand why I get the time step and start as unknown, also I don't know why I can't set the start to be non-zero. From minc-development@bic.mni.mcgill.ca Fri Apr 25 13:00:11 2003 From: minc-development@bic.mni.mcgill.ca (John G. Sled) Date: Fri, 25 Apr 2003 08:00:11 -0400 Subject: [MINC-development] Can anyone help me with four-dimensional datasets In-Reply-To: ; from mgriffin@bic.mni.mcgill.ca on Thu, Apr 24, 2003 at 11:46:49AM -0400 References: Message-ID: <20030425080011.A3121@sickkids.ca> MINC dimensions can be regularly sampled (defined in terms of start and step) or irregularly sampled (the file contains an array specifying each offset. It appears your volume is the latter. As a work around, you can set the start and step manually eg. minc_modify_header -dinsert 'time:step=3' temp.mnc minc_modify_header -dinsert 'time:start=10' temp.mnc John On Thu, Apr 24, 2003 at 11:46:49AM -0400, Mark GRIFFIN wrote: > I'm trying to create a four-dimensional dataset to store fMRI data and get > the following results for mincinfo on my minc file > > shadow:minc_create_data$ mincinfo temp.mnc > file: temp.mnc > image: signed__ short 0 to 19 > image dimensions: time zspace yspace xspace > dimension name length step start > -------------- ------ ---- ----- > time 2 unknown unknown > zspace 19 5.5 0 > yspace 256 1 0 > xspace 256 1 0 > > > The dimension names are set as the variables MItime for example. But I > can't understand why I get the time step and start as unknown, also I > don't know why I can't set the start to be non-zero. > > > _______________________________________________ > 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 Sat Apr 26 00:03:22 2003 From: minc-development@bic.mni.mcgill.ca (Steve ROBBINS) Date: Fri, 25 Apr 2003 19:03:22 -0400 Subject: [MINC-development] reversedef and other things. In-Reply-To: ; from rotor@cmr.uq.edu.au on Thu, Apr 17, 2003 at 03:25:51PM +1000 References: Message-ID: <20030425190322.B971105@shadow.bic.mni.mcgill.ca> On Thu, Apr 17, 2003 at 03:25:51PM +1000, Andrew Janke wrote: > reversedef: This is actually done as part of mincresample using the -invert > C/L option but louis write this long ago should you have a large > number of these to do and want to compute a numerical inverse > for the purposes of speed. > > > I haven't finished updating reversedef yet but most of the way. The reason > being I'm starting to wonder if it's logic should be jsut added to xfminvert in > /s/s/m/cvs/m/progs/xfm/ as an option? > > ie: xfminvert -numerical ? > > thoughts? I tend to agree. The code is already completely or mostly present in minc. -S From minc-development@bic.mni.mcgill.ca Mon Apr 28 20:09:54 2003 From: minc-development@bic.mni.mcgill.ca (Mark GRIFFIN) Date: Mon, 28 Apr 2003 15:09:54 -0400 Subject: [MINC-development] Can anyone help me with four-dimensional datasets In-Reply-To: <20030425080011.A3121@sickkids.ca> Message-ID: Hi John, Thanks for this. I'll look into it. Mark On Fri, 25 Apr 2003, John G. Sled wrote: > > > MINC dimensions can be regularly sampled (defined in terms of start and > step) or irregularly sampled (the file contains an array specifying > each offset. It appears your volume is the latter. As a work around, > you can set the start and step manually eg. > > minc_modify_header -dinsert 'time:step=3' temp.mnc > minc_modify_header -dinsert 'time:start=10' temp.mnc > > John > > > On Thu, Apr 24, 2003 at 11:46:49AM -0400, Mark GRIFFIN wrote: > > I'm trying to create a four-dimensional dataset to store fMRI data and get > > the following results for mincinfo on my minc file > > > > shadow:minc_create_data$ mincinfo temp.mnc > > file: temp.mnc > > image: signed__ short 0 to 19 > > image dimensions: time zspace yspace xspace > > dimension name length step start > > -------------- ------ ---- ----- > > time 2 unknown unknown > > zspace 19 5.5 0 > > yspace 256 1 0 > > xspace 256 1 0 > > > > > > The dimension names are set as the variables MItime for example. But I > > can't understand why I get the time step and start as unknown, also I > > don't know why I can't set the start to be non-zero. > > > > > > _______________________________________________ > > 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 Wed Apr 30 21:23:05 2003 From: minc-development@bic.mni.mcgill.ca (Jason Lerch) Date: 30 Apr 2003 16:23:05 -0400 Subject: [MINC-development] me, I'm stumped Message-ID: <1051734185.11034.11.camel@mephostopheles> 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 From minc-development@bic.mni.mcgill.ca Wed Apr 30 22:37:26 2003 From: minc-development@bic.mni.mcgill.ca (John G. Sled) Date: Wed, 30 Apr 2003 17:37:26 -0400 Subject: [MINC-development] me, I'm stumped In-Reply-To: <1051734185.11034.11.camel@mephostopheles>; from jason@bic.mni.mcgill.ca on Wed, Apr 30, 2003 at 04:23:05PM -0400 References: <1051734185.11034.11.camel@mephostopheles> Message-ID: <20030430173726.E6471@sickkids.ca> 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 > From minc-development@bic.mni.mcgill.ca Wed Apr 30 22:56:44 2003 From: minc-development@bic.mni.mcgill.ca (John G. Sled) Date: Wed, 30 Apr 2003 17:56:44 -0400 Subject: [MINC-development] MINC API Message-ID: <20030430175644.F6471@sickkids.ca> 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