# Retrieve info on current itkwidget.view window bounds - following zoom

**URL:** https://discourse.itk.org/t/retrieve-info-on-current-itkwidget-view-window-bounds-following-zoom/5420
**Category:** Beginner Questions
**Created:** [October 18, 2022, 8:42am UTC](https://discourse.itk.org/t/retrieve-info-on-current-itkwidget-view-window-bounds-following-zoom/5420 "2022-10-18T08:42:07Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![Kevin\_Sweeney](https://discourse.itk.org/user_avatar/discourse.itk.org/kevin_sweeney/32/2947_2.png) [@Kevin\_Sweeney](https://discourse.itk.org/u/Kevin_Sweeney)
#### Post date: [October 18, 2022, 8:42am UTC](https://discourse.itk.org/t/retrieve-info-on-current-itkwidget-view-window-bounds-following-zoom/5420/1 "2022-10-18T08:42:07Z")

</div>

As point selection in `itkwidgets.view` is not currently possible ([Geometry / Point selection · Issue #575 · Kitware/itk-vtk-viewer · GitHub](https://github.com/Kitware/itk-vtk-viewer/issues/575)) is there a way to get the visual bounds of the viewer? i.e. if we create a view as shown below, and then zoom in on a particular region, is there any way to retrieve the x/y/z ranges of the current view window?

something like `bounds = v.camera.GetBounds()`?

```auto
import numpy as np
from itkwidgets import view

number_of_points = 3000
gaussian_mean = [0.0, 0.0]
gaussian_cov = [[1.0, 0.0], [0.0, 2.0]]
point_set = np.random.multivariate_normal(gaussian_mean, gaussian_cov, number_of_points)

v = view(point_sets=point_set)
v

```

---

<div class="post-metadata">

### Author: ![dzenanz](https://discourse.itk.org/user_avatar/discourse.itk.org/dzenanz/32/1093_2.png) [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [October 18, 2022, 3:04pm UTC](https://discourse.itk.org/t/retrieve-info-on-current-itkwidget-view-window-bounds-following-zoom/5420/2 "2022-10-18T15:04:06Z")

</div>

@matt.mccormick and @PaulHax might answer.

---

<div class="post-metadata">

### Author: ![PaulHax](https://discourse.itk.org/user_avatar/discourse.itk.org/paulhax/32/2949_2.png) [@PaulHax](https://discourse.itk.org/u/PaulHax)
#### Post date: [October 18, 2022, 4:58pm UTC](https://discourse.itk.org/t/retrieve-info-on-current-itkwidget-view-window-bounds-following-zoom/5420/3 "2022-10-18T16:58:39Z")

</div>

That feature is not there, but we are close. itk-vtk-viewer is already exposing the “cropping planes” (the manual user controlled planes activated by a button in the UI)

> <https://github.com/Kitware/itk-vtk-viewer/blob/7c88e1e055dc7c793561c4cdb106f9815c05a799/src/ImJoyPluginAPI.js#L353>

I think we just need to wrap the function call to getCroppingPlanes in itkwidgets

> <https://github.com/InsightSoftwareConsortium/itkwidgets/blob/main/itkwidgets/viewer.py>

---

<div class="post-metadata">

### Author: ![Kevin\_Sweeney](https://discourse.itk.org/user_avatar/discourse.itk.org/kevin_sweeney/32/2947_2.png) [@Kevin\_Sweeney](https://discourse.itk.org/u/Kevin_Sweeney)
#### Post date: [October 18, 2022, 10:16pm UTC](https://discourse.itk.org/t/retrieve-info-on-current-itkwidget-view-window-bounds-following-zoom/5420/4 "2022-10-18T22:16:13Z")

</div>

Thanks @PaulHax. Is this something i could easily patch locally or would i be better off waiting for it to be included in some future release?

---

<div class="post-metadata">

### Author: ![PaulHax](https://discourse.itk.org/user_avatar/discourse.itk.org/paulhax/32/2949_2.png) [@PaulHax](https://discourse.itk.org/u/PaulHax)
#### Post date: [October 19, 2022, 6:19pm UTC](https://discourse.itk.org/t/retrieve-info-on-current-itkwidget-view-window-bounds-following-zoom/5420/5 "2022-10-19T18:19:31Z")

</div>

I don’t know how to patch locally. To get this in a release this is what a smarter someone says is needed to expose the “get” functions on Viewer:

> We need to await the getter calls (calling the ImJoy wrapped functions returns a coroutine), and because of the “single threaded” nature of the notebook what happens is a cell can make the call and await it but it gets stuck and never returns. At this point it seems that we may need to take advantage of the background thread that we are using for the setters, but then that introduces additional complications (by running in the background the cells continue to progress after they’re called even if they haven’t returned, so we need to make sure returned values are returned to correct cell).

A little coding challenge there…
