From sean at rogue-research.com Thu Oct 1 10:35:47 2015 From: sean at rogue-research.com (Sean McBride) Date: Thu, 1 Oct 2015 10:35:47 -0400 Subject: [MINC-development] MINC with NetCDF 4.4? In-Reply-To: <3610747.RhXyGNL3Ka@riemann> References: <2204850.mNumVZCYYR@riemann> <18419_1441990310_55F306A6_18419_103_1_CAAd5DeR9vuqyFre5Udf5uf5XWnZMSiuE69ug 0UqfpHgq2mU89g@mail.gmail.com> <3610747.RhXyGNL3Ka@riemann> Message-ID: <20151001143547.1280008432@mail.rogue-research.com> On Sat, 12 Sep 2015 20:38:50 -0500, Steve M. Robbins said: >> So the minc-tools and libminc projects are now merged and tagged, both at >> 2.3.00. "Develop" should now be even with "master." > >Thanks, Bert! The updated libminc and minc-tools are on their way to Debian. So do I understand that minc 2.3 is officially released?!? 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 vladimir.fonov at gmail.com Thu Oct 1 10:57:42 2015 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Thu, 1 Oct 2015 10:57:42 -0400 Subject: [MINC-development] MINC with NetCDF 4.4? In-Reply-To: <20151001143547.1280008432@mail.rogue-research.com> References: <2204850.mNumVZCYYR@riemann> <3610747.RhXyGNL3Ka@riemann> <20151001143547.1280008432@mail.rogue-research.com> Message-ID: it is. On Thu, Oct 1, 2015 at 10:35 AM, Sean McBride wrote: > On Sat, 12 Sep 2015 20:38:50 -0500, Steve M. Robbins said: > > >> So the minc-tools and libminc projects are now merged and tagged, both > at > >> 2.3.00. "Develop" should now be even with "master." > > > >Thanks, Bert! The updated libminc and minc-tools are on their way to > Debian. > > So do I understand that minc 2.3 is officially released?!? > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > -- Best regards, Vladimir S. Fonov ~ vladimir fonov gmail com -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at sumost.ca Tue Oct 6 01:49:11 2015 From: steve at sumost.ca (Steve M. Robbins) Date: Tue, 06 Oct 2015 00:49:11 -0500 Subject: [MINC-development] test failures: minc2-label-test Message-ID: <6011694.lAjOOW3deJ@riemann> Hi, I'm a little stumped. The new libminc 2.3.00 fails on certain Debian architectures but works on others; see https://buildd.debian.org/status/package.php?p=libminc Mostly, it is minc2-label-test that fails. The first failure is line 172: 168 miget_label_value ( vol, "White", &white_value ); 169 miget_label_value ( vol, "Blue", &blue_value ); 170 171 if (white_value != 0xffffff) { 172 TESTRPT("miget_label_value, White", white_value); 173 } Instead of 0x00ffffff, we get -256 = 0xffffff00 -- i.e. a byte-swapped value. I traced through label.c and found this code that employs "miswap4()". Here I'm way over my head, so maybe someone can quickly fill me in: 1. What are volume->mtype_id and volume->ftype_id ? 2. Is there any implicit assumptions in this code about the bit-length of unsigned short and unsigned int? Any implicit assumptions about endianness? int midefine_label(mihandle_t volume, int value, const char *name) { ... MI_CHECK_HDF_CALL_RET(result = H5Tenum_insert(volume->mtype_id, name, &value),"H5Tenum_insert"); /* We might have to swap these values before adding them to * the file type. * * COOL! the whole purpose of HDF5 being machine independent is defeated here! */ if (H5Tget_order(volume->ftype_id) != H5Tget_order(volume->mtype_id)) { switch (H5Tget_size(volume->ftype_id)) { case 2: value = miswap2((unsigned short) value); break; case 4: value = miswap4((unsigned int) value); break; } } MI_CHECK_HDF_CALL_RET(result = H5Tenum_insert(volume->ftype_id, name, &value),"H5Tenum_insert"); Thanks, -Steve P.S. See trivial fixes in https://github.com/BIC-MNI/libminc/pull/59 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 811 bytes Desc: This is a digitally signed message part. URL: From robert.d.vincent at mcgill.ca Tue Oct 6 08:20:22 2015 From: robert.d.vincent at mcgill.ca (Robert D. Vincent) Date: Tue, 6 Oct 2015 08:20:22 -0400 Subject: [MINC-development] test failures: minc2-label-test In-Reply-To: <6011694.lAjOOW3deJ@riemann> References: <6011694.lAjOOW3deJ@riemann> Message-ID: Steve, The mtype_id contains the HDF5 type corresponding to the "memory" or "native" voxel type, and ftype_id contains the HDF5 "file" voxel type. My memory here is a little weak, but I think we tried to create parallel HDF5 types for volumes, such that the "native" type would be in the machine's byte order, but the file type would always be little endian. My guess is that the H5Tenum_insert() function does not do any translation of its argument, so that we needed to swap bytes to keep the label values consistent on big-endian architectures. Once upon a time, we regularly tested on big-endian machines, but that is rare these days. It's certainly possible that there are assumptions about either the byte order or type sizes. Do you happen to know the HDF5 version in use? -bert On Tue, Oct 6, 2015 at 1:49 AM, Steve M. Robbins wrote: > Hi, > > I'm a little stumped. The new libminc 2.3.00 fails on certain Debian > architectures but works on others; see > https://buildd.debian.org/status/package.php?p=libminc > > Mostly, it is minc2-label-test that fails. The first failure is line 172: > > 168 miget_label_value ( vol, "White", &white_value ); > 169 miget_label_value ( vol, "Blue", &blue_value ); > 170 > 171 if (white_value != 0xffffff) { > 172 TESTRPT("miget_label_value, White", white_value); > 173 } > > Instead of 0x00ffffff, we get -256 = 0xffffff00 -- i.e. a byte-swapped > value. > I traced through label.c and found this code that employs "miswap4()". > Here > I'm way over my head, so maybe someone can quickly fill me in: > > 1. What are volume->mtype_id and volume->ftype_id ? > > 2. Is there any implicit assumptions in this code about the bit-length of > unsigned short and unsigned int? Any implicit assumptions about > endianness? > > > > int midefine_label(mihandle_t volume, int value, const char *name) > { > ... > MI_CHECK_HDF_CALL_RET(result = H5Tenum_insert(volume->mtype_id, name, > &value),"H5Tenum_insert"); > > /* We might have to swap these values before adding them to > * the file type. > * > * COOL! the whole purpose of HDF5 being machine independent is > defeated > here! > */ > if (H5Tget_order(volume->ftype_id) != H5Tget_order(volume->mtype_id)) { > switch (H5Tget_size(volume->ftype_id)) { > case 2: > value = miswap2((unsigned short) value); > break; > case 4: > value = miswap4((unsigned int) value); > break; > } > } > MI_CHECK_HDF_CALL_RET(result = H5Tenum_insert(volume->ftype_id, name, > &value),"H5Tenum_insert"); > > > Thanks, > -Steve > P.S. See trivial fixes in https://github.com/BIC-MNI/libminc/pull/59 > > > _______________________________________________ > 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 steve at sumost.ca Wed Oct 7 02:58:58 2015 From: steve at sumost.ca (Steve M. Robbins) Date: Wed, 07 Oct 2015 01:58:58 -0500 Subject: [MINC-development] test failures: minc2-label-test In-Reply-To: References:

Message-ID: <2064658.1R5WaUXexg@riemann> Thanks, Bert, > My memory here is a little weak, but I think we tried to create parallel > HDF5 types for volumes, such that the "native" type would be in the > machine's byte order, but the file type would always be little endian. My > guess is that the H5Tenum_insert() function does not do any translation of > its argument, so that we needed to swap bytes to keep the label values > consistent on big-endian architectures. Did you write that backwards? The test failures coincide with big-endian machines -- the little endian ones all pass (except mipsel, which fails on a different test). What is even more confusing to me is that the test code's function create_label_image() actually defines the labels and then tests them -- with no failures -- using the same miget_label_value() call that later fails at Line 172. The difference I can see is that the first test operates on a volume created in memory and the second operates on a volume read from disk. Does that mean one is using 'mtype' and the other 'ftype'? [That doesn't appear to be the case -- the code of miget_label_value() seems to use only mtype.] > > Once upon a time, we regularly tested on big-endian machines, but that is > rare these days. It's certainly possible that there are assumptions about > either the byte order or type sizes. > > Do you happen to know the HDF5 version in use? All use 1.8.15, except ppc64 which runs 1.8.13. -Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 811 bytes Desc: This is a digitally signed message part. URL: From bert at phalarope.com Wed Oct 7 12:10:53 2015 From: bert at phalarope.com (Robert D. Vincent) Date: Wed, 7 Oct 2015 12:10:53 -0400 Subject: [MINC-development] test failures: minc2-label-test In-Reply-To: <2064658.1R5WaUXexg@riemann> References:

<2064658.1R5WaUXexg@riemann> Message-ID: Hi Steve, Well, whatever is happening, I can reproduce it on a MIPS64 emulator now, so I should be able to fix it. -bert Thanks, Bert, > My memory here is a little weak, but I think we tried to create parallel > HDF5 types for volumes, such that the "native" type would be in the > machine's byte order, but the file type would always be little endian. My > guess is that the H5Tenum_insert() function does not do any translation of > its argument, so that we needed to swap bytes to keep the label values > consistent on big-endian architectures. Did you write that backwards? The test failures coincide with big-endian machines -- the little endian ones all pass (except mipsel, which fails on a different test). What is even more confusing to me is that the test code's function create_label_image() actually defines the labels and then tests them -- with no failures -- using the same miget_label_value() call that later fails at Line 172. The difference I can see is that the first test operates on a volume created in memory and the second operates on a volume read from disk. Does that mean one is using 'mtype' and the other 'ftype'? [That doesn't appear to be the case -- the code of miget_label_value() seems to use only mtype.] > > Once upon a time, we regularly tested on big-endian machines, but that is > rare these days. It's certainly possible that there are assumptions about > either the byte order or type sizes. > > Do you happen to know the HDF5 version in use? All use 1.8.15, except ppc64 which runs 1.8.13. -Steve _______________________________________________ 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 sean at rogue-research.com Thu Oct 8 11:40:48 2015 From: sean at rogue-research.com (Sean McBride) Date: Thu, 8 Oct 2015 11:40:48 -0400 Subject: [MINC-development] MINC with NetCDF 4.4? In-Reply-To: References: <2204850.mNumVZCYYR@riemann> <3610747.RhXyGNL3Ka@riemann> <20151001143547.1280008432@mail.rogue-research.com> Message-ID: <20151008154048.897392717@mail.rogue-research.com> Great! But might I suggest some better notification of this fact? :) Even on this list, people may not have noticed because the subject here is unrelated. Also, for me anyway, the top 4 relevant google results searching for MINC go here, none of which mention 2.3: Sean On Thu, 1 Oct 2015 10:57:42 -0400, Vladimir S. FONOV said: >it is. > >On Thu, Oct 1, 2015 at 10:35 AM, Sean McBride >wrote: > >> On Sat, 12 Sep 2015 20:38:50 -0500, Steve M. Robbins said: >> >> >> So the minc-tools and libminc projects are now merged and tagged, both >> at >> >> 2.3.00. "Develop" should now be even with "master." >> > >> >Thanks, Bert! The updated libminc and minc-tools are on their way to >> Debian. >> >> So do I understand that minc 2.3 is officially released?!? From robert.d.vincent at mcgill.ca Fri Oct 9 16:43:57 2015 From: robert.d.vincent at mcgill.ca (Robert D. Vincent) Date: Fri, 9 Oct 2015 16:43:57 -0400 Subject: [MINC-development] test failures: minc2-label-test In-Reply-To: References:

<2064658.1R5WaUXexg@riemann> Message-ID: Hi Steve, I just checked in a set of changes that seems to fix the minc2-label-test problem on my emulated MIPS64 system. HDF5 does not provide converters between enumerated types and native types, so we needed to supply one. Also, we were not setting up the mtype_id field correctly when opening label volumes. -bert On Wed, Oct 7, 2015 at 12:10 PM, Robert D. Vincent wrote: > Hi Steve, > > Well, whatever is happening, I can reproduce it on a MIPS64 emulator now, > so I should be able to fix it. > > -bert > Thanks, Bert, > > > My memory here is a little weak, but I think we tried to create parallel > > HDF5 types for volumes, such that the "native" type would be in the > > machine's byte order, but the file type would always be little endian. My > > guess is that the H5Tenum_insert() function does not do any translation > of > > its argument, so that we needed to swap bytes to keep the label values > > consistent on big-endian architectures. > > Did you write that backwards? The test failures coincide with big-endian > machines -- the little endian ones all pass (except mipsel, which fails on > a > different test). > > What is even more confusing to me is that the test code's function > create_label_image() actually defines the labels and then tests them -- > with > no failures -- using the same miget_label_value() call that later fails at > Line 172. The difference I can see is that the first test operates on a > volume created in memory and the second operates on a volume read from > disk. > Does that mean one is using 'mtype' and the other 'ftype'? [That doesn't > appear to be the case -- the code of miget_label_value() seems to use only > mtype.] > > > > > > > Once upon a time, we regularly tested on big-endian machines, but that is > > rare these days. It's certainly possible that there are assumptions about > > either the byte order or type sizes. > > > > Do you happen to know the HDF5 version in use? > > All use 1.8.15, except ppc64 which runs 1.8.13. > > -Steve > > _______________________________________________ > 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 Wed Oct 14 00:04:32 2015 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 14 Oct 2015 14:04:32 +1000 Subject: [MINC-development] Register crash on OSX Message-ID: Hi Bert, I have register consistently crashing on OSX with time series volumes, is this a known issue? It's not a memory thing as the file is only 32k in size. I can send you a test case on this if helps? WOrks fine on Ubuntu. ta a From vladimir.fonov at gmail.com Wed Oct 14 00:38:40 2015 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Wed, 14 Oct 2015 00:38:40 -0400 Subject: [MINC-development] Register crash on OSX In-Reply-To: References: Message-ID: <674194CF-5026-40D7-8AC1-1CD1D11D21E7@gmail.com> Yes, send it please. On Oct 14, 2015, at 12:04 AM, Andrew Janke wrote: > Hi Bert, > > I have register consistently crashing on OSX with time series volumes, > is this a known issue? It's not a memory thing as the file is only 32k > in size. I can send you a test case on this if helps? WOrks fine on > Ubuntu. > > > ta > > > a > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development Best regards, Vladimir S. FONOV ~ v.s.fonov ilmarin.info From robert.d.vincent at mcgill.ca Wed Oct 14 03:47:59 2015 From: robert.d.vincent at mcgill.ca (Robert D. Vincent) Date: Wed, 14 Oct 2015 03:47:59 -0400 Subject: [MINC-development] Register crash on OSX In-Reply-To: <674194CF-5026-40D7-8AC1-1CD1D11D21E7@gmail.com> References: <674194CF-5026-40D7-8AC1-1CD1D11D21E7@gmail.com> Message-ID: What Vlad said. Did you build from the current develop branch? On Oct 14, 2015 12:39 AM, "Vladimir S. FONOV" wrote: > Yes, send it please. > > On Oct 14, 2015, at 12:04 AM, Andrew Janke wrote: > > > Hi Bert, > > > > I have register consistently crashing on OSX with time series volumes, > > is this a known issue? It's not a memory thing as the file is only 32k > > in size. I can send you a test case on this if helps? WOrks fine on > > Ubuntu. > > > > > > ta > > > > > > a > > _______________________________________________ > > MINC-development mailing list > > MINC-development at bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > > Best regards, Vladimir S. FONOV ~ v.s.fonov ilmarin.info > > > > > _______________________________________________ > 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: