From a.janke at gmail.com Tue Feb 1 07:49:44 2011 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 1 Feb 2011 22:49:44 +1000 Subject: [MINC-users] The future of MINC In-Reply-To: References: Message-ID: >> catalyst for this might be shifting the MINC CVS repository to >> somewhere that is more conducive to external developers. (NITRC/Google >> Code/Launchpad/etc). >> >> I couldn't agree more. Having a proper development environment would > certainly help making a leap forward in terms of external contributions and > cleaning up the installation procedure. Well then my decree is for NITRC, I know it's not really my decree to make but nonetheless I have made it. I know some of the others (launchpad, google code) are more pretty but at least NITRC is something that we (MINC people) will actually have a hope of changing/updating if the need arises. FWIW: this topic has been beaten around the BIC for a long time now, one of the concerns was keeping the MINC CVS history but the NITRC Boffins tell me that this is possible. > I had the feeling that EZminc was developped to cope with some shortcomings of the existing > libraries. EZminc to my understanding was a bit of glue between the C MINC interface and ITK for vlads needs. Sort of akin to what volume_io was originally for Dave McDonald. Still I don't think the C MINC2 interface needs changing, it works and works well. Pity none of the minc tools use it yet but that's another issue.... I think dumbing down the C MINC2 interface would be a bad idea, very few people use all the features of MINC (eg: block structured files, MINC ID's, automatic History, world + voxel co-ordinates, Big vs Little endian resistance) and most of the glue (R/Matlab/Octave/python) libraries from what I have seen take a very simplistic approach to reading a file. That is: gimmie the file, gimmie all of it, I'll put it in a big short/float array called minc.img. This approach is fine and serves a purpose (and usually well). The point is mincmath/mincaverage/mincresample/minccalc/mincstats _can_ be used on multiple MINC files that are over 10GB in size and yet only use a small amount of memory/CPU. I myself do this on a day to day basis with 19T micro-imaging data on mice/zebrafish. There are pretty much no other tools out there that can handle this sort of analysis gracefully. It's for this reason that I like MINC, it was designed to be flexible not just handle a particular users needs at the time. Thus because of the above the MINC C library is always going to be complex, and will continue to be so. >> I am going to break a taboo, but I believe that to reach a wider audience, >> it is mandatory that MINC tools work with NIFTI. Whether we like it or not, >> NIFTI is by far the most widely used format currently. Guess we should dump gcc and shift to Visual Studio then too... :) Myself I think we have "sufficient" compatibility with Nifti right now (nii2mnc, mnc2nii), I view Nifti as a transfer format not as a primary storage format but then I'm elitist. To me Nifti is overly simple. > I am currently looking into that for the NIAK nifti reader/writer, and at > this stage I don't think I mastered the subtleties ?of NIFTI space > orientation. :) The point is you can't. The different packages (SPM, FSL, etc) write and treat Nifti differently. How they write them depends on certain global variables that you won't have access to when someone sends you a file. > Getting MINC tools to enter, say, NIFTI and > produce MINC sounds dangerous, but as long as you stay in one format I don't > see major problems. Ack! count me out... Again I won't stop you/anyone doing this but I don't have plans on doing this, perhaps in a restricted application area (like fMRI) this will be fine though. > I am not sure if that outline makes sense or if this is > applicable with the existing C MINC libraries. But that's pretty much how I > do it with NIAK. Sounds reasonable and again I applaud you for writing NIAK, in time I can see it making a lot of (MATLAB/Octave) peoples lives easier. > I can only speak for my limited experience : Matlab/Octave. Emma is a pain. For quite some time now if anyone asks me about EMMA / MATLAB I have been pointing the to NIAK. > In my spare time, I am working on a MINC1 & MINC2 > reader/writer that directly use the > NETCDF and HDF5 libraries of Matlab, and this seems to work *much* better. Hrm... I did notice this :) I never have been a fan of this approach but then you are more than free to do as you want, that's the good bit of the MINC license. John Ashburner also wrote a MINC reader a yonk back in SPM that would hunt for the image variable in a netCDF file. If I could make a suggestion for NIAK and mominc it'd be this: * User installs NIAK + mominc == read MINC only, r/w Nifti * User install NIAK + MINC, r/w MINC, r/w Nifti a From jason at phenogenomics.ca Tue Feb 1 08:27:27 2011 From: jason at phenogenomics.ca (Jason Lerch) Date: Tue, 1 Feb 2011 08:27:27 -0500 Subject: [MINC-users] The future of MINC In-Reply-To: References: Message-ID: <92AB57F8-CFE1-44DF-8018-F5696F2137A5@phenogenomics.ca> On 2011-02-01, at 7:49 AM, Andrew Janke wrote: >>> catalyst for this might be shifting the MINC CVS repository to >>> somewhere that is more conducive to external developers. (NITRC/Google >>> Code/Launchpad/etc). >>> >>> I couldn't agree more. Having a proper development environment would >> certainly help making a leap forward in terms of external contributions and >> cleaning up the installation procedure. > > Well then my decree is for NITRC, I know it's not really my decree to > make but nonetheless I have made it. I know some of the others > (launchpad, google code) are more pretty but at least NITRC is > something that we (MINC people) will actually have a hope of > changing/updating if the need arises. Do they support one of the distributed version control systems yet? (git, hg, bzr, etc.) Having used them for a while now I do think that DVCS offers considerable advantages. > > FWIW: this topic has been beaten around the BIC for a long time now, > one of the concerns was keeping the MINC CVS history but the NITRC > Boffins tell me that this is possible. Most version control systems can import from CVS and keep the history - that is assuming folks haven't spend too much time mucking about in the private CVS bits for a project. The joys of CVS ... > >> I had the feeling that EZminc was developped to cope with some shortcomings of the existing >> libraries. > > EZminc to my understanding was a bit of glue between the C MINC > interface and ITK for vlads needs. Sort of akin to what volume_io was > originally for Dave McDonald. Still I don't think the C MINC2 > interface needs changing, it works and works well. Pity none of the > minc tools use it yet but that's another issue.... I think dumbing > down the C MINC2 interface would be a bad idea, very few people use > all the features of MINC (eg: block structured files, MINC ID's, > automatic History, world + voxel co-ordinates, Big vs Little endian > resistance) and most of the glue (R/Matlab/Octave/python) libraries > from what I have seen take a very simplistic approach to reading a > file. That is: gimmie the file, gimmie all of it, I'll put it in a big > short/float array called minc.img. This approach is fine and serves a > purpose (and usually well). The point is > mincmath/mincaverage/mincresample/minccalc/mincstats _can_ be used on > multiple MINC files that are over 10GB in size and yet only use a > small amount of memory/CPU. > > I myself do this on a day to day basis with 19T micro-imaging data on > mice/zebrafish. There are pretty much no other tools out there that > can handle this sort of analysis gracefully. It's for this reason that > I like MINC, it was designed to be flexible not just handle a > particular users needs at the time. Thus because of the above the MINC > C library is always going to be complex, and will continue to be so. I completely agree with you - MINC is complex because it needs to be. Though I do think the glue libraries can access most of the complexity where need be. > >>> I am going to break a taboo, but I believe that to reach a wider audience, >>> it is mandatory that MINC tools work with NIFTI. Whether we like it or not, >>> NIFTI is by far the most widely used format currently. > > Guess we should dump gcc and shift to Visual Studio then too... :) > > Myself I think we have "sufficient" compatibility with Nifti right now > (nii2mnc, mnc2nii), I view Nifti as a transfer format not as a primary > storage format but then I'm elitist. To me Nifti is overly simple. Agreed. MINC = neuroawesome, NIFTI = pain. > > >> In my spare time, I am working on a MINC1 & MINC2 >> reader/writer that directly use the >> NETCDF and HDF5 libraries of Matlab, and this seems to work *much* better. > > Hrm... I did notice this :) I never have been a fan of this approach > but then you are more than free to do as you want, that's the good bit > of the MINC license. I also don't much like this approach either - why not use libminc, it already handles all the NETCDF and HDF5 bits for you and this ensures that you stay compatible with any MINC file, not just a subset. Later, Jason From nic.kassis at gmail.com Tue Feb 1 10:10:45 2011 From: nic.kassis at gmail.com (Nicolas Kassis) Date: Tue, 1 Feb 2011 10:10:45 -0500 Subject: [MINC-users] The future of MINC In-Reply-To: <92AB57F8-CFE1-44DF-8018-F5696F2137A5@phenogenomics.ca> References: <92AB57F8-CFE1-44DF-8018-F5696F2137A5@phenogenomics.ca> Message-ID: On Tue, Feb 1, 2011 at 8:27 AM, Jason Lerch wrote: > > On 2011-02-01, at 7:49 AM, Andrew Janke wrote: > >>>> catalyst for this might be shifting the MINC CVS repository to >>>> somewhere that is more conducive to external developers. (NITRC/Google >>>> Code/Launchpad/etc). >>>> >>>> I couldn't agree more. Having a proper development environment would >>> certainly help making a leap forward in terms of external contributions and >>> cleaning up the installation procedure. >> >> Well then my decree is for NITRC, I know it's not really my decree to >> make but nonetheless I have made it. ?I know some of the others >> (launchpad, google code) are more pretty but at least NITRC is >> something that we (MINC people) will actually have a hope of >> changing/updating if the need arises. > > Do they support one of the distributed version control systems yet? (git, hg, bzr, etc.) Having used them for a while now I do think that DVCS offers considerable advantages. If this is of any help: The LORIS team and CBrain team in Alan's lab are starting to use Git (and Github) for source control. I highly recommend it. Nicolas Kassis From michel.audette at kitware.com Tue Feb 1 11:20:58 2011 From: michel.audette at kitware.com (Michel Audette) Date: Tue, 1 Feb 2011 11:20:58 -0500 Subject: [MINC-users] most descriptive brain atlas? Message-ID: Dear fellow MINC users and developers, can any of you point me out to the most descriptive brain atlas available in open-source? I know of the Harvard SPL atlas, but I also know that there research going on, including at the MNI, towards the co-registration of histological slices, which I assume comes with a large amount of anatomical labels. Cheers, Michel -- Michel Audette, Ph.D. R & D Engineer, Kitware Inc., Chapel Hill, N.C. From sean at rogue-research.com Tue Feb 1 11:47:07 2011 From: sean at rogue-research.com (Sean McBride) Date: Tue, 1 Feb 2011 11:47:07 -0500 Subject: [MINC-users] The future of MINC In-Reply-To: References: <92AB57F8-CFE1-44DF-8018-F5696F2137A5@phenogenomics.ca> Message-ID: <20110201164707.344044335@mail.rogue-research.com> On Tue, 1 Feb 2011 10:10:45 -0500, Nicolas Kassis said: >>> Well then my decree is for NITRC, I know it's not really my decree to >>> make but nonetheless I have made it. ?I know some of the others >>> (launchpad, google code) are more pretty but at least NITRC is >>> something that we (MINC people) will actually have a hope of >>> changing/updating if the need arises. >> >> Do they support one of the distributed version control systems yet? >(git, hg, bzr, etc.) Having used them for a while now I do think that >DVCS offers considerable advantages. > >If this is of any help: >The LORIS team and CBrain team in Alan's lab are starting to use Git >(and Github) for source control. I highly recommend it. +1 for git and github.com. -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From a.janke at gmail.com Tue Feb 1 23:22:44 2011 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 2 Feb 2011 14:22:44 +1000 Subject: [MINC-users] The future of MINC In-Reply-To: <92AB57F8-CFE1-44DF-8018-F5696F2137A5@phenogenomics.ca> References: <92AB57F8-CFE1-44DF-8018-F5696F2137A5@phenogenomics.ca> Message-ID: >> Well then my decree is for NITRC, I know it's not really my decree to >> make but nonetheless I have made it. ?I know some of the others >> (launchpad, google code) are more pretty but at least NITRC is >> something that we (MINC people) will actually have a hope of >> changing/updating if the need arises. > > Do they support one of the distributed version control systems yet? (git, hg, bzr, etc.) Having used them for a while now I do think that DVCS offers considerable advantages. Nope not yet. CVS or SVN for now it would seem. So in an attempt to canvas public MINC opinion for those who do MINC dev please take a few moments to add your comments here: http://en.wikibooks.org/wiki/MINC/Future You don't have to register a username to edit. -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Brisbane->Australia +61 (402) 700 883 From giovanna.pellecchia at camhpet.ca Wed Feb 2 12:54:45 2011 From: giovanna.pellecchia at camhpet.ca (Giovanna Pellecchia) Date: Wed, 02 Feb 2011 12:54:45 -0500 Subject: [MINC-users] The future of MINC Message-ID: <4D499A65.30606@camhpet.ca> Howdy all, the debate is taking an interesting turn, especially after Louis Collins' offer (and not for the reasons you may think!). I have a limited experience with MINC, but if you are interested in expanding the MINC end-user base, with the ultimate goal of generating more MINC development, maybe my experience might be representative of the world out there. I joined Antonio Strafella's lab here in Toronto in 2006 and started by installing the MINC tools on his computers. The most frustrating issue for a newbie was that I could not find a single accessible place where to get code, packages, documentation and help. Finding the right tools still requires an insider's knowledge and there is no user-friendly documentation to be found. As a complete outsider of the BIC and isolated from the MINC community at large, I would have been in deep trouble, if it had not been for Jason Lerch (who trained at the MNI), who helped me with finding the code, understanding abstruse compiling errors, pointing at known (for long-time MINC users) issues, and making everything work seamlessly. There are a few contributors who are extremely prolific, but as it stands now, MINC is a closed community of people who used to know each other. As I see it, unless MINC is able to generate a wider interest, it will not trigger more development or original contributions. It is a more general issue than just deciding where to shift the code development. That's why I think Louis Collins' offer hits the mark. Increasing the end-user base requires an investment in training and tutoring, and may require (an) ?official? coordinator(s) that deploy(s) resources as seen fit by the community. I am certain that there are a few labs, like mine, who are developing with the MINC world and would be happy to contribute, if not with good code at least with good documentation, if given a chance to do so in a simple and welcoming way. Just my one cent. Cheers, Giovanna. From shahin at bic.mni.mcgill.ca Wed Feb 2 21:12:34 2011 From: shahin at bic.mni.mcgill.ca (Shahin Zangenehpour) Date: Wed, 2 Feb 2011 21:12:34 -0500 Subject: [MINC-users] problem with converting microPET files to MINC format Message-ID: Hi All, Does anyone have any idea why I get the following error msg when trying to use the "upet2mnc" command to convert a Concord microPET file to MINC format? Many thanks for your help. Shahin Starting conversion - Input header: A1205_01-11-10_v2FBP.img.hdr - Input image: A1205_01-11-10_v2FBP.img - Output file: A1205_01-11-10_v2FBP.mnc WARNING: Unrecognized keyword manufacturer WARNING: Unrecognized keyword manufacturer WARNING: Unrecognized keyword modality WARNING: Unrecognized keyword modality WARNING: Unrecognized keyword modality_configuration WARNING: Unrecognized keyword modality_configuration WARNING: Unrecognized keyword bed_control WARNING: Unrecognized keyword bed_control WARNING: Unrecognized keyword number_of_bed_positions WARNING: Unrecognized keyword number_of_bed_positions WARNING: Unrecognized keyword horizontal_bed_calibration WARNING: Unrecognized keyword horizontal_bed_calibration WARNING: Unrecognized keyword vertical_bed_calibration WARNING: Unrecognized keyword vertical_bed_calibration WARNING: Unrecognized keyword number_detector_panels WARNING: Unrecognized keyword number_detector_panels Swapping groups of 4 bytes. WARNING: Unrecognized keyword acquisition_user_id WARNING: Unrecognized keyword acquisition_user_id WARNING: Unrecognized keyword histogram_user_id WARNING: Unrecognized keyword histogram_user_id WARNING: Unrecognized keyword reconstruction_user_id WARNING: Unrecognized keyword reconstruction_user_id WARNING: Unrecognized keyword scatter_correction_user_id WARNING: Unrecognized keyword scatter_correction_user_id WARNING: Unrecognized keyword acquisition_notes WARNING: Unrecognized keyword acquisition_notes WARNING: Unrecognized keyword gmt_scan_time WARNING: Unrecognized keyword gmt_scan_time WARNING: Unrecognized keyword volume_origin_x WARNING: Unrecognized keyword volume_origin_x WARNING: Unrecognized keyword volume_origin_y WARNING: Unrecognized keyword volume_origin_y WARNING: Unrecognized keyword volume_origin_z WARNING: Unrecognized keyword volume_origin_z WARNING: Unrecognized keyword registration_available WARNING: Unrecognized keyword registration_available WARNING: Unrecognized keyword transformation_matrix WARNING: Unrecognized keyword transformation_matrix WARNING: Unrecognized keyword spatial_identifier WARNING: Unrecognized keyword spatial_identifier WARNING: Unrecognized keyword pixel_size_x WARNING: Unrecognized keyword pixel_size_x WARNING: Unrecognized keyword pixel_size_y WARNING: Unrecognized keyword pixel_size_y WARNING: Unrecognized keyword pixel_size_z WARNING: Unrecognized keyword pixel_size_z WARNING: Unrecognized keyword subject_date_of_birth WARNING: Unrecognized keyword subject_date_of_birth WARNING: Unrecognized keyword subject_age WARNING: Unrecognized keyword subject_age WARNING: Unrecognized keyword subject_sex WARNING: Unrecognized keyword subject_sex WARNING: Unrecognized keyword subject_scan_region WARNING: Unrecognized keyword subject_scan_region WARNING: Unrecognized keyword acquisition_file_name WARNING: Unrecognized keyword acquisition_file_name WARNING: Unrecognized keyword activity_units WARNING: Unrecognized keyword activity_units WARNING: Unrecognized keyword activity_before_injection WARNING: Unrecognized keyword activity_before_injection WARNING: Unrecognized keyword activity_before_injection_time WARNING: Unrecognized keyword activity_before_injection_time WARNING: Unrecognized keyword residual_activity WARNING: Unrecognized keyword residual_activity WARNING: Unrecognized keyword residual_activity_time WARNING: Unrecognized keyword residual_activity_time WARNING: Unrecognized keyword subject_glucose_level WARNING: Unrecognized keyword subject_glucose_level WARNING: Unrecognized keyword subject_glucose_level_time WARNING: Unrecognized keyword subject_glucose_level_time ncvardef: ncid 5: Invalid dimension id or name micreate_std_variable: MINC package entry point From lconcha at gmail.com Thu Feb 3 12:36:43 2011 From: lconcha at gmail.com (Luis Concha) Date: Thu, 3 Feb 2011 11:36:43 -0600 Subject: [MINC-users] The future of MINC Message-ID: Hello all. Very interesting discussion regarding the future of MINC. I would like to support Giovanna's comments regarding the end-users. As I see it, you have this opportunity to improve MINC, but it should happen at two different levels: (i) development issues, which have already been addressed in previous posts, but, importantly, (ii) usability. Granted, minc users tend to not be black-box users, but they are not necessarily programmers. With notable exceptions, the minc tools are seen as obscure outside of the BIC, which is a shame, given how fantastic they are. When someone tells me this, I always feel sorry for them, because they are truly missing out. But I also do not blame them; minc tools are obscure, indeed. I will not repeat what Giovanna said, but will only urge you to consider making improvements beyond the development level. worth 1/2 cent. Luis > > Message: 1 > Date: Wed, 02 Feb 2011 12:54:45 -0500 > From: Giovanna Pellecchia > Subject: Re: [MINC-users] The future of MINC > To: minc-users at bic.mni.mcgill.ca > Message-ID: <4D499A65.30606 at camhpet.ca> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Howdy all, > the debate is taking an interesting turn, especially after Louis > Collins' offer (and not for the reasons you may think!). > > I have a limited experience with MINC, but if you are interested in > expanding the MINC end-user base, with the ultimate goal of generating > more MINC development, maybe my experience might be representative of > the world out there. > > I joined Antonio Strafella's lab here in Toronto in 2006 and started by > installing the MINC tools on his computers. > > The most frustrating issue for a newbie was that I could not find a > single accessible place where to get code, packages, documentation and > help. Finding the right tools still requires an insider's knowledge and > there is no user-friendly documentation to be found. > As a complete outsider of the BIC and isolated from the MINC community > at large, I would have been in deep trouble, if it had not been for > Jason Lerch (who trained at the MNI), who helped me with finding the > code, understanding abstruse compiling errors, pointing at known (for > long-time MINC users) issues, and making everything work seamlessly. > > There are a few contributors who are extremely prolific, but as it > stands now, MINC is a closed community of people who used to know each > other. As I see it, unless MINC is able to generate a wider interest, it > will not trigger more development or original contributions. It is a > more general issue than just deciding where to shift the code development. > That's why I think Louis Collins' offer hits the mark. Increasing the > end-user base requires an investment in training and tutoring, and may > require (an) ?official? coordinator(s) that deploy(s) resources as seen > fit by the community. > > I am certain that there are a few labs, like mine, who are developing > with the MINC world and would be happy to contribute, if not with good > code at least with good documentation, if given a chance to do so in a > simple and welcoming way. > > Just my one cent. > Cheers, > Giovanna. > > > From pierre.bellec at criugm.qc.ca Thu Feb 3 14:52:23 2011 From: pierre.bellec at criugm.qc.ca (Pierre Bellec) Date: Thu, 3 Feb 2011 14:52:23 -0500 Subject: [MINC-users] The future of MINC In-Reply-To: <4D499A65.30606@camhpet.ca> References: <4D499A65.30606@camhpet.ca> Message-ID: Dear MINC users list, Here's a follow-up on the lattest contributions regarding "the future of MINC" to keep the ball rolling. @Giovanna Thanks a lot for taking the time of expressing your views. We would need more contributions of this kind from people that can be legitimately identified as end-users, rather than insiders that spent a couple of years at the MNI coding applications within or around MINC. Needless to say I totally second your diagnosis : it is currently hard to make any use of the potential of MINC without first-hand training with an enlightened one. We could definitely use contributions in the form of documentation, the MINC wikibook is already in place and a friendly medium to do that. We would still need a roadmap before starting up the work though. @ Andrew > I had the feeling that EZminc was developped to cope with some > shortcomings of the existing > > libraries. > > EZminc to my understanding was a bit of glue between the C MINC > interface and ITK for vlads needs. Sort of akin to what volume_io was > originally for Dave McDonald. Still I don't think the C MINC2 > interface needs changing, it works and works well. Pity none of the > minc tools use it yet but that's another issue.... I think dumbing > down the C MINC2 interface would be a bad idea, very few people use > all the features of MINC (eg: block structured files, MINC ID's, > automatic History, world + voxel co-ordinates, Big vs Little endian > resistance) and most of the glue (R/Matlab/Octave/python) libraries > from what I have seen take a very simplistic approach to reading a > file. That is: gimmie the file, gimmie all of it, I'll put it in a big > short/float array called minc.img. This approach is fine and serves a > purpose (and usually well). The point is > mincmath/mincaverage/mincresample/minccalc/mincstats _can_ be used on > multiple MINC files that are over 10GB in size and yet only use a > small amount of memory/CPU. > > I myself do this on a day to day basis with 19T micro-imaging data on > mice/zebrafish. There are pretty much no other tools out there that > can handle this sort of analysis gracefully. It's for this reason that > I like MINC, it was designed to be flexible not just handle a > particular users needs at the time. Thus because of the above the MINC > C library is always going to be complex, and will continue to be so. > The "Gimmie the file, gimmie all of it" approach clearly is what most coders will want. The simpler the better. fMRI datasets are comparable in size to a 5 Mpixels digital picture. Complex code designed to spare memory in that context is a waste of time. The push for higher resolution may be a valid rationale to keep that level of complexity (even though a 160G SSD is ~400$ at futureshop). If there is something already in place (EZminc) that can simplify the life of some developpers, why not support both libraries rather than stick to the most complex one only ? > > >> I am going to break a taboo, but I believe that to reach a wider > audience, > >> it is mandatory that MINC tools work with NIFTI. Whether we like it or > not, > >> NIFTI is by far the most widely used format currently. > > Guess we should dump gcc and shift to Visual Studio then too... :) > Myself I think we have "sufficient" compatibility with Nifti right now > (nii2mnc, mnc2nii), I view Nifti as a transfer format not as a primary > storage format but then I'm elitist. To me Nifti is overly simple. > Well, we disagree on that one. If NIFTI is good enough for FSL and SPM it should be good enough for us. I don't want to start a full NIFTI vs MINC debate here (on which I am sure we would agree point by point anyway), but NIFTI is an established file format that is widely used. A lot of existing databases are in NIFTI and asking to users to first convert everything before using the MINC tools is quite dissuasive. Most importantly, for someone like me who wants to develop on top of the MINC tools and obviously want to provide support for NIFTI, the support of NIFTI is a major feature. I found my way around the lack of NIFTI support, but I am pretty sure this has discouraged a fair amount of potential contributors in the past. I don't want to unilaterally disclose names here, but spontaneous testimonies are welcomed ;) > > I am currently looking into that for the NIAK nifti reader/writer, and at > > this stage I don't think I mastered the subtleties of NIFTI space > > orientation. > > :) The point is you can't. The different packages (SPM, FSL, etc) > write and treat Nifti differently. How they write them depends on > certain global variables that you won't have access to when someone > sends you a file. > > Well, I agree that ANALYZE is absolute chaos, and does not have orientation infos built in anyway. See this excellent post by Jimmy Shen at the Rotman for details. By contrast, NIFTI seems to have a clear convention, as explained in the NIFTI FAQ. It is right-handed (i.e. left's on the left). More specifically X = left to right, Y = posterior to anterior, Z = ventral to dorsal. From the voxel-to-world LSQ12 transformation matrix, it is relatively straightfoward to pull out the start, steps, direction cosines and dimension order. So at this stage I don't see the problem. You obviously experienced some problems first-hand, so would you mind sharing some confusing cases you encountered ? > > Getting MINC tools to enter, say, NIFTI and > > produce MINC sounds dangerous, but as long as you stay in one format I > don't > > see major problems. > > Ack! count me out... Again I won't stop you/anyone doing this but I > don't have plans on doing this, perhaps in a restricted application > area (like fMRI) this will be fine though. I am sorry to hear that you think this is not worth the effort. > > In my spare time, I am working on a MINC1 & MINC2 > > reader/writer that directly use the > > NETCDF and HDF5 libraries of Matlab, and this seems to work *much* > better. > > Hrm... I did notice this :) I never have been a fan of this approach > but then you are more than free to do as you want, that's the good bit > of the MINC license. John Ashburner also wrote a MINC reader a yonk > back in SPM that would hunt for the image variable in a netCDF file. > If I could make a suggestion for NIAK and mominc it'd be this: > > * User installs NIAK + mominc == read MINC only, r/w Nifti > > * User install NIAK + MINC, r/w MINC, r/w Nifti > > I see one major advantage to build a reader/writer based on native NetCDF/HDF5 libraries : you download the routines and you're done. Nothing to compile, no dependency to install. I am curious to see how the NiPY community will react to the Python MINC2 IO tool of Jason for example (great job BTW, that convinced me to start using python for some projects). It does add a dependency on the development MINC libraries. Not a problem for MINC developers, but will it make it to the standard distribution of NiBabel ? we'll see. In Matlab/Octave I want to avoid compilation if I can. What I like about the libminc2 library option (called in MEX) is that it would work for both Octave and Matlab. I'll think about it :). In any case, the specifications of MINC2 are pretty clean and it is fully HDF5 compliant as far as I can see. I thus don't see why taking that route would be a problem in principle. You're not the first one telling me that the reader's OK but the writer would fail. I haven't tried the writer yet (my reader 90% fine and fully fixable I believe) but is there a dirty secret I should know ? Best regards, Pierre Bellec, PhD Chercheur adjoint Centre de recherche de l'institut de G?riatrie de Montr?al D?partement d'informatique et de recherche op?rationnelle Universit? de Montr?al http://simexp-lab.org/brainwiki/doku.php?id=pierrebellec (001)(514) 340 3540 #3367 2011/2/2 Giovanna Pellecchia > Howdy all, > the debate is taking an interesting turn, especially after Louis Collins' > offer (and not for the reasons you may think!). > > I have a limited experience with MINC, but if you are interested in > expanding the MINC end-user base, with the ultimate goal of generating more > MINC development, maybe my experience might be representative of the world > out there. > > I joined Antonio Strafella's lab here in Toronto in 2006 and started by > installing the MINC tools on his computers. > > The most frustrating issue for a newbie was that I could not find a single > accessible place where to get code, packages, documentation and help. > Finding the right tools still requires an insider's knowledge and there is > no user-friendly documentation to be found. > As a complete outsider of the BIC and isolated from the MINC community at > large, I would have been in deep trouble, if it had not been for Jason Lerch > (who trained at the MNI), who helped me with finding the code, understanding > abstruse compiling errors, pointing at known (for long-time MINC users) > issues, and making everything work seamlessly. > > There are a few contributors who are extremely prolific, but as it stands > now, MINC is a closed community of people who used to know each other. As I > see it, unless MINC is able to generate a wider interest, it will not > trigger more development or original contributions. It is a more general > issue than just deciding where to shift the code development. > That's why I think Louis Collins' offer hits the mark. Increasing the > end-user base requires an investment in training and tutoring, and may > require (an) ?official? coordinator(s) that deploy(s) resources as seen fit > by the community. > > I am certain that there are a few labs, like mine, who are developing with > the MINC world and would be happy to contribute, if not with good code at > least with good documentation, if given a chance to do so in a simple and > welcoming way. > > Just my one cent. > Cheers, > Giovanna. > > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From vladimir.fonov at gmail.com Thu Feb 3 15:58:30 2011 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Thu, 03 Feb 2011 15:58:30 -0500 Subject: [MINC-users] The future of MINC In-Reply-To: References: <4D499A65.30606@camhpet.ca> Message-ID: <4D4B16F6.1000107@gmail.com> Hello Everybody, looks like I missed this somehow. Pierre Bellec wrote: > @ Andrew >> I had the feeling that EZminc was developped to cope with some >> shortcomings of the existing >>> libraries. >> EZminc to my understanding was a bit of glue between the C MINC >> interface and ITK for vlads needs. Sort of akin to what volume_io was >> originally for Dave McDonald. Still I don't think the C MINC2 >> interface needs changing, it works and works well. Pity none of the >> minc tools use it yet but that's another issue.... I think dumbing >> down the C MINC2 interface would be a bad idea, very few people use >> all the features of MINC (eg: block structured files, MINC ID's, >> automatic History, world + voxel co-ordinates, Big vs Little endian >> resistance) and most of the glue (R/Matlab/Octave/python) libraries >> from what I have seen take a very simplistic approach to reading a >> file. That is: gimmie the file, gimmie all of it, I'll put it in a big >> short/float array called minc.img. This approach is fine and serves a >> purpose (and usually well). The point is >> mincmath/mincaverage/mincresample/minccalc/mincstats _can_ be used on >> multiple MINC files that are over 10GB in size and yet only use a >> small amount of memory/CPU. 1. ezminc allows to open a minc file and read/write it slice-by-slice. So, I have programs dealing with 100s of files simultaneously, with total amount of data exceeding total memory several times. This part does not translate to ITK ,though. 2. I don't know how easy volume_io really is. Everybody whom I know who used it at some point, basically hit a stone wall trying to solve intensity normalization problem. Slice normalization and ICV is still a bit of a black magick for me, especially when I am dealing with discrete values. 3. Right now there are two independent APIs - one legacy which allows one to access minc1 and minc2 files and a new one, which only works with minc2. I gave up on newer api after I learned (several years ago) that there are still unsolved problems, again related to intensity normalization. -- Best regards, Vladimir S. FONOV ~ v.s.fonov ilmarin.info From jason at phenogenomics.ca Thu Feb 3 17:26:16 2011 From: jason at phenogenomics.ca (Jason Lerch) Date: Thu, 3 Feb 2011 17:26:16 -0500 Subject: [MINC-users] The future of MINC In-Reply-To: <4D4B16F6.1000107@gmail.com> References: <4D499A65.30606@camhpet.ca> Message-ID: <3B9C4A3C-128E-434B-9A84-5A7A9988F61C@phenogenomics.ca> > > > 3. Right now there are two independent APIs - one legacy which allows one to access minc1 and minc2 files and a new one, which only works with minc2. I gave up on newer api after I learned (several years ago) that there are still unsolved problems, again related to intensity normalization. > Out of curiosity - and this is clearly off-topic for this thread - what are the problems with intensity normalization in libminc2? Jason > -- > Best regards, > Vladimir S. FONOV ~ v.s.fonov ilmarin.info > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From vladimir.fonov at gmail.com Thu Feb 3 17:57:39 2011 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Thu, 03 Feb 2011 17:57:39 -0500 Subject: [MINC-users] The future of MINC In-Reply-To: <3B9C4A3C-128E-434B-9A84-5A7A9988F61C@phenogenomics.ca> References: <4D499A65.30606@camhpet.ca> <3B9C4A3C-128E-434B-9A84-5A7A9988F61C@phenogenomics.ca> Message-ID: <4D4B32E3.5040802@gmail.com> Hello, you wrote: >> 3. Right now there are two independent APIs - one legacy which allows one to access minc1 and minc2 files and a new one, which only works with minc2. I gave up on newer api after I learned (several years ago) that there are still unsolved problems, again related to intensity normalization. >> > > Out of curiosity - and this is clearly off-topic for this thread - what are the problems with intensity normalization in libminc2? I don't remember, and probably they were fixed since. But i needed to read and write minc files back then. -- Best regards, Vladimir S. FONOV ~ v.s.fonov ilmarin.info From jason at phenogenomics.ca Sat Feb 5 10:17:42 2011 From: jason at phenogenomics.ca (Jason Lerch) Date: Sat, 5 Feb 2011 10:17:42 -0500 Subject: [MINC-users] The future of MINC In-Reply-To: References: <4D499A65.30606@camhpet.ca> Message-ID: <3DEE6142-402B-4863-BE6E-A10DB5617C87@phenogenomics.ca> Hi Pierre, >> > I see one major advantage to build a reader/writer based on native > NetCDF/HDF5 libraries : you download the routines and you're done. Nothing > to compile, no dependency to install. I am curious to see how the NiPY > community will react to the Python MINC2 IO tool of Jason for example (great > job BTW, that convinced me to start using python for some projects). It does > add a dependency on the development MINC libraries. Not a problem for MINC > developers, but will it make it to the standard distribution of NiBabel ? > we'll see. In Matlab/Octave I want to avoid compilation if I can. What I > like about the libminc2 library option (called in MEX) is that it would work > for both Octave and Matlab. I'll think about it :). In any case, the > specifications of MINC2 are pretty clean and it is fully HDF5 compliant as > far as I can see. I thus don't see why taking that route would be a problem > in principle. You're not the first one telling me that the reader's OK but > the writer would fail. I haven't tried the writer yet (my reader 90% fine > and fully fixable I believe) but is there a dirty secret I should know ? The dirty secret, such as it is, is two-fold as far as I understand it (and I might very well be missing something obvious too). * while I don't doubt that you can get a correct MINC implementation by making all the appropriate NetCDF and HDF5 calls, the risk of avoiding the MINC libs is that subtly incompatible volumes will be created which we then have to work around in the future. This can be avoided with some care, I'm sure, but has the potential to be tricky. * the more important one is forward incompatibility. Any desired change to how MINC reads and writes volumes (such as the switch from NetCDF to HDF5) will now have to consistently be coded in more than one place. Having the MINC2 lib not read MINC1 files already leads to enough mayhem, so the thought that going forward different tools will read a different range of MINC files scares me. So with that in mind we have to make libminc has ubiquitous and easy to install as possible so that a dependency on it causes little penalty. Jason From sean at rogue-research.com Mon Feb 7 15:02:04 2011 From: sean at rogue-research.com (Sean McBride) Date: Mon, 7 Feb 2011 15:02:04 -0500 Subject: [MINC-users] The future of MINC In-Reply-To: <3DEE6142-402B-4863-BE6E-A10DB5617C87@phenogenomics.ca> References: <3DEE6142-402B-4863-BE6E-A10DB5617C87@phenogenomics.ca> Message-ID: <20110207200204.411886104@mail.rogue-research.com> On Sat, 5 Feb 2011 10:17:42 -0500, Jason Lerch said: >The dirty secret, such as it is, is two-fold as far as I understand it >(and I might very well be missing something obvious too). > >* while I don't doubt that you can get a correct MINC implementation by >making all the appropriate NetCDF and HDF5 calls, the risk of avoiding >the MINC libs is that subtly incompatible volumes will be created which >we then have to work around in the future. This can be avoided with some >care, I'm sure, but has the potential to be tricky. >* the more important one is forward incompatibility. Any desired change >to how MINC reads and writes volumes (such as the switch from NetCDF to >HDF5) will now have to consistently be coded in more than one place. >Having the MINC2 lib not read MINC1 files already leads to enough >mayhem, so the thought that going forward different tools will read a >different range of MINC files scares me. > >So with that in mind we have to make libminc has ubiquitous and easy to >install as possible so that a dependency on it causes little penalty. VTK's MINC reader/writer use NetCDF directly: IIRC, the reason was exactly because building libminc has several dependancies and is a pain to build. -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From lwthucs at gmail.com Mon Feb 7 21:05:17 2011 From: lwthucs at gmail.com (Li Wei) Date: Tue, 8 Feb 2011 10:05:17 +0800 Subject: [MINC-users] ON Building the ezminc examples Message-ID: Hi All: I have a trouble when dealing with the ezminc examples when linking. I have installed the minc in the folder (/usr/local) as the prefix. I have checked the /usr/local/lib/ for the libraries and they are all there. The error reported is like follows: Linking CXX executable any_itk_any ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::history() const': minc_1_rw.cpp:(.text+0x60e): undefined reference to `MI2attinq(int, int, char const*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::var_number() const': minc_1_rw.cpp:(.text+0x78c): undefined reference to `MI2inquire(int, int*, int*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::var_name(int) const': However, I have used nm to check the /usr/local/lib/libminc2.a it shows $ nm libminc2.a |grep MI2attinq U MI2attinq U MI2attinq U MI2attinq 000000b0 T MI2attinq U MI2attinq I have set the cmake path MINC path to /usr/local but I am not sure what I have done wrong. Hope for your kind help. Thanks -- Best Regards, LI Wei IIIS, Tsinghua University From vladimir.fonov at gmail.com Tue Feb 8 14:54:09 2011 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Tue, 8 Feb 2011 14:54:09 -0500 Subject: [MINC-users] ON Building the ezminc examples In-Reply-To: References: Message-ID: Hello Everybody, I found the source of this problem in minc.h header (part of minc distribution). Inside there are some definitions of functions surrounded by usual. #ifdef __cplusplus extern "C" { #endif /* __cplusplus */ ... blah ... #ifdef __cplusplus } #endif /* __cplusplus */ but, some functions are defined in minc_compat.h which doesn't have this preprocessor macros. The quick fix for ezminc to compile is to edit file minc_io/minc_1_rw.h and replace #include with extern "C" { #include } But Ideally minc.h should be fixed instead. P.S. Strangely enough problem doesn't seem to manifest itself with gcc 4.3 and older. On Mon, Feb 7, 2011 at 9:05 PM, Li Wei wrote: > Hi All: > > I have a trouble when dealing with the ezminc examples when linking. I have > installed the minc in the folder (/usr/local) as the prefix. I have checked > the /usr/local/lib/ for the libraries and they are all there. The error > reported is like follows: > > Linking CXX executable any_itk_any > ../minc_io/libminc_io.a(minc_1_rw.o): In function > `minc::minc_1_base::history() const': > minc_1_rw.cpp:(.text+0x60e): undefined reference to `MI2attinq(int, int, > char const*, int*, int*)' > ../minc_io/libminc_io.a(minc_1_rw.o): In function > `minc::minc_1_base::var_number() const': > minc_1_rw.cpp:(.text+0x78c): undefined reference to `MI2inquire(int, int*, > int*, int*, int*)' > ../minc_io/libminc_io.a(minc_1_rw.o): In function > `minc::minc_1_base::var_name(int) const': > > However, I have used nm to check the /usr/local/lib/libminc2.a it shows > > $ nm libminc2.a |grep MI2attinq > ? ? ? ? U MI2attinq > ? ? ? ? U MI2attinq > ? ? ? ? U MI2attinq > 000000b0 T MI2attinq > ? ? ? ? U MI2attinq > > I have set the cmake path MINC path to /usr/local but I am not sure what I > have done wrong. Hope for your kind help. Thanks > > -- > Best Regards, > LI Wei > IIIS, Tsinghua University > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > -- Best regards, ?Vladimir S. Fonov ~ vladimir fonov gmail com From a.janke at gmail.com Tue Feb 8 22:14:02 2011 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 9 Feb 2011 13:14:02 +1000 Subject: [MINC-users] ON Building the ezminc examples In-Reply-To: References: Message-ID: Hi Vladimir, On 9 February 2011 05:54, Vladimir S. FONOV wrote: > I found the source of this problem in minc.h header (part of minc > distribution). Inside there are some definitions of functions > surrounded by usual. > > #ifdef __cplusplus > extern "C" { > #endif /* __cplusplus */ > > ... blah ... > > #ifdef __cplusplus > } > #endif /* __cplusplus */ Hrm, do you include minc_compat.h yourself or is this because of minc.h including it directly? I am guessing the latter so I have fixed this in CVS, can you please try your EZMINC build against this. Thanks -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Brisbane->Australia +61 (402) 700 883 From vladimir.fonov at gmail.com Wed Feb 9 14:37:56 2011 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Wed, 09 Feb 2011 14:37:56 -0500 Subject: [MINC-users] ON Building the ezminc examples In-Reply-To: References: Message-ID: <4D52ED14.5070208@gmail.com> Hello, it seem to fix the problem. In the meantime before this change propagates into official minc release, people can use ezminc version r80: http://www.bic.mni.mcgill.ca/~vfonov/software/ezminc-r80.tar.gz Andrew Janke wrote: > Hi Vladimir, > > On 9 February 2011 05:54, Vladimir S. FONOV wrote: >> I found the source of this problem in minc.h header (part of minc >> distribution). Inside there are some definitions of functions >> surrounded by usual. >> >> #ifdef __cplusplus >> extern "C" { >> #endif /* __cplusplus */ >> >> ... blah ... >> >> #ifdef __cplusplus >> } >> #endif /* __cplusplus */ > > Hrm, do you include minc_compat.h yourself or is this because of > minc.h including it directly? I am guessing the latter so I have > fixed this in CVS, can you please try your EZMINC build against this. -- Best regards, Vladimir S. FONOV ~ v.s.fonov ilmarin.info From lrisa87 at uw.edu Wed Feb 9 18:25:09 2011 From: lrisa87 at uw.edu (Lisa F. Akiyama) Date: Wed, 9 Feb 2011 15:25:09 -0800 Subject: [MINC-users] xv error (mincview) on Ubuntu / make_model error Message-ID: Hello, I am using MINC on Ubuntu 10.10. I am facing two problems at the moment: 1) I get an error saying that the xv command is missing when I try to run mincview: todd at neptune-ubuntu:~/Desktop/SF6-noneck-notcoreg/mritotal$ mincview > 6mth_ucla_little_endian_clean.mnc > Loading > slices...........................................................................................................................................Done > xv: Command not found. > Is there a need for me to install xv following steps such as those listed here?: http://www.halibutdepot.org/xv/building_xv_on_ubuntu.html 2) When running make_model, I get errors saying that it was unable to open the ...mask.mnc files. No mask.mnc files are created (only dxyz.mnc's and blur.mnc's have been created). todd at neptune-ubuntu:~/Desktop/SF6-noneck-notcoreg/mritotal$ make_model > 6mth_ucla_little_endian_clean > Using base filename 6mth_ucla_little_endian_clean > Note that your input volume *must* be in Talairach space for this to work > ** Making 6mth_ucla_little_endian_clean_pad.mnc from > 6mth_ucla_little_endian_clean.mnc by resampling on 2mm grid and padding by > 16mm > [autocrop] [todd at neptune-ubuntu:/home/todd/Desktop/SF6-noneck-notcoreg/mritotal] > [2011-02-09 13:12:46] /usr/local/bic/bin/mincresample -clobber > 6mth_ucla_little_endian_clean.mnc 6mth_ucla_little_endian_clean_pad.mnc > -start -83.8711 -98.0312 -89.2422 -step 2 2 2 -nelements 84 99 90 > Transforming > slices:....................................................................................Done > ** Building 16mm data for 6mth_ucla_little_endian_clean > Making byte volume... > [autocrop] [todd at neptune-ubuntu:/home/todd/Desktop/SF6-noneck-notcoreg/mritotal] > [2011-02-09 13:12:47] /usr/local/bic/bin/mincreshape -clobber > tmp_16_blur.mnc 6mth_ucla_little_endian_clean_16_blur.mnc -start 8,8,18 > -count 68,83,54 > Copying > chunks:....................................................................Done. > *(from miopen): Unable to open file > '6mth_ucla_little_endian_clean_mask.mnc'* > ncvarid: ncid -1: NetCDF: Not a valid ID > ** Building 8mm data for 6mth_ucla_little_endian_clean > Making byte volume... > Transforming > slices:....................................................................................Done > Making byte volume dx...Making byte volume dy...Making byte volume > dz...[autocrop] [todd at neptune-ubuntu:/home/todd/Desktop/SF6-noneck-notcoreg/mritotal] > [2011-02-09 13:12:48] /usr/local/bic/bin/mincreshape -clobber tmp_8_blur.mnc > 6mth_ucla_little_endian_clean_8_blur.mnc -start 8,8,13 -count 68,83,64 > Copying > chunks:....................................................................Done. > [autocrop] [todd at neptune-ubuntu:/home/todd/Desktop/SF6-noneck-notcoreg/mritotal] > [2011-02-09 13:12:48] /usr/local/bic/bin/mincreshape -clobber tmp_8_dxyz.mnc > 6mth_ucla_little_endian_clean_8_dxyz.mnc -start 8,8,13 -count 68,83,64 > Copying > chunks:....................................................................Done. > *(from miopen): Unable to open file > '6mth_ucla_little_endian_clean_mask.mnc' > ncvarid: ncid -1: NetCDF: Not a valid ID* > ** Making 6mth_ucla_little_endian_clean_pad4.mnc from > 6mth_ucla_little_endian_clean.mnc by padding by 4mm > [autocrop] [todd at neptune-ubuntu:/home/todd/Desktop/SF6-noneck-notcoreg/mritotal] > [2011-02-09 13:12:48] /usr/local/bic/bin/mincreshape -clobber > 6mth_ucla_little_endian_clean.mnc 6mth_ucla_little_endian_clean_pad4.mnc > -start -4,-4,-4 -count 149,177,160 > Copying > chunks:.....................................................................................................................................................Done. > ** Building 4mm data for 6mth_ucla_little_endian_clean > Making byte volume... > Transforming > slices:.....................................................................................................................................................Done > Making byte volume dx...Making byte volume dy...Making byte volume > dz...[autocrop] [todd at neptune-ubuntu:/home/todd/Desktop/SF6-noneck-notcoreg/mritotal] > [2011-02-09 13:12:53] /usr/local/bic/bin/mincreshape -clobber tmp_4_blur.mnc > 6mth_ucla_little_endian_clean_4_blur.mnc -start 9,9,9 -count 132,160,143 > Copying > chunks:....................................................................................................................................Done. > [autocrop] [todd at neptune-ubuntu:/home/todd/Desktop/SF6-noneck-notcoreg/mritotal] > [2011-02-09 13:12:53] /usr/local/bic/bin/mincreshape -clobber tmp_4_dxyz.mnc > 6mth_ucla_little_endian_clean_4_dxyz.mnc -start 9,9,9 -count 132,160,143 > Copying > chunks:....................................................................................................................................Done. > *(from miopen): Unable to open file > '6mth_ucla_little_endian_clean_mask.mnc' > ncvarid: ncid -1: NetCDF: Not a valid ID* > ** Building 2mm data for 6mth_ucla_little_endian_clean > Making byte volume... > Transforming > slices:.....................................................................................................................................................Done > Making byte volume dx...Making byte volume dy...Making byte volume > dz...[autocrop] [todd at neptune-ubuntu:/home/todd/Desktop/SF6-noneck-notcoreg/mritotal] > [2011-02-09 13:12:58] /usr/local/bic/bin/mincreshape -clobber tmp_2_blur.mnc > 6mth_ucla_little_endian_clean_2_blur.mnc -start 7,7,7 -count 136,164,147 > Copying > chunks:........................................................................................................................................Done. > [autocrop] [todd at neptune-ubuntu:/home/todd/Desktop/SF6-noneck-notcoreg/mritotal] > [2011-02-09 13:12:58] /usr/local/bic/bin/mincreshape -clobber tmp_2_dxyz.mnc > 6mth_ucla_little_endian_clean_2_dxyz.mnc -start 7,7,7 -count 136,164,147 > Copying > chunks:........................................................................................................................................Done. > *(from miopen): Unable to open file > '6mth_ucla_little_endian_clean_mask.mnc' > ncvarid: ncid -1: NetCDF: Not a valid ID* > Any tips on how to tackle these two problems? Thank you in advance. Best, Lisa From nic.kassis at gmail.com Wed Feb 9 18:27:17 2011 From: nic.kassis at gmail.com (Nicolas Kassis) Date: Wed, 9 Feb 2011 18:27:17 -0500 Subject: [MINC-users] MacOS-X MINC 2.1 In-Reply-To: References: Message-ID: Hi, I was just trying out the portfile that Haz-Edine created (Thank you for that). I get an error during compilation. It seems to choke on image_conversion.c line 206. It can't find MAX_NC_OPEN Here is the tail for the macport install run: :info:build if /bin/sh ./libtool --mode=compile /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I. -I. -I./libsrc -I./volume_io/Include -I./volume_io/Include -I./progs/Proglib -I./conversion/Acr_nema -I/opt/local/include -I/opt/local/include -pipe -O2 -arch x86_64 -MT libsrc/image_conversion.lo -MD -MP -MF "$depbase.Tpo" -c -o libsrc/image_conversion.lo libsrc/image_conversion.c; \ :info:build then mv -f "$depbase.Tpo" "$depbase.Plo"; else rm -f "$depbase.Tpo"; exit 1; fi :info:build /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I. -I. -I./libsrc -I./volume_io/Include -I./volume_io/Include -I./progs/Proglib -I./conversion/Acr_nema -I/opt/local/include -I/opt/local/include -pipe -O2 -arch x86_64 -MT libsrc/image_conversion.lo -MD -MP -MF libsrc/.deps/image_conversion.Tpo -c libsrc/image_conversion.c -o libsrc/image_conversion.o :info:build libsrc/image_conversion.c: In function 'miicv_create': :info:build libsrc/image_conversion.c:206: error: 'MAX_NC_OPEN' undeclared (first use in this function) :info:build libsrc/image_conversion.c:206: error: (Each undeclared identifier is reported only once :info:build libsrc/image_conversion.c:206: error: for each function it appears in.) :info:build make[2]: *** [libsrc/image_conversion.lo] Error 1 :info:build make[2]: *** Waiting for unfinished jobs.... :info:build echo timestamp > libsrc/dim_conversion.lo :info:build make[1]: *** [all-recursive] Error 1 :info:build make: *** [all] Error 2 :info:build shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_science_minc/work/minc-1.4" && /usr/bin/make -j2 all " returned error 2 :error:build Target org.macports.build returned: shell command failed (see log for details) :debug:build Backtrace: shell command failed (see log for details) while executing "command_exec build" (procedure "portbuild::build_main" line 8) invoked from within "$procedure $targetname" :info:build Warning: the following items did not execute (for minc): org.macports.activate org.macports.build org.macports.destroot org.macports.install :notice:build Log for minc is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_science_minc/main.log I hope someone can help :) Nicolas Kassis GBrain Developer ACE Lab On Thu, Oct 21, 2010 at 11:05 AM, Haz-Edine Assemlal - L. Collins Lab wrote: > Hi everyone, > > I have updated the MacPort of MINC 2.1 so it compiles fine on Snow Leopard. > The corresponding Portfile is attached in this email. > > Best, > Haz-Edine > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > -- ----------------- Nicolas Kassis From sean at rogue-research.com Wed Feb 9 18:35:57 2011 From: sean at rogue-research.com (Sean McBride) Date: Wed, 9 Feb 2011 18:35:57 -0500 Subject: [MINC-users] MacOS-X MINC 2.1 In-Reply-To: References: Message-ID: <20110209233557.1796572085@mail.rogue-research.com> On Wed, 9 Feb 2011 18:27:17 -0500, Nicolas Kassis said: >I was just trying out the portfile that Haz-Edine created (Thank you >for that). I get an error during compilation. It seems to choke on >image_conversion.c line 206. It can't find MAX_NC_OPEN I reported that 1.5 years ago: -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From a.janke at gmail.com Wed Feb 9 18:38:16 2011 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 10 Feb 2011 09:38:16 +1000 Subject: [MINC-users] MacOS-X MINC 2.1 In-Reply-To: References: Message-ID: Hi Nicolas, On 10 February 2011 09:27, Nicolas Kassis wrote: > I was just trying out the portfile that Haz-Edine created (Thank you > for that). I get an error during compilation. It seems to choke on > image_conversion.c line 206. It can't find MAX_NC_OPEN Are you sure you are using MINC 2.1? This bug (MAX_NC_OPEN) was squashed in MINC 2.0.19 as this is no longer defined in netcdf. In the meantime, the problem can be worked around by just replacing all occurrences of MAX_NC_OPEN with 32. > Here is the tail for the macport install run: > > :info:build ? ? if /bin/sh ./libtool --mode=compile /usr/bin/gcc-4.2 > -DHAVE_CONFIG_H -I. -I. -I. -I./libsrc -I./volume_io/Include > -I./volume_io/Include -I./progs/Proglib -I./conversion/Acr_nema > -I/opt/local/include -I/opt/local/include ?-pipe -O2 -arch x86_64 -MT > libsrc/image_conversion.lo -MD -MP -MF "$depbase.Tpo" -c -o -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Brisbane->Australia +61 (402) 700 883 From a.janke at gmail.com Wed Feb 9 18:46:17 2011 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 10 Feb 2011 09:46:17 +1000 Subject: [MINC-users] MacOS-X MINC 2.1 In-Reply-To: <20110209233557.1796572085@mail.rogue-research.com> References: <20110209233557.1796572085@mail.rogue-research.com> Message-ID: > I reported that 1.5 years ago: > > Aye, and thus my confusion regarding the subject line.. harold:tmp$ wget http://packages.bic.mni.mcgill.ca/tgz/minc-2.1.00.tar.gz --2011-02-10 09:42:13-- http://packages.bic.mni.mcgill.ca/tgz/minc-2.1.00.tar.gz Resolving packages.bic.mni.mcgill.ca... 132.206.178.83 Connecting to packages.bic.mni.mcgill.ca|132.206.178.83|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1652852 (1.6M) [application/x-tar] Saving to: `minc-2.1.00.tar.gz' 100%[==========================================================================================================================>] 1,652,852 --.-K/s in 0.1s 2011-02-10 09:42:13 (11.0 MB/s) - `minc-2.1.00.tar.gz' saved [1652852/1652852] harold:tmp$ tar zxf minc-2.1.00.tar.gz harold:tmp$ cd minc-2.1.00/ harold:minc-2.1.00$ grep -r MAX_NC_OPEN * ChangeLog: * libsrc/minc.h: replaced MAX_NC_OPEN with 32 ChangeLog: * libsrc/voxel_loop.c: replaced MAX_NC_OPEN with MI_MAX_NUM_ICV libsrc/voxel_loop.c: * * libsrc/minc.h: replaced MAX_NC_OPEN with 32 libsrc/voxel_loop.c: * * libsrc/voxel_loop.c: replaced MAX_NC_OPEN with MI_MAX_NUM_ICV libsrc/minc.h: * * libsrc/minc.h: replaced MAX_NC_OPEN with 32 libsrc/minc.h: * * libsrc/voxel_loop.c: replaced MAX_NC_OPEN with MI_MAX_NUM_ICV libsrc/minc.h:/* changed to 32 as netcdf 4.x no longer defines MAX_NC_OPEN */ libsrc/minc.h:/* #define MI_MAX_NUM_ICV MAX_NC_OPEN */ Nicolas, is it possible that you are inadvertently linking/building against an older version of MINC hidden somewhere on your machine? -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Brisbane->Australia +61 (402) 700 883 From nic.kassis at gmail.com Wed Feb 9 18:57:16 2011 From: nic.kassis at gmail.com (Nicolas Kassis) Date: Wed, 9 Feb 2011 18:57:16 -0500 Subject: [MINC-users] MacOS-X MINC 2.1 In-Reply-To: References: <20110209233557.1796572085@mail.rogue-research.com> Message-ID: Yeah I press send way to fast :P Someone I made a mistake and the port for minc 1.4 was taking precedence of the port for minc 2.1.00. That's entirely my fault. It's compiling fine now. Sorry for the false alarm. Nic On Wed, Feb 9, 2011 at 6:46 PM, Andrew Janke wrote: >> I reported that 1.5 years ago: >> >> > > Aye, and thus my confusion regarding the subject line.. > > harold:tmp$ wget http://packages.bic.mni.mcgill.ca/tgz/minc-2.1.00.tar.gz > --2011-02-10 09:42:13-- > http://packages.bic.mni.mcgill.ca/tgz/minc-2.1.00.tar.gz > Resolving packages.bic.mni.mcgill.ca... 132.206.178.83 > Connecting to packages.bic.mni.mcgill.ca|132.206.178.83|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 1652852 (1.6M) [application/x-tar] > Saving to: `minc-2.1.00.tar.gz' > > 100%[==========================================================================================================================>] > 1,652,852 ? --.-K/s ? in 0.1s > > 2011-02-10 09:42:13 (11.0 MB/s) - `minc-2.1.00.tar.gz' saved [1652852/1652852] > > harold:tmp$ tar zxf minc-2.1.00.tar.gz > harold:tmp$ cd minc-2.1.00/ > harold:minc-2.1.00$ grep -r MAX_NC_OPEN * > ChangeLog: ? * libsrc/minc.h: replaced MAX_NC_OPEN with 32 > ChangeLog: ? * libsrc/voxel_loop.c: replaced MAX_NC_OPEN with MI_MAX_NUM_ICV > libsrc/voxel_loop.c: * ?* libsrc/minc.h: replaced MAX_NC_OPEN with 32 > libsrc/voxel_loop.c: * ?* libsrc/voxel_loop.c: replaced MAX_NC_OPEN > with MI_MAX_NUM_ICV > libsrc/minc.h: * ?* libsrc/minc.h: replaced MAX_NC_OPEN with 32 > libsrc/minc.h: * ?* libsrc/voxel_loop.c: replaced MAX_NC_OPEN with > MI_MAX_NUM_ICV > libsrc/minc.h:/* changed to 32 as netcdf 4.x no longer defines MAX_NC_OPEN */ > libsrc/minc.h:/* #define MI_MAX_NUM_ICV MAX_NC_OPEN */ > > Nicolas, is it possible that you are inadvertently linking/building > against an older version of MINC hidden somewhere on your machine? > > > -- > Andrew Janke > (a.janke at gmail.com || http://a.janke.googlepages.com/) > Brisbane->Australia ? ?+61 (402) 700 883 > -- ----------------- Nicolas Kassis From nic.kassis at gmail.com Wed Feb 9 18:58:19 2011 From: nic.kassis at gmail.com (Nicolas Kassis) Date: Wed, 9 Feb 2011 18:58:19 -0500 Subject: [MINC-users] MacOS-X MINC 2.1 In-Reply-To: References: <20110209233557.1796572085@mail.rogue-research.com> Message-ID: Above email is more proof that I'm a little fast on the send button. /facepalm Nic On Wed, Feb 9, 2011 at 6:57 PM, Nicolas Kassis wrote: > Yeah I press send way to fast :P > > Someone I made a mistake and the port for minc 1.4 was taking > precedence of the port for minc 2.1.00. That's entirely my fault. It's > compiling fine now. > > Sorry for the false alarm. > > Nic > > On Wed, Feb 9, 2011 at 6:46 PM, Andrew Janke wrote: >>> I reported that 1.5 years ago: >>> >>> >> >> Aye, and thus my confusion regarding the subject line.. >> >> harold:tmp$ wget http://packages.bic.mni.mcgill.ca/tgz/minc-2.1.00.tar.gz >> --2011-02-10 09:42:13-- >> http://packages.bic.mni.mcgill.ca/tgz/minc-2.1.00.tar.gz >> Resolving packages.bic.mni.mcgill.ca... 132.206.178.83 >> Connecting to packages.bic.mni.mcgill.ca|132.206.178.83|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 1652852 (1.6M) [application/x-tar] >> Saving to: `minc-2.1.00.tar.gz' >> >> 100%[==========================================================================================================================>] >> 1,652,852 ? --.-K/s ? in 0.1s >> >> 2011-02-10 09:42:13 (11.0 MB/s) - `minc-2.1.00.tar.gz' saved [1652852/1652852] >> >> harold:tmp$ tar zxf minc-2.1.00.tar.gz >> harold:tmp$ cd minc-2.1.00/ >> harold:minc-2.1.00$ grep -r MAX_NC_OPEN * >> ChangeLog: ? * libsrc/minc.h: replaced MAX_NC_OPEN with 32 >> ChangeLog: ? * libsrc/voxel_loop.c: replaced MAX_NC_OPEN with MI_MAX_NUM_ICV >> libsrc/voxel_loop.c: * ?* libsrc/minc.h: replaced MAX_NC_OPEN with 32 >> libsrc/voxel_loop.c: * ?* libsrc/voxel_loop.c: replaced MAX_NC_OPEN >> with MI_MAX_NUM_ICV >> libsrc/minc.h: * ?* libsrc/minc.h: replaced MAX_NC_OPEN with 32 >> libsrc/minc.h: * ?* libsrc/voxel_loop.c: replaced MAX_NC_OPEN with >> MI_MAX_NUM_ICV >> libsrc/minc.h:/* changed to 32 as netcdf 4.x no longer defines MAX_NC_OPEN */ >> libsrc/minc.h:/* #define MI_MAX_NUM_ICV MAX_NC_OPEN */ >> >> Nicolas, is it possible that you are inadvertently linking/building >> against an older version of MINC hidden somewhere on your machine? >> >> >> -- >> Andrew Janke >> (a.janke at gmail.com || http://a.janke.googlepages.com/) >> Brisbane->Australia ? ?+61 (402) 700 883 >> > > > > -- > ----------------- > Nicolas Kassis > -- ----------------- Nicolas Kassis From a.janke at gmail.com Wed Feb 9 18:59:58 2011 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 10 Feb 2011 09:59:58 +1000 Subject: [MINC-users] MacOS-X MINC 2.1 In-Reply-To: References: <20110209233557.1796572085@mail.rogue-research.com> Message-ID: > Someone I made a mistake and the port for minc 1.4 was taking > precedence of the port for minc 2.1.00. That's entirely my fault. It's > compiling fine now. > > Sorry for the false alarm. No worries, I like problems like this (That either solve themselves or aren't). a From a.janke at gmail.com Wed Feb 9 20:47:12 2011 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 10 Feb 2011 11:47:12 +1000 Subject: [MINC-users] xv error (mincview) on Ubuntu / make_model error In-Reply-To: References: Message-ID: Hi Lisa, On 10 February 2011 09:25, Lisa F. Akiyama wrote: > I am using MINC on Ubuntu 10.10. > I am facing two problems at the moment: > > 1) I get an error saying that the xv command is missing when I try to run > mincview: > > todd at neptune-ubuntu:~/Desktop/SF6-noneck-notcoreg/mritotal$ mincview >> 6mth_ucla_little_endian_clean.mnc >> Loading >> slices...........................................................................................................................................Done >> xv: Command not found. mincview is a bit of MINC history that has been left in if only because some users still want it. Sadly the xv licence prohibits people from distributing modified versions and thus it is not included in many linux distributions such as Ubuntu. It was for this reason that I wrote mincpik using imagemagicks convert+display functions. Is there is a specific reason for wanting to use mincview? all it does is display a set of slices that is probably better done with mincpik, if you just want to view data I'd recommend register or Display. Two other old warhorses that seem to also just keep on going. > Is there a need for me to install xv following steps such as those listed > here?: http://www.halibutdepot.org/xv/building_xv_on_ubuntu.html Well that certainly is the easiest way to get xv to work. :( > 2) When running make_model, I get errors saying that it was unable to open > the ...mask.mnc files. > No mask.mnc files are created (only dxyz.mnc's and blur.mnc's have been > created). make_model requires that you have your model.mnc, model_headmask.mnc and model_mask.mnc all in the same folder so you should have these three files: 6mth_ucla_little_endian_clean.mnc 6mth_ucla_little_endian_clean_mask.mnc (mask of cortical structures) 6mth_ucla_little_endian_clean_headmask.mnc (mask of the whole head) at which point you can then say: make_model 6mth_ucla_little_endian_clean and use your model with mritotal. -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Brisbane->Australia +61 (402) 700 883 From lrisa87 at uw.edu Thu Feb 10 12:39:15 2011 From: lrisa87 at uw.edu (Lisa F. Akiyama) Date: Thu, 10 Feb 2011 09:39:15 -0800 Subject: [MINC-users] xv error (mincview) on Ubuntu / make_model error In-Reply-To: References: Message-ID: Hi Andrew, Thanks for all your tips. >Displaying minc files I was simply trying to use mincview because it was stated in a (probably outdated) tutorial I had found. I tried using mincpik, but got a strange string of odd symbols and alphabets. When I ran display, the ImageMagick window opened and I was able to select a file, but got an error saying: > display: no decode delegate for this image format `15331.mnc' @ > error/constitute.c/ReadImage/532. > > make_model Are there minc commands to create these mask and headmask files? Thank you. Best, Lisa On Wed, Feb 9, 2011 at 5:47 PM, Andrew Janke wrote: > Hi Lisa, > > On 10 February 2011 09:25, Lisa F. Akiyama wrote: > > I am using MINC on Ubuntu 10.10. > > I am facing two problems at the moment: > > > > 1) I get an error saying that the xv command is missing when I try to run > > mincview: > > > > todd at neptune-ubuntu:~/Desktop/SF6-noneck-notcoreg/mritotal$ mincview > >> 6mth_ucla_little_endian_clean.mnc > >> Loading > >> > slices...........................................................................................................................................Done > >> xv: Command not found. > > mincview is a bit of MINC history that has been left in if only > because some users still want it. Sadly the xv licence prohibits > people from distributing modified versions and thus it is not included > in many linux distributions such as Ubuntu. It was for this reason > that I wrote mincpik using imagemagicks convert+display functions. > > Is there is a specific reason for wanting to use mincview? all it > does is display a set of slices that is probably better done with > mincpik, if you just want to view data I'd recommend register or > Display. Two other old warhorses that seem to also just keep on > going. > > > Is there a need for me to install xv following steps such as those listed > > here?: http://www.halibutdepot.org/xv/building_xv_on_ubuntu.html > > Well that certainly is the easiest way to get xv to work. :( > > > 2) When running make_model, I get errors saying that it was unable to > open > > the ...mask.mnc files. > > No mask.mnc files are created (only dxyz.mnc's and blur.mnc's have been > > created). > > make_model requires that you have your model.mnc, model_headmask.mnc > and model_mask.mnc all in the same folder so you should have these > three files: > > 6mth_ucla_little_endian_clean.mnc > 6mth_ucla_little_endian_clean_mask.mnc (mask of cortical > structures) > 6mth_ucla_little_endian_clean_headmask.mnc (mask of the whole head) > > at which point you can then say: > > make_model 6mth_ucla_little_endian_clean > > and use your model with mritotal. > > > -- > Andrew Janke > (a.janke at gmail.com || http://a.janke.googlepages.com/) > Brisbane->Australia +61 (402) 700 883 > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From a.janke at gmail.com Mon Feb 14 02:10:59 2011 From: a.janke at gmail.com (Andrew Janke) Date: Mon, 14 Feb 2011 17:10:59 +1000 Subject: [MINC-users] xv error (mincview) on Ubuntu / make_model error In-Reply-To: References: Message-ID: > I was simply trying to use mincview because it was stated in a (probably > outdated) tutorial I had found. > I tried using mincpik, but got a strange string of odd symbols and > alphabets. > When I ran display, the ImageMagick window opened and I was able to select a > file, but got an error saying: > >> display: no decode delegate for this image format `15331.mnc' @ >> error/constitute.c/ReadImage/532. mincpik is made to create single images rather than display a series of images from a single dataset. mincpik expects something like this: $ mincpik -slice 20 -axial infile.mnc slice-20.jpg To create a JPG image of slice 20 in the axial direction. I have also decided that it's also time to update mincview, so have had a quick go at converting it to a bash shell script and also converted it from xv to display which is much more available on most linux distributions. (debian/ubuntu is: $ sudo apt-get install imagemagick). You can give it a try here: http://httpd.cai.uq.edu.au/~rotor/minc-beta/mincview In display you use the space bar to advance to the next image. For the MINC CVS types this change is now also committed to CVS as this removes both the xv and tcsh dependency in MINC. >> make_model > Are there minc commands to create these mask and headmask files? It really depends on the application, sometimes this can be done with simple thresholding and sometimes you have to manually trace this or use a tool like FSL's BET. -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Brisbane->Australia +61 (402) 700 883 From assemlal at cim.mcgill.ca Mon Feb 14 14:54:19 2011 From: assemlal at cim.mcgill.ca (Haz-Edine Assemlal) Date: Mon, 14 Feb 2011 14:54:19 -0500 Subject: [MINC-users] MINC files support for CImg and GMIC Message-ID: <9F5DA787-C757-4D75-8BFD-C9A9625A59A1@cim.mcgill.ca> Dear MINC users, I am glad to announce the support for MINC files in the CImg library, an open source C++ toolkit for image processing (http://cimg.sourceforge.net/). It also means that the GMIC software, an interpreter of image processing macros, now supports MINC files as well. Since a picture is worth a thousand words, here is an illustration of displaying a 3D image. $gmic anat_minc2.mnc GMIC supports many other image formats and has a lot of interesting features, e.g., statistics, denoising, registration. Check the demo gallery for more details http://gmic.sourceforge.net/gallery.shtml. I'm attaching the Portfile to this email for OSX users, the packages for Linux and Windows users should be available soon. You can build it now from the sources available at http://sourceforge.net/projects/gmic/files. Note that the support is still beta and is meant to improve in the near future. As such, please report any bug you may encounter to the sourceforge forums or directly to me :) Sincerely, Haz-Edine From assemlal at cim.mcgill.ca Mon Feb 14 15:19:13 2011 From: assemlal at cim.mcgill.ca (Haz-Edine Assemlal) Date: Mon, 14 Feb 2011 15:19:13 -0500 Subject: [MINC-users] MINC files support for CImg and GMIC In-Reply-To: <9F5DA787-C757-4D75-8BFD-C9A9625A59A1@cim.mcgill.ca> References: <9F5DA787-C757-4D75-8BFD-C9A9625A59A1@cim.mcgill.ca> Message-ID: The link to the screenshot.. http://img585.imageshack.us/i/screenshot20110214at227.png/ and the link to the MacOSX Portfile. http://www.megaupload.com/?d=ERB50W4L -HE On 2011-02-14, at 2:54 PM, Haz-Edine Assemlal wrote: > Dear MINC users, > > I am glad to announce the support for MINC files in the CImg library, an open source C++ toolkit for image processing (http://cimg.sourceforge.net/). > > It also means that the GMIC software, an interpreter of image processing macros, now supports MINC files as well. Since a picture is worth a thousand words, here is an illustration of displaying a 3D image. > > $gmic anat_minc2.mnc > > > > > GMIC supports many other image formats and has a lot of interesting features, e.g., statistics, denoising, registration. Check the demo gallery for more details http://gmic.sourceforge.net/gallery.shtml. > > I'm attaching the Portfile to this email for OSX users, the packages for Linux and Windows users should be available soon. You can build it now from the sources available at http://sourceforge.net/projects/gmic/files. > > Note that the support is still beta and is meant to improve in the near future. As such, please report any bug you may encounter to the sourceforge forums or directly to me :) > > Sincerely, > Haz-Edine > > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From lrisa87 at uw.edu Mon Feb 14 19:02:54 2011 From: lrisa87 at uw.edu (Lisa F. Akiyama) Date: Mon, 14 Feb 2011 16:02:54 -0800 Subject: [MINC-users] xv error (mincview) on Ubuntu / make_model error In-Reply-To: References: Message-ID: Hi Andrew, >mincview THANKS a lot! The new mincview works just fine. >masks and headmasks Thanks for the tips - I will play around and see what works the best. Best, Lisa ______________________________ Lisa F. Akiyama Research Study Assistant Institute for Learning & Brain Sciences (I-LABS) University of Washington Portage Bay Building, BOX 357988 Seattle, WA 98195-7988 U.S.A. E-mail: lrisa87 at uw.edu P Please consider the environment before printing this e-mail. On Sun, Feb 13, 2011 at 11:10 PM, Andrew Janke wrote: > > I was simply trying to use mincview because it was stated in a (probably > > outdated) tutorial I had found. > > I tried using mincpik, but got a strange string of odd symbols and > > alphabets. > > When I ran display, the ImageMagick window opened and I was able to > select a > > file, but got an error saying: > > > >> display: no decode delegate for this image format `15331.mnc' @ > >> error/constitute.c/ReadImage/532. > > mincpik is made to create single images rather than display a series > of images from a single dataset. mincpik expects something like this: > > $ mincpik -slice 20 -axial infile.mnc slice-20.jpg > > To create a JPG image of slice 20 in the axial direction. > > I have also decided that it's also time to update mincview, so have > had a quick go at converting it to a bash shell script and also > converted it from xv to display which is much more available on most > linux distributions. (debian/ubuntu is: $ sudo apt-get install > imagemagick). You can give it a try here: > > http://httpd.cai.uq.edu.au/~rotor/minc-beta/mincview > > In display you use the space bar to advance to the next image. For the > MINC CVS types this change is now also committed to CVS as this > removes both the xv and tcsh dependency in MINC. > > >> make_model > > Are there minc commands to create these mask and headmask files? > > It really depends on the application, sometimes this can be done with > simple thresholding and sometimes you have to manually trace this or > use a tool like FSL's BET. > > > > -- > Andrew Janke > (a.janke at gmail.com || http://a.janke.googlepages.com/) > Brisbane->Australia +61 (402) 700 883 > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From a.janke at gmail.com Mon Feb 14 20:21:29 2011 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 15 Feb 2011 11:21:29 +1000 Subject: [MINC-users] MINC files support for CImg and GMIC In-Reply-To: <9F5DA787-C757-4D75-8BFD-C9A9625A59A1@cim.mcgill.ca> References: <9F5DA787-C757-4D75-8BFD-C9A9625A59A1@cim.mcgill.ca> Message-ID: Hi Haz-Edine, On Tue, Feb 15, 2011 at 05:54, Haz-Edine Assemlal wrote: > I am glad to announce the support for MINC files in the CImg library, an open source C++ toolkit for image processing (http://cimg.sourceforge.net/). Great work! Would you mind adding a small section about this to the MINC wikibooks page: http://en.wikibooks.org/wiki/MINC Perhaps we need another section on the main page called bindings or something that we can then add all the python/MATLAB/etc bindings too. Thanks -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Brisbane->Australia +61 (402) 700 883 From a.janke at gmail.com Mon Feb 14 20:31:03 2011 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 15 Feb 2011 11:31:03 +1000 Subject: [MINC-users] The future of MINC In-Reply-To: <4D499A65.30606@camhpet.ca> References: <4D499A65.30606@camhpet.ca> Message-ID: > The most frustrating issue for a newbie was that I could not find a single > accessible place where to get code, packages, documentation and help. > Finding the right tools still requires an insider's knowledge and there is > no user-friendly documentation to be found. Well this was the hope for: http://en.wikibooks.org/wiki/MINC > It is a more general > issue than just deciding where to shift the code development. Agree but it does sort of go hand in hand > I am certain that there are a few labs, like mine, who are developing with > the MINC world and would be happy to contribute, if not with good code at > least with good documentation, if given a chance to do so in a simple and > welcoming way. I am more than interested in how we/I can change things to allow you to write documentation and/or add code. -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Brisbane->Australia +61 (402) 700 883 From a.janke at gmail.com Mon Feb 14 20:36:08 2011 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 15 Feb 2011 11:36:08 +1000 Subject: [MINC-users] The future of MINC In-Reply-To: References: <92AB57F8-CFE1-44DF-8018-F5696F2137A5@phenogenomics.ca> Message-ID: >> Do they support one of the distributed version control systems yet? (git, hg, bzr, etc.) Having used them for a while now I do think that DVCS offers considerable advantages. > > Nope not yet. ?CVS or SVN for now it would seem. The announcement has been made, NITRC now does git. http://www.nitrc.org/plugins/mwiki/index.php/nitrc:NITRC_Release_Notes#NITRC_Pre-Release_v2.0.5-0_-_2.2F14.2F2011 http://www.nitrc.org/plugins/mwiki/index.php/nitrc:User_Guide_-_Git_Administration -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Brisbane->Australia +61 (402) 700 883 From nikelski at bic.mni.mcgill.ca Tue Feb 15 14:28:40 2011 From: nikelski at bic.mni.mcgill.ca (EJ Nikelski) Date: Tue, 15 Feb 2011 11:28:40 -0800 Subject: [MINC-users] Building minc under Snow Leopard Message-ID: Hi minc-users, I'm encountering a weird problem building the current minc under OSX 10.6.6. Briefly, I build: (1) hdf5-1.8.5 (make check is OK) (2) netcdf-3.6.3 (make check is OK) (3) minc 2.1.00 The minc build is without error, but when I "make check" I get an immediate error in ../volume_io/Testing/check_xfm.sh. Looking at the program (test-xfm), I note all is working OK, but upon reaching the final "return 0", control returns back to the top of main(), and starts again, suggesting ... stack corruption? ... I dunno. Additionally, if I do a "file test-xfm" I get: "test-xfm: POSIX shell script text executable" I get the same response for all minc executables. Doing this for, for example, a netcdf executable, I get a more expected result: file /usr/local/bic/bin/ncgen --> "/usr/local/bic/bin/ncgen: Mach-O 64-bit executable x86_64" So, something is seriously wrong with my minc build. Ideas? -jim -- ================================= Jim Nikelski, Ph.D. Postdoctoral Research Fellow Bloomfield Centre for Research in Aging Lady Davis Institute for Medical Research Sir Mortimer B. Davis - Jewish General Hospital McGill University From nikelski at bic.mni.mcgill.ca Tue Feb 15 15:49:25 2011 From: nikelski at bic.mni.mcgill.ca (EJ Nikelski) Date: Tue, 15 Feb 2011 12:49:25 -0800 Subject: [MINC-users] Building minc under Snow Leopard In-Reply-To: References: Message-ID: Hi again, Just a quick update -- the apparent multiple main() execution has been addressed (a silly error on my part). I still don't know why "file myMincExecutable" does not show these executables as such. I'll continue digging around ... -jim On Tue, Feb 15, 2011 at 11:28 AM, EJ Nikelski wrote: > Hi minc-users, > > ? I'm encountering a weird problem building the current minc under > OSX 10.6.6. Briefly, I build: > > (1) hdf5-1.8.5 (make check is OK) > (2) netcdf-3.6.3 (make check is OK) > (3) minc 2.1.00 > > ?The minc build is without error, but when I "make check" I get an > immediate error in ../volume_io/Testing/check_xfm.sh. Looking at the > program (test-xfm), I note all is working OK, but upon reaching the > final "return 0", control returns back to the top of main(), and > starts again, suggesting ... stack corruption? ... I dunno. > > ?Additionally, if I do a "file test-xfm" I get: > "test-xfm: POSIX shell script text executable" > > ?I get the same response for all minc executables. Doing this for, > for example, a netcdf executable, I get a more expected result: > file /usr/local/bic/bin/ncgen --> "/usr/local/bic/bin/ncgen: Mach-O > 64-bit executable x86_64" > > ?So, something is seriously wrong with my minc build. Ideas? > > > -jim > > > -- > ================================= > Jim Nikelski, Ph.D. > Postdoctoral Research Fellow > Bloomfield Centre for Research in Aging > Lady Davis Institute for Medical Research > Sir Mortimer B. Davis - Jewish General Hospital > McGill University > -- ================================= Jim Nikelski, Ph.D. Postdoctoral Research Fellow Bloomfield Centre for Research in Aging Lady Davis Institute for Medical Research Sir Mortimer B. Davis - Jewish General Hospital McGill University From nikelski at bic.mni.mcgill.ca Tue Feb 15 21:15:02 2011 From: nikelski at bic.mni.mcgill.ca (EJ Nikelski) Date: Tue, 15 Feb 2011 18:15:02 -0800 Subject: [MINC-users] minc "make check" error -- not just a Snow Leopard problem Message-ID: Hi All, I started this investigation yesterday, and had a brief exchange of ideas about it with Andrew. Now that I understand the problem (I think, I hope) , I could use some feedback from all of the minc people who know a lot more than me. So, after spending more than a bit of time going over David MacDonald's code, I think I know what's happening. Recall that the problem manifested as a failure of "make check" within volume_io testing. Here's what seems to be happening: (1) Looking at the test volume "t3_grid_0.mnc" we see: >mincinfo -dimnames t3_grid_0.mnc vector_dimension zspace yspace xspace AND >mincinfo -varnames t3_grid_0.mnc rootvariable zspace yspace xspace image-min image-max image Note that the "vector_dimension" dimension does not have a matching variable of that name, whereas the spatial dimensions do. (2) Looking at "initialize_minc_input_from_minc_id" within "input_mnc.c" we see: (a) a loop over the volume's DIMENSIONS (around line 300), in order to extract matching attributes (dim cosines, mostly) (b) ncvarid() is used to get the varid, based on the variable name ... but is being passed a DIMENSION name, not a variable name. So, it fails with "ncvarid: ncid 4: NetCDF: Variable not found" when passed the variable name "vector_dimension". (c) of course, if all dimensions have matching variable names, then there is no problem. Sadly, our test volume does not. Solutions: (1) a quick and easy solution to the current problem would be to reconstitute volume "t3_grid_0.mnc" so that it has a VARIABLE called "vector_dimension" (2) since this affects all of David MacDonald's code, we might consider implementing a rule that, for minc volumes, all dimension names *must* have a matching variable onto which one could attach attributes. This is usually indeed the case, but it might be helpful to make this explicit. (3) one could implement code changes to enforce (2), i.e. do not permit the creation of minc volumes that have dimension names without matching variable names (David's code already explicitly assumes this). What do you think? -jim -- ================================= Jim Nikelski, Ph.D. Postdoctoral Research Fellow Bloomfield Centre for Research in Aging Lady Davis Institute for Medical Research Sir Mortimer B. Davis - Jewish General Hospital McGill University From claude at bic.mni.mcgill.ca Wed Feb 16 13:27:53 2011 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Wed, 16 Feb 2011 13:27:53 -0500 Subject: [MINC-users] mincmorph output data type Message-ID: <201102161827.p1GIRrUR004587@cassio.bic.mni.mcgill.ca> Hi, Any reason why mincmorph is always writing its output in signed float? Here is the code: #define INTERNAL_PREC NC_FLOAT /* should be NC_FLOAT or NC_DOUBLE */ input_volume(infile, MAX_VAR_DIMS, axis_order, INTERNAL_PREC, TRUE, 0.0, 0.0, TRUE, volume, NULL); output_modified_volume(op->outfile, MI_ORIGINAL_TYPE, 0, // dtype, is_signed, 0.0, 0.0, *volume, infile, arg_string, NULL); The input is always read internally in float, thus MI_ORIGINAL_TYPE gives float on output, regardless of what the user wants. Why has someone chosen to ignore dtype as specified by the user? Any good reason to do so? I can almost think of one, which is related to what I'm trying to do. When using -group, the number of groups could exceed the storage capacity of the integer data type (byte or short). With float, we can safely say that the number of groups will fit. However, it's not really convenient to have group labels like 14.45 (non-integral numbers). Claude From a.janke at gmail.com Wed Feb 16 19:36:25 2011 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 17 Feb 2011 10:36:25 +1000 Subject: [MINC-users] mincmorph output data type In-Reply-To: <201102161827.p1GIRrUR004587@cassio.bic.mni.mcgill.ca> References: <201102161827.p1GIRrUR004587@cassio.bic.mni.mcgill.ca> Message-ID: Hi Claude, On Thu, Feb 17, 2011 at 04:27, Claude LEPAGE wrote: > Any reason why mincmorph is always writing its output in signed float? > > Here is the code: > #define INTERNAL_PREC NC_FLOAT ? ? ? ? /* should be NC_FLOAT or NC_DOUBLE */ > > ? output_modified_volume(op->outfile, MI_ORIGINAL_TYPE, 0, > ? ? ? ? ? ? ? ? ? ? ? ? ?// dtype, is_signed, > ? ? ? ? ? ? ? ? ? ? ? ? ?0.0, 0.0, *volume, infile, arg_string, NULL); > > The input is always read internally in float, thus MI_ORIGINAL_TYPE gives > float on output, regardless of what the user wants. Looks to me like you have a non-released version? Or some errant package from somewhere. Are you building from CVS or something? I say this if only because as a die-hard habit I used C++ style comments in code when fiddling with things and make a concerted effort to remove all such things before a release. > Why has someone chosen to ignore dtype as specified by the user? Any good > reason to do so? I can almost think of one, which is related to what I'm > trying to do. When using -group, the number of groups could exceed the > storage capacity of the integer data type (byte or short). Correct, this was why I added the option for an output datatype originally. Before adding the group option there was little reason to have any other output type to -byte. But then I added grey-scale erosion/dilation and a bunch of other things. :) Certainly the most current version isn't like this: https://github.com/andrewjanke/mincmorph/blob/master/mincmorph.c#L592 -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Brisbane->Australia +61 (402) 700 883 From claude at bic.mni.mcgill.ca Wed Feb 16 22:31:27 2011 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Wed, 16 Feb 2011 22:31:27 -0500 Subject: [MINC-users] mincmorph output data type In-Reply-To: Message-ID: <201102170331.p1H3VR7L018138@cassio.bic.mni.mcgill.ca> Hi Andrew, > Looks to me like you have a non-released version? Or some errant > package from somewhere. Are you building from CVS or something? I say > this if only because as a die-hard habit I used C++ style comments in > code when fiddling with things and make a concerted effort to remove > all such things before a release. I am using mincmorph-1.4 in BIC packages (tgz). It is the latest mincmorph in tgz (2006). Kind of out of date. BIC cvs seems to have a release 1.5 and more current non-released devs. Perhaps it's time to update this package in tgz. Can you do it? Is the BIC cvs up-to-date? Claude From a.janke at gmail.com Thu Feb 17 21:17:00 2011 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 18 Feb 2011 12:17:00 +1000 Subject: [MINC-users] mincmorph output data type In-Reply-To: <201102170331.p1H3VR7L018138@cassio.bic.mni.mcgill.ca> References: <201102170331.p1H3VR7L018138@cassio.bic.mni.mcgill.ca> Message-ID: > I am using mincmorph-1.4 in BIC packages (tgz). It is the latest > mincmorph in tgz (2006). Kind of out of date. BIC cvs seems to have > a release 1.5 and more current non-released devs. Perhaps it's time > to update this package in tgz. As an update, turns out that Claude's local package was modified somehow. The version on pacakges.bic.mni.mcgill.ca is fine. a From lrisa87 at uw.edu Fri Feb 18 19:56:20 2011 From: lrisa87 at uw.edu (Lisa F. Akiyama) Date: Fri, 18 Feb 2011 16:56:20 -0800 Subject: [MINC-users] Trying to install EZMINC Message-ID: Hello, I am trying to install EZMINC, but am running into some errors. I ran cmake-gui to configure the settings (please see attached screen shot image for the settings that I chose), and ran man && make install, as indicated on http://en.wikibooks.org/wiki/MINC/EZMINC/Installing. I get a long list of "undefined" components (please see attached text file). I tried with the ITK location specified in the configuration too, but, although the long list of "undefined" things do not appear, the last few lines mentioning: > collect2: ld returned 1 exit status > make[2]: *** [examples/trilinear_resample] Error 1 > make[1]: *** [examples/CMakeFiles/trilinear_resample.dir/all] Error 2 > make: *** [all] Error 2 > still appear. Any advices on how I should tackle this problem? Thank you. best, Lisa -------------- next part -------------- todd at neptune-ubuntu:/usr/local/ezminc/build$ cmake-gui& [1] 6032 todd at neptune-ubuntu:/usr/local/ezminc/build$ make && make install Scanning dependencies of target minc_io [ 6%] Building CXX object minc_io/CMakeFiles/minc_io.dir/minc_1_rw.o [ 12%] Building CXX object minc_io/CMakeFiles/minc_io.dir/minc_1_simple_rw.o Linking CXX static library libminc_io.a [ 12%] Built target minc_io Scanning dependencies of target minc_image_proc [ 18%] Building CXX object image_proc/CMakeFiles/minc_image_proc.dir/minc_histograms.o [ 25%] Building CXX object image_proc/CMakeFiles/minc_image_proc.dir/dwt.o [ 31%] Building CXX object image_proc/CMakeFiles/minc_image_proc.dir/dwt_utils.o Linking CXX static library libminc_image_proc.a [ 31%] Built target minc_image_proc Scanning dependencies of target trilinear_resample [ 37%] Building CXX object examples/CMakeFiles/trilinear_resample.dir/trilinear_resample.o Linking CXX executable trilinear_resample ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::history() const': minc_1_rw.cpp:(.text+0xf6c): undefined reference to `MI2attinq(int, int, char const*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::var_number() const': minc_1_rw.cpp:(.text+0x1103): undefined reference to `MI2inquire(int, int*, int*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::var_name(int) const': minc_1_rw.cpp:(.text+0x1181): undefined reference to `MI2varinq(int, int, char*, int*, int*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_number(char const*) const': minc_1_rw.cpp:(.text+0x124e): undefined reference to `MI2varid(int, char const*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::var_id(char const*) const': minc_1_rw.cpp:(.text+0x129e): undefined reference to `MI2varid(int, char const*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::var_length(int) const': minc_1_rw.cpp:(.text+0x132b): undefined reference to `MI2varinq(int, int, char*, int*, int*, int*, int*)' minc_1_rw.cpp:(.text+0x1394): undefined reference to `MI2varinq(int, int, char*, int*, int*, int*, int*)' minc_1_rw.cpp:(.text+0x13cb): undefined reference to `MI2diminq(int, int, char*, long*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_number(int) const': minc_1_rw.cpp:(.text+0x1472): undefined reference to `MI2varinq(int, int, char*, int*, int*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_name(char const*, int) const': minc_1_rw.cpp:(.text+0x14fd): undefined reference to `MI2varid(int, char const*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_name(int, int) const': minc_1_rw.cpp:(.text+0x160e): undefined reference to `MI2attname(int, int, int, char*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_value_string(char const*, char const*) const': minc_1_rw.cpp:(.text+0x176a): undefined reference to `MI2varid(int, char const*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_value_string(int, char const*) const': minc_1_rw.cpp:(.text+0x185e): undefined reference to `MI2attinq(int, int, char const*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_value_double(char const*, char const*) const': minc_1_rw.cpp:(.text+0x1a07): undefined reference to `MI2varid(int, char const*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_value_int(char const*, char const*) const': minc_1_rw.cpp:(.text+0x1ae5): undefined reference to `MI2varid(int, char const*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_value_int(int, char const*) const': minc_1_rw.cpp:(.text+0x1bb4): undefined reference to `MI2attinq(int, int, char const*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_value_double(int, char const*) const': minc_1_rw.cpp:(.text+0x1d5a): undefined reference to `MI2attinq(int, int, char const*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_type(char const*, char const*) const': minc_1_rw.cpp:(.text+0x1f08): undefined reference to `MI2varid(int, char const*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_type(int, char const*) const': minc_1_rw.cpp:(.text+0x1f6d): undefined reference to `MI2attinq(int, int, char const*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_length(char const*, char const*) const': minc_1_rw.cpp:(.text+0x1fc8): undefined reference to `MI2varid(int, char const*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_length(int, char const*) const': minc_1_rw.cpp:(.text+0x202d): undefined reference to `MI2attinq(int, int, char const*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_reader::open(char const*, bool, bool, bool)': minc_1_rw.cpp:(.text+0x247c): undefined reference to `MI2varid(int, char const*)' minc_1_rw.cpp:(.text+0x2531): undefined reference to `MI2varinq(int, int, char*, int*, int*, int*, int*)' minc_1_rw.cpp:(.text+0x26c6): undefined reference to `MI2diminq(int, int, char*, long*)' minc_1_rw.cpp:(.text+0x2a8e): undefined reference to `MI2varid(int, char const*)' minc_1_rw.cpp:(.text+0x3216): undefined reference to `MI2varid(int, char const*)' minc_1_rw.cpp:(.text+0x327d): undefined reference to `MI2varinq(int, int, char*, int*, int*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_writer::open(char const*, std::vector > const&, int, int, int)': minc_1_rw.cpp:(.text+0x3bf6): undefined reference to `MI2dimdef(int, char const*, long)' minc_1_rw.cpp:(.text+0x3d69): undefined reference to `MI2attput(int, int, char const*, int, int, void*)' minc_1_rw.cpp:(.text+0x40c1): undefined reference to `MI2attput(int, int, char const*, int, int, void*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_writer::setup_write_float()': minc_1_rw.cpp:(.text+0x45c6): undefined reference to `MI2endef(int)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_writer::setup_write_double()': minc_1_rw.cpp:(.text+0x4ade): undefined reference to `MI2endef(int)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_writer::setup_write_short(bool)': minc_1_rw.cpp:(.text+0x4dac): undefined reference to `MI2endef(int)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_writer::setup_write_ushort(bool)': minc_1_rw.cpp:(.text+0x4f10): undefined reference to `MI2endef(int)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_writer::setup_write_byte(bool)': minc_1_rw.cpp:(.text+0x508c): undefined reference to `MI2endef(int)' ../minc_io/libminc_io.a(minc_1_rw.o):minc_1_rw.cpp:(.text+0x51f0): more undefined references to `MI2endef(int)' follow ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_writer::copy_headers(minc::minc_1_base const&)': minc_1_rw.cpp:(.text+0x6c14): undefined reference to `MI2varid(int, char const*)' minc_1_rw.cpp:(.text+0x6c4a): undefined reference to `MI2varid(int, char const*)' minc_1_rw.cpp:(.text+0x6c80): undefined reference to `MI2varid(int, char const*)' minc_1_rw.cpp:(.text+0x6cb6): undefined reference to `MI2varid(int, char const*)' minc_1_rw.cpp:(.text+0x6cec): undefined reference to `MI2varid(int, char const*)' ../minc_io/libminc_io.a(minc_1_rw.o):minc_1_rw.cpp:(.text+0x6d22): more undefined references to `MI2varid(int, char const*)' follow ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_writer::append_history(char const*)': minc_1_rw.cpp:(.text+0x6e49): undefined reference to `MI2attinq(int, int, char const*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::create_var_id(char const*)': minc_1_rw.cpp:(.text+0x6f99): undefined reference to `MI2vardef(int, char const*, int, int, int const*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::insert(char const*, char const*, double)': minc_1_rw.cpp:(.text+0x7008): undefined reference to `MI2attput(int, int, char const*, int, int, void*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::insert(char const*, char const*, char const*)': minc_1_rw.cpp:(.text+0x7078): undefined reference to `MI2attput(int, int, char const*, int, int, void*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::insert(char const*, char const*, std::vector > const&)': minc_1_rw.cpp:(.text+0x70f9): undefined reference to `MI2attput(int, int, char const*, int, int, void*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::insert(char const*, char const*, std::vector > const&)': minc_1_rw.cpp:(.text+0x717b): undefined reference to `MI2attput(int, int, char const*, int, int, void*)' collect2: ld returned 1 exit status make[2]: *** [examples/trilinear_resample] Error 1 make[1]: *** [examples/CMakeFiles/trilinear_resample.dir/all] Error 2 make: *** [all] Error 2 [1]+ Done cmake-gui todd at neptune-ubuntu:/usr/local/ezminc/build$ cmake-gui & [1] 6243 todd at neptune-ubuntu:/usr/local/ezminc/build$ make && make install [ 12%] Built target minc_io [ 31%] Built target minc_image_proc Linking CXX executable trilinear_resample ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::history() const': minc_1_rw.cpp:(.text+0xf6c): undefined reference to `MI2attinq(int, int, char const*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::var_number() const': minc_1_rw.cpp:(.text+0x1103): undefined reference to `MI2inquire(int, int*, int*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::var_name(int) const': minc_1_rw.cpp:(.text+0x1181): undefined reference to `MI2varinq(int, int, char*, int*, int*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_number(char const*) const': minc_1_rw.cpp:(.text+0x124e): undefined reference to `MI2varid(int, char const*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::var_id(char const*) const': minc_1_rw.cpp:(.text+0x129e): undefined reference to `MI2varid(int, char const*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::var_length(int) const': minc_1_rw.cpp:(.text+0x132b): undefined reference to `MI2varinq(int, int, char*, int*, int*, int*, int*)' minc_1_rw.cpp:(.text+0x1394): undefined reference to `MI2varinq(int, int, char*, int*, int*, int*, int*)' minc_1_rw.cpp:(.text+0x13cb): undefined reference to `MI2diminq(int, int, char*, long*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_number(int) const': minc_1_rw.cpp:(.text+0x1472): undefined reference to `MI2varinq(int, int, char*, int*, int*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_name(char const*, int) const': minc_1_rw.cpp:(.text+0x14fd): undefined reference to `MI2varid(int, char const*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_name(int, int) const': minc_1_rw.cpp:(.text+0x160e): undefined reference to `MI2attname(int, int, int, char*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_value_string(char const*, char const*) const': minc_1_rw.cpp:(.text+0x176a): undefined reference to `MI2varid(int, char const*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_value_string(int, char const*) const': minc_1_rw.cpp:(.text+0x185e): undefined reference to `MI2attinq(int, int, char const*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_value_double(char const*, char const*) const': minc_1_rw.cpp:(.text+0x1a07): undefined reference to `MI2varid(int, char const*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_value_int(char const*, char const*) const': minc_1_rw.cpp:(.text+0x1ae5): undefined reference to `MI2varid(int, char const*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_value_int(int, char const*) const': minc_1_rw.cpp:(.text+0x1bb4): undefined reference to `MI2attinq(int, int, char const*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_value_double(int, char const*) const': minc_1_rw.cpp:(.text+0x1d5a): undefined reference to `MI2attinq(int, int, char const*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_type(char const*, char const*) const': minc_1_rw.cpp:(.text+0x1f08): undefined reference to `MI2varid(int, char const*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_type(int, char const*) const': minc_1_rw.cpp:(.text+0x1f6d): undefined reference to `MI2attinq(int, int, char const*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_length(char const*, char const*) const': minc_1_rw.cpp:(.text+0x1fc8): undefined reference to `MI2varid(int, char const*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::att_length(int, char const*) const': minc_1_rw.cpp:(.text+0x202d): undefined reference to `MI2attinq(int, int, char const*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_reader::open(char const*, bool, bool, bool)': minc_1_rw.cpp:(.text+0x247c): undefined reference to `MI2varid(int, char const*)' minc_1_rw.cpp:(.text+0x2531): undefined reference to `MI2varinq(int, int, char*, int*, int*, int*, int*)' minc_1_rw.cpp:(.text+0x26c6): undefined reference to `MI2diminq(int, int, char*, long*)' minc_1_rw.cpp:(.text+0x2a8e): undefined reference to `MI2varid(int, char const*)' minc_1_rw.cpp:(.text+0x3216): undefined reference to `MI2varid(int, char const*)' minc_1_rw.cpp:(.text+0x327d): undefined reference to `MI2varinq(int, int, char*, int*, int*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_writer::open(char const*, std::vector > const&, int, int, int)': minc_1_rw.cpp:(.text+0x3bf6): undefined reference to `MI2dimdef(int, char const*, long)' minc_1_rw.cpp:(.text+0x3d69): undefined reference to `MI2attput(int, int, char const*, int, int, void*)' minc_1_rw.cpp:(.text+0x40c1): undefined reference to `MI2attput(int, int, char const*, int, int, void*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_writer::setup_write_float()': minc_1_rw.cpp:(.text+0x45c6): undefined reference to `MI2endef(int)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_writer::setup_write_double()': minc_1_rw.cpp:(.text+0x4ade): undefined reference to `MI2endef(int)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_writer::setup_write_short(bool)': minc_1_rw.cpp:(.text+0x4dac): undefined reference to `MI2endef(int)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_writer::setup_write_ushort(bool)': minc_1_rw.cpp:(.text+0x4f10): undefined reference to `MI2endef(int)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_writer::setup_write_byte(bool)': minc_1_rw.cpp:(.text+0x508c): undefined reference to `MI2endef(int)' ../minc_io/libminc_io.a(minc_1_rw.o):minc_1_rw.cpp:(.text+0x51f0): more undefined references to `MI2endef(int)' follow ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_writer::copy_headers(minc::minc_1_base const&)': minc_1_rw.cpp:(.text+0x6c14): undefined reference to `MI2varid(int, char const*)' minc_1_rw.cpp:(.text+0x6c4a): undefined reference to `MI2varid(int, char const*)' minc_1_rw.cpp:(.text+0x6c80): undefined reference to `MI2varid(int, char const*)' minc_1_rw.cpp:(.text+0x6cb6): undefined reference to `MI2varid(int, char const*)' minc_1_rw.cpp:(.text+0x6cec): undefined reference to `MI2varid(int, char const*)' ../minc_io/libminc_io.a(minc_1_rw.o):minc_1_rw.cpp:(.text+0x6d22): more undefined references to `MI2varid(int, char const*)' follow ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_writer::append_history(char const*)': minc_1_rw.cpp:(.text+0x6e49): undefined reference to `MI2attinq(int, int, char const*, int*, int*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::create_var_id(char const*)': minc_1_rw.cpp:(.text+0x6f99): undefined reference to `MI2vardef(int, char const*, int, int, int const*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::insert(char const*, char const*, double)': minc_1_rw.cpp:(.text+0x7008): undefined reference to `MI2attput(int, int, char const*, int, int, void*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::insert(char const*, char const*, char const*)': minc_1_rw.cpp:(.text+0x7078): undefined reference to `MI2attput(int, int, char const*, int, int, void*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::insert(char const*, char const*, std::vector > const&)': minc_1_rw.cpp:(.text+0x70f9): undefined reference to `MI2attput(int, int, char const*, int, int, void*)' ../minc_io/libminc_io.a(minc_1_rw.o): In function `minc::minc_1_base::insert(char const*, char const*, std::vector > const&)': minc_1_rw.cpp:(.text+0x717b): undefined reference to `MI2attput(int, int, char const*, int, int, void*)' collect2: ld returned 1 exit status make[2]: *** [examples/trilinear_resample] Error 1 make[1]: *** [examples/CMakeFiles/trilinear_resample.dir/all] Error 2 make: *** [all] Error 2 [1]+ Done cmake-gui todd at neptune-ubuntu:/usr/local/ezminc/build$ cmake-gui & [1] 6365 From vladimir.fonov at gmail.com Sun Feb 20 14:22:44 2011 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Sun, 20 Feb 2011 14:22:44 -0500 Subject: [MINC-users] Trying to install EZMINC In-Reply-To: References: Message-ID: Hello, are you using r80 version ( http://www.bic.mni.mcgill.ca/~vfonov/software/ezminc-r80.tar.gz ) ? (as was discussed in this mailiing list about two weeks ago) ? On Fri, Feb 18, 2011 at 7:56 PM, Lisa F. Akiyama wrote: > Hello, > > I am trying to install EZMINC, but am running into some errors. > I ran cmake-gui to configure the settings (please see attached screen shot > image for the settings that I chose), and ran man && make install, as > indicated on http://en.wikibooks.org/wiki/MINC/EZMINC/Installing. > I get a long list of "undefined" components (please see attached text file). > I tried with the ITK location specified in the configuration too, but, > although the long list of "undefined" things do not appear, the last few > lines mentioning: > >> collect2: ld returned 1 exit status >> make[2]: *** [examples/trilinear_resample] Error 1 >> make[1]: *** [examples/CMakeFiles/trilinear_resample.dir/all] Error 2 >> make: *** [all] Error 2 >> > > still appear. > > Any advices on how I should tackle this problem? > > Thank you. > > > best, > Lisa > > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > -- Best regards, ?Vladimir S. Fonov ~ vladimir fonov gmail com From lrisa87 at uw.edu Sun Feb 20 16:20:57 2011 From: lrisa87 at uw.edu (Lisa F. Akiyama) Date: Sun, 20 Feb 2011 13:20:57 -0800 Subject: [MINC-users] Trying to install EZMINC In-Reply-To: References: Message-ID: Hi Vlamidir, I somehow skipped over that email conversation that went on 2 weeks ago... Thanks for the link to the ver.r80. I got it to install properly. Thank you (on a weekend, too!). Best, Lisa On Sun, Feb 20, 2011 at 11:22 AM, Vladimir S. FONOV < vladimir.fonov at gmail.com> wrote: > Hello, > > are you using r80 version ( > http://www.bic.mni.mcgill.ca/~vfonov/software/ezminc-r80.tar.gz ) ? > (as was discussed in this mailiing list about two weeks ago) ? > > On Fri, Feb 18, 2011 at 7:56 PM, Lisa F. Akiyama wrote: > > Hello, > > > > I am trying to install EZMINC, but am running into some errors. > > I ran cmake-gui to configure the settings (please see attached screen > shot > > image for the settings that I chose), and ran man && make install, as > > indicated on http://en.wikibooks.org/wiki/MINC/EZMINC/Installing. > > I get a long list of "undefined" components (please see attached text > file). > > I tried with the ITK location specified in the configuration too, but, > > although the long list of "undefined" things do not appear, the last few > > lines mentioning: > > > >> collect2: ld returned 1 exit status > >> make[2]: *** [examples/trilinear_resample] Error 1 > >> make[1]: *** [examples/CMakeFiles/trilinear_resample.dir/all] Error 2 > >> make: *** [all] Error 2 > >> > > > > still appear. > > > > Any advices on how I should tackle this problem? > > > > Thank you. > > > > > > best, > > Lisa > > > > _______________________________________________ > > MINC-users at bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > > > > > -- > Best regards, > > Vladimir S. Fonov ~ vladimir fonov gmail com > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From a.janke at gmail.com Wed Feb 23 23:43:33 2011 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 24 Feb 2011 14:43:33 +1000 Subject: [MINC-users] minc "make check" error -- not just a Snow Leopard problem In-Reply-To: References: Message-ID: Hi Jim, > ? Here's what seems to be happening: > > (1) Looking at the test volume "t3_grid_0.mnc" we see: >>mincinfo -dimnames t3_grid_0.mnc > vector_dimension zspace yspace xspace > >>mincinfo -varnames t3_grid_0.mnc > rootvariable zspace yspace xspace image-min image-max image > > Note that the "vector_dimension" dimension does not have a matching > variable of that name, whereas the spatial dimensions do. I reckon you are onto something here... I'm surprised this hasn't caused problems as of yet. > Solutions: > (1) a quick and easy solution to the current problem would be to > reconstitute volume "t3_grid_0.mnc" so that it has a VARIABLE called > "vector_dimension" > > (2) since this affects all of David MacDonald's code, we might > consider implementing a rule that, for minc volumes, all dimension > names *must* have a matching variable onto which one could attach > attributes. This is usually indeed the case, but it might be helpful > to make this explicit. > > (3) one could implement code changes to enforce (2), i.e. do not > permit the creation of minc volumes that have dimension names without > matching variable names (David's code already explicitly assumes > this). I'm all for #3. It should not be that hard to fix given that all is required is a few lines of extra code in the output_*_minc functions. We would also have to include some sanity checking in open_volume or perhaps in MINC proper to deal with older volumes that have been created like this. From my initial look at the code this should not cause a problem with NetCDF/HDF5 interaction when converting a volume. So who wants to do it? :) -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Brisbane->Australia +61 (402) 700 883 From claude at bic.mni.mcgill.ca Thu Feb 24 00:35:12 2011 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Thu, 24 Feb 2011 00:35:12 -0500 Subject: [MINC-users] minc "make check" error -- not just a Snow Leopard problem In-Reply-To: Message-ID: <201102240535.p1O5ZCt2013973@cassio.bic.mni.mcgill.ca> Hi Andrew, I compiled minc on snow leopard with Jim on Monday. minc seems to work, although make check fails. Failure seems to occur while compiling a test program. I suspect a problem with a #define or #ifdef that causes different code to be compiled. How about a diff of config.h for OSX vs Linux? On Linux 32 and 64, the tests compile and run to completion, reporting 1 failure out of 7 (not the same failure as experienced on OSX). I reproduced the same Linux behaviour on CYGWIN. :-) This seems to be an OSX specific problem. I don't have much spare time to look into this. Moreover, I don't have access to OSX unless Nic brings his laptop to work. Maybe install OSX as a virtual machine on my Linux workstation? :-) Claude > Hi Jim, > > > =A0 Here's what seems to be happening: > > > > (1) Looking at the test volume "t3_grid_0.mnc" we see: > >>mincinfo -dimnames t3_grid_0.mnc > > vector_dimension zspace yspace xspace > > > >>mincinfo -varnames t3_grid_0.mnc > > rootvariable zspace yspace xspace image-min image-max image > > > > Note that the "vector_dimension" dimension does not have a matching > > variable of that name, whereas the spatial dimensions do. > > I reckon you are onto something here... I'm surprised this hasn't > caused problems as of yet. > > > Solutions: > > (1) a quick and easy solution to the current problem would be to > > reconstitute volume "t3_grid_0.mnc" so that it has a VARIABLE called > > "vector_dimension" > > > > (2) since this affects all of David MacDonald's code, we might > > consider implementing a rule that, for minc volumes, all dimension > > names *must* have a matching variable onto which one could attach > > attributes. This is usually indeed the case, but it might be helpful > > to make this explicit. > > > > (3) one could implement code changes to enforce (2), i.e. do not > > permit the creation of minc volumes that have dimension names without > > matching variable names (David's code already explicitly assumes > > this). > > I'm all for #3. It should not be that hard to fix given that all is > required is a few lines of extra code in the output_*_minc functions. > We would also have to include some sanity checking in open_volume or > perhaps in MINC proper to deal with older volumes that have been > created like this. From my initial look at the code this should not > cause a problem with NetCDF/HDF5 interaction when converting a volume. > > So who wants to do it? :) > > > -- = > > Andrew Janke > (a.janke at gmail.com || http://a.janke.googlepages.com/) > Brisbane->Australia +61 (402) 700 883 > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From nic.kassis at gmail.com Thu Feb 24 11:02:12 2011 From: nic.kassis at gmail.com (Nicolas Kassis) Date: Thu, 24 Feb 2011 11:02:12 -0500 Subject: [MINC-users] minc "make check" error -- not just a Snow Leopard problem In-Reply-To: <201102240535.p1O5ZCt2013973@cassio.bic.mni.mcgill.ca> References: <201102240535.p1O5ZCt2013973@cassio.bic.mni.mcgill.ca> Message-ID: Hi Claude, There is an available Mac here in the office we can play with and I can make it available to your through VNC. A virtual OSX installation is more work than it's worth ;p (Using OSx86 is which is not optimal). It would be interesting to be able to make a linux, mac (windows?) available for build testing. Linux is easy, the mac is a little bit more work considering we need a physical machine. Nic On Thu, Feb 24, 2011 at 12:35 AM, Claude LEPAGE wrote: > Hi Andrew, > > I compiled minc on snow leopard with Jim on Monday. minc > seems to work, although make check fails. Failure seems > to occur while compiling a test program. I suspect a > problem with a #define or #ifdef that causes different > code to be compiled. How about a diff of config.h for > OSX vs Linux? On Linux 32 and 64, the tests compile and > run to completion, reporting 1 failure out of 7 (not the > same failure as experienced on OSX). I reproduced the > same Linux behaviour on CYGWIN. :-) This seems to be an > OSX specific problem. > > I don't have much spare time to look into this. Moreover, > I don't have access to OSX unless Nic brings his laptop > to work. Maybe install OSX as a virtual machine on my > Linux workstation? :-) > > Claude > >> Hi Jim, >> >> > =A0 Here's what seems to be happening: >> > >> > (1) Looking at the test volume "t3_grid_0.mnc" we see: >> >>mincinfo -dimnames t3_grid_0.mnc >> > vector_dimension zspace yspace xspace >> > >> >>mincinfo -varnames t3_grid_0.mnc >> > rootvariable zspace yspace xspace image-min image-max image >> > >> > Note that the "vector_dimension" dimension does not have a matching >> > variable of that name, whereas the spatial dimensions do. >> >> I reckon you are onto something here... I'm surprised this hasn't >> caused problems as of yet. >> >> > Solutions: >> > (1) a quick and easy solution to the current problem would be to >> > reconstitute volume "t3_grid_0.mnc" so that it has a VARIABLE called >> > "vector_dimension" >> > >> > (2) since this affects all of David MacDonald's code, we might >> > consider implementing a rule that, for minc volumes, all dimension >> > names *must* have a matching variable onto which one could attach >> > attributes. This is usually indeed the case, but it might be helpful >> > to make this explicit. >> > >> > (3) one could implement code changes to enforce (2), i.e. do not >> > permit the creation of minc volumes that have dimension names without >> > matching variable names (David's code already explicitly assumes >> > this). >> >> I'm all for #3. It should not be that hard to fix given that all is >> required is a few lines of extra code in the output_*_minc functions. >> We would also have to include some sanity checking in open_volume or >> perhaps in MINC proper to deal with older volumes that have been >> created like this. ?From my initial look at the code this should not >> cause a problem with NetCDF/HDF5 interaction when converting a volume. >> >> So who wants to do it? :) >> >> >> -- = >> >> Andrew Janke >> (a.janke at gmail.com || http://a.janke.googlepages.com/) >> Brisbane->Australia ? ?+61 (402) 700 883 >> _______________________________________________ >> MINC-users at bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users >> > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > -- ----------------- Nicolas Kassis From nikelski at bic.mni.mcgill.ca Thu Feb 24 13:45:52 2011 From: nikelski at bic.mni.mcgill.ca (EJ Nikelski) Date: Thu, 24 Feb 2011 13:45:52 -0500 Subject: [MINC-users] minc "make check" error -- not just a Snow Leopard problem In-Reply-To: References: <201102240535.p1O5ZCt2013973@cassio.bic.mni.mcgill.ca> Message-ID: Hi All, OK, back in snowy Victoria after a lovely Montreal visit. There were actually a few new developments since my last post, including an appearance by the mythical Peter Neelin, who suggests ... My rather old version of the minc/volume_io software has the following bit of code: dimvar = ncvarid( file->cdfid, file->dim_names[d] ); if( dimvar != MI_ERROR ) { etc. This is quite correct. If I recall correctly, the vector_dimension is not allowed to have a dimension variable (you would have to have a look at the programmer's reference, I think that it is in there - yup just confirmed). In this case dimvar will have value MI_ERROR and the code that looks for attributes will not be executed. There may be other bugs that assume that the step and start are set, but that would surprise me. In other words, it was certainly quite normal in minc 1 to get error return values back from functions like this as an indication that there was no variable. So, given the thumbs down from Peter, I looked a bit closer. As it turns out, on Snow Leopard, even after ncopts=0 prior to the call to ncvarid(), ncvarid() receives the default ncopts() value of 3 (i.e., display error message and *do not return* to calling program. So the error return handling code is never entered. Funnily enough, as this works correctly under Linux, this *does* appear to be a Snow Leopard problem after all. Perhaps related to the stoopidity that is Snow Leopard, i.e. building 64-bit apps, but still running a 32-bit kernel ( sizeof(int)=4, not 8 on Snow Leopard on my MacBook ). So there you have it. Looks like it's a SL problem. It would be interesting if the MacPros or MackBook Pros that have been coerced to run a 64-bit kernel (hold down the "6" + "4" keys at boot) still show the same problem. -jim On Thu, Feb 24, 2011 at 11:02 AM, Nicolas Kassis wrote: > Hi Claude, > > There is an available Mac here in the office we can play with and I > can make it available to your through VNC. A virtual OSX installation > is more work than it's worth ;p (Using OSx86 is which is not optimal). > It would be interesting to be able to make a linux, mac (windows?) > available for build testing. Linux is easy, the mac is a little bit > more work considering we need a physical machine. > > Nic > > On Thu, Feb 24, 2011 at 12:35 AM, Claude LEPAGE > wrote: >> Hi Andrew, >> >> I compiled minc on snow leopard with Jim on Monday. minc >> seems to work, although make check fails. Failure seems >> to occur while compiling a test program. I suspect a >> problem with a #define or #ifdef that causes different >> code to be compiled. How about a diff of config.h for >> OSX vs Linux? On Linux 32 and 64, the tests compile and >> run to completion, reporting 1 failure out of 7 (not the >> same failure as experienced on OSX). I reproduced the >> same Linux behaviour on CYGWIN. :-) This seems to be an >> OSX specific problem. >> >> I don't have much spare time to look into this. Moreover, >> I don't have access to OSX unless Nic brings his laptop >> to work. Maybe install OSX as a virtual machine on my >> Linux workstation? :-) >> >> Claude >> >>> Hi Jim, >>> >>> > =A0 Here's what seems to be happening: >>> > >>> > (1) Looking at the test volume "t3_grid_0.mnc" we see: >>> >>mincinfo -dimnames t3_grid_0.mnc >>> > vector_dimension zspace yspace xspace >>> > >>> >>mincinfo -varnames t3_grid_0.mnc >>> > rootvariable zspace yspace xspace image-min image-max image >>> > >>> > Note that the "vector_dimension" dimension does not have a matching >>> > variable of that name, whereas the spatial dimensions do. >>> >>> I reckon you are onto something here... I'm surprised this hasn't >>> caused problems as of yet. >>> >>> > Solutions: >>> > (1) a quick and easy solution to the current problem would be to >>> > reconstitute volume "t3_grid_0.mnc" so that it has a VARIABLE called >>> > "vector_dimension" >>> > >>> > (2) since this affects all of David MacDonald's code, we might >>> > consider implementing a rule that, for minc volumes, all dimension >>> > names *must* have a matching variable onto which one could attach >>> > attributes. This is usually indeed the case, but it might be helpful >>> > to make this explicit. >>> > >>> > (3) one could implement code changes to enforce (2), i.e. do not >>> > permit the creation of minc volumes that have dimension names without >>> > matching variable names (David's code already explicitly assumes >>> > this). >>> >>> I'm all for #3. It should not be that hard to fix given that all is >>> required is a few lines of extra code in the output_*_minc functions. >>> We would also have to include some sanity checking in open_volume or >>> perhaps in MINC proper to deal with older volumes that have been >>> created like this. ?From my initial look at the code this should not >>> cause a problem with NetCDF/HDF5 interaction when converting a volume. >>> >>> So who wants to do it? :) >>> >>> >>> -- = >>> >>> Andrew Janke >>> (a.janke at gmail.com || http://a.janke.googlepages.com/) >>> Brisbane->Australia ? ?+61 (402) 700 883 >>> _______________________________________________ >>> MINC-users at bic.mni.mcgill.ca >>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users >>> >> _______________________________________________ >> MINC-users at bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users >> > > > > -- > ----------------- > Nicolas Kassis > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > -- ================================= Jim Nikelski, Ph.D. Postdoctoral Research Fellow Bloomfield Centre for Research in Aging Lady Davis Institute for Medical Research Sir Mortimer B. Davis - Jewish General Hospital McGill University From peter.neelin at gmail.com Thu Feb 24 14:45:55 2011 From: peter.neelin at gmail.com (Peter Neelin) Date: Thu, 24 Feb 2011 14:45:55 -0500 Subject: [MINC-users] minc "make check" error -- not just a Snow Leopard problem In-Reply-To: References: <201102240535.p1O5ZCt2013973@cassio.bic.mni.mcgill.ca> Message-ID: On Thu, Feb 24, 2011 at 1:45 PM, EJ Nikelski wrote: > ? So, given the thumbs down from Peter, I looked a bit closer. As it > turns out, on Snow Leopard, even after ncopts=0 prior to the call to > ncvarid(), ncvarid() receives the default ncopts() value of 3 (i.e., > display error message and *do not return* to calling program. So the > error return handling code is never entered. ?Funnily enough, as this > works correctly under Linux, this *does* appear to be a Snow Leopard > problem after all. I wondered if there might be some funkiness with dynamically-loaded libraries in which ncopts is not truly global. Minc changes the variable but this is not seen by ncvarid() loaded from a different library. Could minc be defining its own ncopts? (Anyone know much about the weirdnesses of building shared libraries in Mac OS X?) I am assuming that we are dealing with shared libraries here - is that true? Or is the binary statically linked? (Does Snow Leopard have an ldd?) Peter -- Peter Neelin (peter.neelin at gmail.com) From nikelski at bic.mni.mcgill.ca Thu Feb 24 15:32:05 2011 From: nikelski at bic.mni.mcgill.ca (EJ Nikelski) Date: Thu, 24 Feb 2011 15:32:05 -0500 Subject: [MINC-users] minc "make check" error -- not just a Snow Leopard problem In-Reply-To: References: <201102240535.p1O5ZCt2013973@cassio.bic.mni.mcgill.ca> Message-ID: Hi Peter and List, Peter, I think you might be onto something here. The ldd equivalent is called otool, and I've taken a look. The latest version that I built with Claude links hdf5 and netcdf as dynamic -- all other libs are statically linked into the executable (minc, volume_io). In the previous build, we had a very different configuration: dynamic=(volume_io, minc2, hdf5), all the rest linked as static (including netcdf). Apple seems to prefer linking dynamically, if it can find a dynamic lib, else it grabs the static. What would be the suggested optimal linking? hdf5 and netcdf dynamic and all of the mincy libs linked statically with the executable. BTW, running "make check" with the latest library configuration seems to given me a different error. Progress? -jim On Thu, Feb 24, 2011 at 2:45 PM, Peter Neelin wrote: > On Thu, Feb 24, 2011 at 1:45 PM, EJ Nikelski wrote: > >> ? So, given the thumbs down from Peter, I looked a bit closer. As it >> turns out, on Snow Leopard, even after ncopts=0 prior to the call to >> ncvarid(), ncvarid() receives the default ncopts() value of 3 (i.e., >> display error message and *do not return* to calling program. So the >> error return handling code is never entered. ?Funnily enough, as this >> works correctly under Linux, this *does* appear to be a Snow Leopard >> problem after all. > > I wondered if there might be some funkiness with dynamically-loaded > libraries in which ncopts is not truly global. Minc changes the > variable but this is not seen by ncvarid() loaded from a different > library. Could minc be defining its own ncopts? (Anyone know much > about the weirdnesses of building shared libraries in Mac OS X?) > > I am assuming that we are dealing with shared libraries here - is that > true? Or is the binary statically linked? (Does Snow Leopard have an > ldd?) > > Peter > -- > Peter Neelin > (peter.neelin at gmail.com) > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > -- ================================= Jim Nikelski, Ph.D. Postdoctoral Research Fellow Bloomfield Centre for Research in Aging Lady Davis Institute for Medical Research Sir Mortimer B. Davis - Jewish General Hospital McGill University From claude at bic.mni.mcgill.ca Thu Feb 24 16:28:31 2011 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Thu, 24 Feb 2011 16:28:31 -0500 Subject: [MINC-users] minc "make check" error -- not just a Snow Leopard problem In-Reply-To: Message-ID: <201102242128.p1OLSVOt017356@cassio.bic.mni.mcgill.ca> Jim, Are you sure about this? I believe my built is totally static for minc, volume_io, hdf5 and netcdf. Do "otool -L minccalc" and post the output. You probably got confused with our first attempt to build minc which had hdf5 and netcdf dynamic since I had /opt/local as part of the build path for configure. Claude > Hi Peter and List, > > Peter, I think you might be onto something here. The ldd > equivalent is called otool, and I've taken a look. The latest version > that I built with Claude links hdf5 and netcdf as dynamic -- all other > libs are statically linked into the executable (minc, volume_io). In > the previous build, we had a very different configuration: > dynamic=3D(volume_io, minc2, hdf5), all the rest linked as static > (including netcdf). Apple seems to prefer linking dynamically, if it > can find a dynamic lib, else it grabs the static. > > What would be the suggested optimal linking? hdf5 and netcdf dynamic > and all of the mincy libs linked statically with the executable. BTW, > running "make check" with the latest library configuration seems to > given me a different error. Progress? > > -jim > > > On Thu, Feb 24, 2011 at 2:45 PM, Peter Neelin wrot= > e: > > On Thu, Feb 24, 2011 at 1:45 PM, EJ Nikelski = > wrote: > > > >> =A0 So, given the thumbs down from Peter, I looked a bit closer. As it > >> turns out, on Snow Leopard, even after ncopts=3D0 prior to the call to > >> ncvarid(), ncvarid() receives the default ncopts() value of 3 (i.e., > >> display error message and *do not return* to calling program. So the > >> error return handling code is never entered. =A0Funnily enough, as this > >> works correctly under Linux, this *does* appear to be a Snow Leopard > >> problem after all. > > > > I wondered if there might be some funkiness with dynamically-loaded > > libraries in which ncopts is not truly global. Minc changes the > > variable but this is not seen by ncvarid() loaded from a different > > library. Could minc be defining its own ncopts? (Anyone know much > > about the weirdnesses of building shared libraries in Mac OS X?) > > > > I am assuming that we are dealing with shared libraries here - is that > > true? Or is the binary statically linked? (Does Snow Leopard have an > > ldd?) > > > > Peter > > -- > > Peter Neelin > > (peter.neelin at gmail.com) > > _______________________________________________ > > MINC-users at bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > > > -- = > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D > Jim Nikelski, Ph.D. > Postdoctoral Research Fellow > Bloomfield Centre for Research in Aging > Lady Davis Institute for Medical Research > Sir Mortimer B. Davis - Jewish General Hospital > McGill University > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From nikelski at bic.mni.mcgill.ca Thu Feb 24 17:24:39 2011 From: nikelski at bic.mni.mcgill.ca (EJ Nikelski) Date: Thu, 24 Feb 2011 17:24:39 -0500 Subject: [MINC-users] minc "make check" error -- not just a Snow Leopard problem In-Reply-To: <201102242128.p1OLSVOt017356@cassio.bic.mni.mcgill.ca> References: <201102242128.p1OLSVOt017356@cassio.bic.mni.mcgill.ca> Message-ID: Hi all, Claude, I'm as sure as sure can get ... jnikelski@[~]: otool -L /usr/local/bic/bin/minccalc /usr/local/bic/bin/minccalc: /usr/local/bic/lib/libhdf5.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /usr/local/bic/lib/libnetcdf.4.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.1) When you built netcdf and hdf5, did you not build the shared libs? If not, then that would explain the use of static linkage on the system that you were working on. Is this not the recommended linkage? ... or do we want everything (eg, hdf5/netcdf) statically linked? -jim On Thu, Feb 24, 2011 at 4:28 PM, Claude LEPAGE wrote: > Jim, > > Are you sure about this? I believe my built is totally static for > minc, volume_io, hdf5 and netcdf. Do "otool -L minccalc" and post > the output. > > You probably got confused with our first attempt to build minc > which had hdf5 and netcdf dynamic since I had /opt/local as part > of the build path for configure. > > Claude > > >> Hi Peter and List, >> >> ? ?Peter, I think you might be onto something here. ?The ldd >> equivalent is called otool, and I've taken a look. The latest version >> that I built with Claude links hdf5 and netcdf as dynamic -- all other >> libs are statically linked into the executable (minc, volume_io). ?In >> the previous build, we had a very different configuration: >> dynamic=3D(volume_io, minc2, hdf5), all the rest linked as static >> (including netcdf). Apple seems to prefer linking dynamically, if it >> can find a dynamic lib, else it grabs the static. >> >> What would be the suggested optimal linking? hdf5 and netcdf dynamic >> and all of the mincy libs linked statically with the executable. ?BTW, >> running "make check" with the latest library configuration seems to >> given me a different error. Progress? >> >> -jim >> >> >> On Thu, Feb 24, 2011 at 2:45 PM, Peter Neelin wrot= >> e: >> > On Thu, Feb 24, 2011 at 1:45 PM, EJ Nikelski = >> ?wrote: >> > >> >> =A0 So, given the thumbs down from Peter, I looked a bit closer. As it >> >> turns out, on Snow Leopard, even after ncopts=3D0 prior to the call to >> >> ncvarid(), ncvarid() receives the default ncopts() value of 3 (i.e., >> >> display error message and *do not return* to calling program. So the >> >> error return handling code is never entered. =A0Funnily enough, as this >> >> works correctly under Linux, this *does* appear to be a Snow Leopard >> >> problem after all. >> > >> > I wondered if there might be some funkiness with dynamically-loaded >> > libraries in which ncopts is not truly global. Minc changes the >> > variable but this is not seen by ncvarid() loaded from a different >> > library. Could minc be defining its own ncopts? (Anyone know much >> > about the weirdnesses of building shared libraries in Mac OS X?) >> > >> > I am assuming that we are dealing with shared libraries here - is that >> > true? Or is the binary statically linked? (Does Snow Leopard have an >> > ldd?) >> > >> > Peter >> > -- >> > Peter Neelin >> > (peter.neelin at gmail.com) >> > _______________________________________________ >> > MINC-users at bic.mni.mcgill.ca >> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users >> > >> >> >> >> -- = >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >> =3D=3D=3D=3D=3D=3D=3D=3D >> Jim Nikelski, Ph.D. >> Postdoctoral Research Fellow >> Bloomfield Centre for Research in Aging >> Lady Davis Institute for Medical Research >> Sir Mortimer B. Davis - Jewish General Hospital >> McGill University >> _______________________________________________ >> MINC-users at bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users >> > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > -- ================================= Jim Nikelski, Ph.D. Postdoctoral Research Fellow Bloomfield Centre for Research in Aging Lady Davis Institute for Medical Research Sir Mortimer B. Davis - Jewish General Hospital McGill University From lrisa87 at uw.edu Thu Feb 24 18:29:46 2011 From: lrisa87 at uw.edu (Lisa F. Akiyama) Date: Thu, 24 Feb 2011 15:29:46 -0800 Subject: [MINC-users] best_nonlin_reg.pl ? Message-ID: Hello, I read on the BIC website that "best_nonlin_reg.pl" is the most commonly used nonlinear registration tool. Is this a tool that is widely available? I do not see it with the version of MINC I have. Thank you. Best, Lisa From claude at bic.mni.mcgill.ca Thu Feb 24 19:59:29 2011 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Thu, 24 Feb 2011 19:59:29 -0500 Subject: [MINC-users] minc "make check" error -- not just a Snow Leopard problem In-Reply-To: Message-ID: <201102250059.p1P0xT2h010737@cassio.bic.mni.mcgill.ca> Jim, ok, that's convincing enough. So our build is wrong. I believed we compiled netcdf 3.6, not 4. Can you send me your script for compilation (the ./configure command) for hdf5, netcdf and minc? The prefix-path and build-path must be conflicting with some other paths. for minc: MINC_FLAG = --with-minc2 MINC_EXTRA = --enable-shared=no --enable-static=yes --enable-acr-nema --enable-minc2 $(LIBMINC): $(MINC_UNTAR) $(MINC_DEPEND) cd ${SOURCE_DIR}/${MINC_PACKAGE}/ ; \ if [ ! -e Makefile ] ; then \ ./configure $(MINC_FLAG) $(MINC_EXTRA) --prefix=$(PREFIX_PATH) --with-build-path=$(BUILD_PATH) ${CFG_COMP_FLAGS} ; \ fi ; \ ${MAKE}; ${MAKE} install Claude > jnikelski@[~]: otool -L /usr/local/bic/bin/minccalc > /usr/local/bic/bin/minccalc: > /usr/local/bic/lib/libhdf5.6.dylib (compatibility version > 7.0.0, current version 7.4.0) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current > version 1.2.3) > /usr/local/bic/lib/libnetcdf.4.dylib (compatibility version > 5.0.0, current version 5.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 125.2.1) > > When you built netcdf and hdf5, did you not build the shared libs? > If not, then that would explain the use of static linkage on the > system that you were working on. Is this not the recommended linkage? > ... or do we want everything (eg, hdf5/netcdf) statically linked? > > -jim From claude at bic.mni.mcgill.ca Thu Feb 24 22:44:05 2011 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Thu, 24 Feb 2011 22:44:05 -0500 Subject: [MINC-users] best_nonlin_reg.pl ? In-Reply-To: Message-ID: <201102250344.p1P3i5tq002657@cassio.bic.mni.mcgill.ca> Hi Lisa, The "best" scripts are part of the CIVET image-processing pipeline for cortical surfaces (Brain-Imaging Center, Alan Evans). They are not part of the mni-autoreg package for volume registration, but they could be added to the package eventually. They are a simplification of the registration script mritotal. Unlike mritotal which incorporates linear and non-linear registration in the same script, there are two separate best scripts for linear and non-linear registration. These scripts are easier to use (in my opinion). Finally, there is another script called nlpfit which also accomplishes non-linear fitting. Are these scripts the best? They seem to be quite robust and accurate. If you are familiar with minctracc, the best non-linear registration scripts will use smallest steps of 4mm whereas the nlpfit script will use smallest steps of 2mm. The best linear registration script provides an option to apply a brain mask, which I feel adds to the robustness of the algorithm (provided you have a tool to extract brain masks). Perhaps you can tell us your intended usage of the minc registration tools so that we can provide more focussed guidance. Claude > Hello, > > I read on the BIC website that "best_nonlin_reg.pl" is the most commonly > used nonlinear registration tool. > Is this a tool that is widely available? I do not see it with the version of > MINC I have. > > Lisa From a.janke at gmail.com Sat Feb 26 06:41:57 2011 From: a.janke at gmail.com (Andrew Janke) Date: Sat, 26 Feb 2011 21:41:57 +1000 Subject: [MINC-users] best_nonlin_reg.pl ? In-Reply-To: <201102250344.p1P3i5tq002657@cassio.bic.mni.mcgill.ca> References: <201102250344.p1P3i5tq002657@cassio.bic.mni.mcgill.ca> Message-ID: Hi Lisa, > Finally, there is another script called nlpfit > which also accomplishes non-linear fitting. And FWIW, you can download it here: http://packages.bic.mni.mcgill.ca/scripts/nlpfit As Claude mentioned the fit config is really what makes this work though, an example for ICBM fitting of brains that I use is like this: spencer:~$ cat work/pipes/ANDI/bin/fit.10-modelfit.conf # ICBM nlin conf @conf = ( {'step' => 32, 'blur_fwhm' => 16, 'iterations' => 20}, {'step' => 16, 'blur_fwhm' => 8, 'iterations' => 20}, {'step' => 12, 'blur_fwhm' => 6, 'iterations' => 20}, {'step' => 8, 'blur_fwhm' => 4, 'iterations' => 20}, {'step' => 6, 'blur_fwhm' => 3, 'iterations' => 20}, ); Note that this may or may not work for your data. The config file here describes a progression of fitting from 32mm step sizes down to 6mm with varying blur parameters along the way. -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Brisbane->Australia +61 (402) 700 883 From lrisa87 at uw.edu Mon Feb 28 13:46:04 2011 From: lrisa87 at uw.edu (Lisa F. Akiyama) Date: Mon, 28 Feb 2011 10:46:04 -0800 Subject: [MINC-users] best_nonlin_reg.pl ? In-Reply-To: References: <201102250344.p1P3i5tq002657@cassio.bic.mni.mcgill.ca> Message-ID: Hi Claude and Andrew, Thanks for all your input and guidance. Perhaps you can tell us your intended usage of the minc > registration tools so that we can provide more focussed > guidance. I am trying to create average infant head templates similar to what Fonov et al 2011 have created with the pediatric population. (He informed me that the infant templates available online were created using similar methods as stated in his 2011 paper involving pediatric data) There are many tools and options available in creating these templates, and I am trying to see what will work best for my purpose. As Claude mentioned the fit config is really what makes this work though Thanks for guiding me on how to modify the configurations. As a start, I will play around with nlpfit and fit config (I'll use what Fonov et al used for their settings as a guidance). Thank you. Best, Lisa ______________________________ On Sat, Feb 26, 2011 at 3:41 AM, Andrew Janke wrote: > Hi Lisa, > > > Finally, there is another script called nlpfit > > which also accomplishes non-linear fitting. > > And FWIW, you can download it here: > > http://packages.bic.mni.mcgill.ca/scripts/nlpfit > > As Claude mentioned the fit config is really what makes this work > though, an example for ICBM fitting of brains that I use is like this: > > spencer:~$ cat work/pipes/ANDI/bin/fit.10-modelfit.conf > # ICBM nlin conf > > @conf = ( > {'step' => 32, 'blur_fwhm' => 16, 'iterations' => 20}, > {'step' => 16, 'blur_fwhm' => 8, 'iterations' => 20}, > {'step' => 12, 'blur_fwhm' => 6, 'iterations' => 20}, > {'step' => 8, 'blur_fwhm' => 4, 'iterations' => 20}, > {'step' => 6, 'blur_fwhm' => 3, 'iterations' => 20}, > ); > > Note that this may or may not work for your data. The config file here > describes a progression of fitting from 32mm step sizes down to 6mm > with varying blur parameters along the way. > > > -- > Andrew Janke > (a.janke at gmail.com || http://a.janke.googlepages.com/) > Brisbane->Australia +61 (402) 700 883 > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users >