Registration Confinement/Restrictions

[Matthew Strugari]

Hi Greg,

Is it possible to apply a restriction or confinement to certain image regions during B-spline registration? In other words, would it be possible to assign material properties to anatomical structures to limit the deformation of said structures during registration (ie. Poisson's ratio or Young's modulus)? 

I understand this is more of a finite element problem. However, since we are using distance maps to perform deformable registration of the prostate, it would be great to identify the malignant region in order to obtain a more realistic deformation result. Any insight to this would be great.

Matthew

[Sharp, Gregory C.]

Hi Matthew,

 

Unfortunately, this capability is not currently available in plastimatch.

 

Greg

--
You received this message because you are subscribed to the Google Groups "Plastimatch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to plastimatch...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

[Matthew Strugari]

That's what I figured. Might there be any plans of this in the future?

Matthew

[Sharp, Gregory C.]

 

I think it may not be that hard to do, provided you are

satisfied with just a weighting of the existing regularization parameter.

 

If you are interested to try, I can walk you through it.

[Matthew Strugari]

Sure, I would be interested in that.

Matthew

[Gregory Sharp]

On Wed, 20 May 2015 13:52:27 -0700
Matthew Strugari <matt.s...@gmail.com> wrote:

> Sure, I would be interested in that.
>
> Matthew
>

OK. Hope you are good at C++ :)

I suppose we still want to keep the global lambda, but also
allow an input image which has a voxel-specific lambda.
The total stiffness can be global * voxel-specific.

So the first step would be to add some code which loads the
regularization mask from an input image.
This would be done in three parts:

1. Add to shared_parms.{h,cxx} support for the variable for the input
filename. It will be just like the ROI, but I guess we only need one for the
fixed image.

2. Add to registration_parms.cxx the support for loading the filename from
the parameter file. It will be just like "fixed_roi".

3. Add support for storing the lambda image to registration_data.{cxx,h}.
Should be a "shared" input file, meaning it can be loaded either in
a GLOBAL section or a STAGE section.

Let me know if you have any questions.

Greg

[Matthew Strugari]

Hi Greg,

To be honest I am not that great with C++ and I don't really know what I'm doing :)

I have a few problems/questions:

1. Should I also modify the registration_parms.h to support the secondary moving image?

1. How can I assign the voxel-specific lambda to my secondary moving image?

2. Do I need to account for the secondary moving image to the landmarks functions?

I will attach the six files that I have modified but I am sure they are not correct. I edited the files which you mentioned by mainly adding in a section to account for the secondary moving image. For example, if there was a section in the file for "fixed_roi" and "moving_roi" then I added an identical section using "moving_secondary_roi". I did this in all of the files.

I apologize for my lack of knowledge on the subject.

Matthew

[Gregory Sharp]

Hi Matthew,

So far so good. I have a few comments.

1) I suggest the term "regularization_image" (or regularization map?)
rather than "secondary_image"
2) It is easier if the regularization image is attached to the fixed
image rather than the moving image.
3) Probably here is no need for a second ROI. The ROI image is for choosing
which voxels are used in the registration (the fixed_roi parameter).
Let me know if I am missing something here.
4) Don't worry about the num_jobs thing. It doesn't work.

Regarding your questions,

1a) The registration_parms.h is holding configuration settings of the
[GLOBAL] section. By putting it in shared_parms.h, it will be allowed
in either [GLOBAL] or [STAGE], so I think this could be better.
1b) The concept is like this:

[GLOBAL]
regularization_image=image.nrrd
[STAGE]
regularization_lambda=1

Then you would create the image.nrrd with higher values for stiff tissues such
as bone, and lower values for flexible tissues such as lung.

3) I don't see any benefit to this.

Anyway, if you agree with my suggestions, I will apply them, and we can
move to the next step.

Greg


On Fri, 22 May 2015 12:45:48 -0700

[Matthew Strugari]

Hi Greg,

In 2) you state that it is easier if the regularization image is attached to the fixed image. Perhaps it would be of benefit if I outline my data and how it is currently being used.

1. Convert MR_Prostate.nrrd and US_Prostate.nrrd segmentations to distance maps.

2. Register MR_Distance_Map_Moving.nrrd to US_Distane_Map_Fixed.nrrd.

        2.a) Rigid Registration

        2.b) B-spline Deformable Registration

3. Apply Deformation Vector Field (rigid field + deformation field contained in one file) to original MR_Prostate.nrrd and MR_DIL.nrrd using the Plastimatch Warp function.

