[Insight-users] Setting the spacing of images for rigid regis tration

Mon Mar 5 08:01:05 EST 2007

Hi,

With MetaIO, you can specify a header size that should be skipped from 
the beginning of each raw file read.  The tag is

HeaderSize = <bytes to skip>

If you don't know the headersize, but you know that all of the image 
data occurs at the end of the file (as is true for most dicom files), 
then you can specify a HeaderSize = -1 and it will automatically 
calculate the header for each raw file under the assumption that the 
image data is at the end.   In that way, a dicom volume stored 
slice-by-slice can be read using metaimage.

Updating the documentation is on my to-do list.

Sorry for the confusion,
Stephen

Christoph Palm wrote:
> Hi Richard,
> 
> unfortunately I don't know the answer to your question. And looking
> on the documentation of the MetaImageIO Class, I would think, there
> is now solution without changing some lines of code.
> 
> I had also a look onto the WiKi pages, 
> 
> http://www.itk.org/Wiki/ITK_File_Formats
> 
> because there is a description
> of the image file formats. Unfortunately, the link to a reference of
> MetaImages  
> 
> http://caddlab.rad.unc.edu/software/MetaIO/MetaIO-Introduction.htm
> 
> gives no answer at the moment. I don't know if it's corrupt in general
> of if there is a temporary problem.
> 
> Overreading some bytes should be easy to implement. Perhaps you
> write this as an extension and submit the code for later releases.
> In my opinion, it would be a usefull thing to have (if it is not
> already there.)
> 
> Your way of transformation seems to be error prone, because there might
> be inherent changes of data type, spacing etc. and you have carefully to
> look onto your result after this procedure. By the way, for me it would
> be much too time consuming, so I would spend the time in adapting the
> code rather than transforming images more or less manually.
> 
> Hope, that helped...
> 
> Regards
> 
> Christoph
> 
> On Mon, 2007-02-19 at 11:13 +0000, Sims Richard (RKB) Clinical Scientist
> wrote:
>> Hi Christoph
>>
>> Thanks for the reply.
>>
>> I actually use dicom image formats and so, as you say, the spacing is
>> implicitly included in the header. In this example I was using bmp/png files
>> (which were sourced from dicom files) and then explicitly defining the image
>> spacing in the code.
>>
>> I have a related question which I hope you, or somebody else on the mailing
>> list, maybe able to help with... 
>>
>> I have access to the Visible Human Project data and would like to read this
>> into ITK. The files have an extension according to the type of data they
>> contain (e.g. frozen CT data has the extension *.fro whereas proton density
>> data has the extension *.pd) and they also include a *.txt file that
>> provides all kinds of information about the data. I have attempted to read
>> these data files into ITK by using a metaimage header of the following type:
>>
>> NDims = 2
>> DimSize = 512 512
>> ElementType = MET_USHORT
>> ElementSpacing = 0.898438 0.898438
>> ElementByteOrderMSB = False
>> ElementDataFile = 1055fre.raw
>>
>> Where the element spacing was found in the *.txt file. Using this *.mha file
>> doesn't work, presumably because there is no information available regarding
>> the size of the header of the raw data file. As a temporary work-around I
>> imported the raw data file into ImageJ and specified the header size - the
>> data is then displayed correctly. I saved this file as a new raw data file
>> (in this case 1055fre.raw) and then use the above *.mha file to load it into
>> ITK. I then visualise the image by creating a PNG file of the data. The data
>> loads and appears pretty much ok, although I think I'll need to use a
>> rescale intensity filter. 
>>
>> Is there any way the header size of the raw data file can be included in a
>> metaimage header file? 
>>
>> Thanks in advance,
>> Richard.
>>
>>
>> -----Original Message-----
>> From: Christoph Palm [mailto:christoph.palm at web.de] 
>> Sent: 16 February 2007 18:34
>> To: Sims Richard (RKB) Clinical Scientist
>> Cc: 'insight-users at itk.org'
>> Subject: Re: [Insight-users] Setting the spacing of images for rigid
>> registration
>>
>> Hi Richard,
>>
>> it would be easiest and most correct to use an image format, that stores
>> your spacing implicitely, e.g. the meta image format of ITK. Reading
>> such images, your spacing is correctly set from the beginning.
>> And note, the registration is computed in real world coordinates and
>> is always dependend on the spacing. What image format do you use?
>> Otherwise use the ChangeImageInformationFilter to change the spacing
>> of your images.
>>
>> Regards
>>
>> Christoph
>>
>> On Fri, 2007-02-16 at 17:13 +0000, Sims Richard (RKB) Clinical Scientist
>> wrote:
>>> Hi all
>>>
>>>  
>>>
>>> I have ammended one of the example codes provided with ITK to perform
>>> rigid registration using a Centered Rigid 2D Transform with a Mattes
>>> Mutual Information Metric. My fixed and moving images are both bitmaps
>>> which of 512x512 size but have different pixel spacing, 0.898mm/pixel
>>> for the fixed image and 0.527mm/pixel for the moving image. I have
>>> successfully registered these images using a Similarity 2D Rigid
>>> Transform (the moving image being re-scaled to the fixed image), but
>>> would like to rigidly register them without scaling by accouting for
>>> their different pixel spacing. I've tried to explicitly define the
>>> spacing of the pixels using the following code:
>>>
>>>  
>>>
>>> FixedImageType::SpacingType spf;
>>>
>>> MovingImageType::SpacingType spm;
>>>
>>> FixedImageType::PointType orf;
>>>
>>> MovingImageType::PointType orm;
>>>
>>>  
>>>
>>> spm[0]=0.527344;
>>>
>>> spm[1]=0.527344;
>>>
>>> //spf[2]=1.000000;
>>>
>>>  
>>>
>>> orf[0]=0.0;
>>>
>>> orf[1]=0.0;
>>>
>>> //orf[2]=0.0;
>>>
>>>  
>>>
>>> spf[0]=0.898438;
>>>
>>> spf[1]=0.898438;
>>>
>>> //spm[2]=1.000000;
>>>
>>>  
>>>
>>> orm[0]=0.0;
>>>
>>> orm[1]=0.0;
>>>
>>> //orm[2]=0.0;
>>>
>>>  
>>>
>>> fixedImage->SetSpacing(spf);
>>>
>>> fixedImage->SetOrigin(orf);
>>>
>>> movingImage->SetSpacing(spm);
>>>
>>> movingImage->SetOrigin(orm);
>>>
>>>  
>>>
>>> But it doesn't seem to have an effect... I'm guessing it has something
>>> to do with the resample image filter, but have reached a stumbling
>>> block... could anyone give me a pointer in the right direction?
>>>
>>>  
>>>
>>> Many thanks,
>>>
>>> Richard.
>>>
>> www.chripa.de/AtWork
>> ----
> 
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
> 

-- 
=============================================================
Stephen R. Aylward, Ph.D.
Chief Medical Scientist
Kitware, Inc. - Chapel Hill Office
http://www.kitware.com
Phone: (518)371-3971 x300