<p>Sorry to post such a silly solution but apparently the problem was reading 16 bit uint data into 8bit uint array. This was the reason for inexplainable noise, interleaving and other artifacts. </p>

<p>After I explored <a href="https://computergraphics.stackexchange.com/questions/9336/how-to-handle-different-data-types-uint8-uint16-float-in-volume-datasets?noredirect=1#comment14110_9336">more</a> about what the medical datasets actually represent and what flavors they come in (8,16,32bit) I managed to solve the problem.</p>

CC BY-SA 4.0
2019-11-18T10:12:41.393Z
2019-11-18T10:12:41.393Z
gallickgunner
<p>So Im trying to implement a Volume Renderer mainly for medical images like CT-scans and MRI images using GPU raymarching. I'm using the book "Real Time Volume Graphics" and <a href="http://graphicsrunner.blogspot.com/2009/01/volume-rendering-101.html" rel="nofollow noreferrer">this</a> tutorial as a refernce. </p>

<p>I'm trying to render only grayscale images as a start. I understand that the <code>pvm2raw</code> part gives us an 8-bit raw file so each voxel has the isovalue in the range [0-255]. So I decided map this single value on all color channels <code>rgba</code> when taking a sample.</p>

<p>I am taking the datasets from <a href="http://schorsch.efi.fh-nuernberg.de/data/volume/" rel="nofollow noreferrer">here</a>. <strong>You can see my Renderer's result in <a href="https://www.reddit.com/r/GraphicsProgramming/comments/chntyk/help_volume_rendering_ray_marching_not_giving/" rel="nofollow noreferrer">this</a> video</strong> (check the end of my post and sorry for not providing a direct link as I already uploaded on my reddit post)</p>

<p>As you can see the lobster dataset stretches when viewed from the side. My first guess was that I wasn't accounting for the aspect ratio correctly. I have tried scaling the Bounding box to account for the aspect ratio, then adjusting the stepsize according to that. I've also tried to ignore aspect ratio altogether. Both give similar images.</p>

<p>I tried rendering more datasets like "Knee", "Bruce's head", "DTI Scan", etc but those didn't even gave an image. There was just random noise everywhere. Here's an example of "Bruce's head"</p>

<p><a href="https://i.sstatic.net/EXyYg.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/EXyYg.png" alt="enter image description here"></a></p>

<p>This happens with both uniform and non-uniform datasets. If some datasets are getting rendered correctly like the "Foot" in my video, this should mean it's more a with that specific dataset itself rather the core algorithm. Nonetheless the link to the code is provided If anybody can point out some mistakes I'd be grateful.</p>

<p><strong><em>The link to the Compute shader is <a href="https://github.com/gallickgunner/Volume-Renderer/blob/master/VolumeRenderer.cs" rel="nofollow noreferrer">here</a>. Main functions are <code>rayMarchVolume</code>. I didn't scale the root bounding box to the dimensions of the volume, it's normalized <code>(0-1)</code>, accounted for the aspect ratio <code>(0, ar)</code> and adjusted so it's in the center <code>(-ar/2, ar/2)</code>. The function <code>cartesianToTextureCoord(vec4 point)</code> accounts for this fact and returns a texture coord in the range 0-1</em></strong></p>

<p>EDIT:- If you are hesitating to post an answer here since it's only a suggestion, you can post on Reddit, then when the problem is solved you can post your answer here</p>

<p><strong>UPDATE</strong>:- I've provided a release to this project on github. If anybody is willing to help me with this, he can download the release and run the program. Since the algorithm is based entirely inside the compute shader you can change the file easily and test your findings on the spot. Thanks.</p>

CC BY-SA 4.0
2019-08-22T07:02:12.907Z
You are computing the ray direction in camera space, but the ray origin is in world space? `eye_ray.dir = normalize(vec4(x,y,z,0));
    eye_ray.dir = normalize((main_cam.view_mat * vec4(eye_ray.dir)));
    eye_ray.origin = main_cam.eye;`
