Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MIP method of thicknessMethod probably don't consider the current slice orientation #392

Open
1 of 7 tasks
andy23512 opened this issue Aug 28, 2019 · 6 comments
Open
1 of 7 tasks

Comments

@andy23512
Copy link
Contributor

Description

When using MIP method (default thickness method with some >0 thickness slice setting) with non-axial slice, it displays some repeated pattern. It seems like the direction that max intensity is calculated is not perpendicular to the slice plane. I am not sure if this is the expected result of MIP, or it is really a bug.

For example, this is a part of coronal view without MIP method (slice thickness = 0)
mipoff
And when MIP method is turned on, the pattern are repeated (and there is no such problem in the axial view).
mipon

Live Demo

Similar behavior can be found in the geometries slice example.
Set thickness to some value > 10. In some direction, you would see some ripple-like pattern and the bright area seems expanded.
Screen Shot 2019-08-29 at 00 31 47

Browsers Affected

  • All
  • Chrome
  • Firefox
  • Edge
  • Safari 9
  • Safari 8
  • IE 11

Versions

  • AMI: locally using v0.22.0, don't know which version is used by the demo site (have cloned and run the latest code, it has the same problem.)
  • THREEJS: locally using v0.93.0, demo site using v0.107.0
@NicolasRannou
Copy link
Member

Interesting, so I guess the normal is not set properly anymore at: https://github.com/FNNDSC/ami/blob/master/src/shaders/shaders.data.vertex.js#L8

It only works in 1 direction right?

Maybe we must also attach the normals here: https://github.com/FNNDSC/ami/blob/master/src/geometries/geometries.slice.js#L113

or call .computeVertexNormals () .

Can you call '.computeVertexNormals () ' then '.normalizeNormals ()' on the buffer geometry of the slice in your code .to see if that helps?

@andy23512
Copy link
Contributor Author

Thanks for the rapid response.
Call '.computeVertexNormals () ' then '.normalizeNormals ()' works in the geometries_slice example. But it does not work for the code I am working on (It's a more complex case that loading a coronal-direction stack). At least now I have some hint for solving it.

@andy23512
Copy link
Contributor Author

andy23512 commented Aug 29, 2019

Ok. After some tries, I think the problem in my case is not caused by the normal vector not updated.
In my case, there are two views, axial view and coronal view.
When I load an axial-direction stack, there is no problem in both views when using MIP method.
But when I load a coronal-direction stack, there is problem (as mentioned above) in coronal view when using MIP method.
My thought is if the direction of normal vector is correctly updated (since no problem when loading axial-direction stack), then the problem might be the data direction is not consistent with the three.js world direction. Is there any hint to figure this out or one coronal-direction dicom image to reproduce this problem?

@andy23512
Copy link
Contributor Author

andy23512 commented Aug 31, 2019

I've generated a fake dicom file (with coronal direction stack). It has black-white stripe image at odd index, and whole gray image at even index. So if the MIP is correctly applied, the expected result should be gray-white stripe image.

But the behavior is that the white area expands as the thickness increases. The result can be viewed at https://codesandbox.io/embed/ami-lesson-03-tz610.

@ikkyunsong
Copy link

I am struggling with this issue. I am wondering if this issue has been resolved.

@ikkyunsong
Copy link

ikkyunsong commented Feb 15, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants