From sean at rogue-research.com Fri May 13 12:49:08 2011 From: sean at rogue-research.com (Sean McBride) Date: Fri, 13 May 2011 12:49:08 -0400 Subject: [MINC-development] MINC and ITK Message-ID: <20110513164908.2035047026@mail.rogue-research.com> Hi MINC devs, The ITK developers are currently working on a major new release, version 4, and as part of the process are cleaning through their 'Review' folder, one such class is the MINC reader written by Leila Baghdadi. While it's great, I wonder what the best path forward is. Would it be better if ITK were to use this code instead: This would have the advantage for supporting MINC1 in addition, and also the perhaps better in the sense that it appears to be something maintained by the core MINC developers themselves. Any thoughts? Thanks, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From vladimir.fonov at gmail.com Sat May 14 09:25:13 2011 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Sat, 14 May 2011 09:25:13 -0400 Subject: [MINC-development] MINC and ITK In-Reply-To: <20110513164908.2035047026@mail.rogue-research.com> References: <20110513164908.2035047026@mail.rogue-research.com> Message-ID: Hello, I think, I can be persuaded to be official minc-ITK supporter - how do I sign up? On Fri, May 13, 2011 at 12:49 PM, Sean McBride wrote: > Hi MINC devs, > > The ITK developers are currently working on a major new release, version > 4, and as part of the process are cleaning through their 'Review' > folder, one such class is the MINC reader written by Leila Baghdadi. > While it's great, I wonder what the best path forward is. > > Would it be better if ITK were to use this code instead: > > > > > This would have the advantage for supporting MINC1 in addition, and also > the perhaps better in the sense that it appears to be something > maintained by the core MINC developers themselves. -- Best regards, ?Vladimir S. Fonov ~ vladimir fonov gmail com From jason at phenogenomics.ca Sat May 14 09:38:31 2011 From: jason at phenogenomics.ca (Jason Lerch) Date: Sat, 14 May 2011 09:38:31 -0400 Subject: [MINC-development] MINC and ITK In-Reply-To: <20110513164908.2035047026@mail.rogue-research.com> References: <20110513164908.2035047026@mail.rogue-research.com> Message-ID: While a discussion on which itk interface to support could be a worthwhile one, I'm rather surprised that it could hinge on the fact that Leila, one of the two main developers behind MINC 2, is somehow not deemed a "core MINC developer." So let's argue on technical merit rather than the suggestion that the ITK interface could not be supported by Leila or the rest of our group in Toronto. Jason On 2011-05-13, at 12:49 PM, "Sean McBride" wrote: > Hi MINC devs, > > The ITK developers are currently working on a major new release, version > 4, and as part of the process are cleaning through their 'Review' > folder, one such class is the MINC reader written by Leila Baghdadi. > While it's great, I wonder what the best path forward is. > > Would it be better if ITK were to use this code instead: > > > > > This would have the advantage for supporting MINC1 in addition, and also > the perhaps better in the sense that it appears to be something > maintained by the core MINC developers themselves. > > Any thoughts? > > Thanks, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development From a.janke at gmail.com Sat May 14 09:35:58 2011 From: a.janke at gmail.com (Andrew Janke) Date: Sat, 14 May 2011 23:35:58 +1000 Subject: [MINC-development] MINC and ITK In-Reply-To: References: <20110513164908.2035047026@mail.rogue-research.com> Message-ID: I think you just did. a On Sat, May 14, 2011 at 23:25, Vladimir S. FONOV wrote: > I think, I can be persuaded to be official minc-ITK supporter - how do > ?I sign up? From a.janke at gmail.com Sat May 14 09:51:57 2011 From: a.janke at gmail.com (Andrew Janke) Date: Sat, 14 May 2011 23:51:57 +1000 Subject: [MINC-development] MINC and ITK In-Reply-To: References: <20110513164908.2035047026@mail.rogue-research.com> Message-ID: Hi Jason (and others), The thought did cross my mind too so you aren't alone there. Still I think while Sean might have said "maintained", I'll punt there is a fair amount of "seen discussion about recently on minc-users". :) We also probably shouldn't kid ourselves regarding "MINC" having a grand poo-bar or any formal structure... Certainly the original ITK interface that Leila implemented and is now maintaining again was a big step forward at the time when there was no ITK reader (beyond mincextract/minctoraw....). My understanding of the birth of EZMINC (by Vlad) was out of his own frustrations of getting his own ITK code to work with MINC1 files. Still I take your point about it being good if we had one 'sanctioned' interface. I take it you lot (by you lot, I mean the minc-ITK users in jason-toronto-leila land) still use the the ITK MINC:IO libraries on a daily basis? I was of the impression that Vlad was volunteering to perhaps integrate his code or ideas into the current ITK MINC reader so that MINC 1 file input was possible? or has this already been done? I haven't followed the ITK + MINC thing much as of late, been too busy working on other things. I was about to suggest to Vlad that he contacts Leila first to get up to speed with what the current status of the "real" ITK MINC IO stuff was, but you beat me to it. (Darn time-zones). a PS: It's freeeeezing here in Brisbane, 13deg C at 23:51, inhumane and here I am doing MINC email in between putting coats of paint on the hall cupboard. On Sat, May 14, 2011 at 23:38, Jason Lerch wrote: > While a discussion on which itk interface to support could be a worthwhile one, I'm rather surprised that it could hinge on the fact that Leila, one of the two main developers behind MINC 2, is somehow not deemed a "core MINC developer." So let's argue on technical merit rather than the suggestion that the ITK interface could not be supported by Leila or the rest of our group in Toronto. > > Jason From jason at phenogenomics.ca Sun May 15 09:38:44 2011 From: jason at phenogenomics.ca (Jason Lerch) Date: Sun, 15 May 2011 09:38:44 -0400 Subject: [MINC-development] MINC and ITK In-Reply-To: References: <20110513164908.2035047026@mail.rogue-research.com> Message-ID: Hi Andrew et al., > We also probably shouldn't kid ourselves regarding "MINC" having a > grand poo-bar or any formal structure... Certainly the original ITK > interface that Leila implemented and is now maintaining again was a > big step forward at the time when there was no ITK reader (beyond > mincextract/minctoraw....). Agreed on both points - nobody can enforce what another person should or should not work on. But still, some coordination can be useful so that there is not too much unnecessary duplication of work. > > My understanding of the birth of EZMINC (by Vlad) was out of his own > frustrations of getting his own ITK code to work with MINC1 files. > Still I take your point about it being good if we had one 'sanctioned' > interface. I take it you lot (by you lot, I mean the minc-ITK users > in jason-toronto-leila land) still use the the ITK MINC:IO libraries > on a daily basis? That's my understanding as well - we (us Toronto folks, that is), seem to be the happiest in the MINC community to discard MINC1 compatibility, which others have never felt comfortable with. By now I'm sure there are many other design differences between EZMINC and ITK MINC:IO libs, but since I've programmed in neither (though used both in end-user tools) I can't comment on what they are. And yes, we do use the ITK MINC:IO libs in existing code and for occasional development. I have no idea if anybody else does. > > I was of the impression that Vlad was volunteering to perhaps > integrate his code or ideas into the current ITK MINC reader so that > MINC 1 file input was possible? or has this already been done? I > haven't followed the ITK + MINC thing much as of late, been too busy > working on other things. I was about to suggest to Vlad that he > contacts Leila first to get up to speed with what the current status > of the "real" ITK MINC IO stuff was, but you beat me to it. (Darn > time-zones). My suspicion is that there's a lot of duplication between the two, so it'll likely end up more as a choice of which one is the more reasonable to go forward with. But again, I've programmed in neither, but would be keen to hear such a discussion on minv-dev! Jason > > > a > > PS: It's freeeeezing here in Brisbane, 13deg C at 23:51, inhumane and > here I am doing MINC email in between putting coats of paint on the > hall cupboard. > > On Sat, May 14, 2011 at 23:38, Jason Lerch wrote: >> While a discussion on which itk interface to support could be a worthwhile one, I'm rather surprised that it could hinge on the fact that Leila, one of the two main developers behind MINC 2, is somehow not deemed a "core MINC developer." So let's argue on technical merit rather than the suggestion that the ITK interface could not be supported by Leila or the rest of our group in Toronto. >> >> Jason > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development From vladimir.fonov at gmail.com Sun May 15 13:46:38 2011 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Sun, 15 May 2011 13:46:38 -0400 Subject: [MINC-development] MINC and ITK In-Reply-To: References: <20110513164908.2035047026@mail.rogue-research.com>

