[MINC-users] minctracc and cropped images
Simon Fristed Eskildsen
se at hst.aau.dk
Thu Nov 22 10:24:46 EST 2007
Thanks Oliver and Andrew,
Unfortunately, this is not a one-time task. I tried fiddling with the
-w_* parameters but it seems that the more weight I put on scale, the
smaller the scale in the transformation becomes.
I did a manual registration for this first image and removed the rotations:
-center 0.00000 0.00000 0.00000
-translation 1.68332 14.59561 12.16452
-rotation 0.00000 0.00000 0.00000
-scale 0.76397 0.91574 0.76318
-shear 0.00000 0.00000 0.00000
This is close enough.
minctracc -identity -lsq7 -w_scales 0.5 0.5 0.5 gives:
-center 0.00000 0.00000 0.00000
-translation -3.36057 5.93894 3.07303
-rotation -2.83953 -3.54900 21.45400
-scale 0.00442 0.00442 0.00442
-shear -0.00000 -0.00000 0.00000
Maybe I'm approaching the problem the wrong way. Allow me to elaborate
on the problem. The original scans are 4mm coronal slices (18-27
slices). Some radiographer looks through the slices in some windoze app
and draws contours around the hippocampus. He then gives me bitmap
images of his drawings, always only 12 consecutive slices. These bitmaps
are cropped.
So in reality the problem can be reduced to finding the match between
one, say the first, bitmap slice and one minc slice, and the global
(x,z) scale between these slices. Then I can use Imagemagick and
rawtominc to produce a volume that matches the original scan. With such
a solution I will only get resampling artifacts in 2D (x,z plane)
instead of in 3D.
Maybe I should write a program for this problem?
for each coronal slice in scan.mnc do
for scale=0.1 to 1.0 do
min = xcorr(scale(bitmap),slice) < min ? xcorr(scale(bitmap)) : min
done
globalmin = min < globalmin ? min : globalmin
done
...and of course keep track of best slice and scale :-)
Simon
Andrew Janke wrote:
> Hi Simon,
>
> Oliver is correct, you should be messing with the -w_* parameters.
> Unfortunately with the way that minctracc works there is no easy way
> to completely remove rotations from a registration (That I am aware
> of). In theory the 0 0 0 solution should work but doesnt due to the
> way the decomposition is done IIRC. In any case I suspect that
> instead of fiddling with the rotation parameter you probably should be
> changing the scale parameters.
>
> What size of scale difference is there between the two images?
> Typically scale is weighted very low in minctracc as this is not a
> very common difference between heads. As a quick test I just did this
> with some success (partial to complete).
>
> # make an evil transform
> $ param2xfm -translation 10 0 0 -scale 2 2 2 xfm.xfm
>
> # apply it
> $ mincresample -use_input_sampling \
> /usr/local/bic/share/mni_autoreg/icbm_avg_152_t1_tal_lin.mnc trans.mnc
>
> $ ln -s /usr/local/bic/share/mni_autoreg/icbm_avg_152_t1_tal_lin.mnc .
>
> # registration time
> $ minctracc -identity -lsq7 -w_scales 0.5 0.5 0.5 \
> trans.mnc icbm_avg_152_t1_tal_lin.mnc a.xfm
>
> $ xfm2param a.xfm
> -center 0.00000 0.00000 0.00000
> -translation 3.51257 2.31355 14.91390
> -rotation -1.38063 -1.11240 -4.42853
> -scale 2.99839 2.99839 2.99839
> -shear 0.00000 -0.00000 -0.00000
>
> Close enough for a first hack to me.. :)
>
>
> FWIW: there is no way to "tell" minctracc that one image is partial.
> The code should deal with this without problem.
>
> I would also guess that you would be best to work on something like a
> gradient image if your images are far apart to start with. I use the
> -identity above to ensure that the initial registration is not
> dependant on a PAT xfm (the default in minctracc) that would not be
> the best in this case given that it uses things like COG's of volumes.
>
> With the right parameters you will be able to make it work, but be
> aware that it may be a multi-step process to get it to work.
>
> a
>
>
> On Nov 23, 2007 1:05 AM, Oliver Gress
> <oliver.gress at medizin.uni-leipzig.de> wrote:
>> Hi Simon,
>>
>> in my case, I used -w_rotations 0 0 1 to set the rotation around x- and y-axis
>> to zero and it worked, so I always got something like
>> -rotation 0.00000 0.00000 0.01142
>> I wonder why you get rotations (your "-rotation" output is from xfm2param,
>> right?). A look into the minctracc manual tells, that the weights are set for
>> the optimization. In my understanding it means that no rotation should be
>> estimated. Perhaps someone from the BIC knows more exactly how the weights
>> are incorporated in the optimization. I'm sorry that I can't help you better.
>>
>> To your other problem, if it is a one-time task, you could manually find an
>> initial translation (and perhaps scaling) and create an initial
>> transformation (param2xfm) that you can feed to minctracc with
>> "-transformation <file.xfm>", but then you probably could also build a coarse
>> mask. And without a mask, I could imagine that the objective function (i.e.
>> the default crosscorrelation) could give better values when the subset is in
>> some way stretched to cover a great part of the full set.
>>
>> I hope that helps a little
>>
>> Oliver
>>
>>
>>
>> On Thursday 22 November 2007 13:34, Simon Fristed Eskildsen wrote:
>>> Hi Oliver,
>>>
>>> Thanks for the quick reply.
>>> If the weights are 0 the optimization will still be able to change the
>>> rotations, right?
>>>
>>> In any case, with -w_rotations 0 0 0, I get:
>>> -rotation -0.84230 -0.25758 87.84906
>>>
>>> where default is:
>>> -rotation -3.17860 -8.78379 80.04449
>>>
>>> I will try with a mask, but my problem is that I have no way to estimate
>>> the size of the mask used for the target, as I only know that my source
>>> is a subset of my target (not how big a subset).
>>>
>>> Simon
>>>
>>> Oliver Gress wrote:
>>>> Hi Simon,
>>>>
>>>> I think the easiest way is to use "-w_rotations 0 0 0". It sets the
>>>> weights for rotations to zero for the optimization, so no rotation will
>>>> be present in the estimated transformation.
>>>> To exclude parts of a volume from the estimation, you can set masks for
>>>> the target and source volumes with "-model_mask <filename>" and
>>>> "-source_mask <filename>". I think the mask files are binary minc files,
>>>> so coordinates of your MRI volumes that fall into regions of zero value
>>>> in the mask files will not be used for the optimization of the objective
>>>> function.
>>>>
>>>> Best regards
>>>> Oliver
>>>>
>>>> On Thursday 22 November 2007 12:17, Simon Fristed Eskildsen wrote:
>>>>> Hi all,
>>>>>
>>>>> I have a number of bitmap images. Each image is a coronal slice from a
>>>>> T1 MRI. Using rawtominc I have managed to create a minc volume from the
>>>>> bitmaps.
>>>>> I have the original scan in dicom, which I have converted to minc using
>>>>> dcm2mnc.
>>>>> Now I would like to align my volume created by rawtominc (let's call it
>>>>> "bitmap volume") with the original scan. However, the bitmap volume is
>>>>> cropped compared to the original scan, and minctracc does not seem to do
>>>>> a very good job aligning the two volumes. Is there a way to let
>>>>> minctracc know that the source does not have to match all of the target?
>>>>> Also, I don't need rotations in the transformation. Is there a way to
>>>>> force minctracc to not use rotations, only translations and scale?
>>>>>
>>>>> Thanks,
>>>>> Simon
>>>> _______________________________________________
>>>> MINC-users at bic.mni.mcgill.ca
>>>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
>
>
>
More information about the MINC-users
mailing list