From minc-users@bic.mni.mcgill.ca Fri May 9 15:59:14 2003 From: minc-users@bic.mni.mcgill.ca (James Dessart) Date: Fri, 9 May 2003 10:59:14 -0400 Subject: [MINC-users] differences between 0.3 and 1.0 Message-ID: Hi all, I'm working on a product that was previously using minc lib 0.3, and I'm trying to bring it up to speed with minc 1.0. With the same calls (normalization turned, short dataset, converted to unsigned bytes), 1.0 seems to be returning slices with varying intensities, whereas 0.3 returned a relatively consistent intensity level through the slices. What might be the reason for this discrepancy? Thanks, James From minc-users@bic.mni.mcgill.ca Thu May 15 22:25:38 2003 From: minc-users@bic.mni.mcgill.ca (minc-users@bic.mni.mcgill.ca) Date: Thu, 15 May 2003 17:25:38 -0400 (EDT) Subject: [MINC-users] where is volume_stats Message-ID: Hi, I am setting up some MACs in the MRS lab and I need to find a the source for a command called 'volume_stats'. Anyone know which tarball I may find that in? thanks robin -- 5:24pm up 3 days, 1:52, 8 users, load average: 0.00, 0.00, 0.00 From minc-users@bic.mni.mcgill.ca Thu May 15 21:54:58 2003 From: minc-users@bic.mni.mcgill.ca (James Dessart) Date: Thu, 15 May 2003 16:54:58 -0400 Subject: [MINC-users] 0.3 vs 1.0 scaling - clarifications Message-ID: <7CFF54AC-8717-11D7-A9FE-003065B4553E@rogue-research.com> It seems that what's happening when loading in my data set with 1.0 is that values are scaled to the image-max for the whole data set. So given a data set with 256 as the global max, when a slice is read in with an image-max of 180, the values are scaled up to reach 256, resulting in inconsistent intensity over slices. This is not the behaviour I want, since 0.3 is what we've been using, and it doesn't do that. What ICV variable needs to be changed to keep 1.0 from doing this? James From minc-users@bic.mni.mcgill.ca Thu May 15 22:59:14 2003 From: minc-users@bic.mni.mcgill.ca (Andrew Janke) Date: Fri, 16 May 2003 07:59:14 +1000 Subject: [MINC-users] where is volume_stats In-Reply-To: References: Message-ID: On Thu, 15 May 2003 rwong@mrs.mni.mcgill.ca wrote: > I am setting up some MACs in the MRS lab and I need to find a the source > for a command called 'volume_stats'. Anyone know which tarball I may find > that in? volume_stats is part of N3 (John Sleds MR inhomogeneity correction package). however since then mincstats has been added to the base minc distibution as a drop-in replacement. In all theory, you should be able to just replace any calls to volume_stats with mincstats with identical arguments. -- Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance Work: +61 7 3365 4100 || Home: +61 7 3800 4042 From minc-users@bic.mni.mcgill.ca Fri May 16 02:35:03 2003 From: minc-users@bic.mni.mcgill.ca (Peter NEELIN) Date: Thu, 15 May 2003 21:35:03 -0400 Subject: [MINC-users] 0.3 vs 1.0 scaling - clarifications In-Reply-To: <7CFF54AC-8717-11D7-A9FE-003065B4553E@rogue-research.com> Message-ID: On Thu, 15 May 2003, James Dessart wrote: > It seems that what's happening when loading in my data set with 1.0 is > that values are scaled to the image-max for the whole data set. So > given a data set with 256 as the global max, when a slice is read in > with an image-max of 180, the values are scaled up to reach 256, > resulting in inconsistent intensity over slices. > > This is not the behaviour I want, since 0.3 is what we've been using, > and it doesn't do that. What ICV variable needs to be changed to keep > 1.0 from doing this? MI_ICV_DO_NORM should be set to FALSE, which is the default. I don't think that this has changed since the beginning of minc. Are you certain that this is not being set to TRUE somewhere in your code? Can you create a small test program to illustrate the behaviour? As far as I can recall, no incompatibilities of this type were introduced into the library - I am normally quite sensitive to backward compatibility issues, so a change like this would surprise me. Although 0.3 was a long time back - perhaps you were relying on a bug... [...sounds of shuffling through old code and logs...] Ah, here is something from the CVS (RCS) log that might be helpful: date: 2001/11/13 21:00:24; author: neelin; state: Exp; lines: +43 -22 Modified icv scaling calculations for no normalization. When the icv type is double, normalization is always done, regardless of the normalization setting. When the external type is floating point, normalization to the slice real range is done (essentially a valid range scaling, but where the valid range for a float is the slice real range). So if your internal type is a floating-point type (I think that double probably means either double or float), then normalization will always be done. This was a rationalization of the library behaviour: floating-point values should always have the real value, rather than a voxel value. I apologize if this breaks your code - I had thought that very few people were using this. Is your icv type NC_FLOAT or NC_DOUBLE? If so, then you cannot get the file voxel values. If it is of an integer type (NC_BYTE, NC_SHORT), then the old behaviour should still apply. Peter ---- Peter Neelin (neelin@bic.mni.mcgill.ca) From minc-users@bic.mni.mcgill.ca Fri May 16 02:43:49 2003 From: minc-users@bic.mni.mcgill.ca (Peter NEELIN) Date: Thu, 15 May 2003 21:43:49 -0400 Subject: [MINC-users] where is volume_stats In-Reply-To: Message-ID: On Fri, 16 May 2003, Andrew Janke wrote: > On Thu, 15 May 2003 rwong@mrs.mni.mcgill.ca wrote: > > > I am setting up some MACs in the MRS lab and I need to find a the source > > for a command called 'volume_stats'. Anyone know which tarball I may find > > that in? > > volume_stats is part of N3 (John Sleds MR inhomogeneity correction package). > however since then mincstats has been added to the base minc distibution as a > drop-in replacement. You can get N3 source from ftp://ftp.bic.mni.mcgill.ca/pub/mni_n3/ and volume_stats can be found in there. BTW, has anyone tested using mincstats as a drop-in replacement - can one just symlink volume_stats to mincstats and scripts work properly (producing the same output)? Peter ---- Peter Neelin (neelin@bic.mni.mcgill.ca) From minc-users@bic.mni.mcgill.ca Fri May 16 02:58:24 2003 From: minc-users@bic.mni.mcgill.ca (Andrew Janke) Date: Fri, 16 May 2003 11:58:24 +1000 Subject: [MINC-users] where is volume_stats In-Reply-To: References: Message-ID: On Thu, 15 May 2003, Peter NEELIN wrote: > BTW, has anyone tested using mincstats as a drop-in replacement - can > one just symlink volume_stats to mincstats and scripts work properly > (producing the same output)? I have run every minc file I can get my hands on through both of them and the results are "similar". Well this is with respect to the stats it outputs. The biggest difference is with the BiModalT as it relies upon the histogram and when you consider that mincstats and volume_stats do binning differently it begins to make sense. mincstats -floor 0.001 ..... seems to give more similar stats (to avoid the 0 bin problem), but not always. On most "normal" data, the differences are miniscule. To the point that mni_autoreg shouldn't break when using it to generate masks. PS: I can supply a ~9000 line file to support the above! ;) -- Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance Work: +61 7 3365 4100 || Home: +61 7 3800 4042 From minc-users@bic.mni.mcgill.ca Fri May 16 13:42:02 2003 From: minc-users@bic.mni.mcgill.ca (James Dessart) Date: Fri, 16 May 2003 08:42:02 -0400 Subject: [MINC-users] 0.3 vs 1.0 scaling - clarifications In-Reply-To: Message-ID: On Thursday, May 15, 2003, at 09:35 PM, Peter NEELIN wrote: > I apologize if this breaks your code - I had thought that very few > people > were using this. Is your icv type NC_FLOAT or NC_DOUBLE? If so, then > you > cannot get the file voxel values. If it is of an integer type (NC_BYTE, > NC_SHORT), then the old behaviour should still apply. Actually, the file is NC_SHORT data, well, all the files I've noticed it in are NC_SHORT, and I've noticed it in all of them, some more than others. I guess they were pre-normalized or something. I even tried setting it explicitly to false, and that didn't change things. It's still getting normalized. I'll try to get some sample code together, to demonstrate. James Dessart Rogue Research Inc. From minc-users@bic.mni.mcgill.ca Fri May 16 14:00:06 2003 From: minc-users@bic.mni.mcgill.ca (Steve ROBBINS) Date: Fri, 16 May 2003 09:00:06 -0400 Subject: [MINC-users] 0.3 vs 1.0 scaling - clarifications In-Reply-To: ; from james@rogue-research.com on Fri, May 16, 2003 at 08:42:02AM -0400 References: Message-ID: <20030516090006.E2771222@shadow.bic.mni.mcgill.ca> On Fri, May 16, 2003 at 08:42:02AM -0400, James Dessart wrote: > > On Thursday, May 15, 2003, at 09:35 PM, Peter NEELIN wrote: > > > I apologize if this breaks your code - I had thought that very few > > people > > were using this. Is your icv type NC_FLOAT or NC_DOUBLE? If so, then > > you > > cannot get the file voxel values. If it is of an integer type (NC_BYTE, > > NC_SHORT), then the old behaviour should still apply. > > Actually, the file is NC_SHORT data, I believe Peter was referring to the data type IN MEMORY, which may be different than the type on disk. -S From minc-users@bic.mni.mcgill.ca Fri May 16 14:11:35 2003 From: minc-users@bic.mni.mcgill.ca (James Dessart) Date: Fri, 16 May 2003 09:11:35 -0400 Subject: [MINC-users] 0.3 vs 1.0 scaling - clarifications In-Reply-To: <20030516090006.E2771222@shadow.bic.mni.mcgill.ca> Message-ID: On Friday, May 16, 2003, at 09:00 AM, Steve ROBBINS wrote: >>> If it is of an integer type (NC_BYTE, >>> NC_SHORT), then the old behaviour should still apply. >> >> Actually, the file is NC_SHORT data, > > I believe Peter was referring to the data type IN MEMORY, which may > be different than the type on disk. Ah, well it's being read in as NC_BYTE, so I still don't know why it's normalizing when I've even explicitly told it not to... Thanks, James Dessart Rogue Research Inc. From minc-users@bic.mni.mcgill.ca Fri May 16 16:59:50 2003 From: minc-users@bic.mni.mcgill.ca (James Dessart) Date: Fri, 16 May 2003 11:59:50 -0400 Subject: [MINC-users] Scaling troubles solved Message-ID: <6CB46709-87B7-11D7-9ED2-003065B4553E@rogue-research.com> I decided to fiddle a little with the variables, and the like... I moved some dim conversion assignments until after other ICV assignments, put MI_ICV_VALID_MAX before MI_ICV_VALID_MIN, and turned normalization on, and the streaks are gone. If I turn it off, the streaks come back. What seems to be happening is that when I have normalization off, the values are stretched to fit the byte range (the values are supposed to be shorts from 0 to 4095, but they go from 0 to 256). As a result, some slices were getting their intensities scaled. But when I do normalization (without setting the user normalization) it works. I'd like to understand this more completely, but the documentation doesn't help too too much. Anyone with some insight? Thanks for your help, James Dessart Rogue Research Inc. From minc-users@bic.mni.mcgill.ca Wed May 21 01:41:16 2003 From: minc-users@bic.mni.mcgill.ca (Peter NEELIN) Date: Tue, 20 May 2003 20:41:16 -0400 Subject: [MINC-users] Scaling troubles solved In-Reply-To: <6CB46709-87B7-11D7-9ED2-003065B4553E@rogue-research.com> Message-ID: On Fri, 16 May 2003, James Dessart wrote: > I decided to fiddle a little with the variables, and the like... I > moved some dim conversion assignments until after other ICV > assignments, put MI_ICV_VALID_MAX before MI_ICV_VALID_MIN, and turned > normalization on, and the streaks are gone. If I turn it off, the > streaks come back. I don't think that the order should matter, but turning normalization on is important to have all of the slices normalized the same way. Many minc files have slices scaled differently (this allows programs to use less memory), so turning normalization on will ensure that all slices are scaled in the same way and you will not see streaking. I re-read your original e-mail, and I noticed that you said "normalization turned" - I had assumed "on", but I'm guessing that you meant "off". If minc 0.3 produced a non-streaked result on exactly the same minc file, then I have to admit to being mystified. If it produced a non-streaked result on a different file, then that would be because the other file did not have separate slice scalings. That's up to the program that produces the output file. That is why the normalization option exists - so that you can turn it on and not worry about have to rescale things yourself. > What seems to be happening is that when I have normalization off, the > values are stretched to fit the byte range (the values are supposed to > be shorts from 0 to 4095, but they go from 0 to 256). Because the program indicates that it wants bytes internally, it rescales the values from [0,4095] to [0,255]. But it does not stretch them to fit the [0,255] - the stretching was already done in the file (stretched to the range [0,4095]). Turning normalization on will "unstretch" the range, while keeping things in the range [0,255]. > As a result, > some slices were getting their intensities scaled. As I mentioned, they had already been scaled by the program that produced the files. > But when I do > normalization (without setting the user normalization) it works. That's why it is there. Peter ---- Peter Neelin (neelin@bic.mni.mcgill.ca) From minc-users@bic.mni.mcgill.ca Wed May 21 14:12:32 2003 From: minc-users@bic.mni.mcgill.ca (James Dessart) Date: Wed, 21 May 2003 09:12:32 -0400 Subject: [MINC-users] Scaling troubles solved In-Reply-To: Message-ID: On Tuesday, May 20, 2003, at 08:41 PM, Peter NEELIN wrote: > If minc 0.3 produced a non-streaked result on exactly the same minc > file, > then I have to admit to being mystified. If it produced a non-streaked > result on a different file, then that would be because the other file > did > not have separate slice scalings. That's up to the program that > produces > the output file. That is why the normalization option exists - so that > you > can turn it on and not worry about have to rescale things yourself. Actually, I realized that the problem was probably related to the fact that the library and application were linked by different linkers. Which shouldn't really cause a problem, but when I changed to the same linker for both, it worked. Although I didn't realize that at first. James From minc-users@bic.mni.mcgill.ca Thu May 22 19:25:03 2003 From: minc-users@bic.mni.mcgill.ca (Andrew Poliakov) Date: Thu, 22 May 2003 11:25:03 -0700 Subject: [MINC-users] Java and MINC References: Message-ID: <3ECD15FF.6020608@u.washington.edu> I was wondering how difficult would it be importing minc files into a java program. Did anyone attempted developing minc bindings in java? I noticed there is a NETCDF package for java. I am not sure how much help that would be. I would greatly appreciate any information and ideas. -- Andrew V. Poliakov, Ph.D. Structural Informatics Group, Department of Biological Structure, University of Washington, Box 357420, Seattle, WA 98195 From minc-users@bic.mni.mcgill.ca Thu May 29 05:19:01 2003 From: minc-users@bic.mni.mcgill.ca (christophe grova) Date: Wed, 28 May 2003 22:19:01 -0600 Subject: [MINC-users] MINC -> Analyze conversion problem Message-ID: <005901c32599$6ecf28c0$6402a8c0@cgrova> Hello everybody, My name is Christophe Grova and I am a new post doc arrived at the MNI in Jean Gotman's team (EEG department). I try tu use 'mnc2ana' to convert a MINC file in an analyze file. I obtained really strange results in my analyze header ! Especially, my dimensions are completely false ! For info, here is a dump of my analyze header followed by a dump of the header of the MINC file (using mincheader : this header seems ok ) Using the Display software I have no problem to look at this MINC file on my PC under linux ... ! Do you have any idea? Thanks a lot in advance , Best regards, Christophe *************************** Christophe Grova, PhD PostDoc - EEG department Montreal Neurological Institute, McGill University 3801 University Street, Montreal, Quebec, Canada, H3A 2B4 email : christophe.grova@mail.mcgill.ca tel : (514) 398 2184 fax : (514) 398 8106 *************************** ANALYZE HEADER: ------------------------------- Analyze Header Dump of: sizeof_hdr: <348> data_type: <0> db_name: <> extents: <16384> session_error: <0> regular: hkey_un0: <0> dim[0]: <4> dim[1]: <-21822> dim[2]: <0> dim[3]: <1> dim[4]: <1> dim[5]: <0> dim[6]: <0> dim[7]: <0> vox_units: <> cal_units: <> unused1: <0> datatype: <1024> bitpix: <4096> pixdim[0]: <-32.0000> pixdim[1]: <0.0000> pixdim[2]: <0.0000> pixdim[3]: <1.0059> pixdim[4]: <-0.0000> pixdim[5]: <0.0000> pixdim[6]: <0.0000> pixdim[7]: <0.0000> vox_offset: <%6.4> funused1: <0.0000> funused2: <-32.0000> funused3: <0.0000> cal_max: <0.0000> cal_min: <0.0000> compressed: <0> verified: <0> glmax: <0> glmin: <-1077739520> descrip: <ΓΏ> aux_file: <> orient: <0> originator: <> generated: <> scannum: <> patient_id: <> exp_date: <> exp_time: <> hist_un0: <> views: <0> vols_added: <0> start_field:<0> field_skip: <0> omax: <0> omin: <0> smax: <0> smin: <0> Header of the corresponding MINC file using mincheader : netcdf mincheader-12520-tmp { dimensions: xspace = 170 ; zspace = 256 ; yspace = 256 ; variables: double xspace(xspace) ; xspace:varid = "MINC standard variable" ; xspace:vartype = "dimension____" ; xspace:version = "MINC Version 1.0" ; xspace:comments = "X increases from patient left to right" ; xspace:spacing = "regular__" ; xspace:alignment = "centre" ; xspace:step = -0.999999999999999 ; xspace:start = 62.6907997131348 ; xspace:spacetype = "native____" ; xspace:direction_cosines = 1., -0., 0. ; int zspace ; zspace:varid = "MINC standard variable" ; zspace:vartype = "dimension____" ; zspace:version = "MINC Version 1.0" ; zspace:comments = "Z increases from patient inferior to superior" ; zspace:spacing = "regular__" ; zspace:alignment = "centre" ; zspace:step = -1. ; zspace:start = 115.464775085449 ; zspace:spacetype = "native____" ; zspace:direction_cosines = 0., -0., 1. ; int yspace ; yspace:varid = "MINC standard variable" ; yspace:vartype = "dimension____" ; yspace:version = "MINC Version 1.0" ; yspace:comments = "Y increases from patient posterior to anterior" ; yspace:spacing = "regular__" ; yspace:alignment = "centre" ; yspace:step = -1. ; yspace:start = 139.535224914551 ; yspace:spacetype = "native____" ; yspace:direction_cosines = 0., 1., 0. ; short image(xspace, zspace, yspace) ; image:parent = "rootvariable" ; image:varid = "MINC standard variable" ; image:vartype = "group________" ; image:version = "MINC Version 1.0" ; image:signtype = "signed__" ; image:valid_range = 0., 4095. ; image:complete = "true_" ; image:image-min = "--->image-min" ; image:image-max = "--->image-max" ; int rootvariable ; rootvariable:varid = "MINC standard variable" ; rootvariable:vartype = "group________" ; rootvariable:version = "MINC Version 1.0" ; rootvariable:parent = "" ; rootvariable:children = "image\n", "patient\n", "study\n", "acquisition\n", "dicominfo\n", "dicom_groups" ; double image-min(xspace) ; image-min:varid = "MINC standard variable" ; image-min:vartype = "var_attribute" ; image-min:version = "MINC Version 1.0" ; image-min:_FillValue = 0. ; image-min:parent = "image" ; double image-max(xspace) ; image-max:varid = "MINC standard variable" ; image-max:vartype = "var_attribute" ; image-max:version = "MINC Version 1.0" ; image-max:_FillValue = 1. ; image-max:parent = "image" ; int patient ; patient:parent = "rootvariable" ; patient:varid = "MINC standard variable" ; patient:vartype = "group________" ; patient:version = "MINC Version 1.0" ; patient:full_name = "c***, r*** " ; patient:identification = "1519860 " ; patient:birthdate = "19810616" ; patient:sex = "male__" ; patient:weight = 90. ; int study ; study:parent = "rootvariable" ; study:varid = "MINC standard variable" ; study:vartype = "group________" ; study:version = "MINC Version 1.0" ; study:start_time = "20010724 104029.201" ; study:modality = "MRI__" ; study:institution = "Montreal Neuro Institute" ; study:station_id = "mrc " ; study:study_id = "20010724" ; study:acquisition_id = "1_2" ; int acquisition ; acquisition:parent = "rootvariable" ; acquisition:varid = "MINC standard variable" ; acquisition:vartype = "group________" ; acquisition:version = "MINC Version 1.0" ; acquisition:scanning_sequence = "fl3d_ns_11b65_vali" ; acquisition:repetition_time = 0.025 ; acquisition:echo_time = 0.011 ; acquisition:flip_angle = 30. ; acquisition:num_averages = 1. ; acquisition:imaging_frequency = 63604645. ; acquisition:imaged_nucleus = "1H" ; int dicominfo ; dicominfo:vartype = "group________" ; dicominfo:varid = "MNI DICOM information variable" ; dicominfo:parent = "rootvariable" ; dicominfo:window_min = -18. ; dicominfo:window_max = 416.5 ; dicominfo:xspace-indices = 6269, 6169, 6069, 5969, 5869, 5769, 5669, 5569, 5469, 5369, 5269, 5169, 5069, 4969, 4869, 4769, 4669, 4569, 4469, 4369, 4269, 4169, 4069, 3969, 3869, 3769, 3669, 3569, 3469, 3369, 3269, 3169, 3069, 2969, 2869, 2769, 2669, 2569, 2469, 2369, 2269, 2169, 2069, 1969, 1869, 1769, 1669, 1569, 1469, 1369, 1269, 1169, 1069, 969, 869, 769, 669, 569, 469, 369, 269, 169, 69, -31, -131, -231, -331, -431, -531, -631, -731, -831, -931, -1031, -1131, -1231, -1331, -1431, -1531, -1631, -1731, -1831, -1931, -2031, -2131, -2231 , -2331, -2431, -2531, -2631, -2731, -2831, -2931, -3031, -3131, -3231, -333 1, -3431, -3531, -3631, -3731, -3831, -3931, -4031, -4131, -4231, -4331, -44 31, -4531, -4631, -4731, -4831, -4931, -5031, -5131, -5231, -5331, -5431, -5 531, -5631, -5731, -5831, -5931, -6031, -6131, -6231, -6331, -6431, -6531, - 6631, -6731, -6831, -6931, -7031, -7131, -7231, -7331, -7431, -7531, -7631, -7731, -7831, -7931, -8031, -8131, -8231, -8331, -8431, -8531, -8631, -8731, -8831, -8931, -9031, -9131, -9231, -9331, -9431, -9531, -9631, -9731, -9831 , -9931, -10031, -10131, -10231, -10331, -10431, -10531, -10631 ; int dicom_groups ; dicom_groups:vartype = "group________" ; dicom_groups:varid = "MNI DICOM variable" ; dicom_groups:parent = "rootvariable" ; dicom_groups:children = "dicom_0x0008\n", "dicom_0x0009\n", "dicom_0x0010\n", "dicom_0x0011\n", "dicom_0x0018\n", "dicom_0x0019\n", "dicom_0x0020\n", "dicom_0x0021\n", "dicom_0x0028\n", "dicom_0x0029" ; int dicom_0x0008 ; dicom_0x0008:vartype = "group________" ; dicom_0x0008:varid = "MNI DICOM variable" ; dicom_0x0008:parent = "dicom_groups" ; dicom_0x0008:el_0x0000 = 0b, 0b, 1b, 82b ; dicom_0x0008:el_0x0008 = "ORIGINAL\\PRIMARY\\UNDEFINED" ; dicom_0x0008:el_0x0016 = 49b, 46b, 50b, 46b, 56b, 52b, 48b, 46b, 49b, 48b, 48b, 48b, 56b, 46b, 53b, 46b, 49b, 46b, 52b, 46b, 49b, 46b, 49b, 46b, 52b, 0b ; dicom_0x0008:el_0x0018 = 49b, 46b, 55b, 51b, 46b, 56b, 48b, 46b, 49b, 49b, 52b, 46b, 53b, 56b, 46b, 57b, 55b, 46b, 49b, 48b, 46b, 56b, 48b, 54b, 52b, 46b, 50b, 48b, 48b, 49b, 48b, 55b, 50b, 52b, 49b, 50b, 49b, 52b, 49b, 49b, 46b, 48b, 48b, 48b, 48b, 48b, 48b, 49b, 50b, 0b ; dicom_0x0008:el_0x0020 = "20010724" ; dicom_0x0008:el_0x0022 = "20010724" ; dicom_0x0008:el_0x0023 = "20010724" ; dicom_0x0008:el_0x0030 = "104029.201" ; dicom_0x0008:el_0x0032 = "104030.210" ; dicom_0x0008:el_0x0033 = "105625.000" ; dicom_0x0008:el_0x0060 = "MR" ; dicom_0x0008:el_0x0070 = "SIEMENS " ; dicom_0x0008:el_0x0080 = "Montreal Neuro Institute" ; dicom_0x0008:el_0x0090 = "" ; dicom_0x0008:el_0x1010 = "mrc " ; dicom_0x0008:el_0x1080 = "" ; dicom_0x0008:el_0x1090 = "MAGNETOM VISION " ; int dicom_0x0009 ; dicom_0x0009:vartype = "group________" ; dicom_0x0009:varid = "MNI DICOM variable" ; dicom_0x0009:parent = "dicom_groups" ; dicom_0x0009:el_0x0000 = 0b, 0b, 0b, 66b ; dicom_0x0009:el_0x1226 = "20010724" ; dicom_0x0009:el_0x1227 = "103354.000" ; dicom_0x0009:el_0x1316 = "723a610a" ; dicom_0x0009:el_0x1320 = "VC " ; int dicom_0x0010 ; dicom_0x0010:vartype = "group________" ; dicom_0x0010:varid = "MNI DICOM variable" ; dicom_0x0010:parent = "dicom_groups" ; dicom_0x0010:el_0x0000 = 0b, 0b, 0b, 90b ; dicom_0x0010:el_0x0010 = "c***, r*** " ; dicom_0x0010:el_0x0020 = "1519860 " ; dicom_0x0010:el_0x0030 = "19810616" ; dicom_0x0010:el_0x0040 = "M " ; dicom_0x0010:el_0x1010 = "020Y" ; dicom_0x0010:el_0x1030 = "90" ; int dicom_0x0011 ; dicom_0x0011:vartype = "group________" ; dicom_0x0011:varid = "MNI DICOM variable" ; dicom_0x0011:parent = "dicom_groups" ; dicom_0x0011:el_0x0000 = 0b, 0b, 0b, 44b ; dicom_0x0011:el_0x1110 = "20010724" ; dicom_0x0011:el_0x1111 = "103343.000" ; dicom_0x0011:el_0x1123 = "90" ; int dicom_0x0018 ; dicom_0x0018:vartype = "group________" ; dicom_0x0018:varid = "MNI DICOM variable" ; dicom_0x0018:parent = "dicom_groups" ; dicom_0x0018:el_0x0000 = 0b, 0b, 0b, -40b ; dicom_0x0018:el_0x0021 = "NONE\\NONE " ; dicom_0x0018:el_0x0050 = "1 " ; dicom_0x0018:el_0x0080 = "25" ; dicom_0x0018:el_0x0081 = "11" ; dicom_0x0018:el_0x0083 = "1 " ; dicom_0x0018:el_0x0084 = "63.604645 " ; dicom_0x0018:el_0x0085 = "1H" ; dicom_0x0018:el_0x0086 = "1 " ; dicom_0x0018:el_0x0090 = "256 " ; dicom_0x0018:el_0x1000 = " 7321" ; dicom_0x0018:el_0x1020 = "VB33A " ; dicom_0x0018:el_0x1200 = "20010704" ; dicom_0x0018:el_0x1201 = "112159.000" ; dicom_0x0018:el_0x1250 = "CP Head " ; dicom_0x0018:el_0x1314 = "30" ; int dicom_0x0019 ; dicom_0x0019:vartype = "group________" ; dicom_0x0019:varid = "MNI DICOM variable" ; dicom_0x0019:parent = "dicom_groups" ; dicom_0x0019:el_0x0000 = 0b, 0b, 3b, 72b ; dicom_0x0019:el_0x1010 = "60" ; dicom_0x0019:el_0x1050 = "0 " ; dicom_0x0019:el_0x1060 = "131072" ; dicom_0x0019:el_0x1210 = "954.5383644104" ; dicom_0x0019:el_0x1211 = "954.5383644104" ; dicom_0x0019:el_0x1212 = "3.97968763868248e-43" ; dicom_0x0019:el_0x1213 = "60" ; dicom_0x0019:el_0x1214 = "1 " ; dicom_0x0019:el_0x1220 = "224 " ; dicom_0x0019:el_0x1221 = "224 " ; dicom_0x0019:el_0x1226 = "111 " ; dicom_0x0019:el_0x1228 = "-112" ; dicom_0x0019:el_0x1230 = "256 " ; dicom_0x0019:el_0x1231 = "256 " ; dicom_0x0019:el_0x1250 = "1 " ; dicom_0x0019:el_0x1260 = "30" ; dicom_0x0019:el_0x1270 = "40" ; dicom_0x0019:el_0x1290 = "0 " ; dicom_0x0019:el_0x1294 = "0 " ; dicom_0x0019:el_0x1298 = "0\\0\\0 " ; dicom_0x0019:el_0x1412 = "1.49380624294281" ; dicom_0x0019:el_0x1414 = "10" ; dicom_0x0019:el_0x1416 = "8.2578125 " ; dicom_0x0019:el_0x1420 = "220 " ; dicom_0x0019:el_0x1421 = "1 " ; dicom_0x0019:el_0x1422 = "34" ; dicom_0x0019:el_0x1424 = "74.7226943969727" ; dicom_0x0019:el_0x1426 = "92.5243682861328" ; dicom_0x0019:el_0x1450 = "88.3300018310547" ; dicom_0x0019:el_0x1451 = "64.8600006103516" ; dicom_0x0019:el_0x1452 = "53.4700012207031" ; dicom_0x0019:el_0x1454 = "-1" ; dicom_0x0019:el_0x1455 = "101.62767791748 " ; dicom_0x0019:el_0x1456 = "8500" ; dicom_0x0019:el_0x1460 = "0.0149458236992359" ; dicom_0x0019:el_0x1462 = "0.595520436763763 " ; dicom_0x0019:el_0x1470 = "1.529296875 " ; dicom_0x0019:el_0x1471 = "1.529296875 " ; dicom_0x0019:el_0x1472 = "0.705882370471954 " ; dicom_0x0019:el_0x1482 = "200 " ; dicom_0x0019:el_0x1490 = "" ; dicom_0x0019:el_0x14a0 = "1 " ; dicom_0x0019:el_0x14a2 = "1.18286526203156" ; dicom_0x0019:el_0x14b0 = "0 " ; dicom_0x0019:el_0x1510 = "/usr/appl/proto/016/c/head/Head_coil_fMRI/global_t1W.prg" ; dicom_0x0019:el_0x1511 = "/usr/vali/pargen/anatomical/fl3d_ns_11b65_vali.wkc" ; dicom_0x0019:el_0x1512 = "USER" ; dicom_0x0019:el_0x1513 = "fl3d" ; int dicom_0x0020 ; dicom_0x0020:vartype = "group________" ; dicom_0x0020:varid = "MNI DICOM variable" ; dicom_0x0020:parent = "dicom_groups" ; dicom_0x0020:el_0x0000 = 0b, 0b, 1b, 60b ; dicom_0x0020:el_0x000d = 49b, 46b, 55b, 51b, 46b, 56b, 48b, 46b, 49b, 49b, 52b, 46b, 53b, 56b, 46b, 57b, 55b, 46b, 49b, 48b, 46b, 56b, 48b, 54b, 52b, 46b, 50b, 48b, 48b, 49b, 48b, 55b, 50b, 52b, 49b, 50b, 49b, 52b, 49b, 49b, 46b, 48b, 48b, 48b, 48b, 48b, 48b, 49b, 51b, 0b ; dicom_0x0020:el_0x000e = 49b, 46b, 55b, 51b, 46b, 56b, 48b, 46b, 49b, 49b, 52b, 46b, 53b, 56b, 46b, 57b, 55b, 46b, 49b, 48b, 46b, 56b, 48b, 54b, 52b, 46b, 50b, 48b, 48b, 49b, 48b, 55b, 50b, 52b, 49b, 50b, 49b, 52b, 49b, 49b, 46b, 48b, 48b, 48b, 48b, 48b, 48b, 49b, 52b, 0b ; dicom_0x0020:el_0x0010 = "2 " ; dicom_0x0020:el_0x0011 = "1 " ; dicom_0x0020:el_0x0012 = "1 " ; dicom_0x0020:el_0x0013 = "4 " ; dicom_0x0020:el_0x0032 = "-62.6907997131348\\-139.535224914551\\115.464775085449" ; dicom_0x0020:el_0x0037 = "0\\1\\-0\\0\\-0\\-1" ; dicom_0x0020:el_0x0050 = "0 " ; dicom_0x0020:el_0x0052 = 49b, 46b, 55b, 51b, 46b, 56b, 48b, 46b, 49b, 49b, 52b, 46b, 53b, 56b, 46b, 57b, 55b, 46b, 49b, 48b, 46b, 56b, 48b, 54b, 52b, 46b, 50b, 48b, 48b, 49b, 48b, 55b, 50b, 52b, 49b, 50b, 49b, 52b, 49b, 49b, 46b, 48b, 48b, 48b, 48b, 48b, 48b, 49b, 53b, 0b ; dicom_0x0020:el_0x1001 = "1 " ; int dicom_0x0021 ; dicom_0x0021:vartype = "group________" ; dicom_0x0021:varid = "MNI DICOM variable" ; dicom_0x0021:parent = "dicom_groups" ; dicom_0x0021:el_0x0000 = 0b, 0b, 1b, 88b ; dicom_0x0021:el_0x1020 = 0b, 0b ; dicom_0x0021:el_0x1122 = "1 " ; dicom_0x0021:el_0x1160 = "-62.6907997131348\\12.0352249145508\\12.0352249145508 " ; dicom_0x0021:el_0x1161 = "1\\0\\-0" ; dicom_0x0021:el_0x1163 = "-62.6907997131348 " ; dicom_0x0021:el_0x1165 = 1b, 0b ; dicom_0x0021:el_0x116a = "0\\-1\\0" ; dicom_0x0021:el_0x116b = "0\\0\\1 " ; dicom_0x0021:el_0x1180 = "Head_coil_fMRI/global_t1W " ; dicom_0x0021:el_0x1322 = "0 " ; dicom_0x0021:el_0x1324 = "0 " ; dicom_0x0021:el_0x1330 = "170 " ; dicom_0x0021:el_0x1331 = "170 " ; dicom_0x0021:el_0x1334 = "170 " ; dicom_0x0021:el_0x1336 = "1 " ; dicom_0x0021:el_0x1339 = "170 " ; dicom_0x0021:el_0x1340 = "1 " ; dicom_0x0021:el_0x1341 = "1 " ; dicom_0x0021:el_0x1342 = "1 " ; dicom_0x0021:el_0x1343 = "1 " ; dicom_0x0021:el_0x1344 = "-19222" ; dicom_0x0021:el_0x1356 = "25" ; dicom_0x0021:el_0x1370 = "1 " ; int dicom_0x0028 ; dicom_0x0028:vartype = "group________" ; dicom_0x0028:varid = "MNI DICOM variable" ; dicom_0x0028:parent = "dicom_groups" ; dicom_0x0028:el_0x0000 = 0b, 0b, 0b, -86b ; dicom_0x0028:el_0x0002 = 1b, 0b ; dicom_0x0028:el_0x0004 = "MONOCHROME2 " ; dicom_0x0028:el_0x0005 = 2b, 0b ; dicom_0x0028:el_0x0010 = 0b, 1b ; dicom_0x0028:el_0x0011 = 0b, 1b ; dicom_0x0028:el_0x0030 = "1\\1 " ; dicom_0x0028:el_0x0100 = 16b, 0b ; dicom_0x0028:el_0x0101 = 12b, 0b ; dicom_0x0028:el_0x0102 = 11b, 0b ; dicom_0x0028:el_0x0103 = 0b, 0b ; dicom_0x0028:el_0x0200 = -32b, 127b ; dicom_0x0028:el_0x1050 = "41\\41 " ; dicom_0x0028:el_0x1051 = "96\\96 " ; dicom_0x0028:el_0x1052 = "0 " ; dicom_0x0028:el_0x1053 = "1 " ; int dicom_0x0029 ; dicom_0x0029:vartype = "group________" ; dicom_0x0029:varid = "MNI DICOM variable" ; dicom_0x0029:parent = "dicom_groups" ; dicom_0x0029:el_0x0000 = 0b, 0b, 0b, 10b ; dicom_0x0029:el_0x1152 = "1 " ; // global attributes: :history = "Tue Jul 24 12:09:26 2001>>> dicomserver\n", "" ; } From minc-users@bic.mni.mcgill.ca Thu May 29 05:50:07 2003 From: minc-users@bic.mni.mcgill.ca (Andrew Janke) Date: Thu, 29 May 2003 14:50:07 +1000 Subject: [MINC-users] Java and MINC In-Reply-To: <3ECD15FF.6020608@u.washington.edu> References: <3ECD15FF.6020608@u.washington.edu> Message-ID: On Thu, 22 May 2003, Andrew Poliakov wrote: > I was wondering how difficult would it be importing minc files into a > java program. Did anyone attempted developing minc bindings in java? > > I noticed there is a NETCDF package for java. I am not sure how much > help that would be. > > I would greatly appreciate any information and ideas. I suggest you get in contact with Chris Cocosco, the authour of jiv http://www.bic.mni.mcgill.ca/~crisco/jiv/ -- Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance Work: +61 7 3365 4100 || Home: +61 7 3800 4042 From minc-users@bic.mni.mcgill.ca Fri May 30 08:16:30 2003 From: minc-users@bic.mni.mcgill.ca (Andrew Janke) Date: Fri, 30 May 2003 17:16:30 +1000 Subject: [MINC-users] MINC -> Analyze conversion problem In-Reply-To: <005901c32599$6ecf28c0$6402a8c0@cgrova> References: <005901c32599$6ecf28c0$6402a8c0@cgrova> Message-ID: On Wed, 28 May 2003, christophe grova wrote: > My name is Christophe Grova and I am a new post doc arrived at the MNI in > Jean Gotman's team (EEG department). I try tu use 'mnc2ana' to convert a > MINC file in an analyze file. > I obtained really strange results in my analyze header ! Especially, my > dimensions are completely false ! > > For info, here is a dump of my analyze header followed by a dump of the header > of the MINC file (using mincheader : this header seems ok ) Using the Display > software I have no problem to look at this MINC file on my PC under linux ... Did you by any chance convert the file to analyze on an SGI and then view the resulting analyse header on a linux box? If so perhaps you are getting byte swapping problems. try running the conversion as such (on the SGI): $ mnc2ana -verbose file.mnc out.hdr This should provide a dump of the analyze header as it is created. either that or use the C/L tool 'ana_show out.hdr' on the SGI or at least where you run mnc2ana. With this output I may be able to assist you a bit more. -- Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance Work: +61 7 3365 4100 || Home: +61 7 3800 4042 From minc-users@bic.mni.mcgill.ca Fri May 30 17:26:19 2003 From: minc-users@bic.mni.mcgill.ca (Christophe Grova) Date: Fri, 30 May 2003 10:26:19 -0600 Subject: [MINC-users] MINC -> Analyze conversion problem References: <005901c32599$6ecf28c0$6402a8c0@cgrova> Message-ID: <001501c326c8$345cd680$e136d884@cgrova> Hello Andrew, > Did you by any chance convert the file to analyze on an SGI and then view the > resulting analyse header on a linux box? No, everything was made on my linux box. Dale Einarson installed on my machine all usual softwares or the BIC. So I used Display and mnc2ana on my linux box. > > try running the conversion as such (on the SGI): > > $ mnc2ana -verbose file.mnc out.hdr I did not manage to access this function on SGI as feeble or bullcalf :o( Here is the result of the verbose ...and evreything seems to be OK: The analyze dump I used last time was obtained using a software that I obtained on the Mayo clinic website via information found in the help of SPM (but they have changed their website since :o() . I obtained the same wrong information using my dump software or when I open this analyze file with SPM. I also obtained wrong info using ana_show (see the second dump below) Any ideas ??? Thanks in advance, Christophe Start: 62.690799713134801152 - 139.53522491455080967 - 115.46477508544920454 Step: -0.99999999999999877875 - -1 - -1 Length: 170 - 256 - 256 Dims: xspace - zspace - yspace HDR: sizeof_hdr <348> data_type <0> db_name <> extents <16384> session_error <0> regular hkey_un0 <0> DIMENSION: dim: <4 170 256 256 0 0 0 0> vox_units <> cal_units <> unused1 <0> datatype <4> bitpix <16> dim_un0 <0> pixdim <4 0.999999999999999 1 1 0 0 0 0> vox_offset <0> scale_factor <1> funused1 <0> funused2 <0> cal_max <0> cal_min <0> compressed <0> verified <0> glmax <65535> glmin <0> HISTORY: descrip <> aux_file <> orient <0> originator <0 0 0 0 0> generated <> scannum <> patient_id <> exp_date <> exp_time <> hist_un0 <> views <0> vols_added <0> start_field <0> field_skip <0> omax <0> omin <0> smax <0> smin <0> mincextract -normalize -positive_direction -filetype -signed calistus_rukshan_20010724_1_2_mri.mnc > calistus_rukshan_20010724_1_2_mri.img > > This should provide a dump of the analyze header as it is created. > either that or use the C/L tool 'ana_show out.hdr' on the SGI or at least where > you run mnc2ana. > I tried this function (still on my linux box) ...and obtained this wrong information this time (both mnc2ana and ana_show were performed on my linux box, so it should not be a pb of byte swapping)....here is the result of ana_show: HDR: sizeof_hdr <348> data_type <0> db_name <> extents <16384> session_error <0> regular hkey_un0 <0> DIMENSION: dim: <4 -21822 0 1 1 0 0 0> vox_units <> cal_units <> unused1 <0> datatype <1024> bitpix <4096> dim_un0 <0> pixdim <-32 2.31382402429314e-41 5.83182585793452e-39 1.00592041015625 -1.78160862546503e-38 8.82818032524635e-44 0 0> vox_offset <0> scale_factor <0> funused1 <-32> funused2 <2.27795078360642e-41> cal_max <0> cal_min <0> compressed <0> verified <0> glmax <0> glmin <-1077739520> HISTORY: descrip <> aux_file <> orient <0> originator <0 0 0 0 0> generated <> scannum <> patient_id <> exp_date <> exp_time <> hist_un0 <> views <0> vols_added <0> start_field <0> field_skip <0> omax <0> omin <0> smax <0> smin <0>