Nadir
CC BY-SA 4.0
2019-08-22T07:37:07.590Z
@Nadir - no actually the view mat, sorry for the poor naming, is actually the `view2world_mat` so it converts the direction from camera space to world space.
gallickgunner
<raymarching><volume-rendering>
Volume Rendering - Dataset not rendered correctly
gallickgunner
# Volume Rendering - Dataset not rendered correctly

(Asked by: username_0 on 2019-07-09)

So Im trying to implement a Volume Renderer mainly for medical images like CT-scans and MRI images using GPU raymarching. I'm using the book "Real Time Volume Graphics" and [this](http://graphicsrunner.blogspot.com/2009/01/volume-rendering-101.html) tutorial as a refernce.

I'm trying to render only grayscale images as a start. I understand that the `pvm2raw` part gives us an 8-bit raw file so each voxel has the isovalue in the range [0-255]. So I decided map this single value on all color channels `rgba` when taking a sample.

I am taking the datasets from [here](http://schorsch.efi.fh-nuernberg.de/data/volume/). **You can see my Renderer's result in [this](https://www.reddit.com/r/GraphicsProgramming/comments/chntyk/help_volume_rendering_ray_marching_not_giving/) video** (check the end of my post and sorry for not providing a direct link as I already uploaded on my reddit post)

As you can see the lobster dataset stretches when viewed from the side. My first guess was that I wasn't accounting for the aspect ratio correctly. I have tried scaling the Bounding box to account for the aspect ratio, then adjusting the stepsize according to that. I've also tried to ignore aspect ratio altogether. Both give similar images.

I tried rendering more datasets like "Knee", "Bruce's head", "DTI Scan", etc but those didn't even gave an image. There was just random noise everywhere. Here's an example of "Bruce's head"

[![enter image description here](https://i.sstatic.net/EXyYg.png)](https://i.sstatic.net/EXyYg.png)

This happens with both uniform and non-uniform datasets. If some datasets are getting rendered correctly like the "Foot" in my video, this should mean it's more a with that specific dataset itself rather the core algorithm. Nonetheless the link to the code is provided If anybody can point out some mistakes I'd be grateful.

***The link to the Compute shader is [here](https://github.com/username_0/Volume-Renderer/blob/master/VolumeRenderer.cs). Main functions are `rayMarchVolume`. I didn't scale the root bounding box to the dimensions of the volume, it's normalized `(0-1)`, accounted for the aspect ratio `(0, ar)` and adjusted so it's in the center `(-ar/2, ar/2)`. The function `cartesianToTextureCoord(vec4 point)` accounts for this fact and returns a texture coord in the range 0-1***

EDIT:- If you are hesitating to post an answer here since it's only a suggestion, you can post on Reddit, then when the problem is solved you can post your answer here

**UPDATE**:- I've provided a release to this project on github. If anybody is willing to help me with this, he can download the release and run the program. Since the algorithm is based entirely inside the compute shader you can change the file easily and test your findings on the spot. Thanks.

**Tags:** raymarching, volume-rendering

> **Comments:**
> **username_1**: You are computing the ray direction in camera space, but the ray origin is in world space? `eye_ray.dir = normalize(vec4(x,y,z,0));     eye_ray.dir = normalize((main_cam.view_mat * vec4(eye_ray.dir)));     eye_ray.origin = main_cam.eye;`  
> **username_0**: @username_1 - no actually the view mat, sorry for the poor naming, is actually the `view2world_mat` so it converts the direction from camera space to world space.  

---

## 1 answers

### Answer by username_0 on 2019-11-18. Score: 0 | Accepted answer

Sorry to post such a silly solution but apparently the problem was reading 16 bit uint data into 8bit uint array. This was the reason for inexplainable noise, interleaving and other artifacts.

After I explored [more](https://computergraphics.stackexchange.com/questions/9336/how-to-handle-different-data-types-uint8-uint16-float-in-volume-datasets?noredirect=1#comment14110_9336) about what the medical datasets actually represent and what flavors they come in (8,16,32bit) I managed to solve the problem.


---