It is the MR_DIL.nrrd image that I would like to use to limit the "stiffness" of the malignant region within the prostate. In order to use the MR_DIL.nrrd with the fixed image it would have to be rigidly aligned first. I believe that this would require two registration parameter files in order to obtain the initial rigid registration vector field output followed by a deformation vector field contained in two separate files. Would there be a simpler way to attach the MR_DIL.nrrd regularization image to the fixed image without requiring an intermediate warp step using the rigid vector field? I hope this makes sense.

Aside from this concern, I agree with your suggestions.

Matthew

[Sharp, Gregory C.]

Hi Matthew,

 

Would you be willing to set MR as fixed, and then invert the vector field?

 

Greg

 

 

From: plast...@googlegroups.com [mailto:plast...@googlegroups.com] On Behalf Of Matthew Strugari
Sent: Monday, May 25, 2015 12:10 PM
To: plast...@googlegroups.com
Cc: Sharp, Gregory C.
Subject: Re: [Plastimatch] Registration Confinement/Restrictions

 

Hi Greg,

--

[Matthew Strugari]

That seems like a viable option. Does Plastimatch have an option to invert a vector field?

Matthew

[Sharp, Gregory C.]

Yes.   It is a separate executable “vf_invert”

 

(In a future version it will be absorbed into the main executable.)

[Matthew Strugari]

Okay great. 

Are you going to take care of the code to include the extended regularization parameter? If so then I will revert back to the original files and update Plastimatch to the most recent version.

Matthew

[Sharp, Gregory C.]

Yep.  Sounds like a good plan.

I’ll report back when it is done.

[Matthew Strugari]

Excellent. Thank-you Greg!!!

Matthew

[Matthew Strugari]

Hi Greg,

Any updates on the implementation of this feature?

Matthew

[Gregory Sharp]

Hi Matt,

I seem to have something working. Can you please update your plastimatch
and give it a try?

There are some instructions and a few screenshots of results here:

http://plastimatch.org/regularization.html#stiffness-images

The result is pleasing, but it took me several tries.
You may need to use finer grid spacing and/or run for
extra iterations.

Greg

[Matthew Strugari]

Hi Greg,

Just a couple of questions before I begin testing:

1. How can I specify the regularization_lambda parameters for the two different regions? I had been using regularization_lambda=0.02 for the prostate but I will need a different value for the DIL region.

2. How do I invert the resultant transformation?

Matthew

[Gregory Sharp]

Hi Matt,

1. The regions are specified as an image.  For your case, you could keep regularization_lambda = 0.02.  Then, create an image with (for example) value of 2 in DIL, and 1 elsewhere.

2. (One of these days I will make this easier!)

 # Convert bspline to vector field (if necessary)

plastimatch xf-convert --input bspline.txt --output-type vf --output vf.mha

 # Invert vector field

vf_invert --input vf.mha --fixed moving_image.mha --output vf-inv.mha

Greg

--

[Matthew Strugari]

Hi Greg,

I am registering the distance maps for the prostate region. Will I be able to use the unmodified DIL labelmap as the fixed_stiffness image? It has a value of 1 in the DIL and 0 elsewhere. Would this mean that the DIL would then have a penalty of 1 x 0.02 = 0.02?

I attempted to use the vf_invert function but it does not appear to be implemented in this version (5105). It just populates the usual list of possible commands. Also, when I tried to convert a bspline transformation to a vector field I received the message: "Sorry, didn't implement get_grid_spacing (type = 5)". I don't need the xf-convert function but I figured I would try it out anyway.

Matthew

[Gregory Sharp]

Hi Matt,

1. I think it's good to try this way as a first step. But keep in mind this
gives you a regularization of 0 outside the DIL, which sounds sub-optimal.

If the results are not satisfying, you can adjust the values.
For example, change 0 to 0.1, keeping 1 as 1, like this:

# Change 0 to 0.1, but keep 1 as 1
plastimatch adjust --input mask.mha --output new-mask.mha
--pw-linear "0,0.1,1,1"

The voxel-specific stiffness feature is still "Beta", so please give your
feedback and suggestions.

2. Ah, this is a bug. Thank you for the report. What happened is you are
using an ITK format of the B-spline parameters, which is not supported by
xf-convert. I will try to fix in a future version.

Greg

[nami]

Dear Greg and Matthew,

 

that is really nice feature that I wanted to have!

 

I have started using it with 4DCTs of a livar patient (with revision 5105 on linux and windows).

It seems working, but I do need to find good parameters and good mapping to adjust the regularization.

 

Greg, is there any output line on the screen to check whether the Stiffness is handled (just to make sure it is running properly..)?

There is a line "Loading fixed stiffness: C:\..", so I see the reading of map was done. But the regularization related output shows just same as we have for the numeric:

