From alex at bic.mni.mcgill.ca Mon Jul 30 16:42:12 2007 From: alex at bic.mni.mcgill.ca (Alex Zijdenbos) Date: Mon, 30 Jul 2007 16:42:12 -0400 Subject: [MINC-development] label volumes Message-ID: Hello all, Claude and I have been looking at a problem relating to the handling of label volumes (e.g., atlases) in minc (1.x). There exist a number of atlas files associated with ANIMAL which have intensity scaling in them (real range != voxel range). This causes the labels to appear as floating point values, which can sometime be several decimal points away from the integer label value; this in turn can cause label values to switch over to the adjacent label when manipulated by certain minc tools. There are two issues or questions: 1. How *should* label volumes be constructed? The simple answer I believe is to make sure that the intensity mapping is the identity mapping, so that in effect the real values are equal to the voxel values. 2. How do existing minc tools handle label volumes? It turns out that tools like mincmath and minccalc do not have a -keep_real_range option, and will *always* create slice-specific intensity mappings. This wreaks havoc on label files. A simple solution may be to add a -keep_real_range option to tools like mincmath and minccalc. Now this is all referring to minc1 - at this point I don't have a clear view on how this was dealt with in minc2. But either way, i think mincmath and minccalc should be fixed such as to allow the user to not destroy minc1 label volumes :) Thoughts, comments? -- Alex From smr at sumost.ca Mon Jul 30 20:54:02 2007 From: smr at sumost.ca (Steve M. Robbins) Date: Mon, 30 Jul 2007 19:54:02 -0500 Subject: [MINC-development] label volumes In-Reply-To: References: Message-ID: <20070731005402.GA5928@sumost.ca> On Mon, Jul 30, 2007 at 04:42:12PM -0400, Alex Zijdenbos wrote: > Hello all, > > Claude and I have been looking at a problem relating to the handling > of label volumes (e.g., atlases) in minc (1.x). There exist a number > of atlas files associated with ANIMAL which have intensity scaling in > them (real range != voxel range). This causes the labels to appear as > floating point values, which can sometime be several decimal points > away from the integer label value; this in turn can cause label values > to switch over to the adjacent label when manipulated by certain minc > tools. > > There are two issues or questions: > > 1. How *should* label volumes be constructed? > > The simple answer I believe is to make sure that the intensity > mapping is the identity mapping, so that in effect the real values are > equal to the voxel values. I think that's right. In fact, I have a vague recollection (and vague notes from 2003) that one can "fix" a byte label file using: mincreshape -image_range 0 255 bad.mnc good.mnc Regards, -Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.bic.mni.mcgill.ca/pipermail/minc-development/attachments/20070730/f77a71ba/attachment.bin From a.janke at gmail.com Tue Jul 31 09:45:12 2007 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 31 Jul 2007 23:45:12 +1000 Subject: [MINC-development] label volumes In-Reply-To: References: Message-ID: > Claude and I have been looking at a problem relating to the handling > of label volumes (e.g., atlases) in minc (1.x). There exist a number > of atlas files associated with ANIMAL which have intensity scaling in > them (real range != voxel range). This causes the labels to appear as > floating point values, which can sometime be several decimal points > away from the integer label value; this in turn can cause label values > to switch over to the adjacent label when manipulated by certain minc > tools. > > There are two issues or questions: > 1. How *should* label volumes be constructed? > > The simple answer I believe is to make sure that the intensity > mapping is the identity mapping, so that in effect the real values are > equal to the voxel values. Correct, the way I have always done this is do a mincreshape to files that are misbehaving.. mincreshape -image_range 0 255 -valid_range 0 255 ... If you are dealing with a byte file. The problem occurs in that the notion of a label volume really is just that in MINC, there is no real support for it. There is however support for it in volume_io. Take a look at the end part of the code in mincmorph for one example of how you can make sure that things are "right" in C code. > 2. How do existing minc tools handle label volumes? Not all that well if only because there are no easy heuristics that you can use to figure out if the input file is indeed a "label" volume and there is no special tag for this. > It turns out that tools like mincmath and minccalc do not have a > -keep_real_range option, and will *always* create slice-specific > intensity mappings. This wreaks havoc on label files. A simple > solution may be to add a -keep_real_range option to tools like > mincmath and minccalc. Correct, this really is true of not just these two in isolation but rather any program that uses voxel_loop. Still I dont think that there is a better way in code to do it without rewriting vast swathes of code in each of the MINC tools with a big "if(label)" at the top. > Thoughts, comments? Well my approach is as such. 1. labels are bad. (personal view, I much prefer to stick with probabilistic maps!) 2. Use float. It is the only way that you can guarantee that you are getting what you (think you) want. 3. Use byte and religiously reset the range after each operation. It is for these reasons that tools like mincstats have the options like -mask_binvalue you can generally be sure that +/- 0.5 will work.. ;) This at least was always Peters impression of how a label volume should work. a From jason at bic.mni.mcgill.ca Tue Jul 31 09:41:51 2007 From: jason at bic.mni.mcgill.ca (Jason Lerch) Date: Tue, 31 Jul 2007 09:41:51 -0400 Subject: [MINC-development] label volumes In-Reply-To: References: Message-ID: <46AF3C1F.2030405@bic.mni.mcgill.ca> MINC2 has explicit support for label volumes, right? At what point should the various MINC tools take advantage of such features, even if that breaks backwards compatibility? (see http://www.bic.mni.mcgill.ca/software/minc/minc2_format/node23.html - though I don't know if this has actually been implemented yet) Jason Andrew Janke wrote: >> Claude and I have been looking at a problem relating to the handling >> of label volumes (e.g., atlases) in minc (1.x). There exist a number >> of atlas files associated with ANIMAL which have intensity scaling in >> them (real range != voxel range). This causes the labels to appear as >> floating point values, which can sometime be several decimal points >> away from the integer label value; this in turn can cause label values >> to switch over to the adjacent label when manipulated by certain minc >> tools. >> >> There are two issues or questions: >> 1. How *should* label volumes be constructed? >> >> The simple answer I believe is to make sure that the intensity >> mapping is the identity mapping, so that in effect the real values are >> equal to the voxel values. >> > > Correct, the way I have always done this is do a mincreshape to files > that are misbehaving.. > > mincreshape -image_range 0 255 -valid_range 0 255 ... > > If you are dealing with a byte file. The problem occurs in that the > notion of a label volume really is just that in MINC, there is no real > support for it. There is however support for it in volume_io. > > Take a look at the end part of the code in mincmorph for one example > of how you can make sure that things are "right" in C code. > > >> 2. How do existing minc tools handle label volumes? >> > > Not all that well if only because there are no easy heuristics that > you can use to figure out if the input file is indeed a "label" volume > and there is no special tag for this. > > >> It turns out that tools like mincmath and minccalc do not have a >> -keep_real_range option, and will *always* create slice-specific >> intensity mappings. This wreaks havoc on label files. A simple >> solution may be to add a -keep_real_range option to tools like >> mincmath and minccalc. >> > > Correct, this really is true of not just these two in isolation but > rather any program that uses voxel_loop. Still I dont think that > there is a better way in code to do it without rewriting vast swathes > of code in each of the MINC tools with a big "if(label)" at the top. > > >> Thoughts, comments? >> > > Well my approach is as such. > > 1. labels are bad. (personal view, I much prefer to stick with > probabilistic maps!) > > 2. Use float. It is the only way that you can guarantee that you > are getting what you (think you) want. > > 3. Use byte and religiously reset the range after each operation. > > It is for these reasons that tools like mincstats have the options > like -mask_binvalue you can generally be sure that +/- 0.5 will work.. > ;) This at least was always Peters impression of how a label volume > should work. > > > a > _______________________________________________ > 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 Tue Jul 31 09:53:19 2007 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 31 Jul 2007 23:53:19 +1000 Subject: [MINC-development] label volumes In-Reply-To: <46AF3C1F.2030405@bic.mni.mcgill.ca> References: <46AF3C1F.2030405@bic.mni.mcgill.ca> Message-ID: Correct Forgot to mention that bit (thanks) however this would require someone to write something using the minc2 API! :) The only thing that I know of so far that uses this feature is leila's MINC2 ITK binding. a On 7/31/07, Jason Lerch wrote: > MINC2 has explicit support for label volumes, right? At what point > should the various MINC tools take advantage of such features, even if > that breaks backwards compatibility? > > (see http://www.bic.mni.mcgill.ca/software/minc/minc2_format/node23.html > - though I don't know if this has actually been implemented yet) > > Jason > > Andrew Janke wrote: > >> Claude and I have been looking at a problem relating to the handling > >> of label volumes (e.g., atlases) in minc (1.x). There exist a number > >> of atlas files associated with ANIMAL which have intensity scaling in > >> them (real range != voxel range). This causes the labels to appear as > >> floating point values, which can sometime be several decimal points > >> away from the integer label value; this in turn can cause label values > >> to switch over to the adjacent label when manipulated by certain minc > >> tools. > >> > >> There are two issues or questions: > >> 1. How *should* label volumes be constructed? > >> > >> The simple answer I believe is to make sure that the intensity > >> mapping is the identity mapping, so that in effect the real values are > >> equal to the voxel values. > >> > > > > Correct, the way I have always done this is do a mincreshape to files > > that are misbehaving.. > > > > mincreshape -image_range 0 255 -valid_range 0 255 ... > > > > If you are dealing with a byte file. The problem occurs in that the > > notion of a label volume really is just that in MINC, there is no real > > support for it. There is however support for it in volume_io. > > > > Take a look at the end part of the code in mincmorph for one example > > of how you can make sure that things are "right" in C code. > > > > > >> 2. How do existing minc tools handle label volumes? > >> > > > > Not all that well if only because there are no easy heuristics that > > you can use to figure out if the input file is indeed a "label" volume > > and there is no special tag for this. > > > > > >> It turns out that tools like mincmath and minccalc do not have a > >> -keep_real_range option, and will *always* create slice-specific > >> intensity mappings. This wreaks havoc on label files. A simple > >> solution may be to add a -keep_real_range option to tools like > >> mincmath and minccalc. > >> > > > > Correct, this really is true of not just these two in isolation but > > rather any program that uses voxel_loop. Still I dont think that > > there is a better way in code to do it without rewriting vast swathes > > of code in each of the MINC tools with a big "if(label)" at the top. > > > > > >> Thoughts, comments? > >> > > > > Well my approach is as such. > > > > 1. labels are bad. (personal view, I much prefer to stick with > > probabilistic maps!) > > > > 2. Use float. It is the only way that you can guarantee that you > > are getting what you (think you) want. > > > > 3. Use byte and religiously reset the range after each operation. > > > > It is for these reasons that tools like mincstats have the options > > like -mask_binvalue you can generally be sure that +/- 0.5 will work.. > > ;) This at least was always Peters impression of how a label volume > > should work. > > > > > > a > > _______________________________________________ > > 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 > -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From jason at bic.mni.mcgill.ca Tue Jul 31 09:47:52 2007 From: jason at bic.mni.mcgill.ca (Jason Lerch) Date: Tue, 31 Jul 2007 09:47:52 -0400 Subject: [MINC-development] label volumes In-Reply-To: References: Message-ID: <46AF3D88.2020009@bic.mni.mcgill.ca> Andrew Janke wrote: > Correct > > Forgot to mention that bit (thanks) > > however this would require someone to write something using the minc2 > API! :) The only thing that I know of so far that uses this feature is > leila's MINC2 ITK binding. > Don't forget RMINC! Somewhere on my todo list is writing a tutorial on programming with the MINC2 API ... sometime this century, I promise, unless someone beats me to it. But that still begs the question: has MINC2 been accepted enough yet that the MINC tools can slowly begin to branch off from backwards compatibility with MINC1? Or would that be premature? Jason > a > > On 7/31/07, Jason Lerch wrote: > >> MINC2 has explicit support for label volumes, right? At what point >> should the various MINC tools take advantage of such features, even if >> that breaks backwards compatibility? >> >> (see http://www.bic.mni.mcgill.ca/software/minc/minc2_format/node23.html >> - though I don't know if this has actually been implemented yet) >> >> Jason >> >> Andrew Janke wrote: >> >>>> Claude and I have been looking at a problem relating to the handling >>>> of label volumes (e.g., atlases) in minc (1.x). There exist a number >>>> of atlas files associated with ANIMAL which have intensity scaling in >>>> them (real range != voxel range). This causes the labels to appear as >>>> floating point values, which can sometime be several decimal points >>>> away from the integer label value; this in turn can cause label values >>>> to switch over to the adjacent label when manipulated by certain minc >>>> tools. >>>> >>>> There are two issues or questions: >>>> 1. How *should* label volumes be constructed? >>>> >>>> The simple answer I believe is to make sure that the intensity >>>> mapping is the identity mapping, so that in effect the real values are >>>> equal to the voxel values. >>>> >>>> >>> Correct, the way I have always done this is do a mincreshape to files >>> that are misbehaving.. >>> >>> mincreshape -image_range 0 255 -valid_range 0 255 ... >>> >>> If you are dealing with a byte file. The problem occurs in that the >>> notion of a label volume really is just that in MINC, there is no real >>> support for it. There is however support for it in volume_io. >>> >>> Take a look at the end part of the code in mincmorph for one example >>> of how you can make sure that things are "right" in C code. >>> >>> >>> >>>> 2. How do existing minc tools handle label volumes? >>>> >>>> >>> Not all that well if only because there are no easy heuristics that >>> you can use to figure out if the input file is indeed a "label" volume >>> and there is no special tag for this. >>> >>> >>> >>>> It turns out that tools like mincmath and minccalc do not have a >>>> -keep_real_range option, and will *always* create slice-specific >>>> intensity mappings. This wreaks havoc on label files. A simple >>>> solution may be to add a -keep_real_range option to tools like >>>> mincmath and minccalc. >>>> >>>> >>> Correct, this really is true of not just these two in isolation but >>> rather any program that uses voxel_loop. Still I dont think that >>> there is a better way in code to do it without rewriting vast swathes >>> of code in each of the MINC tools with a big "if(label)" at the top. >>> >>> >>> >>>> Thoughts, comments? >>>> >>>> >>> Well my approach is as such. >>> >>> 1. labels are bad. (personal view, I much prefer to stick with >>> probabilistic maps!) >>> >>> 2. Use float. It is the only way that you can guarantee that you >>> are getting what you (think you) want. >>> >>> 3. Use byte and religiously reset the range after each operation. >>> >>> It is for these reasons that tools like mincstats have the options >>> like -mask_binvalue you can generally be sure that +/- 0.5 will work.. >>> ;) This at least was always Peters impression of how a label volume >>> should work. >>> >>> >>> a >>> _______________________________________________ >>> 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 a.janke at gmail.com Tue Jul 31 09:58:55 2007 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 31 Jul 2007 23:58:55 +1000 Subject: [MINC-development] label volumes In-Reply-To: References: Message-ID: > 2. Use float. It is the only way that you can guarantee that you > are getting what you (think you) want. I should clarify this. By this I mean, use float during processing and then convert back to whatever datatype you were using originally, I suspect that in most cases, this would be byte. At this stage, you should then possibly rerun mincreshape/mincmath with one of the fiddles that have been described in this thread Just to be sure. a From a.janke at gmail.com Tue Jul 31 10:02:43 2007 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 1 Aug 2007 00:02:43 +1000 Subject: [MINC-development] label volumes In-Reply-To: <46AF3D88.2020009@bic.mni.mcgill.ca> References: <46AF3D88.2020009@bic.mni.mcgill.ca> Message-ID: > > however this would require someone to write something using the minc2 > > API! :) The only thing that I know of so far that uses this feature is > > leila's MINC2 ITK binding. > > > Don't forget RMINC! seems that I really am forgetful tonight... :) If you do get to this. Please consider adding this to the MINC wikibooks page here: http://en.wikibooks.org/wiki/MINC This is where I have been putting any new documentation that I write. > But that still begs the question: has MINC2 been accepted enough yet > that the MINC tools can slowly begin to branch off from backwards > compatibility with MINC1? Or would that be premature? I think this comes down to the fact that at this stage there is no new tool needed by anybody. :) And if there is, I suspect that they would use something like minc_simple.h to do it. (well at least I hope they would!) a From jason at bic.mni.mcgill.ca Tue Jul 31 10:00:41 2007 From: jason at bic.mni.mcgill.ca (Jason Lerch) Date: Tue, 31 Jul 2007 10:00:41 -0400 Subject: [MINC-development] label volumes In-Reply-To: References: Message-ID: <46AF4089.3050105@bic.mni.mcgill.ca> Andrew Janke wrote: >>> however this would require someone to write something using the minc2 >>> API! :) The only thing that I know of so far that uses this feature is >>> leila's MINC2 ITK binding. >>> >>> >> Don't forget RMINC! >> > > seems that I really am forgetful tonight... :) If you do get to > this. Please consider adding this to the MINC wikibooks page here: > > http://en.wikibooks.org/wiki/MINC > > This is where I have been putting any new documentation that I write. > > Sure. >> But that still begs the question: has MINC2 been accepted enough yet >> that the MINC tools can slowly begin to branch off from backwards >> compatibility with MINC1? Or would that be premature? >> > > I think this comes down to the fact that at this stage there is no new > tool needed by anybody. :) And if there is, I suspect that they would > use something like minc_simple.h to do it. (well at least I hope they > would!) > I'm not talking about new tools - and I think this entire thread sort of disproves your assertion. Many MINC tools would benefit from treating label volumes differently than regular volumes. mincmath and minccalc could treat complex numbers (for which there is also support in MINC2) correctly. And so on. Nothing essential, as these issues can be circumnavigated, yet doing so often results in unnecessary and ugly hacks. Jason > > a > _______________________________________________ > 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 Tue Jul 31 10:18:37 2007 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 1 Aug 2007 00:18:37 +1000 Subject: [MINC-development] label volumes In-Reply-To: <46AF4089.3050105@bic.mni.mcgill.ca> References: <46AF4089.3050105@bic.mni.mcgill.ca> Message-ID: > > I think this comes down to the fact that at this stage there is no new > > tool needed by anybody. :) And if there is, I suspect that they would > > use something like minc_simple.h to do it. (well at least I hope they > > would!) > > > I'm not talking about new tools - and I think this entire thread sort of > disproves your assertion. Many MINC tools would benefit from treating > label volumes differently than regular volumes. mincmath and minccalc > could treat complex numbers (for which there is also support in MINC2) > correctly. And so on. Nothing essential, as these issues can be > circumnavigated, yet doing so often results in unnecessary and ugly hacks. I was waiting until someone was going to pull the MINC one is broken card :) Yes, of course, in these cases, there is a lot of work that could be done on the core programmes of MINC. Unfortunately, I have been spending most of my spare time as of late working on porting some existing MINC tools such as N3 and mni_autoreg to a clean MINC1/2 build first. Once I have managed to achieve this, then I can worry about actually porting them to MINC 2! :) So if someone is boored. I would suggest that a good project would be to implement voxel loop in MINC2 native. a From claude at bic.mni.mcgill.ca Tue Jul 31 10:21:55 2007 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Tue, 31 Jul 2007 10:21:55 -0400 (EDT) Subject: [MINC-development] label volumes References: Message-ID: <200707311421.l6VELtkf919794@yorick.bic.mni.mcgill.ca> Hi, > Correct, the way I have always done this is do a mincreshape to files > that are misbehaving.. > > mincreshape -image_range 0 255 -valid_range 0 255 ... This does not correct the problem if the min/max are set per slice and that they vary for each slice. Once a label file has been "decimalized" by the ranges, there is no way to recover the original values by the above operation. For example: Take a label = 10, with voxel value of 10 if there is a one-to-one correspondence with voxel range and image real. Now assume that the slice has a min=0 and a max=61. That's 62 values over a 256 range, so each bin has a value of 62/256=0.2421875. The label 10 will be best approximated by the 41th bin with value 41*0.2421 = 9.9297. (There might be some ajustment to do if the values are range-centered, but my argument is still valid.) Setting back max=255 for the slice will not recover the original label 10. Now keep doing this repeatedly (minccalc, mincmath, etc) and some labels will change value (10 drifts to 9, for example). The option -keep_real_range in mincresample does the trick as the global min/max of the image are applied to each slice, thus not changing the internal voxel values. minccalc (which uses voxel_loop as AJ pointed out) does not. Despite being ugly, I also think that working in floats might be the best compromise (on the temporary files, of course). Claude From a.janke at gmail.com Tue Jul 31 10:28:22 2007 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 1 Aug 2007 00:28:22 +1000 Subject: [MINC-development] label volumes In-Reply-To: <200707311421.l6VELtkf919794@yorick.bic.mni.mcgill.ca> References: <200707311421.l6VELtkf919794@yorick.bic.mni.mcgill.ca> Message-ID: On 8/1/07, Claude LEPAGE wrote: > Hi, > > > Correct, the way I have always done this is do a mincreshape to files > > that are misbehaving.. > > > > mincreshape -image_range 0 255 -valid_range 0 255 ... > > This does not correct the problem if the min/max are set per slice and that > they vary for each slice. Once a label file has been "decimalized" by the > ranges, there is no way to recover the original values by the above > operation. > > For example: > Take a label = 10, with voxel value of 10 if there is a one-to-one > correspondence with voxel range and image real. Now assume that the slice > has a min=0 and a max=61. That's 62 values over a 256 range, so each bin > has a value of 62/256=0.2421875. The label 10 will be best approximated > by the 41th bin with value 41*0.2421 = 9.9297. (There might be some > ajustment to do if the values are range-centered, but my argument is still > valid.) Setting back max=255 for the slice will not recover the original > label 10. Now keep doing this repeatedly (minccalc, mincmath, etc) and > some labels will change value (10 drifts to 9, for example). > > The option -keep_real_range in mincresample does the trick as the global > min/max of the image are applied to each slice, thus not changing the > internal voxel values. minccalc (which uses voxel_loop as AJ pointed out) > does not. > > Despite being ugly, I also think that working in floats might be the best > compromise (on the temporary files, of course). Ooops, sorry yes, that "use mincreshape" comment of mine should only be used as Claude points out if you are using floats in between as I usually do... But if what you are asking amounts to merely amounts to setting the range for each slice/chunk with some pre-determined number is this not what: minccalc -range 0 255 ... does? If not I have always suspected that this was the intended purpose of this option. Again, if it is not I do not see why we cannot override this functionality within voxel whoop and have it do exactly as you are saying and set the maximum and minimum values for each slice. Can anyone see any problems with doing this? a From alex at bic.mni.mcgill.ca Tue Jul 31 11:10:09 2007 From: alex at bic.mni.mcgill.ca (Alex Zijdenbos) Date: Tue, 31 Jul 2007 11:10:09 -0400 Subject: [MINC-development] label volumes In-Reply-To: <46AF4089.3050105@bic.mni.mcgill.ca> References: <46AF4089.3050105@bic.mni.mcgill.ca> Message-ID: > >> But that still begs the question: has MINC2 been accepted enough yet > >> that the MINC tools can slowly begin to branch off from backwards > >> compatibility with MINC1? Or would that be premature? > >> > > > > I think this comes down to the fact that at this stage there is no new > > tool needed by anybody. :) And if there is, I suspect that they would > > use something like minc_simple.h to do it. (well at least I hope they > > would!) > > > I'm not talking about new tools - and I think this entire thread sort of > disproves your assertion. Many MINC tools would benefit from treating > label volumes differently than regular volumes. mincmath and minccalc > could treat complex numbers (for which there is also support in MINC2) > correctly. And so on. Nothing essential, as these issues can be > circumnavigated, yet doing so often results in unnecessary and ugly hacks. I would agree. I've been handling label volumes for a looong time now and had gotten somewhat used to the extra mincreshape call to invoke at the end, but it's not terribly intuitive (that's called 'understatement') to anybody who may not be too familiar with this. But what i was not aware of is that voxel-loop based code *always* generates slice-specific ranges which really muck up label volumes. I think at the very least a user should be able to force the intensity range calculation to be turned off. Which in turn begs the question why the set of 'standard' options is not uniform across all minc tools. Why would I have to know to use mincreshape to fix the ranges, while really i don't want to reshape anything? It seems to me the same set of range options should/could be present in minc*. This way at least a simple advice to anybody manipulating label volumes, would be to always make add the right range-preserving options to the tool they run. But i agree with Jason - it would be much better still to properly define a label datatype and teach all minc tools how to handle them the Right Way. Better, but obviously much more involved. -- A From vladimir.fonov at gmail.com Tue Jul 31 11:20:46 2007 From: vladimir.fonov at gmail.com (Vladimir FONOV) Date: Tue, 31 Jul 2007 11:20:46 -0400 Subject: [MINC-development] label volumes In-Reply-To: References: <46AF4089.3050105@bic.mni.mcgill.ca> Message-ID: Hello, > > I would agree. I've been handling label volumes for a looong time now > and had gotten somewhat used to the extra mincreshape call to invoke > at the end, but it's not terribly intuitive (that's called > 'understatement') to anybody who may not be too familiar with this. > But what i was not aware of is that voxel-loop based code *always* > generates slice-specific ranges which really muck up label volumes. I > think at the very least a user should be able to force the intensity > range calculation to be turned off. > > Which in turn begs the question why the set of 'standard' options is > not uniform across all minc tools. Why would I have to know to use > mincreshape to fix the ranges, while really i don't want to reshape > anything? It seems to me the same set of range options should/could be > present in minc*. This way at least a simple advice to anybody > manipulating label volumes, would be to always make add the right > range-preserving options to the tool they run. > > But i agree with Jason - it would be much better still to properly > define a label datatype and teach all minc tools how to handle them > the Right Way. Better, but obviously much more involved. How about introducing some special header flag "don't scale values unless told so" ? -- Best regards, Vladimir S. Fonov ~ vladimir.fonov gmail.com From vladimir.fonov at gmail.com Tue Jul 31 11:20:46 2007 From: vladimir.fonov at gmail.com (Vladimir FONOV) Date: Tue, 31 Jul 2007 11:20:46 -0400 Subject: [MINC-development] label volumes In-Reply-To: References: <46AF4089.3050105@bic.mni.mcgill.ca> Message-ID: Hello, > > I would agree. I've been handling label volumes for a looong time now > and had gotten somewhat used to the extra mincreshape call to invoke > at the end, but it's not terribly intuitive (that's called > 'understatement') to anybody who may not be too familiar with this. > But what i was not aware of is that voxel-loop based code *always* > generates slice-specific ranges which really muck up label volumes. I > think at the very least a user should be able to force the intensity > range calculation to be turned off. > > Which in turn begs the question why the set of 'standard' options is > not uniform across all minc tools. Why would I have to know to use > mincreshape to fix the ranges, while really i don't want to reshape > anything? It seems to me the same set of range options should/could be > present in minc*. This way at least a simple advice to anybody > manipulating label volumes, would be to always make add the right > range-preserving options to the tool they run. > > But i agree with Jason - it would be much better still to properly > define a label datatype and teach all minc tools how to handle them > the Right Way. Better, but obviously much more involved. How about introducing some special header flag "don't scale values unless told so" ? -- Best regards, Vladimir S. Fonov ~ vladimir.fonov gmail.com From a.janke at gmail.com Tue Jul 31 22:40:57 2007 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 1 Aug 2007 12:40:57 +1000 Subject: [MINC-development] label volumes In-Reply-To: References: <46AF4089.3050105@bic.mni.mcgill.ca> Message-ID: > How about introducing some special header flag "don't scale values > unless told so" ? Sure this could be done, but whoever implements it had best also make sure it works with all the tools..... :) Not that I am trying to stop anyone from doing it. a