From nikelski at bic.mni.mcgill.ca Thu Dec 6 16:29:22 2007 From: nikelski at bic.mni.mcgill.ca (EJ Nikelski) Date: Thu, 6 Dec 2007 16:29:22 -0500 Subject: [MINC-users] minc2 build error -- resolved Message-ID: Hi all, I just found a solution to my rather bizarre error when building minc2 (2.0.14). It manifested as a "multiple definition of `compress'" linkage error. To summarize, I did the following: (1) Build zlib-1.2.3 (2) Build hdf5-1.6.6 (3) Build netcdf-3.6.2 (4) Build minc-2.0.14 All steps up to the minc2 build looked good -- and the "make check/test" was OK for everything. The minc2 build (first on Edgy, then on Feisty) failed with the abovementioned link error. Solution: Build hdf5 *with* the shared libraries enabled. Nope, dunno why this should make a difference, but it absolutely does (for 1.6.6, anyway). So, my build options for hdf5 look like this - ./configure --prefix=/data/raid01/quarantine/Dec2007/minc2 --with-zlib=/data/raid01/quarantine/Dec2007/minc2 --enable-static-exec Note the you can still build statically linked executables without any problem. Only the use of the "--disable-shared" option causes problems. Without this option all is well, ... even the "make check" runs to completion when the run_tests.sh & run_test2.sh test scripts are corrected (the list assigned to $tests needs to be quoted). Hope this helps. Cheers, Jim From claude at bic.mni.mcgill.ca Thu Dec 6 18:47:26 2007 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Thu, 6 Dec 2007 18:47:26 -0500 (EST) Subject: [MINC-users] minc2 build error -- resolved Message-ID: <200712062347.lB6NlQ3Z74223856@yorick.bic.mni.mcgill.ca> Hi Jim, It seems odd that your solution actually works given the nature of the problem. Here is the "real" fix for it: the global variable 'compress' conflicts with another variable named 'compress' in libz. This is very bad programming in libz; global variables should be protected in a namespace, in my opinion. Anyway, try the following in progs/mincconvert/mincconvert.c: At line 65: static int compress = -1; In fact, all those global variables should have a static in front. That's bad programming too. The linker will not fuss anymore. Andrew: make sure this goes through the next minc-2.0.15 revision. :-) bye Claude > I just found a solution to my rather bizarre error when building > minc2 (2.0.14). It manifested as a "multiple definition of `compress'" > linkage error. To summarize, I did the following: > > (1) Build zlib-1.2.3 > (2) Build hdf5-1.6.6 > (3) Build netcdf-3.6.2 > (4) Build minc-2.0.14 > > All steps up to the minc2 build looked good -- and the "make > check/test" was OK for everything. The minc2 build (first on Edgy, > then on Feisty) failed with the abovementioned link error. > > Solution: Build hdf5 *with* the shared libraries enabled. Nope, dunno > why this should make a difference, but it absolutely does (for 1.6.6, > anyway). So, my build options for hdf5 look like this - > > ./configure > --prefix=/data/raid01/quarantine/Dec2007/minc2 > --with-zlib=/data/raid01/quarantine/Dec2007/minc2 > --enable-static-exec > > Note the you can still build statically linked executables without any > problem. Only the use of the "--disable-shared" option causes > problems. Without this option all is well, ... even the "make check" > runs to completion when the run_tests.sh & run_test2.sh test scripts > are corrected (the list assigned to $tests needs to be quoted). > > Hope this helps. > > Cheers, > > Jim > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From nikelski at bic.mni.mcgill.ca Sat Dec 8 14:48:58 2007 From: nikelski at bic.mni.mcgill.ca (EJ Nikelski) Date: Sat, 8 Dec 2007 14:48:58 -0500 Subject: [MINC-users] minc2 build error -- resolved In-Reply-To: <200712062347.lB6NlQ3Z74223856@yorick.bic.mni.mcgill.ca> References: <200712062347.lB6NlQ3Z74223856@yorick.bic.mni.mcgill.ca> Message-ID: Hi Claude, Yes, I agree ... I was more than a little surprised when building the shared hdf5 libraries made the problem disappear. At any rate, you put your finger on the *real* problem. Rebuilding minc2 with the modified mincconvert.c cleared up my linking error. Thanks again. Now, off to build the rest of the world ... -Jim On Dec 6, 2007 6:47 PM, Claude LEPAGE wrote: > Hi Jim, > > It seems odd that your solution actually works given the nature of the problem. > > Here is the "real" fix for it: the global variable 'compress' conflicts with > another variable named 'compress' in libz. This is very bad programming in > libz; global variables should be protected in a namespace, in my opinion. > Anyway, try the following in progs/mincconvert/mincconvert.c: > > At line 65: > static int compress = -1; > > In fact, all those global variables should have a static in front. That's bad > programming too. The linker will not fuss anymore. > > Andrew: make sure this goes through the next minc-2.0.15 revision. :-) > > bye > > Claude > > > > I just found a solution to my rather bizarre error when building > > minc2 (2.0.14). It manifested as a "multiple definition of `compress'" > > linkage error. To summarize, I did the following: > > > > (1) Build zlib-1.2.3 > > (2) Build hdf5-1.6.6 > > (3) Build netcdf-3.6.2 > > (4) Build minc-2.0.14 > > > > All steps up to the minc2 build looked good -- and the "make > > check/test" was OK for everything. The minc2 build (first on Edgy, > > then on Feisty) failed with the abovementioned link error. > > > > Solution: Build hdf5 *with* the shared libraries enabled. Nope, dunno > > why this should make a difference, but it absolutely does (for 1.6.6, > > anyway). So, my build options for hdf5 look like this - > > > > ./configure > > --prefix=/data/raid01/quarantine/Dec2007/minc2 > > --with-zlib=/data/raid01/quarantine/Dec2007/minc2 > > --enable-static-exec > > > > Note the you can still build statically linked executables without any > > problem. Only the use of the "--disable-shared" option causes > > problems. Without this option all is well, ... even the "make check" > > runs to completion when the run_tests.sh & run_test2.sh test scripts > > are corrected (the list assigned to $tests needs to be quoted). > > > > Hope this helps. > > > > Cheers, > > > > Jim > > _______________________________________________ > > MINC-users at bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > -- ================================= Jim Nikelski, Ph.D. Postdoctoral Research Fellow Bloomfield Centre for Research in Aging Lady Davis Institute for Medical Research Sir Mortimer B. Davis - Jewish General Hospital McGill University Tel: (514) 340-8222 x 2298 Fax: (514) 340-8295 From alex at bic.mni.mcgill.ca Sun Dec 9 14:58:04 2007 From: alex at bic.mni.mcgill.ca (Alex Zijdenbos) Date: Sun, 9 Dec 2007 14:58:04 -0500 Subject: [MINC-users] bug in dcm2mnc Message-ID: Hi all, [posting this wide as many may be affected] I stumbled across a bug in dcm2mnc which mangles echo times. From dicom_read.c: gi_ptr->acq.echo_time = acr_find_double(group_list, ACR_Echo_time, -DBL_MAX); if (gi_ptr->acq.echo_time != -DBL_MAX) gi_ptr->acq.echo_time /= 1000.0; gi_ptr->acq.echo_time = acr_find_double(group_list, ACR_Echo_train_length, -DBL_MAX); /*added echo train length ilana*/ That last one overwrites the just-gotten echo_time with echo_train_length, and should have read read: gi_ptr->acq.echo_train_length = acr_find_double(group_list, ACR_Echo_train_length, -DBL_MAX); /*added echo train length ilana*/ Ah... the dangers of cut-and-paste :) I have fixed this and checked the fix into cvs. However, my guess is that all minc files created with dcm2mnc since ilana's modification, done in June this year, will have bad echo times. I suppose this only affected the minc-2.0.14 release - Andrew? -- Alex From alex at bic.mni.mcgill.ca Sun Dec 9 22:23:54 2007 From: alex at bic.mni.mcgill.ca (Alex Zijdenbos) Date: Sun, 9 Dec 2007 22:23:54 -0500 Subject: [MINC-users] Another bug in dcm2mnc -> x/y step switch? Message-ID: Hello all, I have been trying to solve another dicom-to-minc conversion problem, and that is that I have some data that are anisotropic in-plane (128x256), with step sizes 0.19 and 0.39 mm (the FoV is square). However, when converting this with dcm2mnc, the x- and y-step sizes are inverted, such that the resulting minc volume is, well rather squashed. In the DICOM data, I have: (0028, 0010) US 2: Rows = 128 (0028, 0011) US 2: Columns = 256 (0028, 0030) DS 18: PixelSpacing = 0.390625\0.1953125 However, converting that with dcm2mnc, I get: dimension name length step start -------------- ------ ---- ----- zspace 29 1 -13.3 yspace 128 -0.195312 25 xspace 256 -0.390625 25 Clearly the x-and y-steps are reversed. On lines 1417/18 of dicom_read.c: steps[VCOLUMN] = psize[0]; steps[VROW] = psize[1]; /* anisotropic resolution? */ I *think* that this is wrong, that the indices into psize should in fact be reversed. And sure enough, if I do that and reconvert my data, everything looks good... However, I was wondering if somebody more familiar than I am with dicom-to-minc conversions could verify this. Anybody else seen this? Most commonly people acquire data which is isotropic, or close to isotropic, in-plane, so it would not surprise me if it hasn't been noticed before - but there could also be something specific about the data that I have. If this is indeed a bug I'm happy to check the fix into cvs, but I'd rather be sure that it is a general problem. Thanks, -- Alex From a.janke at gmail.com Mon Dec 10 08:18:02 2007 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 11 Dec 2007 00:18:02 +1100 Subject: [MINC-users] bug in dcm2mnc In-Reply-To: References: Message-ID: > gi_ptr->acq.echo_train_length = > acr_find_double(group_list, ACR_Echo_train_length, -DBL_MAX); > /*added echo train length ilana*/ > > Ah... the dangers of cut-and-paste :) > > I have fixed this and checked the fix into cvs. However, my guess is > that all minc files created with dcm2mnc since ilana's modification, > done in June this year, will have bad echo times. I suppose this only > affected the minc-2.0.14 release - Andrew? That is correct, only 2.0.14 from what I can see. I will be releasing a 2.0.15 shortly (this week) so hopefully we can get around this and few other bugs that have cropped up with linking. a From alex at bic.mni.mcgill.ca Mon Dec 10 22:06:39 2007 From: alex at bic.mni.mcgill.ca (Alex Zijdenbos) Date: Mon, 10 Dec 2007 22:06:39 -0500 Subject: [MINC-users] bug in dcm2mnc In-Reply-To: References: Message-ID: On Dec 10, 2007 8:18 AM, Andrew Janke wrote: > > gi_ptr->acq.echo_train_length = > > acr_find_double(group_list, ACR_Echo_train_length, -DBL_MAX); > > /*added echo train length ilana*/ > > > > Ah... the dangers of cut-and-paste :) > > > > I have fixed this and checked the fix into cvs. However, my guess is > > that all minc files created with dcm2mnc since ilana's modification, > > done in June this year, will have bad echo times. I suppose this only > > affected the minc-2.0.14 release - Andrew? > > That is correct, only 2.0.14 from what I can see. I will be releasing > a 2.0.15 shortly (this week) so hopefully we can get around this and > few other bugs that have cropped up with linking. Sounds good. It would be good to fix the other bug I raised as well (switched x- and y-step) - assuming it is a bug and that my suggested fix is a general one... Do you have thoughts on that, or a way to verify? Would need to find some DICOM data that is anisotropic in-plane. -- A From steve at sumost.ca Thu Dec 13 17:45:39 2007 From: steve at sumost.ca (Steve M. Robbins) Date: Thu, 13 Dec 2007 16:45:39 -0600 Subject: [MINC-users] bug in dcm2mnc In-Reply-To: References: Message-ID: <20071213224539.GC8595@sumost.ca> On Mon, Dec 10, 2007 at 10:06:39PM -0500, Alex Zijdenbos wrote: > Sounds good. It would be good to fix the other bug I raised as well > (switched x- and y-step) - assuming it is a bug and that my suggested > fix is a general one... Do you have thoughts on that, or a way to > verify? Would need to find some DICOM data that is anisotropic > in-plane. If you spend some quality time with DCMTK's dcmdump / dump2dcm, it's not hard to manufacture anisotropic DICOM data. One could even script it into a unit test. -S From nikelski at bic.mni.mcgill.ca Sun Dec 16 13:45:51 2007 From: nikelski at bic.mni.mcgill.ca (EJ Nikelski) Date: Sun, 16 Dec 2007 13:45:51 -0500 Subject: [MINC-users] minc volume integrity checks Message-ID: Hi All, A wee bit back, our lab ran into a problem with an XFS driver causing corruption on our RAID system. This error resulted in quite a few files having blocks of random garbage written to them ... which, of course, also affected our minc volumes. The problem was resolved, however, I am left with the nagging suspicion that some of our minc volumes might still be corrupted. Does anyone have any idea of how I might scan through all of our volumes and identify at least some of the corrupted volumes? On a related note, as larger and larger volumes find themselves moved around in a number of ways, might it not be useful to have an image checksum attribute initialized in the minc header at volume creation? Yes, TCP/IP transfers are *supposed* to validate that blocks are transferred correctly ... but the XFS driver was also not supposed to corrupt our RAID. Is this checksum idea a possibility (is it already in minc2, and I've missed it?), or is this best addressed in minc3 ;) -Jim From a.janke at gmail.com Mon Dec 17 15:45:12 2007 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 18 Dec 2007 07:45:12 +1100 Subject: [MINC-users] minc volume integrity checks In-Reply-To: References: Message-ID: Hi Jim, This is something that I wanted to have included in MINC2 (md5 sums of important headers, data and header+data) but it never made it. But the MINC id stuff did make it into MINC2. I have since simply coded up most of what you want in perl via a few shell commands I will dig around in my home directory and send it to you. a On Dec 17, 2007 5:45 AM, EJ Nikelski wrote: > Hi All, > > A wee bit back, our lab ran into a problem with an XFS driver > causing corruption on our RAID system. This error resulted in quite a > few files having blocks of random garbage written to them ... which, > of course, also affected our minc volumes. The problem was resolved, > however, I am left with the nagging suspicion that some of our minc > volumes might still be corrupted. Does anyone have any idea of how I > might scan through all of our volumes and identify at least some of > the corrupted volumes? > > On a related note, as larger and larger volumes find themselves > moved around in a number of ways, might it not be useful to have an > image checksum attribute initialized in the minc header at volume > creation? Yes, TCP/IP transfers are *supposed* to validate that > blocks are transferred correctly ... but the XFS driver was also not > supposed to corrupt our RAID. Is this checksum idea a possibility (is > it already in minc2, and I've missed it?), or is this best addressed > in minc3 ;) > > -Jim > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From jharlap at bic.mni.mcgill.ca Tue Dec 18 10:25:54 2007 From: jharlap at bic.mni.mcgill.ca (Jonathan Harlap) Date: Tue, 18 Dec 2007 10:25:54 -0500 Subject: [MINC-users] another bug in dcm2mnc Message-ID: <8FF53835-A24C-44CB-9CEA-A980D03AC3FA@bic.mni.mcgill.ca> [possibly a repeat - last one went from the wrong address and thus may be rejected] These two bugs seem to only affect dcm2mnc in minc 2.0.14. Cross- posted as it belongs primarily in the development list but affects users of 2.0.14 and so should be known. 1) For reasons unknown the attribute acquisition comments was renamed to acquisition image_comments, which breaks consistency with old data. It has been reverted back from whence it came. 2) All dicom_* groups were left out of the produced minc headers which may have seemed convenient to someone making the change but is rather inconvenient to anyone who expected those fields to be there, as it used to be. These have been reverted, with the one change that attributes with length=0 are not added as it makes HDF complain and we can probably assume safely that an attribute with no content isn't particularly useful. And yes, that's me making a judgement call about what might be useful to others - which is exactly what I'm railing against here, but I do so only because it avoids screenfuls of HDF warning messages. Fixes are in CVS and will hopefully appear shortly in 2.0.15. Cheers, J