(Algorithm flavor = g
Regularization: flavor = a lambda = 0.005000
Warning: vox_per_rgn was less than 4.
bspline_xform_initialize

..)

Concerning the value of lambda, I usually use 0.005 with analytic regularization. In general with numeric algorithm, should I expect the same penality effect if I specify same lambda value? (I mean.. is the C_RM normalized to be comparible to analyritic and numeric?)

best regards,

Nami

2015年6月18日木曜日 15時18分38秒 UTC+2 Gregory Sharp:

[Sharp, Gregory C.]

Hi Nami,

Good to hear from you.

 

There is not yet a clear indication that the map is being used.

For example, if you choose analytic regularization, the map gets

loaded, but is not used. 

 

If you run with and without the map, do you get the same scores?

The scores should be different.

 

There is no automatic normalization. 

My (naive, not experimentally verified) suggestion would be to keep

the lambda at the same value, and create a map where

“standard” tissues have value of 1, and more or less stiff

tissues are higher or lower than 1.

 

Greg

 

From: nami [mailto:nami...@gmail.com]
Sent: Friday, June 19, 2015 11:28 AM
To: plast...@googlegroups.com
Cc: matt.s...@gmail.com; Sharp, Gregory C.
Subject: Re: [Plastimatch] Registration Confinement/Restrictions

 

Dear Greg and Matthew,

[Matthew Strugari]

Hi Greg,

The first runthroughs seem to be fairly successful! The fixed_stiffness image region maintains its structure quite well. This is a significant improvement over the results that were previously obtained where this secondary image would develop a less than perfect boundary in the same region. I have not modified any of the input files but I will look into experimenting with different stiffness values.

In the past, we were using distance maps for registration purposes. I have tested the fixed_stiffness implementation using labelmaps and distance maps separately for the fixed and moving images while keeping the fixed_stiffness image as a labelmap. Here is a brief summary of some results:

Labelmaps for registration:

     Time: 4600s

     Vector Field Jacobian: 0.82 - 1.69

     Prostate Dice Similarity: 0.89

     Prostate Hausdorff Distance: 6.2mm

     DIL Dice Similarity: 0.38

     DIL Hausdorff Distance: 10.9mm

Distance maps for registration:

     Time: 800s

     Vector Field Jacobian: -2.50 - 13.98

     Prostate Dice Similarity: 0.95

     Prostate Hausdorff Distance: 3.0mm

     DIL Dice Similarity: 0.35

     DIL Hausdorff Distance: 10.3mm

Previously obtained results (no fixed_stiffness image):

     Time: 700s

     Vector Field Jacobian: -0.01 - 1.28

     Prostate Dice Similarity: 0.95

     Prostate Hausdorff Distance: 2.2mm

     DIL Dice Similarity: 0.29

     DIL Hausdorff Distance: 11.4mm

The labelmap method proved to yield the best DIL results which is quite important for us. However, the registration time seems far too long to be clinically feasible even though these registrations were performed on my laptop. I will experiment with the labelmap stiffness value and regularization value as well as labelmap cropping. Hopefully this will decrease the registration time and improve the DSC and Hausdorff distances for the prostate. I am unsure if it would be best to continue using the distance maps with this new feature.

Please let me know if you have any further suggestions or questions.

Matthew

[Sharp, Gregory C.]

Hi Matthew,

Thank you for the update.  I have a question, are you trying to simultaneously

align prostate and DIL?  If so, you may consider a composite distance map

that encodes both regions.  It will probably work faster than the stiffness map.

 

Greg

 

From: plast...@googlegroups.com [mailto:plast...@googlegroups.com] On Behalf Of Matthew Strugari

Sent: Tuesday, June 23, 2015 1:06 PM
To: plast...@googlegroups.com

Cc: Sharp, Gregory C.; nami...@gmail.com
Subject: Re: [Plastimatch] Registration Confinement/Restrictions

 

Hi Greg,

--

You received this message because you are subscribed to the Google Groups "Plastimatch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to plastimatch...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

The information in this e-mail is intended only for the person to whom it is

[nami]

Dear Greg,

I have tested the feature with a Stiffness map. It is good that I see effects on both images and score as I expected.

I realized that the numeric algorithm of the regularization process takes time by a factor of about 100 comparing to analytical regularization for my case. 

I have run it with cuda, but it didn't not impove the speed.  For example an analytical RG registration took 100s without applying fixed stiffness (score 848), with numerical RG took 9000s for both openmp (score 687 with a stiffness map) and cuda (score 688 with the same map) cases.

I see the output message of the GPU memory (244MB for low resolution, 1003MB for a high resolution stage) for the cuda case, so I think GPU (2 Tesla k20c + Qeadro) was used for calculation. I just expected more acceleration with cuda, but it was comparable to threading with CPU (windows, Intel Xeon E5-2687W of 2processors). I have tested with a linux server with openmp, it was slower than the windows PC I used.

