From jordigh at octave.org Tue Jan 8 15:25:28 2013 From: jordigh at octave.org (=?UTF-8?Q?Jordi_Guti=C3=A9rrez_Hermoso?=) Date: Tue, 8 Jan 2013 15:25:28 -0500 Subject: [MINC-development] The handsome gentleman at https://github.com/BIC-MNI Message-ID: I have no criticisms of the aesthetic merits of the dashing young man greeting us at this address: https://github.com/BIC-MNI However, could I kindly request that if this is the "official" repository in some way have a more encompassing face? A logo, perhaps? - Jordi G. H. From vladimir.fonov at gmail.com Tue Jan 8 15:33:32 2013 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Tue, 08 Jan 2013 15:33:32 -0500 Subject: [MINC-development] The handsome gentleman at https://github.com/BIC-MNI In-Reply-To: References: Message-ID: <50EC829C.9040209@gmail.com> Well, looks like you have enough energy to write funny emails to the list, but not enough to do anything useful w.r.t. minc development? On 13-01-08 03:25 PM, Jordi Guti?rrez Hermoso wrote: > I have no criticisms of the aesthetic merits of the dashing young man > greeting us at this address: > > https://github.com/BIC-MNI > > However, could I kindly request that if this is the "official" > repository in some way have a more encompassing face? A logo, perhaps? -- Best regards, Vladimir S. FONOV ~ vladimir.fonov gmail.com From vladimir.fonov at gmail.com Thu Jan 17 15:36:16 2013 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Thu, 17 Jan 2013 15:36:16 -0500 Subject: [MINC-development] MINC2 file with floating-point voxels and slice normalization Message-ID: Hello Everybody, I came across a following problem - I have got a minc volume with float type, but with image_max and image_min specifying range for each slice. It turns out that there is actually no normalization performed in the actual voxel values (as one would expect) and MINC1 api while dealing with this file forks properly. Unfortunately, MINC2 api checks if the image_max and image_min variables have dimension more then 1 and if it is the case, the inter-slice normalization is enabled (i.e see https://github.com/BIC-MNI/libminc/blob/master/libsrc2/volume.c#L1122 ). So, the question to MINC founding fathers - should MINC2 api be modified to make sure that no inter-slice normalization happens when voxel type is float, or is there any some other considerations? -- Best regards, Vladimir S. Fonov ~ vladimir fonov gmail com -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.janke at gmail.com Thu Jan 17 18:02:30 2013 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 18 Jan 2013 09:02:30 +1000 Subject: [MINC-development] MINC2 file with floating-point voxels and slice normalization In-Reply-To: References: Message-ID: Hi Vladimir, On 18 January 2013 06:36, Vladimir S. FONOV wrote: > I came across a following problem - I have got a minc volume with float > type, but with image_max and image_min specifying range for each slice. > > It turns out that there is actually no normalization performed in the actual > voxel values (as one would expect) and MINC1 api while dealing with this > file forks properly. > > Unfortunately, MINC2 api checks if the image_max and image_min variables > have dimension more then 1 and if it is the case, the inter-slice > normalization is enabled (i.e see > https://github.com/BIC-MNI/libminc/blob/master/libsrc2/volume.c#L1122 ). Ack! good catch. > So, the question to MINC founding fathers - should MINC2 api be modified to > make sure that no inter-slice normalization happens when voxel type is > float, or is there any some other considerations? My understanding was that float/double MINC files don't do slice normalisation as it doesn't make sense. Float+Double filetypes specify a precision for your datatype, the range is irrelevant. So yes this should be removed. It was my understanding that if you convert a file to float/double using MINC tools the slice max/mins are discarded. I have taken the liberty of CC'ing Peter on this just to make sure, trust it isn't too much of an intrusion 10 years or so down the track... a From vladimir.fonov at gmail.com Thu Jan 17 18:09:20 2013 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Thu, 17 Jan 2013 18:09:20 -0500 Subject: [MINC-development] MINC2 file with floating-point voxels and slice normalization In-Reply-To: References:

Message-ID: Hello, On Thu, Jan 17, 2013 at 6:02 PM, Andrew Janke wrote: > Hi Vladimir, > > On 18 January 2013 06:36, Vladimir S. FONOV > wrote: > > I came across a following problem - I have got a minc volume with float > > type, but with image_max and image_min specifying range for each slice. > > > > It turns out that there is actually no normalization performed in the > actual > > voxel values (as one would expect) and MINC1 api while dealing with this > > file forks properly. > > > > Unfortunately, MINC2 api checks if the image_max and image_min variables > > have dimension more then 1 and if it is the case, the inter-slice > > normalization is enabled (i.e see > > https://github.com/BIC-MNI/libminc/blob/master/libsrc2/volume.c#L1122 ). > > Ack! good catch. > I made a hack which fixes the problem in minc_lite: https://github.com/BIC-MNI/libminc/blob/minc_lite/libsrc2/hyper.c#L776 and https://github.com/BIC-MNI/libminc/blob/minc_lite/libsrc2/hyper.c#L1099 > > So, the question to MINC founding fathers - should MINC2 api be modified > to > > make sure that no inter-slice normalization happens when voxel type is > > float, or is there any some other considerations? > > My understanding was that float/double MINC files don't do slice > normalisation as it doesn't make sense. Float+Double filetypes specify > a precision for your datatype, the range is irrelevant. So yes this > should be removed. It was my understanding that if you convert a file > to float/double using MINC tools the slice max/mins are discarded. > Nope, they are not - just try running mincreshape -float on a file with slice normalization. -- Best regards, Vladimir S. Fonov ~ vladimir fonov gmail com -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.neelin at gmail.com Thu Jan 17 20:16:45 2013 From: peter.neelin at gmail.com (Peter Neelin) Date: Thu, 17 Jan 2013 20:16:45 -0500 Subject: [MINC-development] MINC2 file with floating-point voxels and slice normalization In-Reply-To: References:

Message-ID: On Jan 17, 2013 6:03 PM, "Andrew Janke" wrote: > On 18 January 2013 06:36, Vladimir S. FONOV wrote: > > So, the question to MINC founding fathers - should MINC2 api be modified to > > make sure that no inter-slice normalization happens when voxel type is > > float, or is there any some other considerations? > > My understanding was that float/double MINC files don't do slice > normalisation as it doesn't make sense. Float+Double filetypes specify > a precision for your datatype, the range is irrelevant. So yes this > should be removed. It was my understanding that if you convert a file Andrew is right. Remember that in the original design of minc, there were only real numbers (conceptually) - storing as bytes or shorts has always just been a representational trick for fixed point. The real values are rescaled to fit in the integer range, potentially on a slice-by-slice basis, preserving the scaling info in the image max/min. Floating-point representations do not need any rescaling to fit, so none is done. Normalization on read does not make sense since the values are already normalized. > to float/double using MINC tools the slice max/mins are discarded. In the float/double case the slice max/mins are preserved for informational purposes (it is not necessary to read the whole image to know the range). Peter -- Peter Neelin peter.neelin at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.janke at gmail.com Thu Jan 17 20:31:15 2013 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 18 Jan 2013 11:31:15 +1000 Subject: [MINC-development] MINC2 file with floating-point voxels and slice normalization In-Reply-To: References:

Message-ID: Peter wrote: > Remember that in the original design of minc, there were > only real numbers (conceptually) - storing as bytes or shorts has always > just been a representational trick for fixed point. The real values are > rescaled to fit in the integer range, potentially on a slice-by-slice basis, > preserving the scaling info in the image max/min. Floating-point > representations do not need any rescaling to fit, so none is done. Thanks for the info Peter. >> to float/double using MINC tools the slice max/mins are discarded. > > In the float/double case the slice max/mins are preserved for informational > purposes (it is not necessary to read the whole image to know the range). OK, good to know. Vlad, I vote that we discard this information on conversion to float/double in MINC2/minc_lite. I'm not sure if still having this information around was the reason why scaling was implemented in MINC2 but it might have contributed. I see no reason to keep it and add to any confusion. ta a From jgsled at phenogenomics.ca Fri Jan 18 10:46:32 2013 From: jgsled at phenogenomics.ca (John G. Sled) Date: Fri, 18 Jan 2013 10:46:32 -0500 Subject: [MINC-development] MINC2 file with floating-point voxels and slice normalization In-Reply-To: References: Message-ID: <50F96E58.7050401@phenogenomics.ca> Since we are voting ... I vote for keeping Peter's design where the slice min / max is maintained for informational purposes when the underlying data type is float. This allows visualization tools to make a sensible initial choice for the window and level. John On 13-01-17 8:31 PM, Andrew Janke wrote: > Peter wrote: >> Remember that in the original design of minc, there were >> only real numbers (conceptually) - storing as bytes or shorts has always >> just been a representational trick for fixed point. The real values are >> rescaled to fit in the integer range, potentially on a slice-by-slice basis, >> preserving the scaling info in the image max/min. Floating-point >> representations do not need any rescaling to fit, so none is done. > Thanks for the info Peter. > >>> to float/double using MINC tools the slice max/mins are discarded. >> In the float/double case the slice max/mins are preserved for informational >> purposes (it is not necessary to read the whole image to know the range). > OK, good to know. Vlad, I vote that we discard this information on > conversion to float/double in MINC2/minc_lite. I'm not sure if still > having this information around was the reason why scaling was > implemented in MINC2 but it might have contributed. > > I see no reason to keep it and add to any confusion. > > ta > > > 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 Fri Jan 18 16:48:21 2013 From: a.janke at gmail.com (Andrew Janke) Date: Sat, 19 Jan 2013 07:48:21 +1000 Subject: [MINC-development] MINC2 file with floating-point voxels and slice normalization In-Reply-To: <50F96E58.7050401@phenogenomics.ca> References:

<50F96E58.7050401@phenogenomics.ca> Message-ID: Isn't this done by the valid min and max for the file? I'll have to look at the register and Display code again. a On 19/01/2013 1:47 AM, "John G. Sled" wrote: > > Since we are voting ... I vote for keeping Peter's design where the slice > min / max is maintained for informational purposes when the underlying data > type is float. This allows visualization tools to make a sensible initial > choice for the window and level. > > John > > > > On 13-01-17 8:31 PM, Andrew Janke wrote: > >> Peter wrote: >> >>> Remember that in the original design of minc, there were >>> only real numbers (conceptually) - storing as bytes or shorts has always >>> just been a representational trick for fixed point. The real values are >>> rescaled to fit in the integer range, potentially on a slice-by-slice >>> basis, >>> preserving the scaling info in the image max/min. Floating-point >>> representations do not need any rescaling to fit, so none is done. >>> >> Thanks for the info Peter. >> >> to float/double using MINC tools the slice max/mins are discarded. >>>> >>> In the float/double case the slice max/mins are preserved for >>> informational >>> purposes (it is not necessary to read the whole image to know the range). >>> >> OK, good to know. Vlad, I vote that we discard this information on >> conversion to float/double in MINC2/minc_lite. I'm not sure if still >> having this information around was the reason why scaling was >> implemented in MINC2 but it might have contributed. >> >> I see no reason to keep it and add to any confusion. >> >> ta >> >> >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.neelin at gmail.com Sat Jan 19 00:06:19 2013 From: peter.neelin at gmail.com (Peter Neelin) Date: Sat, 19 Jan 2013 00:06:19 -0500 Subject: [MINC-development] MINC2 file with floating-point voxels and slice normalization In-Reply-To: References:

<50F96E58.7050401@phenogenomics.ca> Message-ID: On Jan 18, 2013 4:48 PM, "Andrew Janke" wrote: > Isn't this done by the valid min and max for the file? I'll have to look at the register and Display code again. The valid min/max give the range for the entire file. The image min/max variables allow it to be specified by image (or frame, or other dimensions of interest). Peter -- Peter Neelin peter.neelin at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.fonov at gmail.com Sat Jan 19 09:13:28 2013 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Sat, 19 Jan 2013 09:13:28 -0500 Subject: [MINC-development] MINC2 file with floating-point voxels and slice normalization In-Reply-To: References:

<50F96E58.7050401@phenogenomics.ca> Message-ID: Hello, I think these relics of the past have to go, right now it takes much more time to extract the right slice from the dataset (especially if it is a histological volume located on NFS server) then actually dynamically calculating min and max range of the memory buffer. On Sat, Jan 19, 2013 at 12:06 AM, Peter Neelin wrote: > On Jan 18, 2013 4:48 PM, "Andrew Janke" wrote: > > > Isn't this done by the valid min and max for the file? I'll have to > look at the register and Display code again. > > The valid min/max give the range for the entire file. The image min/max > variables allow it to be specified by image (or frame, or other dimensions > of interest). > > Peter > -- > Peter Neelin > peter.neelin at gmail.com > > _______________________________________________ > 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 peter.neelin at gmail.com Sat Jan 19 14:05:42 2013 From: peter.neelin at gmail.com (Peter Neelin) Date: Sat, 19 Jan 2013 14:05:42 -0500 Subject: [MINC-development] MINC2 file with floating-point voxels and slice normalization In-Reply-To: References:

<50F96E58.7050401@phenogenomics.ca> Message-ID: On Jan 19, 2013 9:13 AM, "Vladimir S. FONOV" wrote: > I think these relics of the past have to go, right now it takes much more time to extract the right slice from the dataset (especially if it is a histological volume located on NFS server) then actually dynamically calculating min and max range of the memory buffer. FWIW, I don't feel strongly one way or another (since I am no longer a MINC user), but you might want to have a discussion with John before changing things. As John mentions, it can be helpful in certain applications to be able get range information for a large multi-dimensional dataset without having to read it all first (e.g. on-demand loading). In my experience, IO speed limitations can be a significant obstacle for things like time to display first image for large datasets, so you want to be able to quickly get any required meta-data (such as dataset range for window level initialization). Note that valid min/max would be sufficient for this unless you are looking at volumes in a 4 or 5D file. Perhaps John could give examples where this is useful. In my world, we still top out at around 1-10 GB for big individual datasets, but research data always seemed to be 1-2 orders of magnitude bigger (is that still true? I'm a bit afraid to ask). Ignoring the memory requirements, with even fast IO the load time could be very annoying. All that to say that I can still see these concepts as being potentially useful. They certainly are in my business (distributed radiology) although we are more about viewing than large-scale image processing. Peter -- Peter Neelin peter.neelin at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.janke at gmail.com Sun Jan 20 16:00:44 2013 From: a.janke at gmail.com (Andrew Janke) Date: Mon, 21 Jan 2013 07:00:44 +1000 Subject: [MINC-development] MINC2 file with floating-point voxels and slice normalization In-Reply-To: <50F96E58.7050401@phenogenomics.ca> References:

<50F96E58.7050401@phenogenomics.ca> Message-ID: Hi John, I went looking for an example of this in the Register/Display code but it seems to use the valid min/max of a file (not the per slice values even if they are present). Yes, the per slice values are used while reading and normalised by volume_io but not in register/Display themselves. In our MINC2 based web viewer for large histology (TissueStack) we use the valid min/max as a starting guess. We also normalise during conversion to its own internal fast format but that's another story. Do you have an example of this behaviour? I didn't get to looking far into postf to see what it does, I ask as while I see this as being useful for discrete data types I don't see the point for float/double given that they are "normalised" already and thus a file min/max should be a decent approximation. Storing a min/max for each slice is also only going to work for viewing in a particular orientation. ta a On 19 January 2013 01:46, John G. Sled wrote: > Since we are voting ... I vote for keeping Peter's design where the slice > min / max is maintained for informational purposes when the underlying data > type is float. This allows visualization tools to make a sensible initial > choice for the window and level. From a.janke at gmail.com Sun Jan 20 16:06:13 2013 From: a.janke at gmail.com (Andrew Janke) Date: Mon, 21 Jan 2013 07:06:13 +1000 Subject: [MINC-development] MINC2 file with floating-point voxels and slice normalization In-Reply-To: References:

<50F96E58.7050401@phenogenomics.ca> Message-ID: > Note that valid min/max would be sufficient for this unless > you are looking at volumes in a 4 or 5D file. Perhaps John could give > examples where this is useful. In my world, we still top out at around 1-10 > GB for big individual datasets, but research data always seemed to be 1-2 > orders of magnitude bigger (is that still true? I'm a bit afraid to ask). Indeed.. :) Here's a "small" ~2GB mouse imaging dataset: http://caivm1.qern.qcif.edu.au/desktop.html?ds=1&plane=y&x=0.55&y=1.551&z=0.35&zoom=5 And then we get a bit bigger with a nigh on 200GB micro-CT: http://caivm1.qern.qcif.edu.au/desktop.html?ds=22&plane=y&x=0.009&y=0.017&z=-0.009&zoom=3 Once we get to restacked histology it goes mental (1TB), at this stage we seem to hit the limits of what MINC/HDF5 can do in a reasonable time frame and start to break the volume up although I now suspect that this is a limitation of how the MINC2 compatibility layer was coded. This was one of the major motivating things for me to investigate a pure HDF5 only MINC. Vlad has done 99.9% of the work on this for integration into ITK via minc-lite. For now the results we get with minc-lite are a lot quicker than minc2 but it's still not quite there for large (1TB) datasets. a From vladimir.fonov at gmail.com Sun Jan 20 17:02:24 2013 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Sun, 20 Jan 2013 17:02:24 -0500 Subject: [MINC-development] MINC2 file with floating-point voxels and slice normalization In-Reply-To: References:

<50F96E58.7050401@phenogenomics.ca> Message-ID: Hello, On Sun, Jan 20, 2013 at 4:06 PM, Andrew Janke wrote: > For now the results we get with minc-lite are a lot quicker than minc2 > but it's still not quite there for large (1TB) datasets. Did you try running it with a profiler ? I am curious which part is a slow down, and could it be restructure_array ( https://github.com/BIC-MNI/libminc/blob/minc_lite/libsrc2/hyper.c#L81 ) slowing things down. -- Best regards, Vladimir S. Fonov ~ vladimir fonov gmail com From peter.neelin at gmail.com Sun Jan 20 23:07:57 2013 From: peter.neelin at gmail.com (Peter Neelin) Date: Sun, 20 Jan 2013 23:07:57 -0500 Subject: [MINC-development] MINC2 file with floating-point voxels and slice normalization In-Reply-To: References:

<50F96E58.7050401@phenogenomics.ca> Message-ID: On Sun, Jan 20, 2013 at 4:06 PM, Andrew Janke wrote: > > And then we get a bit bigger with a nigh on 200GB micro-CT: > > http://caivm1.qern.qcif.edu.au/desktop.html?ds=22&plane=y&x=0.009&y=0.017&z=-0.009&zoom=3 Nice! Peter -- Peter Neelin (peter.neelin at gmail.com) From jgsled at phenogenomics.ca Mon Jan 21 10:28:21 2013 From: jgsled at phenogenomics.ca (John G. Sled) Date: Mon, 21 Jan 2013 10:28:21 -0500 Subject: [MINC-development] MINC2 file with floating-point voxels and slice normalization In-Reply-To: References: Message-ID: <50FD5E95.9070800@phenogenomics.ca> Hi Andrew, Thanks for investigating. I was under the impression that Display used the image min/max rather than valid min/max for the initial colour range with float volumes. I often encouter float MINC volumes where neither valid range or image range are set sensibly, which causes Display to quantize them to zero bit precision. This is likely a fault of file converters or a python API rather than the core minc libraries. I think there is value in having the correct minimum and maximum recorded in the header for floating point volumes. Computing this on the fly when the volume is read seems wasteful given that volumes are more often read than written. My preference would be to have one value for the whole float volume and store this as the image-min/image-max. Obviously, the valid-min/valid-max fields could serve the same purpose; however, the 'valid' part is not as intuitive a name. Vlad's question of whether to dispense with slice scaling entirely is worth further discussion. The two arguments that I am aware of that are in favour of per-slice scaling are: (i) that one can squeeze more numerical precision out of fixed point datatypes than with per-volume scaling; and (ii) that one can make a loss-less conversion to MINC of DICOM or similar data types that are inherently 2D and may not keep the same scaling for each slice. The arguments against per-slice scaling are that for out-of-core applications where one wants a section orthogonal to the slice direction, keeping track of slice scaling for every row of the section is complicated. Also, the slice concept doesn't generalize elegantly to features such as block layout files that HDF5 supports. In addition, given that most users of MINC are interested in 3D image processing of data that are presumed to have stationary image statistics, the benefits of (i) are often small or counterproductive. Point (ii) has merit but is more relevant to a radiologist's work flow than mine. I have talked myself into Vlad's point of view. I am unclear on how to achieve this though without breaking too many useful tools and legacy datasets. cheers, John On 13-01-20 4:00 PM, Andrew Janke wrote: > Hi John, > > I went looking for an example of this in the Register/Display code but > it seems to use the valid min/max of a file (not the per slice values > even if they are present). Yes, the per slice values are used while > reading and normalised by volume_io but not in register/Display > themselves. > > In our MINC2 based web viewer for large histology (TissueStack) we use > the valid min/max as a starting guess. We also normalise during > conversion to its own internal fast format but that's another story. > > Do you have an example of this behaviour? I didn't get to looking far > into postf to see what it does, I ask as while I see this as being > useful for discrete data types I don't see the point for float/double > given that they are "normalised" already and thus a file min/max > should be a decent approximation. > > Storing a min/max for each slice is also only going to work for > viewing in a particular orientation. > > ta > > > a > > > On 19 January 2013 01:46, John G. Sled wrote: >> Since we are voting ... I vote for keeping Peter's design where the slice >> min / max is maintained for informational purposes when the underlying data >> type is float. This allows visualization tools to make a sensible initial >> choice for the window and level. > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development From vladimir.fonov at gmail.com Mon Jan 21 10:42:53 2013 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Mon, 21 Jan 2013 10:42:53 -0500 Subject: [MINC-development] MINC2 file with floating-point voxels and slice normalization In-Reply-To: <50FD5E95.9070800@phenogenomics.ca> References: <50FD5E95.9070800@phenogenomics.ca> Message-ID: Hell Everybody, On 2013-01-21, at 10:28 AM, "John G. Sled" wrote: > Vlad's question of whether to dispense with slice scaling entirely is worth further discussion. I never said that we need to dispose of slice-scaling in case of storing floating-point values in integer volume. I said that we need to dispose of per-slice min-max information in case of floating-point volume, since it is useless and confusing. At least it was confusing enough for the MINC2 api authors to misinterpret. --- Best regards, Vladimir S. FONOV ~ v.s.fonov ilmarin.info From bert at bic.mni.mcgill.ca Mon Jan 21 16:12:15 2013 From: bert at bic.mni.mcgill.ca (Robert VINCENT) Date: Mon, 21 Jan 2013 16:12:15 -0500 (EST) Subject: [MINC-development] MINC2 file with floating-point voxels and slice normalization In-Reply-To: References: <50FD5E95.9070800@phenogenomics.ca> Message-ID: Hi all, My recollection is pretty dim at this point, but I think we probably assumed that the image min and max could be used to scale even fp voxels, even if it didn't really make sense. It's not like fp normalization is completely unheard-of. FWIW, NIfTI-1 defined per-image scaling of fp voxels, although it was clearly not the recommended usage. I probably found it hard to believe NIfTI-1 would be more general than MINC in any area... -bert On Mon, 21 Jan 2013, Vladimir S. FONOV wrote: > Hell Everybody, > > On 2013-01-21, at 10:28 AM, "John G. Sled" wrote: >> Vlad's question of whether to dispense with slice scaling entirely is worth further discussion. > > > I never said that we need to dispose of slice-scaling in case of storing floating-point values in integer volume. I said that we need to dispose of per-slice min-max information in case of floating-point volume, since it is useless and confusing. At least it was confusing enough for the MINC2 api authors to misinterpret. > --- > 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 > From a.janke at gmail.com Wed Jan 23 01:12:17 2013 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 23 Jan 2013 16:12:17 +1000 Subject: [MINC-development] MINC2 file with floating-point voxels and slice normalization In-Reply-To: References: <50FD5E95.9070800@phenogenomics.ca> Message-ID: Thanks Bert. So from all that has been said. I'll now re-iterate that I think we should dump slice scaling in float/double volumes. The viewing min/max functionality should be handled using the file min/max. Yes I know this *might* break a few edge cases of functional(time) data in which each slice is scaled differently. Still I won't loose much sleep breaking this as it will only work in one dimension in any case. As mentioned I can't see in the code where Register/Display or postf or any other viewer that I know of reads this slice scaling. the valid range yes, but that's different. a On 22 January 2013 07:12, Robert VINCENT wrote: > Hi all, > > My recollection is pretty dim at this point, but I think we probably assumed > that the image min and max could be used to scale even fp voxels, even if it > didn't really make sense. It's not like fp normalization is completely > unheard-of. > > FWIW, NIfTI-1 defined per-image scaling of fp voxels, although it was > clearly not the recommended usage. I probably found it hard to believe > NIfTI-1 would be more general than MINC in any area... > > -bert > > > On Mon, 21 Jan 2013, Vladimir S. FONOV wrote: > >> Hell Everybody, >> >> On 2013-01-21, at 10:28 AM, "John G. Sled" >> wrote: >>> >>> Vlad's question of whether to dispense with slice scaling entirely is >>> worth further discussion. >> >> >> >> I never said that we need to dispose of slice-scaling in case of storing >> floating-point values in integer volume. I said that we need to dispose of >> per-slice min-max information in case of floating-point volume, since it is >> useless and confusing. At least it was confusing enough for the MINC2 api >> authors to misinterpret. >> --- >> 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 >> > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development