Message-ID: Hello Everybody, here is a test project: https://github.com/downloads/vfonov/EZminc/minc_test_itk.zip - inside there are two c++ programs: any_itk_any_3d and any_itk_any_4d - both a just reading and writing file using ITK functions. It's possible to compile both either with EZminc, or with Leila's MINC2 IO library. Here is what happens if you compile it with InsightToolkit-3.20.0 : I think, we have already reported similar results about 2 years ago. a. Using EZminc: 1. testing with MNI 152 2009a template : $ ./minc_test_build_ezminc/any_itk_any_3d mni_icbm152_t1_tal_nlin_sym_09a.mnc test_ezminc.mnc Reading mni_icbm152_t1_tal_nlin_sym_09a.mnc... Writing test_ezminc.mnc... $ mincinfo mni_icbm152_t1_tal_nlin_sym_09a.mnc file: mni_icbm152_t1_tal_nlin_sym_09a.mnc image: signed__ short -32768 to 32767 image dimensions: zspace yspace xspace dimension name length step start -------------- ------ ---- ----- zspace 189 1 -72 yspace 233 1 -134 xspace 197 1 -98 $ mincinfo test_ezminc.mnc file: test_ezminc.mnc image: signed__ short -32768 to 32767 image dimensions: zspace yspace xspace dimension name length step start -------------- ------ ---- ----- zspace 189 1 -72 yspace 233 1 -134 xspace 197 1 -98 $ mincstats -min -max mni_icbm152_t1_tal_nlin_sym_09a.mnc *** mincstats - reported min (0.0677952) doesn't equal header (0.0677952) Min: 0.06779524744 Max: 97.32924302 $ mincstats -min -max test_ezminc.mnc Min: 0.06779524684 Max: 97.32924652 2. testing with 4D dti file: $ mincinfo ibis_289656_living_phantom_phi_sd_20090527_dti_001.mnc file: ibis_289656_living_phantom_phi_sd_20090527_dti_001.mnc image: unsigned short 0 to 4095 image dimensions: time zspace yspace xspace dimension name length step start -------------- ------ ---- ----- time 26 13.3 0 zspace 81 2 -74.9735 yspace 96 -1.97917 107.812 xspace 96 -1.97917 98.2338 $ ./minc_test_build_ezminc/any_itk_any_4d ibis_289656_living_phantom_phi_sd_20090527_dti_001.mnc test_ezminc_4d.mnc Reading ibis_289656_living_phantom_phi_sd_20090527_dti_001.mnc ... Writing test_ezminc_4d.mnc ... (from micreate_group_variable): Variable 'dicom_0x0008' is not a standard MINC variable micreate_group_variable: MINC package entry point (from micreate_group_variable): Variable 'dicom_0x0010' is not a standard MINC variable micreate_group_variable: MINC package entry point (from micreate_group_variable): Variable 'dicom_0x0018' is not a standard MINC variable micreate_group_variable: MINC package entry point (from micreate_group_variable): Variable 'dicom_0x0019' is not a standard MINC variable micreate_group_variable: MINC package entry point (from micreate_group_variable): Variable 'dicom_0x0020' is not a standard MINC variable micreate_group_variable: MINC package entry point (from micreate_group_variable): Variable 'dicom_0x0021' is not a standard MINC variable micreate_group_variable: MINC package entry point (from micreate_group_variable): Variable 'dicom_0x0023' is not a standard MINC variable micreate_group_variable: MINC package entry point (from micreate_group_variable): Variable 'dicom_0x0028' is not a standard MINC variable micreate_group_variable: MINC package entry point (from micreate_group_variable): Variable 'dicom_0x0029' is not a standard MINC variable micreate_group_variable: MINC package entry point (from micreate_group_variable): Variable 'dicom_0x0032' is not a standard MINC variable micreate_group_variable: MINC package entry point (from micreate_group_variable): Variable 'dicom_0x0040' is not a standard MINC variable micreate_group_variable: MINC package entry point (from micreate_group_variable): Variable 'dicom_0x0051' is not a standard MINC variable micreate_group_variable: MINC package entry point (from micreate_group_variable): Variable 'dicom_groups' is not a standard MINC variable micreate_group_variable: MINC package entry point (from micreate_group_variable): Variable 'dicominfo' is not a standard MINC variable micreate_group_variable: MINC package entry point $ mincinfo test_4d_ezminc.mnc file: test_4d_ezminc.mnc image: unsigned short 0 to 65535 image dimensions: zspace yspace xspace time dimension name length step start -------------- ------ ---- ----- zspace 81 2 -74.9735 yspace 96 1.97917 -80.2086 xspace 96 1.97917 -89.787 time 26 13.3 0 $ mincstats -min -max ibis_289656_living_phantom_phi_sd_20090527_dti_001.mnc Min: 0 Max: 4095 $ mincstats -min -max test_ezminc_4d.mnc Min: 0 Max: 4095 b. using Leila's library: 1. testing with MNI 152 2009a template : $ ./minc_test_build_leila/any_itk_any_3d mni_icbm152_t1_tal_nlin_sym_09a.mnc test_leila.mnc Reading mni_icbm152_t1_tal_nlin_sym_09a.mnc... Writing test_leila.mnc... $ mincinfo test_leila.mnc file: test_leila.mnc image: signed__ float -3.4028234663852885981e+38 to 3.4028234663852885981e+38 image dimensions: zspace yspace xspace dimension name length step start -------------- ------ ---- ----- zspace 189 1 -72 yspace 233 1 -134 xspace 197 1 -98 $ mincstats -min -max test_leila.mnc *** mincstats - reported min (-32768) doesn't equal header (0) *** mincstats - reported max (32767) doesn't equal header (1) Min: -32768 Max: 32767 2. testing with 4D dti file: $ ./minc_test_build_leila/any_itk_any_4d ibis_289656_living_phantom_phi_sd_20090527_dti_001.mnc test_4d_leila.mnc Reading ibis_289656_living_phantom_phi_sd_20090527_dti_001.mnc ... Writing test_4d_leila.mnc ... HDF5-DIAG: Error detected in HDF5 (1.8.6) thread 0: #000: H5Dio.c line 153 in H5Dread(): selection+offset not within extent major: Dataspace minor: Out of range HDF5-DIAG: Error detected in HDF5 (1.8.6) thread 0: #000: H5Dio.c line 153 in H5Dread(): selection+offset not within extent major: Dataspace .... 44502 lines of errors $ mincinfo test_4d_leila.mnc file: test_4d_leila.mnc image: signed__ float -3.4028234663852885981e+38 to 3.4028234663852885981e+38 image dimensions: zspace yspace xspace vector_dimension dimension name length step start -------------- ------ ---- ----- zspace 96 -1.97917 107.812 yspace 96 -1.97917 98.2338 xspace 26 13.3 0 vector_dimension 26 0 0 $ mincstats -min -max test_4d_leila.mnc *** mincstats - reported max (41049) doesn't equal header (1) Min: 0 Max: 41049 On Sun, May 15, 2011 at 9:38 AM, Jason Lerch wrote: > Hi Andrew et al., > >> We also probably shouldn't kid ourselves regarding "MINC" having a >> grand poo-bar or any formal structure... ?Certainly the original ITK >> interface that Leila implemented and is now maintaining again was a >> big step forward at the time when there was no ITK reader (beyond >> mincextract/minctoraw....). > > Agreed on both points - nobody can enforce what another person should or should not work on. But still, some coordination can be useful so that there is not too much unnecessary duplication of work. > >> >> My understanding of the birth of EZMINC (by Vlad) was out of his own >> frustrations of getting his own ITK code to work with MINC1 files. >> Still I take your point about it being good if we had one 'sanctioned' >> interface. ?I take it you lot (by you lot, I mean the minc-ITK users >> in jason-toronto-leila land) still use the the ITK MINC:IO libraries >> on a daily basis? > > That's my understanding as well - we (us Toronto folks, that is), seem to be the happiest in the MINC community to discard MINC1 compatibility, which others have never felt comfortable with. By now I'm sure there are many other design differences between EZMINC and ITK MINC:IO libs, but since I've programmed in neither (though used both in end-user tools) I can't comment on what they are. And yes, we do use the ITK MINC:IO libs in existing code and for occasional development. I have no idea if anybody else does. > >> >> I was of the impression that Vlad was volunteering to perhaps >> integrate his code or ideas into the current ITK MINC reader so that >> MINC 1 file input was possible? ?or has this already been done? I >> haven't followed the ITK + MINC thing much as of late, been too busy >> working on other things. I was about to suggest to Vlad that he >> contacts Leila first to get up to speed with what the current status >> of the "real" ITK MINC IO stuff was, but you beat me to it. ?(Darn >> time-zones). > > My suspicion is that there's a lot of duplication between the two, so it'll likely end up more as a choice of which one is the more reasonable to go forward with. But again, I've programmed in neither, but would be keen to hear such a discussion on minv-dev! > > Jason > >> >> >> a >> >> PS: It's freeeeezing here in Brisbane, 13deg C at 23:51, inhumane and >> here I am doing MINC email in between putting coats of paint on the >> hall cupboard. >> >> On Sat, May 14, 2011 at 23:38, Jason Lerch wrote: >>> While a discussion on which itk interface to support could be a worthwhile one, I'm rather surprised that it could hinge on the fact that Leila, one of the two main developers behind MINC 2, is somehow not deemed a "core MINC developer." So let's argue on technical merit rather than the suggestion that the ITK interface could not be supported by Leila or the rest of our group in Toronto. >>> >>> Jason >> _______________________________________________ >> MINC-development mailing list >> MINC-development at bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > -- Best regards, ?Vladimir S. Fonov ~ vladimir fonov gmail com From sean at rogue-research.com Sun May 15 13:58:29 2011 From: sean at rogue-research.com (sean at rogue-research.com) Date: Sun, 15 May 2011 13:58:29 -0400 Subject: [MINC-development] MINC and ITK In-Reply-To: References: <20110513164908.2035047026@mail.rogue-research.com> Message-ID: <3c0a0a643f14d83cafcc629cf76449d8.squirrel@www.rogue-research.com> > While a discussion on which itk interface to support could be a worthwhile > one, I'm rather surprised that it could hinge on the fact that Leila, one > of the two main developers behind MINC 2, is somehow not deemed a "core > MINC developer." So let's argue on technical merit rather than the > suggestion that the ITK interface could not be supported by Leila or the > rest of our group in Toronto. Apologies if my words gave offense, none was intended. I was not aware of her involvement. I was not trying diminish (or inflate) anyone's contributions, competencies, or otherwise. Indeed, I am only interested in technical matters. (Notice that I cc'ed Leila on my original post!) My interest is merely in ITK being able to open any medical image file format. ITK currently does DICOM, Analyze, and NIfTI. It also does MINC2 (thanks Leila!) and PAR/REC, but these last two are in ITK's 'Review' directory, which I should have described in my first post: it acts like the 'entry point' for code contributed to ITK. It is not meant as a final place for such code. It is not included in default builds. It is not built and tested nightly (by anyone except myself, as far as I can tell). Unlike (I gather) most people on this list, I am not part of any MNI / McGill / MINC circle, I have no knowledge of your inner workings, I don't know who the developers are. I simply googled for info on MINC and ITK integration and found stuff like this on the MINC wiki: http://en.wikibooks.org/wiki/MINC/EZMINC/ITK_Integration "If you are not satisfied with MINC2 only interface provided by ITK, or need access to MINC file attributes, or want to read/write 4D data use ITK interface provided by EZMINC" http://en.wikibooks.org/wiki/MINC/Future/Tconf20110223 "ITK & VTK ? currently with limited support." My impression therefore was that the "core MINC developers" (whoever you all are!) acknowledge that there is work to be done in this area. I only wanted to inform this list of the discussion that started here: http://www.itk.org/pipermail/insight-users/2011-May/040953.html As Andrew suggests, I think "one 'sanctioned' interface" would be best, so that ITK can include it. The one ITK currently has is great, but your own wiki implies that it does not support: MINC1, 4D data, and MINC file attributes. I believe it also does not support .xfm files. Support for all those would be great since the idea here is for ITK to open any image format you throw at it. It could well help adoption of MINC; ITK, and thus all apps based on it, can already open all the 'competitor' formats. >I was of the impression that Vlad was volunteering to perhaps >integrate his code or ideas into the current ITK MINC reader so that >MINC 1 file input was possible? or has this already been done? In ITK itself anyway, itkMINC2ImageIO hasn't changed since 2008: http://itk.org/gitweb?p=ITK.git;a=history;f=Code/Review/itkMINC2ImageIO.cxx;h=32006d7f597eff40629e76c7d3266872e9c248dc;hb=f338f8a0ce5fe94e8a02cd3e7e9c2a728e9c1a00 I'm sure both codebases have their pros and cons (I have not really looked), but an integration combining the best of each sounds ideal! If such a thing is to happen, now is probably the best time (from the perspective of ITK), since they are cleaning through their Review folder. I know next to nothing of MINC, but know something of ITK, and could contribute a little time to help in this endeavour. > think, I can be persuaded to be official minc-ITK supporter - how do > I sign up? Leila and I are already members, if anyone else is interested, I suggesting joining the ITK mailing list(s): http://www.itk.org/mailman/listinfo/insight-users http://www.itk.org/mailman/listinfo/insight-developers Cheers, Sean From a.janke at gmail.com Sun May 15 20:29:27 2011 From: a.janke at gmail.com (Andrew Janke) Date: Mon, 16 May 2011 10:29:27 +1000 Subject: [MINC-development] MINC and ITK In-Reply-To: References: <20110513164908.2035047026@mail.rogue-research.com>

