From a.janke at gmail.com Thu Jan 6 00:37:54 2011 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 6 Jan 2011 15:37:54 +1000 Subject: [MINC-development] mincresample issue/bug at smaller voxel sizes using concatenated transforms In-Reply-To: <4D137D5D.5050803@phenogenomics.ca> References: <201012212023.oBLKNSa3032658@cassio.bic.mni.mcgill.ca> <4D137D5D.5050803@phenogenomics.ca> Message-ID: Perhaps it's time for YACLA for mincresample? I like this approach more than an environment variable as it will preserve operation when scripts are passed around. YACLA - Yet Another Command Line Argument -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 On 24 December 2010 02:48, Matthijs van Eede wrote: > Initially I thought the current solution in minc 2.1 would work for use, but > we quite frequently use transformation grids with resolutions that are a lot > coarser than the volumes we transform with them, so we would still run into > the same problem. Is it possible to have an environment variable that can > override the value that is set for ftol? From jason at phenogenomics.ca Thu Jan 6 08:14:02 2011 From: jason at phenogenomics.ca (Jason Lerch) Date: Thu, 6 Jan 2011 08:14:02 -0500 Subject: [MINC-development] mincresample issue/bug at smaller voxel sizes using concatenated transforms In-Reply-To: References: <201012212023.oBLKNSa3032658@cassio.bic.mni.mcgill.ca> Message-ID: <5EFFB918-F4ED-4CBD-BF7B-9DABB59F42A9@phenogenomics.ca> But that would require an API change, wouldn't it? Unless the command line switch to mincresample changes that environment variable ... Or am I missing something too obvious due to lack of coffee? Jason On 2011-01-06, at 12:37 AM, Andrew Janke wrote: > Perhaps it's time for YACLA for mincresample? > > I like this approach more than an environment variable as it will > preserve operation when scripts are passed around. > > > YACLA - Yet Another Command Line Argument > > -- > Andrew Janke > (a.janke at gmail.com || http://a.janke.googlepages.com/) > Canberra->Australia +61 (402) 700 883 > > > > > On 24 December 2010 02:48, Matthijs van Eede wrote: >> Initially I thought the current solution in minc 2.1 would work for use, but >> we quite frequently use transformation grids with resolutions that are a lot >> coarser than the volumes we transform with them, so we would still run into >> the same problem. Is it possible to have an environment variable that can >> override the value that is set for ftol? > _______________________________________________ > 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 Thu Jan 6 16:17:39 2011 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 7 Jan 2011 07:17:39 +1000 Subject: [MINC-development] mincresample issue/bug at smaller voxel sizes using concatenated transforms In-Reply-To: <5EFFB918-F4ED-4CBD-BF7B-9DABB59F42A9@phenogenomics.ca> References: <201012212023.oBLKNSa3032658@cassio.bic.mni.mcgill.ca> <4D137D5D.5050803@phenogenomics.ca> <5EFFB918-F4ED-4CBD-BF7B-9DABB59F42A9@phenogenomics.ca> Message-ID: Nope, you're not missing anything. It would require an API change (or adding a copy of the same function with _ftol(... or something added to the end). I am just very adverse to making the result of a MINC analysis dependent on an environment variable. It's just too hidden. What would be the plan for distributing scripts that work on mouse data? A line in a script that first sets/overrides an ENV variable? ack. a On 6 January 2011 23:14, Jason Lerch wrote: > But that would require an API change, wouldn't it? Unless the command line switch to mincresample changes that environment variable ... Or am I missing something too obvious due to lack of coffee? > > Jason > > On 2011-01-06, at 12:37 AM, Andrew Janke wrote: > >> Perhaps it's time for YACLA for mincresample? >> >> I like this approach more than an environment variable as it will >> preserve operation when scripts are passed around. >> >> >> YACLA - Yet Another Command Line Argument >> >> -- >> Andrew Janke >> (a.janke at gmail.com || http://a.janke.googlepages.com/) >> Canberra->Australia ? ?+61 (402) 700 883 >> >> >> >> >> On 24 December 2010 02:48, Matthijs van Eede wrote: >>> Initially I thought the current solution in minc 2.1 would work for use, but >>> we quite frequently use transformation grids with resolutions that are a lot >>> coarser than the volumes we transform with them, so we would still run into >>> the same problem. Is it possible to have an environment variable that can >>> override the value that is set for ftol? >> _______________________________________________ >> 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 > From zijdenbos at gmail.com Thu Jan 6 17:01:22 2011 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Thu, 6 Jan 2011 17:01:22 -0500 Subject: [MINC-development] mincresample issue/bug at smaller voxel sizes using concatenated transforms In-Reply-To: References: <201012212023.oBLKNSa3032658@cassio.bic.mni.mcgill.ca> <4D137D5D.5050803@phenogenomics.ca> <5EFFB918-F4ED-4CBD-BF7B-9DABB59F42A9@phenogenomics.ca> Message-ID: I agree... ugly. This doesn't seem like something that should be handled by an environment variable, and not even a command-line option (although the latter would allow for easier scripting around it). I'll happily admit that I am not familiar with the innards of mincresample; but conceptually I would say mincresample should "just work" regardless of voxel size - which I think leads back to the "ideal" solution that Claude pointed out - making ftol somehow dependent on voxel size. If that is not possible, would it work to set it it to a fixed but very small value that would work across the expected range of resolutions? As a side note, I have worked my way around issues like this by scaling the images up to a ~1mm voxel size, registering and resampling there, then scaling the voxel size back. -- A On Thu, Jan 6, 2011 at 4:17 PM, Andrew Janke wrote: > Nope, you're not missing anything. It would require an API change (or > adding a copy of the same function with _ftol(... or something added > to the end). I am just very adverse to making the result of a MINC > analysis dependent on an environment variable. > > It's just too hidden. ?What would be the plan for distributing scripts > that work on mouse data? ?A line in a script that first sets/overrides > an ENV variable? ?ack. > > > a > > On 6 January 2011 23:14, Jason Lerch wrote: >> But that would require an API change, wouldn't it? Unless the command line switch to mincresample changes that environment variable ... Or am I missing something too obvious due to lack of coffee? >> >> Jason >> >> On 2011-01-06, at 12:37 AM, Andrew Janke wrote: >> >>> Perhaps it's time for YACLA for mincresample? >>> >>> I like this approach more than an environment variable as it will >>> preserve operation when scripts are passed around. >>> >>> >>> YACLA - Yet Another Command Line Argument >>> >>> -- >>> Andrew Janke >>> (a.janke at gmail.com || http://a.janke.googlepages.com/) >>> Canberra->Australia ? ?+61 (402) 700 883 >>> >>> >>> >>> >>> On 24 December 2010 02:48, Matthijs van Eede wrote: >>>> Initially I thought the current solution in minc 2.1 would work for use, but >>>> we quite frequently use transformation grids with resolutions that are a lot >>>> coarser than the volumes we transform with them, so we would still run into >>>> the same problem. Is it possible to have an environment variable that can >>>> override the value that is set for ftol? >>> _______________________________________________ >>> 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 >> > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > > From rick.hoge at linev.ca Fri Jan 7 21:33:12 2011 From: rick.hoge at linev.ca (Rick Hoge) Date: Fri, 7 Jan 2011 21:33:12 -0500 Subject: [MINC-development] Unexpected value scaling with miget_real_value_hyperslab Message-ID: <115A818F-80C1-4B58-AEFE-5538B2A8C75E@linev.ca> I've been working on some code to load data from a MINC2 file into memory, and have encountered some puzzling behaviour. The files I've been testing have been generated with dcm2mnc (minc-2.0.18) from Siemens DICOM files. I'm running x86_64 binaries on OSX 10.6. I'm using dcm2mnc without any flags other than the required input and output paths. Here's the background: First I run dcm2mnc DICOM_Files/*.dcm ./ Next I run the program that reads the created MINC2 file - miget_data_type(minc_volume, &mincDataType) says that the data in my MINC2 file (created as described above) is MI_TYPE_USHORT. I set up the arrays 'starts' and 'counts', allocate an appropriately sized memory buffer, and call miget_real_value_hyperslab(minc_volume, MI_TYPE_USHORT, starts, counts, buffer) to copy the entire 4D dataset into my buffer. I get the series as expected, however the unsigned shorts in the buffer appear to have been scaled so that the minimum and maximum values correspond respectively to 0 and USHRT_MAX. I know the values in the file should be within the range 0 to 4095 since it comes from 12-bit DICOM - this is in fact the 'valid range' reported for the MINC2 file by mincinfo. The true range of data values in my example file is actually 0 to 1006. What is causing this scaling to happen? I notice also that miget_slice_scaling_flag(minc_volume, &slice_scaling_flag) returns 1, so it appears that some kind of scaling has been applied. I've tried using miget_real_value_hyperslab() but then the intensities of the different slices are individually remapped. Creating MINC1 files from the same DICOM files with the same dcm2mnc binary and reading the values with miicv_get () returns the correct numeric values for the voxel data (i.e. the numbers match what I see in the DICOM files). Finally I noticed that if I use miget_real_value_hyperslab(minc_volume, MI_TYPE_FLOAT, starts, counts, buffer) to fill a buffer with float values from the same file, I get close to the correct numeric voxel values. However the values all include a non-zero decimal fraction component, so that a voxel with a true value of 327 comes out as 326.74. At this point I'm not sure if this is a feature or a bug, but I'd be grateful for any suggestions on what is happening and how to recover the original values that were read from the DICOM file in a simple and robust way. Thanks in advance! Rick From rick.hoge at linev.ca Fri Jan 7 23:37:37 2011 From: rick.hoge at linev.ca (Rick Hoge) Date: Fri, 7 Jan 2011 23:37:37 -0500 Subject: [MINC-development] Unexpected value scaling with miget_real_value_hyperslab In-Reply-To: <115A818F-80C1-4B58-AEFE-5538B2A8C75E@linev.ca> References: <115A818F-80C1-4B58-AEFE-5538B2A8C75E@linev.ca> Message-ID: <6C42933B-2E9F-4DC0-ACD0-6F1FC591AAA3@linev.ca> On 2011-01-07, at 9:33 PM, Rick Hoge wrote: > I get the series as expected, however the unsigned shorts in the buffer appear to have been scaled so that the minimum and maximum values correspond respectively to 0 and USHRT_MAX. I know the values in the file should be within the range 0 to 4095 since it comes from 12-bit DICOM - this is in fact the 'valid range' reported for the MINC2 file by mincinfo. The true range of data values in my example file is actually 0 to 1006. I've been exploring the ICV functions some more, but honestly I couldn't find *any* way to recover the original maximum data value (1006 in my example) from the MINC2 file I generated using dcm2mnc in the reference at http://en.wikibooks.org/wiki/MINC/Reference/MINC2.0_Application_Programmers_Interface Finally I found the function miget_volume_real_range(), which does return the actual min and max values. However this is not really documented anywhere... Playing around with ICV's the only other thing I've been able to do is to get the data values mapped into the 12-bit range 0 to 4095, which is still not the actual data range. I realize that in some cases there can be an advantage to using the whole dynamic range of a given data type, but surely there is a way to preserve the original values? Thanks again, Rick From a.janke at gmail.com Sun Jan 9 06:23:21 2011 From: a.janke at gmail.com (Andrew Janke) Date: Sun, 9 Jan 2011 21:23:21 +1000 Subject: [MINC-development] Unexpected value scaling with miget_real_value_hyperslab In-Reply-To: <6C42933B-2E9F-4DC0-ACD0-6F1FC591AAA3@linev.ca> References: <115A818F-80C1-4B58-AEFE-5538B2A8C75E@linev.ca> <6C42933B-2E9F-4DC0-ACD0-6F1FC591AAA3@linev.ca> Message-ID: Hi Rick, >> I get the series as expected, however the unsigned shorts in the buffer appear to have been scaled so that the minimum and maximum values correspond respectively to 0 and USHRT_MAX. ?I know the values in the file should be within the range 0 to 4095 since it comes from 12-bit DICOM - this is in fact the 'valid range' reported for the MINC2 file by mincinfo. ?The true range of data values in my example file is actually 0 to 1006. > > I've been exploring the ICV functions some more, but honestly I couldn't find *any* way to recover the original maximum data value (1006 in my example) from the MINC2 file I generated using dcm2mnc in the reference at > > http://en.wikibooks.org/wiki/MINC/Reference/MINC2.0_Application_Programmers_Interface > > Finally I found the function miget_volume_real_range(), which does return the actual min and max values. ?However this is not really documented anywhere... Ah good to see you found one of the functions you (might) need. I think you are still being bitten by slice scaling though. In order to make sure that this is or isn't the case perhaps run the output file through something like mincreshape -signed -short (and then back again) to check this? Jason gives a nice example of how to deal with slice scaling here: http://en.wikibooks.org/wiki/MINC/Tutorials/Programming04 > Playing around with ICV's the only other thing I've been able to do is to get the data values mapped into the 12-bit range 0 to 4095, which is still not the actual data range. Again, I'll punt this is slice scaling biting you here. > I realize that in some cases there can be an advantage to using the whole dynamic range of a given data type, but surely there is a way to preserve the original values? In MINC1 there was never any magic to do this, you'd just do something like this (in the output file) to take a crack at it: /* set the range to something sensible (if possible) */ if(dtype == NC_BYTE && is_signed == FALSE){ if(min >= 0 && max < 255){ fprintf(stdout, "BYTE data, setting 1:1 mapping (0-256)\n"); min = 0; max = 255; } } set_volume_real_range(*volume, min, max); The above is nicked from mincmorph and is an attempt to make 0-255 in the real range line up with 0-255 in the voxel range. If you _really_ want to preserve values in a MINC file your best bet is to use something like a float. Yes, it takes more space but then that's somewhat cheap now. MINC2 really needed a "integer" type or flag of some description to define a label volume but introducing it would have meant a world of pain adding special code to deal with this in all the other tools. In some cases the behavior would have been fairly arbitrary in any case. Hope that helps. -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From rick.hoge at linev.ca Sun Jan 9 23:45:51 2011 From: rick.hoge at linev.ca (Rick Hoge) Date: Sun, 9 Jan 2011 23:45:51 -0500 Subject: [MINC-development] Unexpected value scaling with miget_real_value_hyperslab In-Reply-To: References: <115A818F-80C1-4B58-AEFE-5538B2A8C75E@linev.ca> <6C42933B-2E9F-4DC0-ACD0-6F1FC591AAA3@linev.ca> Message-ID: Thanks for the suggestion Andrew, [...] >>> Finally I found the function miget_volume_real_range(), which does return the actual min and max values. However this is not really documented anywhere... > > Ah good to see you found one of the functions you (might) need. I > think you are still being bitten by slice scaling though. In order to > make sure that this is or isn't the case perhaps run the output file > through something like mincreshape -signed -short (and then back > again) to check this? I tried a few permutations of mincreshape, including the above, but no matter what I tried the data values were mapped to span the whole valid range when loaded into an integer type. > Jason gives a nice example of how to deal with slice scaling here: > > http://en.wikibooks.org/wiki/MINC/Tutorials/Programming04 I'd looked at this (and these tutorials are indeed very helpful), but the example was a bit different in that it shows a set of nested loops with miget_real_value at the core and setting the range values for each slice. I just want to read the entire dataset into a single buffer, which I'd expect should be possible in one function call. > >> Playing around with ICV's the only other thing I've been able to do is to get the data values mapped into the 12-bit range 0 to 4095, which is still not the actual data range. > > Again, I'll punt this is slice scaling biting you here. As I'd mentioned, slice scaling is indeed turned on for the data in question, which were generated using dcm2mnc. I'm not sure why this scaling would be applied to 12-bit numbers stored in short integer words in the DICOM file, as it does not add anything to the real dynamic range and could alter the original values. > >> I realize that in some cases there can be an advantage to using the whole dynamic range of a given data type, but surely there is a way to preserve the original values? > > In MINC1 there was never any magic to do this, you'd just do something > like this (in the output file) to take a crack at it: > Like you say, it was fairly simple using the MINC1 API. [...] > If you _really_ want to preserve values in a MINC file your best bet > is to use something like a float. Yes, it takes more space but then > that's somewhat cheap now. I'm not so concerned about the disk space (although saving it is nice); it's more a question of data integrity. For MR quality assurance it's useful in a number of situations to be able to know the binary exact value that was stored on the scanner. Also if the data were assigned integer values in some kind of labelling or lookup table scheme, a programmer would reasonably expect to be able to test for exact integer equality - this breaks down if the data are converted to float. The really weird thing is that if I do load the data as float, the numbers appear to deviate from the original integer values by a decimal fraction that is quite significant. For example if I use miget_real_value_hyperslab(minc_volume, MI_TYPE_FLOAT, starts, counts, buffer) to fill a buffer with float values from a file purported to contain unsigned short values, I get close to the correct numeric voxel values. However the values all include a non-zero decimal fraction component, so that a voxel with a true value of 327 comes out as 326.74. Maybe MINC2 has a new dithering feature? :) Before creating a panic I should triple check this, and post a small code fragment that demonstrates the phenomenon. > MINC2 really needed a "integer" type or flag of some description to > define a label volume but introducing it would have meant a world of > pain adding special code to deal with this in all the other tools. In > some cases the behavior would have been fairly arbitrary in any case. I can certainly see the appeal of just deciding to always use float or doubles internally, but in some contexts it's nice to preserve the original data values. However it's true that - in the case of fMRI - as soon as you motion-correct, smooth, etc. it becomes kind of silly to retain the data as integer. Also virtually everything ever done in Matlab is treating everything as a double float. A kind of kludgy workaround I came up with was to load the data as float, then round the voxel values, which appears to recover the original short ints. > Hope that helps. It does - thanks! Rick > > > -- > Andrew Janke > (a.janke at gmail.com || http://a.janke.googlepages.com/) > Canberra->Australia +61 (402) 700 883 > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.janke at gmail.com Sun Jan 9 23:51:53 2011 From: a.janke at gmail.com (Andrew Janke) Date: Mon, 10 Jan 2011 14:51:53 +1000 Subject: [MINC-development] Unexpected value scaling with miget_real_value_hyperslab In-Reply-To: References: <115A818F-80C1-4B58-AEFE-5538B2A8C75E@linev.ca> <6C42933B-2E9F-4DC0-ACD0-6F1FC591AAA3@linev.ca>

Message-ID: > Jason gives a nice example of how to deal with slice scaling here: > > ??http://en.wikibooks.org/wiki/MINC/Tutorials/Programming04 > > I'd looked at this (and these tutorials are indeed very helpful), but the > example was a bit different in that it shows a set of nested loops with > miget_real_value at the core and setting the range values for each slice. ?I > just want to read the entire dataset into a single buffer, which I'd expect > should be possible in one function call. You might be interested in this then: (presuming your MINC install is in the "standard place"). /usr/local/bic/lib/minc_simple.h a From rick.hoge at linev.ca Sun Jan 9 23:56:13 2011 From: rick.hoge at linev.ca (Rick Hoge) Date: Sun, 9 Jan 2011 23:56:13 -0500 Subject: [MINC-development] HDF5 Error trying to read acquisition attributes from a MINC file Message-ID: <0F1BB64C-7163-4886-A535-51796339B3CE@linev.ca> Hi, I've trying to load the acquisition information from a MINC2 file into memory, and while I've been able to get the correct values, I am getting strange HDF5 messages to stderr. For example the following code fragment /////////////////////////// int attr_length; int attr_type; char string_value[1024]; miget_attr_type(minc_volume, "acquisition","protocol", &attr_type); miget_attr_length(minc_volume, "acquisition", "protocol", &attr_length); miget_attr_values(minc_volume, attr_type, "acquisition", "protocol", attr_length, string_value); /////////////////////////// Is able to get the type, length, and value of the protocol attribute. However the first two miget_ calls generate the following messages to stderr: --------------------------- HDF5-DIAG: Error detected in HDF5 library version: 1.6.5 thread 0. Back trace follows. #000: H5G.c line 346 in H5Gclose(): not a group major(01): Function arguments minor(03): Inappropriate type HDF5-DIAG: Error detected in HDF5 library version: 1.6.5 thread 0. Back trace follows. #000: H5G.c line 346 in H5Gclose(): not a group major(01): Function arguments minor(03): Inappropriate type --------------------------- They appear to be harmless (no crash and I get the right values), but obviously it would be nice to know why they occur and how to get rid of them. This is from a build of minc-2.0.18 against hdf5-1.6.5 on a 64-bit Intel system running OSX 10.6.5 Would be grateful for any insight and suggestions on how to cure! Rick From rick.hoge at linev.ca Mon Jan 10 14:47:47 2011 From: rick.hoge at linev.ca (Rick Hoge) Date: Mon, 10 Jan 2011 14:47:47 -0500 Subject: [MINC-development] HDF5 Error trying to read acquisition attributes from a MINC file In-Reply-To: <0F1BB64C-7163-4886-A535-51796339B3CE@linev.ca> References: <0F1BB64C-7163-4886-A535-51796339B3CE@linev.ca> Message-ID: I found that the following function call will suppress the generation of these warnings: H5Eset_auto(NULL, NULL); of course that is only curing the symptom, and the cause... It's documented at http://www.hdfgroup.org/HDF5/doc1.6/RM_H5E.html#Error-SetAuto Rick On 2011-01-09, at 11:56 PM, Rick Hoge wrote: > > Hi, > > I've trying to load the acquisition information from a MINC2 file into memory, and while I've been able to get the correct values, I am getting strange HDF5 messages to stderr. > > For example the following code fragment > > /////////////////////////// > int attr_length; > int attr_type; > char string_value[1024]; > miget_attr_type(minc_volume, "acquisition","protocol", &attr_type); > miget_attr_length(minc_volume, "acquisition", "protocol", &attr_length); > miget_attr_values(minc_volume, attr_type, "acquisition", "protocol", attr_length, string_value); > /////////////////////////// > > Is able to get the type, length, and value of the protocol attribute. However the first two miget_ calls generate the following messages to stderr: > > --------------------------- > HDF5-DIAG: Error detected in HDF5 library version: 1.6.5 thread 0. Back trace follows. > #000: H5G.c line 346 in H5Gclose(): not a group > major(01): Function arguments > minor(03): Inappropriate type > HDF5-DIAG: Error detected in HDF5 library version: 1.6.5 thread 0. Back trace follows. > #000: H5G.c line 346 in H5Gclose(): not a group > major(01): Function arguments > minor(03): Inappropriate type > --------------------------- > > They appear to be harmless (no crash and I get the right values), but obviously it would be nice to know why they occur and how to get rid of them. This is from a build of minc-2.0.18 against hdf5-1.6.5 on a 64-bit Intel system running OSX 10.6.5 > > Would be grateful for any insight and suggestions on how to cure! > > Rick > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development From rick.hoge at linev.ca Tue Jan 11 23:43:55 2011 From: rick.hoge at linev.ca (Rick Hoge) Date: Tue, 11 Jan 2011 23:43:55 -0500 Subject: [MINC-development] Opening MINC2 HDF5 file from /dev/fd/ file descriptor Message-ID: Hi - I have some code that gunzips a compressed MINC file, sending the uncompressed result to stdout. I connect stdout of the gunzip process to a pipe which is mapped to the device /dev/df/n where 'n' is the POSIX file descriptor. This has worked in the past for other file formats, where I could access the data like this: FILE *fptr = fopen("/dev/fd/12","r"); // Assuming the file descriptor is 12 // Load data from file fclose(fptr); For some reason, miopen_volume() does not like these file descriptor handles. Is there any simple to way to read a MINC2 file from stdin or a stream? For this application I can just create a temp file and clean it up after reading, but I'm still wondering if it's possible to do this type of thing using /dev/fd/. I'd heard that HDF5 supports reading from streams. Thanks for any info, Rick From a.janke at gmail.com Thu Jan 13 11:20:31 2011 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 14 Jan 2011 02:20:31 +1000 Subject: [MINC-development] Opening MINC2 HDF5 file from /dev/fd/ file descriptor In-Reply-To: References: Message-ID: Hi Rick, > I have some code that gunzips a compressed MINC file, sending the uncompressed result to stdout. ?I connect stdout of the gunzip process to a pipe which is mapped to the device /dev/df/n where 'n' is the POSIX file descriptor. > > This has worked in the past for other file formats, where I could access the data like this: > > FILE *fptr = fopen("/dev/fd/12","r"); // Assuming the file descriptor is 12 > // Load data from file > fclose(fptr); My understanding is that this is always going to be a problem with a MINC NetCDF file and likely HDF too. NetCDF has a "define" (set file dimensions, type, etc) and a "data" mode (other headers, the data itself). These two modes sort of preclude you merrily redirecting MINC files around with pipes. a From matthijs at phenogenomics.ca Thu Jan 13 13:14:48 2011 From: matthijs at phenogenomics.ca (Matthijs van Eede) Date: Thu, 13 Jan 2011 13:14:48 -0500 Subject: [MINC-development] Missing headers in ebtks-1.6.4? Message-ID: <4D2F4118.9050303@phenogenomics.ca> Greetings, I've installed ebtks-1.6.4 on a Ubuntu Lucid machine using gcc-4.1/g++-4.1, and wanted to install N3-1.12.0 after that, but two headers in the ebtks package are missing: EBTKS/Spline.h EBTKS/TBSpline.h Are these versions of ebtks and N3 compatible? Those headers are included in ebtks-1.6.3. Thanks, Matthijs From claude at bic.mni.mcgill.ca Thu Jan 13 14:08:42 2011 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Thu, 13 Jan 2011 14:08:42 -0500 Subject: [MINC-development] Missing headers in ebtks-1.6.4? In-Reply-To: <4D2F4118.9050303@phenogenomics.ca> Message-ID: <201101131908.p0DJ8gjk002410@cassio.bic.mni.mcgill.ca> Hi, > I've installed ebtks-1.6.4 on a Ubuntu Lucid machine using > gcc-4.1/g++-4.1, and wanted to install N3-1.12.0 after that, but two > headers in the ebtks package are missing: > > EBTKS/Spline.h > EBTKS/TBSpline.h > > Are these versions of ebtks and N3 compatible? Those headers are > included in ebtks-1.6.3. N3-1.12.0 goes with ebtks-1.6.4. The headers are in: N3-1.12.0/src/Splines/ In brief, the splines that were in EBTKS have been moved to N3 since they are only used by N3. Claude From matthijs at phenogenomics.ca Thu Jan 13 14:48:17 2011 From: matthijs at phenogenomics.ca (Matthijs van Eede) Date: Thu, 13 Jan 2011 14:48:17 -0500 Subject: [MINC-development] Missing headers in ebtks-1.6.4? In-Reply-To: <201101131908.p0DJ8gjk002410@cassio.bic.mni.mcgill.ca> References: <201101131908.p0DJ8gjk002410@cassio.bic.mni.mcgill.ca> Message-ID: <4D2F5701.5060800@phenogenomics.ca> Thanks Claude, At the moment in the N3-1.12.0 package the file: src/SplineSmooth/fieldIO.cc contains the lines (34-36): #include // (bert) - Added EBTKS subdirectory #include // (bert) #include // (bert) which is why the make failed. The EBTKS in lines 34 and 36 can be safely changed into src/Splines? Matthijs Claude LEPAGE wrote: > Hi, > > >> I've installed ebtks-1.6.4 on a Ubuntu Lucid machine using >> gcc-4.1/g++-4.1, and wanted to install N3-1.12.0 after that, but two >> headers in the ebtks package are missing: >> >> EBTKS/Spline.h >> EBTKS/TBSpline.h >> >> Are these versions of ebtks and N3 compatible? Those headers are >> included in ebtks-1.6.3. >> > > N3-1.12.0 goes with ebtks-1.6.4. The headers are in: > N3-1.12.0/src/Splines/ > > In brief, the splines that were in EBTKS have been moved to N3 since > they are only used by N3. > > Claude > > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > From rick.hoge at linev.ca Thu Jan 20 08:55:51 2011 From: rick.hoge at linev.ca (Rick Hoge) Date: Thu, 20 Jan 2011 08:55:51 -0500 Subject: [MINC-development] Opening MINC2 HDF5 file from /dev/fd/ file descriptor In-Reply-To: References:

Message-ID: <6EED9119-651E-4AC5-AA00-E9CD64FEB097@linev.ca> Thanks Andrew, This confirms my suspicions. Ended up using another approach for MINC files. Rick >> [...] > > My understanding is that this is always going to be a problem with a > MINC NetCDF file and likely HDF too. NetCDF has a "define" (set file > dimensions, type, etc) and a "data" mode (other headers, the data > itself). These two modes sort of preclude you merrily redirecting MINC > files around with pipes. > > > a > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development