[Insight-users] Question on MHD format

[Tim Soper]

Yes I think this is clear, alhtough in my original
question I was interested in reading a subregion (say
volume 2) from the whole image in Volume1.raw. That is
to say, I wanted to define a subregion of a volume
within the header itself that would essentially skip
over data that fell outside the defined subregion when
reading from the raw data file. If I am correct, I
would still need 2 data files in this instance even
though Volume 2.raw is redundant data from a subregion
of Volume1.raw. Because my desired subregion varies
from image to image, it would be handy to store this
info whithin the header itself rather than reading in
the whole image and defining a subregion in the code.
Does this make sense? 

--- Karthik Krishnan <Karthik.Krishnan at kitware.com>
wrote:

> No.. DimSize should refer to the size of your image.
> The point is that 
> you are merely making sure that both volumes have
> the same location in 
> real world (physical) coordinates.
> 
> For instance if you had Volume 1:  256 x 256 x 256
> with a spacing of 1.0 
> 1.0 1.0
> 
> NDims = 3
> DimSize = 256 256 256
> ElementSpacing = 1.0 1.0 1.0
> Position = 0.0 0.0 0.0
> ElementByteOrderMSB = False
> ElementType = MET_SHORT
> ElementDataFile = Volume1.raw
> 
> 
> Volume 2 that represented the extents of some
> anatomical region from 
> (100, 100, 100)- (120, 120, 120)
> 
> NDims = 3
> DimSize = 21 21 21
> ElementSpacing = 1.0 1.0 1.0
> Position = 100.0 100.0 100.0
> ElementByteOrderMSB = False
> ElementType = MET_SHORT
> ElementDataFile = Volume2.raw
> 
> Then for any physical point p, you would get the
> same pixel by
> 
> volume1->TransformPhysicalPointToIndex( p, idx1 );
> volume1->GetPixel(idx1);  
> 
> volume2->TransformPhysicalPointToIndex( p, idx2 );
> volume2->GetPixel(idx2);  
> 
> In other words p is the same physical point, but its
> index in the two 
> volumes, idx1 and idx2 will be different.
> 
> Does this make it clear ?
> 
> -karthik
> 
> 
> Tim Soper wrote:
> 
> >Karthik,
> >  Thanks for your reply, I'm almost there.  If I
> used
> >the position tag, how then would I specify the size
> of
> >the sub region? (I assume the DimSize tag still
> needs
> >to refer to the size of the  whole image). 
> >
> >-Tim-
> >
> >--- Karthik Krishnan <Karthik.Krishnan at kitware.com>
> >wrote:
> >
> >  
> >
> >>The position tag lets you represent subregions.
> >>
> >>Here's the header
> >>...
> >>...
> >>Position = -10.5 -10.5 -10.5
> >>...
> >>
> >>That means the origin of this image is at -10.5.
> So
> >>if you had a small 
> >>image that represented a subregion of a larger
> >>image, you could have the 
> >>subregion handled by itk::Image at the right
> >>physical location in the 
> >>image by specifying its origin at the appropriate
> >>position. We do this 
> >>often during registration where images from
> >>different modalities might 
> >>have different physical extents.
> >>
> >>HTH
> >>karthik
> >>
> >>Luis Ibanez wrote:
> >>
> >>    
> >>
> >>>Hi Tim,
> >>>
> >>>An easier way of saving disk space is by
> >>>      
> >>>
> >>compressing
> >>    
> >>
> >>>your images.
> >>>
> >>>The MetaImage formal let you gzip your raw files.
> >>>
> >>>What you will have to do is to edit the .mhd
> files
> >>>and update the name of the .raw file in order to
> >>>include the additional extension  .raw.gz (or any
> >>>other name that you decide to give to the
> >>>      
> >>>
> >>compressed
> >>    
> >>
> >>>file).
> >>>
> >>>This compression works quite well for labeled
> >>>      
> >>>
> >>images
> >>    
> >>
> >>>since it is based on Run Length Encoding. It
> >>>      
> >>>
> >>doesn't
> >>    
> >>
> >>>work quite well on noisy images though....
> >>>
> >>>Note that gzip compression is lossless, so you
> >>>      
> >>>
> >>shouldn't
> >>    
> >>
> >>>have any concerns about degradation of the image
> >>>      
> >>>
> >>data
> >>    
> >>
> >>>due to the compression.
> >>>
> >>>Please give it a try to compress the raw files
> >>>      
> >>>
> >>(and
> >>    
> >>
> >>>modify their name accordingly in the .mhd files)
> >>>      
> >>>
> >>and
> >>    
> >>
> >>>let us know if you find any problems.
> >>>
> >>>
> >>>
> >>>    Thanks
> >>>
> >>>
> >>>
> >>>       Luis
> >>>
> >>>
> >>>
> >>>
> >>>=======================
> >>>Tim Soper wrote:
> >>>
> >>>      
> >>>
> >>>>Hi,
> >>>>   I intersted in finding a way to reduce the
> >>>>        
> >>>>
> >>space
> >>    
> >>
> >>>>taken up on my hard drive by a number of raw
> data
> >>>>files roughly 512^3 in size. I find that I am
> >>>>        
> >>>>
> >>making
> >>    
> >>
> >>>>several images that are both clipped versions of
> >>>>        
> >>>>
> >>the
> >>    
> >>
> >>>>original large image as well as creating
> >>>>        
> >>>>
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com