Message-ID: > That's my understanding as well - we (us Toronto folks, that is), seem to be the happiest in the MINC community to discard MINC1 compatibility, Pick me too! I have been MINC2 only for at least the last 3 years, the impending MINC2.2 release will finally drive the final nail in the MINC1 coffin. The default will be to write out MINC2 files irrespective of what the input was. I don't plan to add a -1 flag to all the binaries to write out MINC1 and instead will only add a -1 flag to mincconvert for the sticklers. For those asking why, I have had requests for this from users none of whom were from the BIC! Perhaps I should open a separate thread about this on minc-dev but expect to see my commits for this on github shortly. a From baghdadi at phenogenomics.ca Mon May 16 10:11:30 2011 From: baghdadi at phenogenomics.ca (Leila Baghdadi) Date: Mon, 16 May 2011 10:11:30 -0400 Subject: [MINC-development] MINC and ITK Message-ID: <6351474.47321305555090061.JavaMail.root@mail2.phenogenomics.ca> Hi everyone, I wrote the ITK minc2 support sometime after the development of minc2 was complete mostly because I was writing a lot of code in ITK and was tired of having to change file formats all the time and lose the minc header information. I got a few posts from people who knew I was doing both ITK and MINC2 development so I submitted the ITKMINC2 support to the ITK journal so that these people could get a hold of the code and use it. ITKMINC2 support makes MINC2 API calls exclusively and as a result unable to read MINC1 format which is not used much in our lab. As Jason mentioned, we are happily using MINC2 so the thought of supporting MINC1 never crossed my mind. If you check vtk for instance, I wrote my own vtkMINC2Image reader and writer when we needed it in our lab and David Gobbi has committed various classes for reading/writing minc1 and obj formats and so on. I agree that the time has come to have one ITK-MINC support code which can take care of both formats, So I think the best way is for Vladimir and I to join forces for itk-minc support and figure out what is the best way to proceed. I will update the list as soon as I have some information. Leila p.s thank you Sean for your interest and starting this thread p.p.s Thank you Jason for granting me the minc core developer privilege although I have written a lot of minc2 code, some of those guys still beat me to it, they started way before I knew what imaging is! ----- Original Message ----- From: Andrew Janke Sent: Sun, 5/15/2011 8:29pm To: MINC development discussion & planning Subject: Re: [MINC-development] MINC and ITK > That's my understanding as well - we (us Toronto folks, that is), seem to be the happiest in the MINC community to discard MINC1 compatibility, Pick me too! I have been MINC2 only for at least the last 3 years, the impending MINC2.2 release will finally drive the final nail in the MINC1 coffin. The default will be to write out MINC2 files irrespective of what the input was. I don't plan to add a -1 flag to all the binaries to write out MINC1 and instead will only add a -1 flag to mincconvert for the sticklers. For those asking why, I have had requests for this from users none of whom were from the BIC! Perhaps I should open a separate thread about this on minc-dev but expect to see my commits for this on github shortly. a _______________________________________________ MINC-development mailing list MINC-development at bic.mni.mcgill.ca http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development From a.janke at gmail.com Tue May 17 01:55:17 2011 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 17 May 2011 15:55:17 +1000 Subject: [MINC-development] MINC previews in nautilus. Message-ID: Figured why can't we have these too... So for the brave using nautilus (gnome file manager) try this 1. give MINC a mime type: cai-harold:minc-thumbnailer$ cat x-minc.xml MINC file 2. Copy it to: $HOME/.local/share/mime/application 3. Let xdg know about it: $ update-mime-database $HOME/.local/share/mime 4. Test it: $ xdg-mime query filetype ~/data/me/a.mnc application/x-minc 5. create the gnome gconf magic $ gconftool-2 -s /desktop/gnome/thumbnailers/application at x-minc/command -t string "/usr/bin/minc-thumbnailer %u %o" $ gconftool-2 -s /desktop/gnome/thumbnailers/application at x-minc/enable -t boolean true 6. create /usr/bin/minc-thumbnailer: #! /bin/sh # # MINC file previewer # # Andrew Janke - a.janke at gmail.com USAGE="[OPTION] -h, -? print this message" if [ $1 = "-h" ] then echo -e usage: $0 "$USAGE" >&2 exit 1 fi infile=${1#file://} outfile=$2 export PATH=$PATH:/usr/local/bic/bin /usr/local/bic/bin/mincpik -triplanar -tilesize 100 \ -horizontal -sagittal_offset_perc 10 "$infile" "png:$outfile" 7. Now you might have to clear out all the old cached pngs from when nautilus failed to create pngs from MINC files in the past and couldn't as it didn't know how: $ rm -f $HOME/.thumbnails/fail/gnome-thumbnail-factory/* 8. restart nautilus: $ nautilus -q 9. Go to a directory with .mnc files in it and bask in your glory. YMWV and if I can get this to work fairly consistently I will include it in the mincbundle ubuntu package. ie: PLEASE PLEASE test this. I'll upload the various bits and pieces to github soon. a refs: http://wiki.ubuntuusers.de/OpenDocument_Thumbnails http://jens.triq.net/thumbnail-spec/index.html From mishkind at gmail.com Tue May 17 15:35:28 2011 From: mishkind at gmail.com (Mishkin Derakhshan) Date: Tue, 17 May 2011 15:35:28 -0400 Subject: [MINC-development] MINC previews in nautilus. In-Reply-To: References: Message-ID: Hi Andrew, Didn't work for me. Here is my debugging info: opus[~]$ uname -a Linux opus 2.6.24-24-generic #1 SMP Tue Aug 18 16:22:17 UTC 2009 x86_64 GNU/Linux opus[/etc]$ cat debian_version lenny/sid opus[~]$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 8.04.3 LTS Release: 8.04 Codename: hardy On Tue, May 17, 2011 at 1:55 AM, Andrew Janke wrote: > Figured why can't we have these too... > > So for the brave using nautilus (gnome file manager) try this > > 1. give MINC a mime type: > > cai-harold:minc-thumbnailer$ cat x-minc.xml > > type="application/x-minc"> > ? > ?MINC file > ? > > > 2. Copy it to: > > ? $HOME/.local/share/mime/application I didn't have this directory. I had: opus[~/.local/share]$ ll total 20K drwx------ 4 mishkin cta 4.0K 2009-09-09 17:21 Trash drwxr-xr-x 2 mishkin cta 4.0K 2009-09-12 19:47 desktop-directories drwxr-xr-x 3 mishkin mishkin 4.0K 2011-03-08 10:38 tracker drwxr-xr-x 2 mishkin cta 4.0K 2011-05-05 13:46 applications I created mime/application and put it in there. > > 3. Let xdg know about it: > > ? $ update-mime-database $HOME/.local/share/mime opus[~/.local/share/mime/application]$ update-mime-database /home/mishkin/.local/share/mime/ Directory '/home/mishkin/.local/share/mime/packages' does not exist! I created mime/packages and it worked. > > 4. Test it: > > ? $ xdg-mime query filetype ~/data/me/a.mnc > ? application/x-minc > opus[~]$ xdg-mime query filetype data/cube.mnc application/octet-stream opus[~]$ file data/cube.mnc data/cube.mnc: NetCDF Data Format data I did the rest of the steps but was unable to bask in any glory. > 5. create the gnome gconf magic > > ? $ gconftool-2 -s > /desktop/gnome/thumbnailers/application at x-minc/command -t string > "/usr/bin/minc-thumbnailer %u %o" > ? $ gconftool-2 -s > /desktop/gnome/thumbnailers/application at x-minc/enable -t boolean true > > 6. create /usr/bin/minc-thumbnailer: > > #! /bin/sh > # > # MINC file previewer > # > # Andrew Janke - a.janke at gmail.com > > USAGE="[OPTION] > ?-h, -? ? print this message" > > if [ $1 = "-h" ] > then > ? echo -e usage: $0 "$USAGE" >&2 > ? exit 1 > fi > > infile=${1#file://} > outfile=$2 > > export PATH=$PATH:/usr/local/bic/bin > > /usr/local/bic/bin/mincpik -triplanar -tilesize 100 \ > ? -horizontal -sagittal_offset_perc 10 "$infile" "png:$outfile" > > 7. Now you might have to clear out all the old cached pngs from when > nautilus failed to create pngs from MINC files in the past and > couldn't as it didn't know how: > > ? $ rm -f $HOME/.thumbnails/fail/gnome-thumbnail-factory/* > > 8. restart nautilus: > > ? $ nautilus -q > > 9. Go to a directory with .mnc files in it and bask in your glory. > > YMWV and if I can get this to work fairly consistently I will include > it in the mincbundle ubuntu package. ?ie: PLEASE PLEASE test this. > I'll upload the various bits and pieces to github soon. > > > > > a > > refs: > http://wiki.ubuntuusers.de/OpenDocument_Thumbnails > http://jens.triq.net/thumbnail-spec/index.html > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > From a.janke at gmail.com Tue May 17 19:15:57 2011 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 18 May 2011 09:15:57 +1000 Subject: [MINC-development] MINC previews in nautilus. In-Reply-To: References: Message-ID: > Didn't work for me. Here is my debugging info: Thanks for the debugging Mishkin, >> ? $HOME/.local/share/mime/application > > I didn't have this directory. I had: And that's because I'm a gumby and gave the wrong info for the mime types. Instead create this: $ cat $HOME/.local/share/mime/packages/minc.xml

MINC file

And then $ update-mime-database $HOME/.local/share/mime/ This should create the file I first posted. > opus[~]$ xdg-mime query filetype data/cube.mnc > application/octet-stream This means the mime stuff didn't work. It should say application/x-minc. I am yet to figure out how to make this a global mime type, no doubt in /usr/share/mime somewhere. If the mime query above works, restarting nautilus (nautilus -q) should then have things working. a