[Insight-users] Question on MHD format

[Karthik Krishnan]

None of the ITK readers that are in ITK right now (somebody correct me 
if I am wrong) support block by block reading. This has been in part due 
to file format limitations . They will gobble in the entire image data. 
That said, there are some new formats scheduled for inclusion in ITK in 
the very near future. (HDF5 and MINC) that support reading of blocks in 
the volume.

-karthik

Tim Soper wrote:

>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 
>
>  
>