Open agirault opened 6 years ago
The 2D render windows will be oriented to align with the orientation of the primary image. This is how viewers in radiology operate - it would incorrect to interpolate/reconstruct slices shown in the slice views for the primary image. So, while the presentation is physical space, a step in that physical space (e.g., to the next slice) is driven by the index space of the primary image. I agree that in addition to displaying slice number we should also display the physical coordinates of the current slice - but we should not allow folks to move to physical slice that doesn't align with a data/index slice of the primary image.
This is REALLY important. Don't interpolate data unless absolutely necessary and definitely don't interpolate data without the user explicitly knowing it!
On Wed, Jun 27, 2018 at 9:42 AM Alexis Girault notifications@github.com wrote:
When displaying anatomical oriented data in an MPR viewer, the slice views are slicing through the world space and not the data space, which glance does properly. However, in that case, using the term "Slice number" is incorrect since we are not displaying one slice of the data but a reconstructed slice along a world axis at a certain distance from the world origin (in mm).
I would, therefore, recommend to:
- replace Dataset > Slices > Slices by Dataset > Slices > Slicing in the left bar of the UI
- allow for decimals in the X/Y/Z values (currently shows ...)
[image: screen shot 2018-06-27 at 9 40 04 am] https://user-images.githubusercontent.com/4910855/41977750-23365716-79ee-11e8-87a0-f3da746fd613.png
- replace Slice ${value} by ${value} mm or Slicing at ${value} mm in the label overlay within the 2d view
[image: screen shot 2018-06-27 at 9 33 38 am] https://user-images.githubusercontent.com/4910855/41977749-232a6bfe-79ee-11e8-9ac4-2bf5cfa57ab1.png
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Kitware/paraview-glance/issues/112, or mute the thread https://github.com/notifications/unsubscribe-auth/AAREr_iMeOxdeeXer0hPRXZVc1Qlq_Fcks5uA4vCgaJpZM4U5vXv .
This is how viewers in radiology operate - it would incorrect to interpolate/reconstruct slices shown in the slice views for the primary image.
I don't pretend to know how it should work since my experience in this domain is obviously limited, I only have 3DSlicer as a reference, and this is what 3D Slicer does: data slices are reconstructed to be orthogonal to the axial/sagittal/coronal axis, which is the fixed orientation of the 2d views. If the oriented data is not aligned with the world coordinate system (aka, more than just permutations and inversions) then the value of the slices are interpolated. Those 2d views are not oriented to align with the image coordinate system in Slicer. That is also why Slicer does not show any slice index but only physical coordinates.
So I suppose doing either is fine, but it needs to be consistent:
is mm the only unite?
FYI: There might be some tweaks needed, but I made sure vtk-js would support both in the SliceRepresentation Proxy: https://github.com/Kitware/vtk-js/blob/master/Sources/Proxy/Representations/SliceRepresentationProxy/index.js#L33-L55
Yes, I know but IJK does not necessary match XYZ due to possible rotation?
Looking at the API and seeing getSliceAtPosition()
which could give me the matching IJK index especially since we don't do any interpolation as we only snap to the corresponding IJK.
It is something odd that Slicer does. Radiological workstations, in their 2D windows, always show the slices as they were acquired, rather than resampling them. You can do multi-planar reformatting to create arbitrarily oriented slices - but that is different (and in addition to) offering standard 2D slices.
Here is a nice article on how 2D viewing is different than MPR viewing (and curvilenear viewing and others); https://pubs.rsna.org/doi/full/10.1148/rg.255055044 "Introduction to the Language of Three-dimensional Imaging with Multidetector CT"
On Wed, Jun 27, 2018 at 11:09 AM Alexis Girault notifications@github.com wrote:
This is how viewers in radiology operate - it would incorrect to interpolate/reconstruct slices shown in the slice views for the primary image.
I don't pretend to know how it should work since my experience in this domain is obviously limited, I only have 3DSlicer as a reference, and this is what 3D Slicer does: data slices are reconstructed to be orthogonal to the axial/sagittal/coronal axis, which is the fixed orientation of the 2d views. Those 2d views are not oriented to align with the image coordinate system in Slicer. That is also why Slicer does not show any slice index but only physical coordinates.
So I suppose doing either is fine, but it needs to be consistent:
- currently, glance slices along the world coordinate axis (XYZ or LPS), like Slicer does (axial, coronal, sagittal): if we keep doing this, then the label should say it's physical coordinates (mm), not an index (slice nbr).
- if we want to use index space as you suggest then glance should not do physical space slicing along the world coordinates (XYZ or LPS) but align the 2d view cameras along the data coordinate system axis, which is not what is being done right now. If we do that (different from Slicer) we can then keep the current labels based on slice index.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Kitware/paraview-glance/issues/112#issuecomment-400708703, or mute the thread https://github.com/notifications/unsubscribe-auth/AARErx6YVlJK9hNNhUKtoOnErX4Pr7uZks5uA6AlgaJpZM4U5vXv .
Ok now I have the freedom to print what ever, but I would need guidance in term of what you want to see...
Here is one example of corner annotations. Most workstations follow this general format for corner annotations. [image: Osirix-CornerAnnotations.png]
On Wed, Jun 27, 2018 at 11:32 AM Sebastien Jourdain < notifications@github.com> wrote:
Ok now I have the freedom to print what ever, but I would need guidance in term of what you want to see...
[image: screen shot 2018-06-27 at 9 30 36 am] https://user-images.githubusercontent.com/294518/41984051-e6a33112-79ec-11e8-8bec-10d505a1cb1e.png
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Kitware/paraview-glance/issues/112#issuecomment-400718545, or mute the thread https://github.com/notifications/unsubscribe-auth/AAREr2HmndbB0L9B4Lr7PGmhGGiyE3-1ks5uA6VwgaJpZM4U5vXv .
Didn't get the image. You need to drop it in the web ui. Reply from mail doesn't seem to do it.
Here is what VolView provided: https://www.flickr.com/photos/kitware/2387782605
On Wed, Jun 27, 2018 at 11:37 AM Stephen Aylward < stephen.aylward@kitware.com> wrote:
Here is one example of corner annotations. Most workstations follow this general format for corner annotations. [image: Osirix-CornerAnnotations.png]
On Wed, Jun 27, 2018 at 11:32 AM Sebastien Jourdain < notifications@github.com> wrote:
Ok now I have the freedom to print what ever, but I would need guidance in term of what you want to see...
[image: screen shot 2018-06-27 at 9 30 36 am] https://user-images.githubusercontent.com/294518/41984051-e6a33112-79ec-11e8-8bec-10d505a1cb1e.png
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Kitware/paraview-glance/issues/112#issuecomment-400718545, or mute the thread https://github.com/notifications/unsubscribe-auth/AAREr2HmndbB0L9B4Lr7PGmhGGiyE3-1ks5uA6VwgaJpZM4U5vXv .
--
Stephen R. Aylward, Ph.D. Senior Director of Strategic Initiatives, Kitware, Inc., North Carolina http://www.kitware.com and http://www.aylward.org (919) 969-6990 x300
but we should not allow folks to move to physical slice that doesn't align with a data/index slice of the primary image.
Having an non-interpolated mode is indeed important, it allows to duplicate the behavior of a radiology workstation.
That said, when you build a more sophisticated application, interpolating between slices would be needed:
Slicer does not show any slice index but only physical coordinates
Indeed, we do not show the slice index (that said, generally, you can obtain it adding one to the IJK coordinate displayed in the probe)
Am I understanding right that the volview label ( 56 y, 55 y )
represent the range of that slice?
This both give us the axis and thickness of that slice? In some of our dataset we could get ( 34.12 x, 33.12 x)
, would that be correct?
It seems that Osirix do both:
Thickness: 3.00 mm Location: -561.50mm
and
-67 y M
(but not sure what M means)
I'll add methods to retrieve Thickness/Location as well.
I have that so far. (Location drop to the second line if the window is not wide enough.
Regretfully few formats support specifying slice thickness. It is different from slice spacing. Thickness is related to the size of the point-spread-function used to acquire/reconstruct the data. For convenience rendering assumes that spacing and thickness are the same. So, instead of Thickness lets report spacing
How about:
Upper Left for static info: (Orientation) Image size: III x JJJ (Image size shown depends on orientation wrt volume)
Lower Left for slice-specific info: (OrientationBox/Axis) (useful to map to colors/orientation in 3D) KKK of NNN (Current slice of NNN possible slices) Spacing: S.SS mm (Spacing between this slice and next in this orientation) Origin: XXX, YYY, ZZZ (slice origin, not volume origin, changes as you move slices, in physical space)
Lower Right for view-specific info: (ValueAtCursor) (CursorI), (CursorJ), (CursorK) / (CursorX), (CursorY), (CursorZ)
(Give IJK and XYZ coordinates)* WL: LLLL / WW: WWW
?
On Wed, Jun 27, 2018 at 12:27 PM Sebastien Jourdain < notifications@github.com> wrote:
I have that so far. (Location drop to the second line if the window is not wide enough.
[image: screen shot 2018-06-27 at 10 25 20 am] https://user-images.githubusercontent.com/294518/41986831-90ef216a-79f4-11e8-8a1c-e3956298cfc5.png
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Kitware/paraview-glance/issues/112#issuecomment-400741239, or mute the thread https://github.com/notifications/unsubscribe-auth/AAREr303sXKzIhkrehIySjLKYrDCAxwdks5uA7JjgaJpZM4U5vXv .
Each view has a selector for its orientation, so that information is already readable on each view. Do we want to duplicate the (Orientation) information?
I'll update the annotations to match your suggestion.
Great point - let's not duplicate that info. No need for it in an annotation.
On Thu, Jun 28, 2018 at 10:13 AM Sebastien Jourdain < notifications@github.com> wrote:
Each view has a selector for its orientation, so that information is already readable on each view. Do we want to duplicate the (Orientation) information?
I'll update the annotations to match your suggestion.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Kitware/paraview-glance/issues/112#issuecomment-401049318, or mute the thread https://github.com/notifications/unsubscribe-auth/AARErxOhOO_yzza6O1MKboHRQWJIOsSqks5uBOSRgaJpZM4U5vXv .
There is an issue with the lower left corner since we have our orientation axis there.
Moreover, because of the gradient, the bottom is usually not good, unless we change the text color. (which is also possible)
Is it really what we want for the Image size: Width x Heigh
location?
Two options: 1) Remove Image size for now. 2) Move the orientation axis up - to be just above the Image size info.
Happy to do whatever you think is best (most aesthetic).
s
On Thu, Jun 28, 2018 at 12:21 PM Sebastien Jourdain < notifications@github.com> wrote:
Is it really what we want for the Image size: Width x Heigh location?
[image: screen shot 2018-06-28 at 10 20 20 am] https://user-images.githubusercontent.com/294518/42047239-fcf93242-7abc-11e8-9533-efaf4478194b.png
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Kitware/paraview-glance/issues/112#issuecomment-401092153, or mute the thread https://github.com/notifications/unsubscribe-auth/AAREr9TBjOVoDHsn-GH412e4SF0JvTdyks5uBQKBgaJpZM4U5vXv .
3) Put it on top-left 4) Put it on bottom-right
So many choices!
I say 1 - for now. The problem with 3 and 4 is that they break the organization/allocation of info.
On Thu, Jun 28, 2018 at 12:56 PM Sebastien Jourdain < notifications@github.com> wrote:
- Put it on top-left
- Put it on bottom-right
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Kitware/paraview-glance/issues/112#issuecomment-401103112, or mute the thread https://github.com/notifications/unsubscribe-auth/AAREr4q7ckw6ho7gtM-oy1XWRkSQ5bkSks5uBQrAgaJpZM4U5vXv .
it is sad in the sense that it was working awesome even when you were rolling the camera, the W x H will automatically switch ;-)
Anyhow, I'll remove it from the template for now. Thanks!
What about moving the orientation axis on the top right corner and shift the camera control tools?
That way the camera orientation axis and the buttons that control the camera are somehow collocated?
I dunno. Perhaps try in 2 places and see what others think during Monday's meeting.
On Thu, Jun 28, 2018 at 1:38 PM Sebastien Jourdain notifications@github.com wrote:
What about moving the orientation axis on the top right corner and shift the camera control tools?
That way the camera orientation axis and the buttons that control the camera are somehow collocated?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Kitware/paraview-glance/issues/112#issuecomment-401115604, or mute the thread https://github.com/notifications/unsubscribe-auth/AARErzv5Iq1yCzT2UiDAdkdzjZvj0TPNks5uBRSpgaJpZM4U5vXv .
I'll add a bunch of screenshots here, then you can pick the one you like on Monday since I'll be in vacations.
I end up putting it in the center as moving the orientation axis was not trivial.
Looks good to me!
Thanks!
On Thu, Jun 28, 2018 at 6:18 PM Sebastien Jourdain notifications@github.com wrote:
I end up putting it in the center as moving the orientation axis was not trivial.
[image: screen shot 2018-06-28 at 3 36 39 pm] https://user-images.githubusercontent.com/294518/42063416-c6ca78ac-7aee-11e8-9835-e04e82a1036c.png
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Kitware/paraview-glance/issues/112#issuecomment-401190145, or mute the thread https://github.com/notifications/unsubscribe-auth/AAREr-yYUdfcVaUAPAkxRauRh6RlV4Sgks5uBVYYgaJpZM4U5vXv .
Only issue I see is that we show the physical coordinate on the left hand side (under slices), and the index in the 2d view overlays (top left corner of views)
Great catch - the sliders on the left hand panel should be given in terms of slice number - not physical coordinates.
Thanks Alexis and Seb!
When displaying anatomical oriented data in an MPR viewer, the slice views are slicing through the world space and not the data space, which glance does properly. However, in that case, using the term "Slice number" is incorrect since we are not displaying one slice of the data but a reconstructed slice along a world axis at a certain distance from the world origin (in mm).
I would, therefore, recommend to:
replace
Dataset > Slices > Slices
byDataset > Slices > Slicing
in the left bar of the UIallow for decimals in the X/Y/Z values (currently shows ...)
replace
Slice ${value}
by${value} mm
orSlicing at ${value} mm
in the label overlay within the 2d view