From m.audette@aist.go.jp Wed Jan 5 00:40:04 2005 From: m.audette@aist.go.jp (Michel Audette) Date: Wed Jan 5 00:40:04 2005 Subject: [MINC-users] problems saving images in Display Message-ID: <006d01c4f2eb$af5e84a0$3a751d96@surgsim2> Hello everyone, I've been trying to save images with a freshly compiled version of Display, only to see that I needed to recompile the bicpl library with a means of writing image files. I downloaded netpbm, and configured bicpl --with-image-ppm, recompiled Display and now I now longer am seeing error messages. What I'm seeing, however, is that saving the image does not produce the expected results. I had no problems with this feature in the past, with prior a MNI release. I am doing all this on Slackware Linux, from a re-compiled kernel 2.4.19. Can anyone suggest a way to solve this? Best regards, and Happy 2005. Michel Michel Audette, Ph.D., Research Fellow, Surgical Simulation, Surgical Assist Technology Group, AIST, Namiki 1-2, Tsukuba, Japan, 305-8564. -------------------------------------------------------- "If you think you can do it, you're right. If you think you can't do it, you're still right." - Henry Ford From dswack@buffalo.edu Wed Jan 5 15:33:05 2005 From: dswack@buffalo.edu (dswack@buffalo.edu) Date: Wed Jan 5 15:33:05 2005 Subject: [MINC-users] ecattominc on linux Message-ID: <1104957140.41dc4ed4aa985@mail2.buffalo.edu> I'm trying to compile ecattominc on redhat linux 8.0. The instructions say that I have to first compile netcdf and minc. I have trouble doing this, however I've downloaded the rpms, for these and installed them. But, I still have trouble compiling ecattominc. I've whittled away at the compilation. I've tried linking against netcdf and minc, however, I am still missing three functions. get_vax_short(1, &header[offset], &short_value); get_vax_long(1, &header[offset], &long_value); get_vax_float( 1, &header[offset], &float_value); I've searched around for these but can't find them. Anyone have any ideas? dave David Wack Dept. Nuclear Medicine University at Buffalo dswack@buffalo.edu (716) 862-8789 From andrew_janke@iinet.net.au Wed Jan 5 17:45:04 2005 From: andrew_janke@iinet.net.au (Andrew Janke) Date: Wed Jan 5 17:45:04 2005 Subject: [MINC-users] problems saving images in Display In-Reply-To: <006d01c4f2eb$af5e84a0$3a751d96@surgsim2> References: <006d01c4f2eb$af5e84a0$3a751d96@surgsim2> Message-ID: On Wed, 5 Jan 2005, Michel Audette wrote: > I've been trying to save images with a freshly compiled version of Display, > only to see that I needed to recompile the bicpl library with a means of > writing image files. I downloaded netpbm, and configured > bicpl --with-image-ppm, recompiled Display and now I now longer am seeing > error messages. What I'm seeing, however, is that saving the image does not > produce the expected results. I had no problems with this feature in the > past, with prior a MNI release. I am doing all this on Slackware Linux, from > a re-compiled kernel 2.4.19. Hrm, I too struck this problem a while back. It seems to work with me using these versions: bicpl 1.4.1 --with-image-ppm Display 1.3.8 --lpthread Which versions are you working with? -- Andrew Janke (andrew_janke@iinet.net DOT au || www.cmr.uq.edu.au/~rotor) Australia->Brisbane H: +61 7 3390 6332 || M: +61 4 2138 8581 From steven.robbins@videotron.ca Wed Jan 5 20:10:05 2005 From: steven.robbins@videotron.ca (Steve M. Robbins) Date: Wed Jan 5 20:10:05 2005 Subject: [MINC-users] problems saving images in Display In-Reply-To: References: <006d01c4f2eb$af5e84a0$3a751d96@surgsim2> Message-ID: <20050106010731.GF17655@nyongwa.montreal.qc.ca> On Thu, Jan 06, 2005 at 08:44:41AM +1000, Andrew Janke wrote: > On Wed, 5 Jan 2005, Michel Audette wrote: > > >I've been trying to save images with a freshly compiled version of Display, > >only to see that I needed to recompile the bicpl library with a means of > >writing image files. I downloaded netpbm, and configured > >bicpl --with-image-ppm, recompiled Display and now I now longer am seeing > >error messages. What I'm seeing, however, is that saving the image does not > >produce the expected results. I had no problems with this feature in the > >past, with prior a MNI release. I am doing all this on Slackware Linux, > >from > >a re-compiled kernel 2.4.19. > > Hrm, > > I too struck this problem a while back. It seems to work with me using > these versions: > > bicpl 1.4.1 --with-image-ppm > Display 1.3.8 --lpthread > > Which versions are you working with? Also: which version of netpbm? What does the config.log say when probing for PPM? Netpbm changed from four libraries (ppm, pbm, pgm, pnm) in version 9 to one library (netpbm) in version 10. The configure script currently assumes version 9 layout. This should be fixed; see bicpl/TODO. -Steve From m.audette@aist.go.jp Wed Jan 5 20:29:05 2005 From: m.audette@aist.go.jp (Michel Audette) Date: Wed Jan 5 20:29:05 2005 Subject: [MINC-users] problems saving images in Display References: <006d01c4f2eb$af5e84a0$3a751d96@surgsim2> <20050106010731.GF17655@nyongwa.montreal.qc.ca> Message-ID: <00c901c4f391$c8402130$3a751d96@surgsim2> Hi Andrew and Steve, I am using Display 1.3.8, bicpl 1.4.1, and netpbm-10.18.18, all from source code. I didn't configure Display with --lpthread. I didn't see that anywhere mentioned, nor does it seem to be a recognized configure option for Display right now. I used the --with-image-ppm option for bicpl. By the way, I had to edit some makefiles to also account for pbm and pgm dependencies, along with ppm. I didn't see a simple way to fix that in configuration files. Thanks for your help. Cheers, Michel Michel Audette, Ph.D., Research Fellow, Surgical Simulation, Surgical Assist Technology Group, AIST, Namiki 1-2, Tsukuba, Japan, 305-8564. -------------------------------------------------------- "If you think you can do it, you're right. If you think you can't do it, you're still right." - Henry Ford ----- Original Message ----- From: "Steve M. Robbins" To: "Michel Audette" ; "The MINC mailing list" Sent: Thursday, January 06, 2005 10:07 AM Subject: Re: [MINC-users] problems saving images in Display > On Thu, Jan 06, 2005 at 08:44:41AM +1000, Andrew Janke wrote: > > On Wed, 5 Jan 2005, Michel Audette wrote: > > > > >I've been trying to save images with a freshly compiled version of Display, > > >only to see that I needed to recompile the bicpl library with a means of > > >writing image files. I downloaded netpbm, and configured > > >bicpl --with-image-ppm, recompiled Display and now I now longer am seeing > > >error messages. What I'm seeing, however, is that saving the image does not > > >produce the expected results. I had no problems with this feature in the > > >past, with prior a MNI release. I am doing all this on Slackware Linux, > > >from > > >a re-compiled kernel 2.4.19. > > > > Hrm, > > > > I too struck this problem a while back. It seems to work with me using > > these versions: > > > > bicpl 1.4.1 --with-image-ppm > > Display 1.3.8 --lpthread > > > > Which versions are you working with? > > Also: which version of netpbm? What does the config.log say > when probing for PPM? > > Netpbm changed from four libraries (ppm, pbm, pgm, pnm) in version 9 > to one library (netpbm) in version 10. The configure script currently > assumes version 9 layout. This should be fixed; see bicpl/TODO. > > -Steve From dswack@buffalo.edu Thu Jan 6 11:16:05 2005 From: dswack@buffalo.edu (dswack@buffalo.edu) Date: Thu Jan 6 11:16:05 2005 Subject: [MINC-users] ecattominc on linux In-Reply-To: References: <1104957140.41dc4ed4aa985@mail2.buffalo.edu> Message-ID: <1105027732.41dd629475918@mail2.buffalo.edu> Peter, thank you very much for your reply. I know I had deviated from the instructions. Forgive me, I'm about to do worse. :) With the addition of the vax_conversions file the compilation went fairly smoothly, with linking against the pre-built libraries. The problem arises in running, where I get a segmentation fault. I ran it through gdb, and believe the problem is basicly a bigendian littleendian issue. I threw caution to the wind, and was able to get the program to execute completely, by forcing to use the vax conversion routines on ecat 7 files. This allowed things like the frames and planes to be read correctly. However, after completion of the program with my edits, the resulting mnc file has some issues. I don't believe the floating point numbers are being handle correctly. At this point, I figured I back off, and ask the question: has anyone run this before on Linux?? Or, does my problem truly stem back to not compiling minc myself. dave Quoting Peter Neelin : > On Wed, 05 Jan 2005 15:32:20 -0500, dswack@buffalo.edu > wrote: > > > > > > I'm trying to compile ecattominc on redhat linux 8.0. > > > > The instructions say that I have to first compile > > netcdf and minc. > > > > I have trouble doing this, however I've downloaded the rpms, > > for these and installed them. But, I still have trouble > > compiling ecattominc. > > The ecattominc tar file was intended to be unpacked in the minc > source > directory (as described in at least one set of instructions). If you > have an rpm that only includes the minc programs and minc and > volume_io libraries, then it will not work. Furthermore, the vax > conversion routines were removed from minc in version 1.1, so > ecattominc will not build with that or later versions. You should > get > the 1.0 minc source tarball (from the BIC web site under > /software/distribution/packages/OLD/) and try building ecattominc in > that directory structure. The vax_conversions.c and > vax_conversions.h > files are in there (progs/Proglib). Better yet, you could just lift > those two files out of there and fiddle the ecattominc Makefile to > build properly - if you do that then I think that you will be able > to > link with a newer libminc and not have to worry about building minc. > > I don't know if anyone is trying to repackage the conversion > programs > so that they build out of the box with the the new versions of minc. > Bert? Andrew? > > Peter > > From Peter Neelin Thu Jan 6 17:23:03 2005 From: Peter Neelin (Peter Neelin) Date: Thu Jan 6 17:23:03 2005 Subject: [MINC-users] ecattominc on linux In-Reply-To: <1104957140.41dc4ed4aa985@mail2.buffalo.edu> References: <1104957140.41dc4ed4aa985@mail2.buffalo.edu> Message-ID: On Wed, 05 Jan 2005 15:32:20 -0500, dswack@buffalo.edu wrote: > > > I'm trying to compile ecattominc on redhat linux 8.0. > > The instructions say that I have to first compile > netcdf and minc. > > I have trouble doing this, however I've downloaded the rpms, > for these and installed them. But, I still have trouble > compiling ecattominc. The ecattominc tar file was intended to be unpacked in the minc source directory (as described in at least one set of instructions). If you have an rpm that only includes the minc programs and minc and volume_io libraries, then it will not work. Furthermore, the vax conversion routines were removed from minc in version 1.1, so ecattominc will not build with that or later versions. You should get the 1.0 minc source tarball (from the BIC web site under /software/distribution/packages/OLD/) and try building ecattominc in that directory structure. The vax_conversions.c and vax_conversions.h files are in there (progs/Proglib). Better yet, you could just lift those two files out of there and fiddle the ecattominc Makefile to build properly - if you do that then I think that you will be able to link with a newer libminc and not have to worry about building minc. I don't know if anyone is trying to repackage the conversion programs so that they build out of the box with the the new versions of minc. Bert? Andrew? Peter From andrew_janke@iinet.net.au Sun Jan 9 09:27:04 2005 From: andrew_janke@iinet.net.au (Andrew Janke) Date: Sun Jan 9 09:27:04 2005 Subject: [MINC-users] problems saving images in Display In-Reply-To: <00c901c4f391$c8402130$3a751d96@surgsim2> References: <006d01c4f2eb$af5e84a0$3a751d96@surgsim2> <20050106010731.GF17655@nyongwa.montreal.qc.ca> <00c901c4f391$c8402130$3a751d96@surgsim2> Message-ID: On Thu, 6 Jan 2005, Michel Audette wrote: > I am using Display 1.3.8, bicpl 1.4.1, and netpbm-10.18.18, all from source > code. I didn't configure Display with --lpthread. I didn't see that anywhere > mentioned, nor does it seem to be a recognized configure option for Display > right now. I used the --with-image-ppm option for bicpl. Sorry, the -lpthread was an LDFLAGS extra that is typically required only when you are using hardware accelerated OpenGL on linux. -- Andrew Janke (andrew_janke@iinet.net DOT au || www.cmr.uq.edu.au/~rotor) Australia->Brisbane H: +61 7 3390 6332 || M: +61 4 2138 8581 From sdrouin@bic.mni.mcgill.ca Tue Jan 18 15:38:05 2005 From: sdrouin@bic.mni.mcgill.ca (Simon Drouin) Date: Tue Jan 18 15:38:05 2005 Subject: [MINC-users] Building Display Message-ID: <41ED73CC.6050808@bic.mni.mcgill.ca> Hi all, I'm trying to build Display on Mandrake Linux 10.1 and I get the following link error: libtool: link: warning: library `/usr/local/mni/lib/libbicpl.la' was moved. libtool: link: cannot find the library `/usr/X11R6/lib/libGL.la' I know I've see something about .la files on the list before, but I can't find the mailing list archive. Anyone can help? Thanks in advance. Simon Drouin From andrew_janke@iinet.net.au Tue Jan 18 17:23:04 2005 From: andrew_janke@iinet.net.au (Andrew Janke) Date: Tue Jan 18 17:23:04 2005 Subject: [MINC-users] Building Display In-Reply-To: <41ED73CC.6050808@bic.mni.mcgill.ca> References: <41ED73CC.6050808@bic.mni.mcgill.ca> Message-ID: On Tue, 18 Jan 2005, Simon Drouin wrote: > I'm trying to build Display on Mandrake Linux 10.1 and I get the following > link error: > > libtool: link: warning: library `/usr/local/mni/lib/libbicpl.la' was moved. > libtool: link: cannot find the library `/usr/X11R6/lib/libGL.la' > > I know I've see something about .la files on the list before, but I can't > find the mailing list archive. Anyone can help? It libtool speaking the truth? ie: have you moved the libraries? if often the easiest way around this is to go to /usr/local/mni/lib and simply remove all the .la files... a From cogilvie@ualberta.ca Mon Jan 24 13:37:05 2005 From: cogilvie@ualberta.ca (Catherine Ogilvie) Date: Mon Jan 24 13:37:05 2005 Subject: [MINC-users] ana2mnc problem Message-ID: <41F746D3@webmail.ualberta.ca> Andrew, the new ana2mnc program you sent me worked wonderfully. However, I then needed the images transformed into sagittal orientation. I tried to use the minc programs suggested by everyone on minc-users, but when I had a lot of difficulty I had them transformed into sagittal while in .hdr .img format by the group sending them to me. Now when I run the dimension transformed .hdr .img files on the ana2mnc program it does not turn out a readable format, with the repeated warning output: Warning: you specified -swap_bytes, but I can't swap this type if input I'm not sure what's happening. When I convert to minc, the dimensions of the images in original axial form are: image: signed__ short 0 to 32767 image dimensions: zspace yspace xspace dimension name length step start -------------- ------ ---- ----- zspace 64 2.72727 -87.2727 yspace 256 0.859375 -110 xspace 256 -0.859375 110 The dimensions in transformed sagittal form, when converted to minc, are: image: signed__ float -1.6814541463787951101e+38 to 3.3836776830158255673e+38 image dimensions: zspace yspace xspace dimension name length step start -------------- ------ ---- ----- zspace 256 0.859375 -110 yspace 256 0.859375 -110 xspace 256 -0.859375 110 not sure if this makes a difference, but this is the one that's giving me the errors and pixelated output. Thanks for your help. Catherine Ogilvie >===== Original Message From Andrew Janke ===== >On Wed, 8 Dec 2004, Catherine Ogilvie wrote: > >> Hi. I'm trying to use ana2mnc for the first time. I have had a .img and .hdr >> pair sent to me from another lab which uses analyze. When I run ana2mnc I get >> this: >> >> ana2mnc: sizeof header: 1543569408 >> ana2mnc: Hrm, attempting byte-swapping on ANATcw.24_02_03_2.fid_001.hdr >> ana2mnc: No x origin info found, guessing.. >> ana2mnc: No y origin info found, guessing.. >> ana2mnc: No z origin info found, guessing.. >> >> and a very strangely pixelated output. > >I'm guessing that when you tranferred the data, the header was byte swapped and >the data wasn't. > >Try this version of ana2mnc > > http://www.bic.mni.mcgill.ca/~rotor/distro/ana2mnc-1.3c > >using the -swap_data option. > >If this works, I'll add this feature into the next release of ana2mnc > > >-- >Andrew Janke (andrew_janke@iinet.net DOT au || www.cmr.uq.edu.au/~rotor) >Australia->Brisbane H: +61 7 3390 6332 || M: +61 4 2138 8581 From bert@bic.mni.mcgill.ca Mon Jan 24 13:57:04 2005 From: bert@bic.mni.mcgill.ca (Robert VINCENT) Date: Mon Jan 24 13:57:04 2005 Subject: [MINC-users] ana2mnc problem In-Reply-To: <41F746D3@webmail.ualberta.ca> Message-ID: Hi Catherine, The revised (sagittal) files seem to be in floating-point format, whereas the originals were in short integer format. Ana2mnc calls rawtominc, which doesn't deal with byte-swapping floating-point datatypes. What was the difficulty in reorienting the MINC files? That should have been pretty straightforward. I'll be happy to help if you're willing to give that approach another try. -bert On Mon, 24 Jan 2005, Catherine Ogilvie wrote: > Andrew, the new ana2mnc program you sent me worked wonderfully. > > However, I then needed the images transformed into sagittal orientation. I > tried to use the minc programs suggested by everyone on minc-users, but when I > had a lot of difficulty I had them transformed into sagittal while in .hdr > .img format by the group sending them to me. Now when I run the dimension > transformed .hdr .img files on the ana2mnc program it does not turn out a > readable format, with the repeated warning output: > > Warning: you specified -swap_bytes, but I can't swap this type if input > > I'm not sure what's happening. > > When I convert to minc, the dimensions of the images in original axial form > are: > > image: signed__ short 0 to 32767 > image dimensions: zspace yspace xspace > dimension name length step start > -------------- ------ ---- ----- > zspace 64 2.72727 -87.2727 > yspace 256 0.859375 -110 > xspace 256 -0.859375 110 > > The dimensions in transformed sagittal form, when converted to minc, are: > > image: signed__ float -1.6814541463787951101e+38 to 3.3836776830158255673e+38 > image dimensions: zspace yspace xspace > dimension name length step start > -------------- ------ ---- ----- > zspace 256 0.859375 -110 > yspace 256 0.859375 -110 > xspace 256 -0.859375 110 > > not sure if this makes a difference, but this is the one that's giving me the > errors and pixelated output. > > Thanks for your help. > Catherine Ogilvie > > > >===== Original Message From Andrew Janke ===== > >On Wed, 8 Dec 2004, Catherine Ogilvie wrote: > > > >> Hi. I'm trying to use ana2mnc for the first time. I have had a .img and > .hdr > >> pair sent to me from another lab which uses analyze. When I run ana2mnc I > get > >> this: > >> > >> ana2mnc: sizeof header: 1543569408 > >> ana2mnc: Hrm, attempting byte-swapping on ANATcw.24_02_03_2.fid_001.hdr > >> ana2mnc: No x origin info found, guessing.. > >> ana2mnc: No y origin info found, guessing.. > >> ana2mnc: No z origin info found, guessing.. > >> > >> and a very strangely pixelated output. > > > >I'm guessing that when you tranferred the data, the header was byte swapped > and > >the data wasn't. > > > >Try this version of ana2mnc > > > > http://www.bic.mni.mcgill.ca/~rotor/distro/ana2mnc-1.3c > > > >using the -swap_data option. > > > >If this works, I'll add this feature into the next release of ana2mnc > > > > > >-- > >Andrew Janke (andrew_janke@iinet.net DOT au || www.cmr.uq.edu.au/~rotor) > >Australia->Brisbane H: +61 7 3390 6332 || M: +61 4 2138 8581 > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From cogilvie@ualberta.ca Wed Jan 26 15:20:04 2005 From: cogilvie@ualberta.ca (Catherine Ogilvie) Date: Wed Jan 26 15:20:04 2005 Subject: [MINC-users] RE: ana2mnc - resampling images Message-ID: <41FBB1D0@webmail.ualberta.ca> --sorry if this goes out twice. Hi Robert, thanks for offering to help. I've been working on this all day now using mincresample. I'm trying to change the original axial oriented images into sagittal and/or coronal orientations. The original file formats were in .hdr .img pairs. I converted them to minc using ana2mnc and this was the mincinfo: image: signed__ short 0 to 32767 image dimensions: zspace yspace xspace dimension name length step start -------------- ------ ---- ----- zspace 64 2.72727 -87.2727 yspace 256 0.859375 -110 xspace 256 -0.859375 110 This file worked fine but was optimized to axial orientation. I had our collaborators in London (who were sending me the files) convert to sagittal orientation in .hdr .img format. Then I converted that to minc format with ana2mnc on my computer. The mincinfo on that file was: image: signed__ float -1.6814541463787951101e+38 to 3.3836776830158255673e+38 image dimensions: zspace yspace xspace dimension name length step start -------------- ------ ---- ----- zspace 256 0.859375 -110 yspace 256 0.859375 -110 xspace 256 -0.859375 110 But this file didn't work - just random pixels. So... I tried to use mincresample to resample/reorient the original axial oriented image to all of these different dimensions - changing the -nelements, -step, -start for the file to: (All) image: signed__ short 0 to 32767 dimension name length step start -------------- ------ ---- ----- zspace 256 0.859375 -110 yspace 256 0.859375 -110 xspace 256 -0.859375 110 dimension name length step start -------------- ------ ---- ----- zspace 256 0.859375 -110 yspace 64 2.72727 -87.2727 xspace 256 -0.859375 110 dimension name length step start -------------- ------ ---- ----- zspace 256 0.859375 -110 yspace 256 0.859375 -110 xspace 64 -2.72727 87.2727 But none of these worked. Clearly I don't have a good understanding of the program? Any advice you can offer would be greatly appreciated! Thanks again. Catherine. >Message: 2 >Date: Mon, 24 Jan 2005 13:56:54 -0500 >From: Robert VINCENT >To: Catherine Ogilvie >cc: Andrew Janke , > The MINC mailing list >Subject: RE: [MINC-users] ana2mnc problem > >Hi Catherine, > >The revised (sagittal) files seem to be in floating-point format, whereas >the originals were in short integer format. Ana2mnc calls rawtominc, >which doesn't deal with byte-swapping floating-point datatypes. > >What was the difficulty in reorienting the MINC files? That should have >been pretty straightforward. I'll be happy to help if you're willing to >give that approach another try. > > -bert > >On Mon, 24 Jan 2005, Catherine Ogilvie wrote: > >> Andrew, the new ana2mnc program you sent me worked wonderfully. >> >> However, I then needed the images transformed into sagittal orientation. I >> tried to use the minc programs suggested by everyone on minc-users, but when I >> had a lot of difficulty I had them transformed into sagittal while in .hdr >> .img format by the group sending them to me. Now when I run the dimension >> transformed .hdr .img files on the ana2mnc program it does not turn out a >> readable format, with the repeated warning output: >> >> Warning: you specified -swap_bytes, but I can't swap this type if input >> >> I'm not sure what's happening. >> >> When I convert to minc, the dimensions of the images in original axial form >> are: >> >> image: signed__ short 0 to 32767 >> image dimensions: zspace yspace xspace >> dimension name length step start >> -------------- ------ ---- ----- >> zspace 64 2.72727 -87.2727 >> yspace 256 0.859375 -110 >> xspace 256 -0.859375 110 >> >> The dimensions in transformed sagittal form, when converted to minc, are: >> >> image: signed__ float -1.6814541463787951101e+38 to 3.3836776830158255673e+38 >> image dimensions: zspace yspace xspace >> dimension name length step start >> -------------- ------ ---- ----- >> zspace 256 0.859375 -110 >> yspace 256 0.859375 -110 >> xspace 256 -0.859375 110 >> >> not sure if this makes a difference, but this is the one that's giving me the >> errors and pixelated output. >> >> Thanks for your help. >> Catherine Ogilvie >> >> >> >===== Original Message From Andrew Janke ===== >> >On Wed, 8 Dec 2004, Catherine Ogilvie wrote: >> > >> >> Hi. I'm trying to use ana2mnc for the first time. I have had a .img and >> .hdr >> >> pair sent to me from another lab which uses analyze. When I run ana2mnc I >> get >> >> this: >> >> >> >> ana2mnc: sizeof header: 1543569408 >> >> ana2mnc: Hrm, attempting byte-swapping on ANATcw.24_02_03_2.fid_001.hdr >> >> ana2mnc: No x origin info found, guessing.. >> >> ana2mnc: No y origin info found, guessing.. >> >> ana2mnc: No z origin info found, guessing.. >> >> >> >> and a very strangely pixelated output. >> > >> >I'm guessing that when you tranferred the data, the header was byte swapped >> and >> >the data wasn't. >> > >> >Try this version of ana2mnc >> > >> > http://www.bic.mni.mcgill.ca/~rotor/distro/ana2mnc-1.3c >> > >> >using the -swap_data option. >> > >> >If this works, I'll add this feature into the next release of ana2mnc >> > >> > >> >-- >> >Andrew Janke (andrew_janke@iinet.net DOT au || www.cmr.uq.edu.au/~rotor) >> >Australia->Brisbane H: +61 7 3390 6332 || M: +61 4 2138 8581 >> >> _______________________________________________ >> MINC-users@bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users >> > > > >--__--__-- > >_______________________________________________ >MINC-users mailing list >MINC-users@bic.mni.mcgill.ca >http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > >End of MINC-users Digest From bert@bic.mni.mcgill.ca Fri Jan 28 15:48:09 2005 From: bert@bic.mni.mcgill.ca (Robert VINCENT) Date: Fri Jan 28 15:48:09 2005 Subject: [MINC-users] minc-2.0.08 available Message-ID: Hello MINC fans, We have released an update to the MINC 2.0 system. Source code is available for download at: http://www.bic.mni.mcgill.ca/~bert/minc-2.0.08.tar.gz Leila Baghdadi has created binary installer for Windows, which is available for download here: http://www.bic.mni.mcgill.ca/~bert/MINC20_INSTALLER_JAN25.exe The latest documentation for MINC is available at: http://www.bic.mni.mcgill.ca/software/minc/ Major features of this release include: * We have taken the step of including some format conversion utilities with the core MINC distribution. This release includes tools for NIfTI-1, ECAT, and Concorde microPET format. These conversion utilities should be considered preliminary and we welcome your comments and bug reports! * The MINC "simplified" programming interface code has been updated and corrected. * The "mincstats" program now includes new methods for calculating a bimodal threshold for an image. The default method remains the same, but the algorithm has been fixed to avoid problems. * Many, many bug fixes have been made to the MINC 2.0 libraries. * MINC 2.0 should now build with C99-compliant compilers. Thanks especially to Leila Baghdadi, Andrew Janke, and Anthonin Reilhac for their contributions to this release. -bert From petersv@bic.mni.mcgill.ca Fri Jan 28 15:49:06 2005 From: petersv@bic.mni.mcgill.ca (Peter Savadjiev) Date: Fri Jan 28 15:49:06 2005 Subject: [MINC-users] basic volume_io question Message-ID: Hi, I'm trying to create a 4D volume with the following snippet of code: Volume out; STRING names[4]; int sizes[4]; int s2[4]; sizes[0] = 90; sizes[1] = 40; sizes[2] = 96; sizes[3] = 128; names[0] = "time"; names[1] = "zspace"; names[2] = "yspace"; names[3] = "xspace"; out = create_volume( 4,names, FLOAT, FALSE,0,1); set_volume_sizes(out, sizes); alloc_volume_data(out); Apparently, everything is correct. Yet, when I run the code I get the following error: Error: cannot allocate array data until size specified. if I insert get_volume_sizes(out, s2); printf("%d %d %d %d\n", s2[0],s2[1],s2[2],s2[3]); between the calls to set_volume_sizes and alloc_volume_data, the sizes are printed correctly, which tells me that set_volume_sizes works properly. Could please anyone give me an idea what may be going wrong? Thank you very much for your help, Peter From bert@bic.mni.mcgill.ca Fri Jan 28 16:12:15 2005 From: bert@bic.mni.mcgill.ca (Robert VINCENT) Date: Fri Jan 28 16:12:15 2005 Subject: [MINC-users] basic volume_io question In-Reply-To: Message-ID: Hi Peter, Are you building on Linux, IRIX, or elsewhere? I've built the same code fragment on my Linux system but I do not get the same error message. -bert On Fri, 28 Jan 2005, Peter Savadjiev wrote: > Hi, > > I'm trying to create a 4D volume with the following snippet of code: > > Volume out; > STRING names[4]; > int sizes[4]; > int s2[4]; > > sizes[0] = 90; > sizes[1] = 40; > sizes[2] = 96; > sizes[3] = 128; > > names[0] = "time"; > names[1] = "zspace"; > names[2] = "yspace"; > names[3] = "xspace"; > > out = create_volume( 4,names, FLOAT, FALSE,0,1); > set_volume_sizes(out, sizes); > alloc_volume_data(out); > > > Apparently, everything is correct. Yet, when I run the code I get the > following error: > > Error: cannot allocate array data until size specified. > > if I insert > > get_volume_sizes(out, s2); > printf("%d %d %d %d\n", s2[0],s2[1],s2[2],s2[3]); > > between the calls to set_volume_sizes and alloc_volume_data, the sizes are > printed correctly, which tells me that set_volume_sizes works properly. > > Could please anyone give me an idea what may be going wrong? > > Thank you very much for your help, > > Peter > > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users >