Since the numeric algorithm takes time, investigation of the suitable maps is time consuming.

Do you have any suggestion to reduce the calculation with this enviroment?

best regards,

Nami

On Monday, 22 June 2015 19:18:39 UTC+2, Sharp, Gregory C. wrote:

[Matthew Strugari]

Hi Greg,

Yes, we are re-aligning the MR Prostate and DIL contours to the US Prostate contour. Ideally I would like to apply no regularization to the MR prostate so that I can get as close of a match as possible between prostates. I would like to be able to independently control the DIL regularization to allow for a slight deformation/relocation without any vector field folding or contour stretching.

What would be the benefit for the end results by using a composite distance map?

Matthew

[Sharp, Gregory C.]

Hi Matthew,

 

The benefit of matching distance maps is that you can get very good alignment of

the contours.

 

The disadvantage is that image information is ignored.  Only contours are considered.

 

A composite distance map would allow alignment of the boundaries of multiple structures.

(But still image intensities are ignored.)

 

Greg

 

From: Matthew Strugari [mailto:matt.s...@gmail.com]
Sent: Monday, July 27, 2015 10:29 AM
To: Plastimatch
Cc: nami...@gmail.com; Sharp, Gregory C.
Subject: Re: [Plastimatch] Registration Confinement/Restrictions

 

Hi Greg,

The information in this e-mail is intended only for the person to whom it is

[Matthew Strugari]

Hi Greg,

We have not been using any MR or US images during the registration so it would not matter that image information is ignored. The US image is used after registration to resample the warped contours.

If we were to use a composite distance map, would both composite maps require the same structures? ie. Would both the DIL and prostate have to be accounted for within the MR and US datasets? The US dataset does not have a DIL region specified within the prostate. It is just the US prostate that is used as a reference when deforming the MR dataset.

Matthew

[Gregory Sharp]

Hi Matthew,

You are correct. I'm afraid then this option is not available without
the DIL contour.

Greg

On Thu, 13 Aug 2015 08:41:49 -0700
Matthew Strugari <matt.s...@gmail.com> wrote:

> Hi Greg,
>
> We have not been using any MR or US images during the registration so it
> would not matter that image information is ignored. The US image is used
> after registration to resample the warped contours.
>
> If we were to use a composite distance map, would both composite maps
> require the same structures? ie. Would both the DIL and prostate have to be
> accounted for within the MR and US datasets? The US dataset does not have a
> DIL region specified within the prostate. It is just the US prostate that
> is used as a reference when deforming the MR dataset.
>
> Matthew
>
> On Thursday, July 30, 2015 at 1:14:34 PM UTC-6, Sharp, Gregory C. wrote:
> >
> > Hi Matthew,
> >
> >
> >
> > The benefit of matching distance maps is that you can get very good
> > alignment of
> >
> > the contours.
> >
> >
> >
> > The disadvantage is that image information is ignored. Only contours are
> > considered.
> >
> >
> >
> > A composite distance map would allow alignment of the boundaries of
> > multiple structures.
> >
> > (But still image intensities are ignored.)
> >
> >
> >
> > Greg
> >
> >
> >

> > *From:* Matthew Strugari [mailto:matt.s...@gmail.com <javascript:>]
> > *Sent:* Monday, July 27, 2015 10:29 AM
> > *To:* Plastimatch
> > *Cc:* nami...@gmail.com <javascript:>; Sharp, Gregory C.
> > *Subject:* Re: [Plastimatch] Registration Confinement/Restrictions

[Matthew Strugari]

Hi Greg,

That is okay. The goal of our project is to eliminate the intra-observer variability when contouring the DIL on the US image during HDR prostate brachytherapy. Since the DIL is not visible in US, its location is being estimated by comparing a side by side view of the diagnostic MR data with the live US data. We are trying to remove as much uncertainly as possible of where the DIL is located during the treatment by deforming the MR data to correspond to the US prostate contour. The resulting deformed DIL from the MR data will then be fused to the US image and used during the dose planning and optimization.

Matthew

[Chang Chih-Chieh]

Hi Greg,

Thanks for this discussion! I have the same purpose to get the inverse vector field. 

I wonder that dose plastimatch version 1.9.3 still provide  "vf_invert" function to inverse the vector field?
I tried this command (vf_invert --input foreward.nrrd --output backward.nrrd), but it showed 'vf_invert' is not recognized as an internal or external command.

Thanks!

Gregory Sharp 在 2015年6月17日 星期三凌晨2:03:51 [UTC+8] 的信中寫道：