Open csireszabolcs opened 1 year ago
so seems like that study and that series T2 HAST AX is not completely orthonormal
then since MPR pick axial view it causes those artifacts in the ends. So I don't think anything is wrong.
it is same for other oblique acuqisitions too like this study and this series https://viewer-dev.ohif.org/viewer?StudyInstanceUIDs=1.3.6.1.4.1.14519.5.2.1.3671.4754.298665348758363466150039312520&hangingprotocolid=mpr
as you see it has cut of in the ends because of oblique acquisition.
If you wish to render it like stack viewport, you should choose the correct normal for the camera (not axial) which you can get/calculate from row and column cosines
Are you going to support such cases? And recalculate orientation based on those values for each series? So it is shown straight.
you can use crosshairs to rotate volume
This is related to the new orientations that we need to make regarding axial, sag and coronal for oblique
Describe the Bug
First and last image of a series are partially loaded or rendered to VolumeViewport using WADO-URI and streaming-image-volume-loader. The issue doesn't occur on every series, however can be always reproduced on the specific ones. With StackViewport it works properly, but if I know right it uses a different image loader.
It seems like two new partially loaded images are added to the start and the end of the series, and there is a small offset as images are slightly different to the ones in StackViewport.
Different example in OHIF Viewer: link
Steps to Reproduce
Note: In the top right corner image number is 42 instead of 40
The current behavior
First and last image of a series are partially loaded or rendered to VolumeViewport using WADO-URI and streaming-image-volume-loader.
The expected behavior
Images are loaded properly to VolumeViewport using WADO-URI
OS
Windows11
Node version
16.20.1
Browser
Chrome 115.0.5790.171, Firefox 115.0.3