Stability of Brainsfit
thatguy14 opened this issue · 2 comments
Hello everyone, I have an inquiry into brainsfit in slicer. I am going to copy/paste the email I sent to the slicer user group for anyone that is not apart of it. At the end I also have a tangential question:
Hello everyone, I have another question concerning the stability of brainsfit’s registration.
What lead me to ask this was I ran a registration on an image set one day and then about a week later ran it again after I noticed some weird artifacts. I got different outputs where many of the “barrelling” and “pin cushioning” effects from the bspline registration were gone when I reran it. Below I am giving some more details about the nature of my registration in case it’s relevant but my main question is: If I were to have a set of images (in this case DCE-MRI images) and I registered them on day 1 and then again on day 10 (for example), is it guaranteed that I would get the same output (or at least mostly the same) or could it be that on day 1 it arrives at some local minima and day 10 it avoids it somehow. I know that the sampling strategy is random but I am localizing the registration to an ROI and using 100% of that ROI (i.e., if my image is 384x384x112 = 16515072 voxels and my ROI is 1e6 voxels, then the percent sampling I use is 1e6/16515072 – in a previous email thread I was told that even though it randomly samples, it supposedly doesn’t sample the same ROI twice) – so the randomness can’t come from there. Hopefully that question is clear enough. Below is some extra information in case it is pertinent.
Also don’t know if it is relevant but when I run brainsfit either through my script or through the GUI I also get an error:
WARNING: In ..........\ITKv4\Modules\Numerics\Optimizersv4\src\itkLBFGSBOptimizerv4.cxx, line 116
LBFGSBOptimizerv4 (00000000EE382A50): LBFGSB optimizer does not support scaling. All scales are set to one.--- Additional info
• Registering DCE-MRI images using a script that loops through the moving images (post contrast images) and registers to the pre-contrast. I can attach script if necessary though it’s pretty messy and inefficient since I am not a programmer and have very little experience with Python
• I am using brainsfit. The percent sampling is specified above with an ROI. I can attach a log if necessary.
• There is no bulk transform i.e., only using bsplines
• For options that I want as the default I do not specify them in my script. Ex. I don’t specify things like “max iterations.” It seems the default parameters are still set anyways from the log.
Any other info needed let me know.
OTHER QUESTION
In addition to the question above, I am curious how brainsfit handles the samples it chooses for estimation of the cost function. I think my question is best asked by use of an example. Lets say I have some image with "y" voxels and an ROI defined over some region that contains "x" voxels. I select the ROI as the region I want to preform the registration over. As far as I understand it, this limits the sampling of voxels to only over this region. I am also assuming that even though it is randomly sampling, it never chooses the same voxel twice - at least that is my impression from past conversations. If that's not the case please let me know! Anyways, if I then set my percent sampling to x/y (i.e., to 100% of the ROI since the percent sampling is over the entire image) then it should select every single voxel in the ROI. Now what happens if I put the percent sampling to 2x/y, i.e., 2x the number of voxels in the ROI. Does Brainsfit ignore the repeat voxel or will it populate the cost function twice?
I know this was long, hopefully it is clear enough. Please let me know if there are any clarifications needed. Also I hope this was posted in the right place, if not please delete it and direct me to the correct place. Thanks!
@mmouawad This was written a very long time ago, and modified many times by folks that no longer work for me. I honestly do not know the answers to your very specific questions. To get the answers you desire is going to require careful inspection of the source code.
In many cases we defer to ITK proper for much of the behavior.
Hans
No recent activity on this, so closing.