Improving the Workflow Code (based on the Community Feedback)

 

Hey there,

So, there has been some delay in the timeline for my project but this delay isn’t intentional, I have been able to create good results for visual quality assessment. In fact, the Image Registration workflow is supplemented by both quantitative and qualitative metrics for assessment.

This blog post is about reviewing what has been done in the Image Registration Workflow and also about the many improvements that (I have been working on lately) have been done in the code based on community feedback.

Reviewing the additions to the workflow (for assessing quality)

For quantitative assessment: There is the option of saving the distance and optimal parameter metric now. For details about the code, see the following PR.

(old) PR for quantitative metric addition in the workflow

Testing and benchmarking the Image Registration with DIPY

Qualitative assessment: I am working on a separate branch to create the mosaic of registered images, this branch isn’t the part of the master because the primary Image registration workflow is not being merged (yet). More details about what these mosaics are and how they can help in quality assessment can be seen in one of my older posts below.

Visualizing the Registration Progress

Reviewing the improvements to the Image Registration workflow

The PR 1581 got a good response from the DIPY development community. I am discussing a few of the issues (by no means this discussion is exhaustive, it is just that I am selecting the points which I think made a difference). Majority of these issues are noted by the DIPY developer @nilgoyette.  Many thanks to @Nilgoyette for pointing them out and helping me to improve the code.

Modifying the code based on the community feedback (Many thanks to @NilGoyette & @skoudoro for the useful comments) 

Improvement-1: Following the code consistency and uniform standards. I overlooked the fact that simple things like, ‘import statement’ and line widths are not uniform in the file after I added my code.  For example, using both “,” and “()” for importing multiple classes from a module.

Old Commit

New Commit 

While these things don’t hurt the functionality of the code but they make the code look more consistent. I updated the code to follow same standards everywhere.

Improvement-2:  Moving to assert_almost_equal for comparing long floating point numbers. I wrote redundant code by rounding off the floating number to compare it with another float whereas, the NumPY’s assert_almost_equal are made for this purpose, so I updated the old test case by moving to assert_almost_equal.

This not only improved the code readability but also made the test objective clear.  Furthermore, using the NumPy’s default functions made the test cases look more consistent with the code base.

Commit Link

Improvement-3: Reducing the code duplication. The Image Registration workflow is complicated by the fact that it supports multiple registration modes both progressively and non-progressively. This lead to a part of various local functions being duplicated, I have reduced the code duplication (marginally, though) by moving a part of original code into a separate function.

Commit Link

Improvement-4: Using the “_” placeholder in python for variables not going to be used (but returned by the function call). I was using a variable name to hold the data returned by the function but the variable wasn’t used anywhere in the code later, So I moved to a more pythonic way of holding the data by using the “_” placeholder.

Commit Link

Improvement-5: Using the python’s default assert statement in the test cases. Part of the test cases was simply using the NumPy’s assert_equal to check for equality but the equality was checked against the boolean ‘True/False’ and so it made more sense to just use the default assert for doing such checks. Not that the assert_equal was incorrect but using assert made more sense for doing unit checks such as checking for equality to True/False.

Commit Link

All this feedback made the code more consistent and optimal. All these improvements (along with other changes to the code base) are now part of the PR 1581 and waiting to be merged.

In the coming weeks, I will be sharing more details about the results of apply_transform workflow (as promised earlier) and also about awesome new visualization that can be done with registered data by using the native matplotlib calls. More details about the apply_transform_workflow can be seen in the following post,

Transforming multiple MRI Images (in a Jiffy!)

Adios for now!

Parichit.

Leave a Reply

Your email address will not be published. Required fields are marked *