From vladimir.fonov at gmail.com Tue Dec 11 15:47:08 2012 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Tue, 11 Dec 2012 15:47:08 -0500 Subject: [MINC-development] MINC2 API inconsistent data type Message-ID: Hello, could somebody explain why int miget_dimension_size(midimhandle_t dimension, unsigned int *size_ptr); and int miget_dimension_sizes(const midimhandle_t dimensions[], int array_length, unsigned int sizes[]); - uses unsigned int for dimension size, while int miget_real_value_hyperslab(mihandle_t volume, mitype_t buffer_data_type, const unsigned long start[], const unsigned long count[], void *buffer); - uses unsigned long for indexing hyperslabs ? Which makes a difference on 64bit platform. maybe it's worth to have uniform datatype describing size of the dimensions ? -- Best regards, Vladimir S. Fonov ~ vladimir fonov gmail com -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.janke at gmail.com Tue Dec 11 15:53:19 2012 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 12 Dec 2012 06:53:19 +1000 Subject: [MINC-development] MINC2 API inconsistent data type In-Reply-To: References: Message-ID: Hi Vlad, > could somebody explain why > > int miget_dimension_size(midimhandle_t dimension, unsigned int *size_ptr); > > int miget_dimension_sizes(const midimhandle_t dimensions[], int array_length, > unsigned int sizes[]); > > > - uses unsigned int for dimension size, while > > int miget_real_value_hyperslab(mihandle_t volume, > mitype_t buffer_data_type, > const unsigned long start[], > const unsigned long count[], > void *buffer); > > - uses unsigned long for indexing hyperslabs ? Which makes a difference on 64bit platform. My initial reaction is: "because it's wrong". > maybe it's worth to have uniform datatype describing size of the dimensions ? Indeed. I'll bet this is a result of history in that the first two functions existed first and the last was added as part of MINC2 at which point it was decided that such things should be a long. Mind you long is very much overkill for dimension sizes/start/count but I imagine it was done because of the 64bit problem as you have said. a From vladimir.fonov at gmail.com Tue Dec 11 16:00:13 2012 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Tue, 11 Dec 2012 16:00:13 -0500 Subject: [MINC-development] MINC2 API inconsistent data type In-Reply-To: References: Message-ID: <50C79EDD.5050302@gmail.com> Hello, I think the best would be to use hsize_t - since that's the underlying HDF5 data type. On 12-12-11 03:53 PM, Andrew Janke wrote: >> - uses unsigned long for indexing hyperslabs ? Which makes a difference on 64bit platform. > > My initial reaction is: "because it's wrong". > >> maybe it's worth to have uniform datatype describing size of the dimensions ? -- Best regards, Vladimir S. FONOV ~ vladimir.fonov gmail.com From a.janke at gmail.com Tue Dec 11 16:08:01 2012 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 12 Dec 2012 07:08:01 +1000 Subject: [MINC-development] MINC2 API inconsistent data type In-Reply-To: <50C79EDD.5050302@gmail.com> References: <50C79EDD.5050302@gmail.com> Message-ID: On 12 December 2012 07:00, Vladimir S. FONOV wrote: > > I think the best would be to use hsize_t - since that's the underlying HDF5 > data type. Sounds like a very good plan to me. I wonder how many people have already used the original two functions in code? Still I think it's an important enough change to warrant "breaking" things. a From jason at phenogenomics.ca Tue Dec 11 16:11:45 2012 From: jason at phenogenomics.ca (Jason Lerch) Date: Tue, 11 Dec 2012 16:11:45 -0500 Subject: [MINC-development] MINC2 API inconsistent data type In-Reply-To: References: Message-ID: <020ABCD6-5540-4FE8-8704-5C71F8CC8611@phenogenomics.ca> On 2012-12-11, at 4:08 PM, Andrew Janke wrote: > On 12 December 2012 07:00, Vladimir S. FONOV wrote: >> >> I think the best would be to use hsize_t - since that's the underlying HDF5 >> data type. > > Sounds like a very good plan to me. I wonder how many people have > already used the original two functions in code? Still I think it's > an important enough change to warrant "breaking" things. I use them both in RMINC, pyminc, and a few bits of C code but agree that some breakage to get rid of these kind of inconsistencies (unless there's a reason for them, though I can't think of it) is worth it. Jason From baghdadi at phenogenomics.ca Tue Dec 11 16:23:41 2012 From: baghdadi at phenogenomics.ca (Leila Baghdadi) Date: Tue, 11 Dec 2012 16:23:41 -0500 Subject: [MINC-development] MINC2 API inconsistent data type Message-ID: <18143642.320031355261021585.JavaMail.root@mail2.phenogenomics.ca> Hi guys, Yep, I think Andrew summarized it well. I wanted to at least change the first two functions in the past but every time got into some ditch regarding compatibility with existing code either mine or someone else's, which grew exponentially! for instance my vtk MINC2 reader/writer, all of my recon code and alot of other code I agree that hsize_t is the right way to proceed! once the change has been made, I can make sure all the code on our end is changed! Leila ----- Original Message ----- From: Andrew Janke Sent: Tue, 12/11/2012 3:53pm To: MINC development discussion & planning Subject: Re: [MINC-development] MINC2 API inconsistent data type Hi Vlad, > could somebody explain why > > int miget_dimension_size(midimhandle_t dimension, unsigned int *size_ptr); > > int miget_dimension_sizes(const midimhandle_t dimensions[], int array_length, > unsigned int sizes[]); > > > - uses unsigned int for dimension size, while > > int miget_real_value_hyperslab(mihandle_t volume, > mitype_t buffer_data_type, > const unsigned long start[], > const unsigned long count[], > void *buffer); > > - uses unsigned long for indexing hyperslabs ? Which makes a difference on 64bit platform. My initial reaction is: "because it's wrong". > maybe it's worth to have uniform datatype describing size of the dimensions ? Indeed. I'll bet this is a result of history in that the first two functions existed first and the last was added as part of MINC2 at which point it was decided that such things should be a long. Mind you long is very much overkill for dimension sizes/start/count but I imagine it was done because of the 64bit problem as you have said. a _______________________________________________ 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 Tue Dec 11 16:32:58 2012 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Tue, 11 Dec 2012 16:32:58 -0500 Subject: [MINC-development] MINC2 API error handling Message-ID: <50C7A68A.7040204@gmail.com> Hello Everybody, another issue in MINC2 API - is almost complete lack of error reporting and sometimes checking. I.e functions are sometimes quietly returning MI_ERROR , and sometimes there is no check for the error from underlying HDF5 call. I've been recently inserting code pieces like: https://github.com/BIC-MNI/libminc/blob/minc_lite/libsrc2/hyper.c#L606 which is printing some info on stderr. Which is not the most elegant way for handling errors, especially for some GUI program. Would anyone have some other suggestions? -- Best regards, Vladimir S. FONOV ~ vladimir.fonov gmail.com From baghdadi at phenogenomics.ca Tue Dec 11 16:49:14 2012 From: baghdadi at phenogenomics.ca (Leila Baghdadi) Date: Tue, 11 Dec 2012 16:49:14 -0500 Subject: [MINC-development] MINC2 API error handling In-Reply-To: <50C7A68A.7040204@gmail.com> Message-ID: <22315583.320191355262554217.JavaMail.root@mail2.phenogenomics.ca> Hello, from what I have seen hdf5 returns meaningful errors including function and line number but I did not find it useful specially when I was trying to debug minc2 code!! so I guess your method of reporting some info is more useful when it comes to debugging, Leila ----- Original Message ----- From: Vladimir S. FONOV Sent: Tue, 12/11/2012 4:32pm To: "discussion & planning, MINC" Subject: [MINC-development] MINC2 API error handling Hello Everybody, another issue in MINC2 API - is almost complete lack of error reporting and sometimes checking. I.e functions are sometimes quietly returning MI_ERROR , and sometimes there is no check for the error from underlying HDF5 call. I've been recently inserting code pieces like: https://github.com/BIC-MNI/libminc/blob/minc_lite/libsrc2/hyper.c#L606 which is printing some info on stderr. Which is not the most elegant way for handling errors, especially for some GUI program. Would anyone have some other suggestions? -- Best regards, Vladimir S. FONOV ~ vladimir.fonov gmail.com _______________________________________________ MINC-development mailing list MINC-development at bic.mni.mcgill.ca http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development From sean at rogue-research.com Tue Dec 11 16:59:30 2012 From: sean at rogue-research.com (Sean McBride) Date: Tue, 11 Dec 2012 16:59:30 -0500 Subject: [MINC-development] MINC2 API inconsistent data type In-Reply-To: <50C79EDD.5050302@gmail.com> References: <50C79EDD.5050302@gmail.com> Message-ID: <20121211215930.1180007917@mail.rogue-research.com> On Tue, 11 Dec 2012 16:00:13 -0500, Vladimir S. FONOV said: >I think the best would be to use hsize_t - since that's the underlying >HDF5 data type. But then that exposes the fact that MINC uses HDF5. MINC has already switched from NetCDF to HDF and maybe will switch again in the future. What about just size_t? ... which is probably how hsize_t is defined anyway. Cheers, -- ____________________________________________________________ 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 Dec 11 17:01:47 2012 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 12 Dec 2012 08:01:47 +1000 Subject: [MINC-development] MINC2 API error handling In-Reply-To: <50C7A68A.7040204@gmail.com> References: <50C7A68A.7040204@gmail.com> Message-ID: Hi Vlad, > another issue in MINC2 API - is almost complete lack of error reporting and > sometimes checking. I.e functions are sometimes quietly returning MI_ERROR , > and sometimes there is no check for the error from underlying HDF5 call. > I've been recently inserting code pieces like: > https://github.com/BIC-MNI/libminc/blob/minc_lite/libsrc2/hyper.c#L606 > > which is printing some info on stderr. Which is not the most elegant way for > handling errors, especially for some GUI program. > > Would anyone have some other suggestions? Ideally this should all be done via minc_error. https://github.com/BIC-MNI/minc/blob/master/libsrc/minc_error.h Perhaps adding a method that doesn't require an entry in a great big enum would be useful. The idea was that in time we'd add code to this such that you could redirect the error from stderr to somewhere else via a function call so that GUI's could capture this output. There also was a plan to add calls to this to log errors at various levels but this was never done. a From vladimir.fonov at gmail.com Tue Dec 11 17:10:43 2012 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Tue, 11 Dec 2012 17:10:43 -0500 Subject: [MINC-development] MINC2 API error handling In-Reply-To: References: <50C7A68A.7040204@gmail.com> Message-ID: <50C7AF63.3060001@gmail.com> Hello, so, that would require putting macros like MI_SAVE_ROUTINE_NAME/MI_RETURN_ERROR/MI_LOG_PKG_ERROR2 in all minc2 api functions? On 12-12-11 05:01 PM, Andrew Janke wrote: > Hi Vlad, > >> another issue in MINC2 API - is almost complete lack of error reporting and >> sometimes checking. I.e functions are sometimes quietly returning MI_ERROR , >> and sometimes there is no check for the error from underlying HDF5 call. >> I've been recently inserting code pieces like: >> https://github.com/BIC-MNI/libminc/blob/minc_lite/libsrc2/hyper.c#L606 >> >> which is printing some info on stderr. Which is not the most elegant way for >> handling errors, especially for some GUI program. >> >> Would anyone have some other suggestions? > > Ideally this should all be done via minc_error. > > https://github.com/BIC-MNI/minc/blob/master/libsrc/minc_error.h > > Perhaps adding a method that doesn't require an entry in a great big > enum would be useful. > > The idea was that in time we'd add code to this such that you could > redirect the error from stderr to somewhere else via a function call > so that GUI's could capture this output. There also was a plan to add > calls to this to log errors at various levels but this was never done. -- Best regards, Vladimir S. FONOV ~ vladimir.fonov gmail.com From a.janke at gmail.com Tue Dec 11 17:18:54 2012 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 12 Dec 2012 08:18:54 +1000 Subject: [MINC-development] MINC2 API error handling In-Reply-To: <50C7AF63.3060001@gmail.com> References: <50C7A68A.7040204@gmail.com> <50C7AF63.3060001@gmail.com> Message-ID: On 12 December 2012 08:10, Vladimir S. FONOV wrote: > so, that would require putting macros like > MI_SAVE_ROUTINE_NAME/MI_RETURN_ERROR/MI_LOG_PKG_ERROR2 in all minc2 api > functions? Well while that might be ideal, I think we could just assume that whoever is writing the error messages is going to make them informative! :) We could always just use things like __FILE__ and __LINE__ in the error message itself. a From claude at bic.mni.mcgill.ca Tue Dec 11 18:49:24 2012 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Tue, 11 Dec 2012 18:49:24 -0500 Subject: [MINC-development] warning from volume_io/alloc.h Message-ID: <201212112349.qBBNnOib009057@agrippa.bic.mni.mcgill.ca> Hi, Would anyone object to change volume_io/Include/volume_io/alloc.h to avoid a compilation warning for const char *? Here is the new piece of code: #ifdef NO_DEBUG_ALLOC #define _ALLOC_SOURCE_LINE #define _ALLOC_SOURCE_LINE_ARG_DEF #define _ALLOC_SOURCE_LINE_ARGUMENTS #define PRINT_ALLOC_SOURCE_LINE #else #define _ALLOC_SOURCE_LINE , (char*)__FILE__, __LINE__ #define _ALLOC_SOURCE_LINE_ARG_DEF , char filename[], int line_number #define _ALLOC_SOURCE_LINE_ARGUMENTS , filename, line_number #define PRINT_ALLOC_SOURCE_LINE \ print_alloc_source_line( filename, line_number ); #endif Note the cast (char*) on __FILE__, which is consistent with the definition on the next line char filename[]. By default, the compiler assumes const char * and writes out a warning. Unless we change _ALLOC_SOURCE_LINE_ARG_DEF to const char filename[]... Andrew, I'll let you githubize this one as I'm not a minc developer. :-) Claude From sean at rogue-research.com Tue Dec 11 20:10:51 2012 From: sean at rogue-research.com (Sean McBride) Date: Tue, 11 Dec 2012 20:10:51 -0500 Subject: [MINC-development] warning from volume_io/alloc.h In-Reply-To: <201212112349.qBBNnOib009057@agrippa.bic.mni.mcgill.ca> References: <201212112349.qBBNnOib009057@agrippa.bic.mni.mcgill.ca> Message-ID: <20121212011051.2020074825@mail.rogue-research.com> On Tue, 11 Dec 2012 18:49:24 -0500, Claude LEPAGE said: >#define _ALLOC_SOURCE_LINE , (char*)__FILE__, __LINE__ >#define _ALLOC_SOURCE_LINE_ARG_DEF , char filename[], int line_number >#define _ALLOC_SOURCE_LINE_ARGUMENTS , filename, line_number >#define PRINT_ALLOC_SOURCE_LINE \ > print_alloc_source_line( filename, line_number ); >#endif > > >Note the cast (char*) on __FILE__, which is consistent with the >definition on the next line char filename[]. By default, the compiler >assumes const char * and writes out a warning. Unless we change >_ALLOC_SOURCE_LINE_ARG_DEF to const char filename[]... The latter sounds preferable. Casting away const is a big enough code smell to be listed in places like this: Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From claude at bic.mni.mcgill.ca Tue Dec 11 23:46:21 2012 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Tue, 11 Dec 2012 23:46:21 -0500 Subject: [MINC-development] warning from volume_io/alloc.h In-Reply-To: <20121212011051.2020074825@mail.rogue-research.com> Message-ID: <201212120446.qBC4kLOH014311@agrippa.bic.mni.mcgill.ca> Hi, Security rules... I like this one: EXP05-EX1: An exception to this recommendation is allowed when it is necessary to cast away const when invoking a legacy API that does not accept a const argument, provided the function does not attempt to modify the referenced variable. For example, the following code casts away the const qualification of INVFNAME in the call to the audit_log() function. Is minc a "legacy" code? :-) For the case of the FREE macro, I think it is safe to use const char *. However, I'm not sure what would happen if we used const char * in ParseArgv. Theoretically, those strings shouldn't be modified. Claude > > >#define =5FALLOC=5FSOURCE=5FLINE , (char*)=5F=5FFILE=5F=5F, = > =5F=5FLINE=5F=5F > >#define =5FALLOC=5FSOURCE=5FLINE=5FARG=5FDEF , char filename[], int = > line=5Fnumber > >#define =5FALLOC=5FSOURCE=5FLINE=5FARGUMENTS , filename, line=5Fnumber > >#define PRINT=5FALLOC=5FSOURCE=5FLINE \ > > print=5Falloc=5Fsource=5Fline( filename, line=5Fnumber ); > >#endif > > > > > >Note the cast (char*) on =5F=5FFILE=5F=5F, which is consistent with the > >definition on the next line char filename[]. By default, the compiler > >assumes const char * and writes out a warning. Unless we change > >=5FALLOC=5FSOURCE=5FLINE=5FARG=5FDEF to const char filename[]... > > The latter sounds preferable. Casting away const is a big enough code = > smell to be listed in places like this: > > ot+cast+away+a+const+qualification> > > Cheers, > > -- > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr=E9al, Qu=E9bec, Canada > > From claude at bic.mni.mcgill.ca Wed Dec 12 00:44:17 2012 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Wed, 12 Dec 2012 00:44:17 -0500 Subject: [MINC-development] warning from volume_io/alloc.h In-Reply-To: <20121212011051.2020074825@mail.rogue-research.com> Message-ID: <201212120544.qBC5iHvB015263@agrippa.bic.mni.mcgill.ca> Hi, I tried Sean's suggestion of the latter. Well... not so fun says the compiler. My former way is much simpler to implement. Changing to const char * would mean redefining VIO_STR (alias STRING) to be a const char * instead of its current definition of char *. Lots of prototypes to change everywhere (I'm too lazy to do it). :-) I also tried const char * in /libsrc/ParseArgv.h and it compiles cleanly: /* * Structure used to specify how to handle argv options. */ typedef struct { const char *key; /* The key string that flags the option in the * argv array. */ int type; /* Indicates option type; see below. */ char *src; /* Value to be used in setting dst; usage * depends on type. */ char *dst; /* Address of value to be modified; usage * depends on type. */ const char *help; /* Documentation message describing this option. */ } ArgvInfo; Claude > >#define =5FALLOC=5FSOURCE=5FLINE , (char*)=5F=5FFILE=5F=5F, = > =5F=5FLINE=5F=5F > >#define =5FALLOC=5FSOURCE=5FLINE=5FARG=5FDEF , char filename[], int = > line=5Fnumber > >#define =5FALLOC=5FSOURCE=5FLINE=5FARGUMENTS , filename, line=5Fnumber > >#define PRINT=5FALLOC=5FSOURCE=5FLINE \ > > print=5Falloc=5Fsource=5Fline( filename, line=5Fnumber ); > >#endif > > > > > >Note the cast (char*) on =5F=5FFILE=5F=5F, which is consistent with the > >definition on the next line char filename[]. By default, the compiler > >assumes const char * and writes out a warning. Unless we change > >=5FALLOC=5FSOURCE=5FLINE=5FARG=5FDEF to const char filename[]... > > The latter sounds preferable. Casting away const is a big enough code = > smell to be listed in places like this: > > ot+cast+away+a+const+qualification> > > Cheers, > > -- > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr=E9al, Qu=E9bec, Canada > > From vladimir.fonov at gmail.com Fri Dec 21 17:57:46 2012 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Fri, 21 Dec 2012 17:57:46 -0500 Subject: [MINC-development] MINC2 API for accessing metadata - broken ? Message-ID: <50D4E96A.9010704@gmail.com> Hello Everybody, I am trying to add metadata functionality to the new MINC2 ITK reader/writer ( http://review.source.kitware.com/#/c/9033/ ) Using MINC2 API functions ( milist_start , milist_grp_next , milist_attr_next ) First of all, there was a bug in grpattr.c ,function milist_grp_op , preventing function milist_grp_next actually returning group name. My question is following - what is the official way of getting values of what was a global attributes in MINC1 world (i.e :ident, :minc_version ). Since in MINC2 world the function miget_attr_values does following: if ( strcmp ( name, "history" ) ) { strncpy ( fullpath, MI_ROOT_PATH "/" MI_INFO_NAME, sizeof ( fullpath ) ); } else { strncpy ( fullpath, MI_ROOT_PATH "/" , sizeof ( fullpath ) ); } so, ident and minc_version is not accessible. But also if somebody will happen to create an attribute history of some other dataset this whole procedure will cause MINC2 api to try to read it from /minc-2.0/ instead of /minc-2.0/info/ -- Best regards, Vladimir S. FONOV ~ vladimir.fonov gmail.com From baghdadi at phenogenomics.ca Sat Dec 22 18:57:14 2012 From: baghdadi at phenogenomics.ca (Leila Baghdadi) Date: Sat, 22 Dec 2012 18:57:14 -0500 Subject: [MINC-development] MINC2 API for accessing metadata - broken ? Message-ID: <17243764.416461356220634774.JavaMail.root@mail2.phenogenomics.ca> Hello, I can not say anything about minc1 because I am not sure how things were meant to function. but The reason "history" specifically is added this way (/minc-2.0/history instead of /minc-2.0/info/history) is because, it would be unreadable by tools like mincheader even-though you could see it if you ran "h5ls" on the file. HTH Leila ----- Original Message ----- From: Vladimir S. FONOV Sent: Fri, 12/21/2012 5:57pm To: "discussion & planning, MINC" Subject: [MINC-development] MINC2 API for accessing metadata - broken ? Hello Everybody, I am trying to add metadata functionality to the new MINC2 ITK reader/writer ( http://review.source.kitware.com/#/c/9033/ ) Using MINC2 API functions ( milist_start , milist_grp_next , milist_attr_next ) First of all, there was a bug in grpattr.c ,function milist_grp_op , preventing function milist_grp_next actually returning group name. My question is following - what is the official way of getting values of what was a global attributes in MINC1 world (i.e :ident, :minc_version ). Since in MINC2 world the function miget_attr_values does following: if ( strcmp ( name, "history" ) ) { strncpy ( fullpath, MI_ROOT_PATH "/" MI_INFO_NAME, sizeof ( fullpath ) ); } else { strncpy ( fullpath, MI_ROOT_PATH "/" , sizeof ( fullpath ) ); } so, ident and minc_version is not accessible. But also if somebody will happen to create an attribute history of some other dataset this whole procedure will cause MINC2 api to try to read it from /minc-2.0/ instead of /minc-2.0/info/ -- Best regards, Vladimir S. FONOV ~ vladimir.fonov gmail.com _______________________________________________ MINC-development mailing list MINC-development at bic.mni.mcgill.ca http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development