# Python : how to centre volume on load?

**URL:** <https://discourse.slicer.org/t/python-how-to-centre-volume-on-load/10220>\
**Category:** Support\
**Created:** [February 12, 2020, 4:45pm UTC](https://discourse.slicer.org/t/python-how-to-centre-volume-on-load/10220 "2020-02-12T16:45:08Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![chir.set](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/chir.set/32/66982_2.png) [@chir.set](https://discourse.slicer.org/u/chir.set)\
**Post date:** [February 12, 2020, 4:45pm UTC](https://discourse.slicer.org/t/python-how-to-centre-volume-on-load/10220/1 "2020-02-12T16:45:08Z")

</div>

Previously, using the ‘Add data’ menu, we would check the ‘Centre’ widget so that the loaded volume (DICOM series) was centered. The ‘Add data’ menu is no longer maintained for this use, and I’m using the DICOM module instead.

I could not find an option to centre a loaded volume in the DICOM module. I can always go the Volumes module to do that. I’m looking for an automated way however. This is because I have to CROP the volumes after loading them, using fixed ROIs (saved on storage) as templates. Studies from different OEMs have different centre point.

I tried this to no avail in slicerrc.py :

```
@vtk.calldata_type(vtk.VTK_OBJECT)
def onNodeAdded(caller, event, calldata):
  node = calldata
  if isinstance(node, slicer.vtkMRMLVolumeNode):
    volumesLogic = slicer.modules.volumes.logic()
    volumesLogic.CenterVolume(node)

slicer.mrmlScene.AddObserver(slicer.vtkMRMLScene.NodeAddedEvent, onNodeAdded)

```

I could not find more useful code in the [repository](https://www.slicer.org/wiki/Documentation/4.10/ScriptRepository). (There’s a code snippet to centre the 3D view, but that’s not what I need to do.)

I’m asking for some help here for this task.

Thank you.

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [February 12, 2020, 7:27pm UTC](https://discourse.slicer.org/t/python-how-to-centre-volume-on-load/10220/2 "2020-02-12T19:27:21Z")

</div>

Looks like you are on the right track - you might try adding some print statements to confirm the node is what you expect. Maybe it doesn’t have the image data yet or something.

But, for your workflow, I understand you are loading loading dicoms as scalar volumes and you know how you plan to process them, so why not write a custom import feature. Even overload the drag-and-drop so that everything behaves in the most efficient way for you?

---

<div class="post-metadata">

**Author:** ![chir.set](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/chir.set/32/66982_2.png) [@chir.set](https://discourse.slicer.org/u/chir.set)\
**Post date:** [February 12, 2020, 9:00pm UTC](https://discourse.slicer.org/t/python-how-to-centre-volume-on-load/10220/3 "2020-02-12T21:00:22Z")

</div>

I’m not skilled at Python , and even less in Slicer’s internals. I was expecting a few liners solution here, I’ll try a few random inspirations wildly.

Thanks.

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [February 13, 2020, 1:17am UTC](https://discourse.slicer.org/t/python-how-to-centre-volume-on-load/10220/4 "2020-02-13T01:17:57Z")

</div>

> [@chir.set](#):
>
> Studies from different OEMs have different centre point.

Center of the coordinate system is chosen by the scanner’s operator. It often contains somewhat useful information that is should not be simply discarded. Erasing the information would also make the volume spatially misaligned with other data structures that are defined in the same coordinate reference.

“Center volume” irreversibly erases image position and orientation, so it should not be used. This option was added decades ago and we haven’t removed it, because it is quite hidden and so unlikely that people would find it.

If you want to automatically fit templates to an image then image bounds are not ideal for this anyway, but you want to do a simple analysis of the image content instead. For example, if you apply simple thresholding then [oriented bounding box or principal axes](https://discourse.slicer.org/t/new-segment-statistics-oriented-bounding-box-diameter-and-more/10203) will tell you the physical location of the chosen object within the image.

---

<div class="post-metadata">

**Author:** ![chir.set](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/chir.set/32/66982_2.png) [@chir.set](https://discourse.slicer.org/u/chir.set)\
**Post date:** [February 13, 2020, 12:46pm UTC](https://discourse.slicer.org/t/python-how-to-centre-volume-on-load/10220/5 "2020-02-13T12:46:03Z")

</div>

> [@pieper](#):
>
> But, for your workflow … so why not write a custom import feature

This hinted me to modify my [custom](https://github.com/chir-set/TemplateROICrop) module, it restores back automated centering like before.

> [@lassoan](#):
>
> we haven’t removed it, because it is quite hidden

Removing it would be a major drawback to me. It’s deeply hidden, no one is seeing, so it can remain there 🙂

Thanks.

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [February 13, 2020, 1:42pm UTC](https://discourse.slicer.org/t/python-how-to-centre-volume-on-load/10220/6 "2020-02-13T13:42:48Z")

</div>

> [@chir.set](#):
>
> Removing it would be a major drawback to me. It’s deeply hidden, no one is seeing, so it can remain there

Centering the volume is just a single line of code (set the origin to half the size of the volume), but you can do much better than that, with fully automatic positioning of the ROIs based on image _content_ (using oriented bounding box or centroid/principal axes/moments).