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

Multi volume #47

Merged
merged 17 commits into from
Jun 17, 2021
Merged

Multi volume #47

merged 17 commits into from
Jun 17, 2021

Conversation

benjamindkilleen
Copy link
Member

major pull request before tech report

mmjudish and others added 17 commits March 13, 2021 14:02
Changed the function parameters and handled declaration of CUDA textures

Next steps are:
- modify Projector initialization to reflect changes to kernel
- see if total_area_density[...] array is needed
- macro-ify the places in the kernel that involve repeating a step for each of the volumes
Moved the SingleProjector functionality to Projector class
The CUDA at least compiles.  Currently, the self.minPointX_gpu, etc. is giving me errors about "pycuda._driver.LogicError: cuMemcpyHtoD failed: invalid argument"
I don't get it.  Why didn't this cuda.memcpy_htod(...) bug show up earlier?  I've been using memcpy_htod(...) for a while.

Traceback (most recent call last):
  File "example_projector.py", line 117, in <module>
    main()
  File "example_projector.py", line 92, in main
    images = projector.project_over_carm_range(
  File "C:\git\deepdrr\deepdrr\projector\projector.py", line 317, in project_over_carm_range
    return self.project(*camera_projections)
  File "C:\git\deepdrr\deepdrr\projector\projector.py", line 195, in project
    cuda.memcpy_dtoh(int(self.sourceX_gpu) + (4 * vol_id), np.array([source_ijk[0]]))
Boost.Python.ArgumentError: Python argument types in
    pycuda._driver.memcpy_dtoh(int, numpy.ndarray)
did not match C++ signature:
    memcpy_dtoh(class pycudaboost::python::api::object dest, unsigned __int64 src)
Results:
1. For single volume-case, results differed BARELY for [phi=90,theta=0] and [phi=90,theta=60] -- three and one miniscule pixel regions, respectively.
2. For the three-volume case, this branch performed pretty badly.  The errors are probably from the wrapper code (?), since that's the main difference between the single-volume and three-volume case
The output for the single-volume case looks like the desired output, but really zoomed in on the central cube.  I have determined that the {minAlpha, maxAlpha} are correct by comparing the values at pixel (600,400), a pixel that shows up in the central cube for the alpha branch.
Confirmed that if we omit the portion of code in the "last segment" calculation, this code is equivalent to the alpha branch IN THE SINGLE VOLUME CASE.

Have not tested the multi-volume case.
When splicing volumes of the same material, the boundary between them it pretty obvious, even when it should be invisible.  For example, consider the following two-volume scenario:
  ____________
/___/___/___/|
|___|___ |___| |
|___|___ |___| |
|___|___ |___|/

and we define the volumes:
- volume0: all boxes, all soft tissue
- volume1: the central box, all soft tissue

The boundary between the volumes appears darker than the surrounding pixels, even though the materials are the same.  This happens regardless of whether the input is:
- [(volume0, 0), (volume1, 0)], or
- [(volume0, 1), (volume1, 0)]
Priorities "switch" is now separate from the volumes "switch".

Also established that the boundary artefact effect has something to do with the interpolation at the boundary.
Code works (multi-volume has that artefact), but some TODOs left.

Consult with Benjamin about what to do with the Projector.volume function
@benjamindkilleen benjamindkilleen merged commit 4028534 into dev Jun 17, 2021
@benjamindkilleen benjamindkilleen deleted the multi-volume branch June 17, 2021 18:20
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

Successfully merging this pull request may close these issues.

None yet

2 participants