<p>Yes, and there are several ways this can apply. First off though, we need to fix a misconception in your diagram. Even if pixels really were square, the volume contributing to the pixel gets wider as it gets further away from the image plane, because of perspective. For a square pixel, the volume would be a square pyramid, whose apex is at the camera. It's not quite a <em>regular</em> square pyramid, because the apex is not in the centre of the square: the outer pixels are very skewed. But pixels aren't square anyway, they're cone-shaped.</p>

<p>First off, some people have experimented with <em>cone tracing</em>, where instead of a single ray, you trace a cone with a half-angle determined from the area of the image covered. It's not very popular, because when the cone intersects the edge of a polygon, you need special handling for the remainder of the cone - the part that wasn't blocked by the polygon. For a square pyramid, it's a little easier, because you can change the shape of the base as parts of the pyramid are blocked, but it's still tricky and slow.</p>

<p>You also don't gain much from this technique compared to just <em>supersampling</em>. Even if you trace rays, you don't just trace a single ray through the centre of each pixel. You trace many rays across the area of the pixel, and use a <em>reconstruction filter</em> to take the shape of the pixel into account. This technique has many possibilities that cone tracing doesn't offer: it works better with volumes, you can jitter your samples to avoid structured artefacts, you can use full path-tracing techniques, etc.</p>

<p>Another area where the pixel size matters is in texture sampling. If you want to get nice texturing, you don't just take a point sample of the texture, you set some <em>filter width</em> according to the area of the texture the sample relates to. This doesn't just make your sampling more efficient by using the right mipmap level: it is required for correct sampling to avoid sampling artefacts. In a GPU fragment shader, you might use the <code>dFdx</code> and <code>dFdy</code> functions to do this. In a ray-tracer, you might have use a cone-tracing style of carrying the filter width with the ray, initially based on the level of supersampling at the camera, but updated whenever a child ray is spawned.</p>

CC BY-SA 3.0
2018-04-21T08:50:52.313Z
2018-04-21T08:50:52.313Z
Dan Hulme
<p>From what I'm reading, it looks like a ray tracer views a pixel as one color and computes that color using the ray starting in the center of that pixel. Yet a pixel has a width and a height.</p>

<p>Do we ever use the actual square (now a day pixels are considered squares) that the pixel represents to calculate it true color from all possible source within that entire square?</p>

<p>I am thinking that this is how we come up with colors on edges of shapes in scanline rendering and was wondering whether the same could be applied to ray tracing.</p>

<p>There is a picture which I hope better represents what I am trying to ask here. Should we only consider the pixels to be single points? Or are we to consider pixels as <em>large</em> areas?</p>

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

CC BY-SA 3.0
2018-04-20T18:42:39.267Z
This article "A pixel is not a square"(http://alvyray.com/Memos/CG/Microsoft/6_pixel.pdf) would be helpful to your understanding of a pixel.
TheBusyTypist
CC BY-SA 3.0
2018-04-20T20:49:20.013Z
@TheBusyTypist fun reading but quite misleading. I do love how it starts with "This is not a religious issue" and then pretty much makes it into one.
Olivier
CC BY-SA 3.0
2018-04-21T02:38:52.707Z
afaik, pixels are considered as areas, that is why we have the concept of multiple samples per pixel and it's a way of implementing anti aliasing.
gallickgunner
CC BY-SA 3.0
2018-04-21T05:40:54.240Z
@TheBusyTypist Interesting read, but when you calculate an image you want to make it perfect. He's mixing the display of the result with the result and he's complaining about the positioning (_pixel center_), which does make some algorithms easier to handle. As the wandering warrior says, it's useful to consider a pixel as being a small square to mix partial pixels together and get _perfect_anti-aliasing. Here, though, I'm wondering about the potential effect in Ray Tracing. Maybe what I need to do is generate a bigger image and then scale it down to make sure I get the right colors...
Alexis Wilke
CC BY-SA 3.0
2018-04-21T12:49:10.790Z
@wandering-warrior No a pixel is a sample its no more a square than a sound samples are lines. Though, considering it a square is not a bad model, just not the best one. Evaluating the sample over better sampling is better. In fact if pixel is a area it should consider stuff outside of a square area. Because the perfect representation of a pixel is not square.
joojaa
<raytracing><pixels>
Do we ever consider the size of the pixel to calculate the color in Ray Tracing?
Alexis Wilke
# Do we ever consider the size of the pixel to calculate the color in Ray Tracing?

(Asked by: username_0 on 2018-04-20)

From what I'm reading, it looks like a ray tracer views a pixel as one color and computes that color using the ray starting in the center of that pixel. Yet a pixel has a width and a height.

Do we ever use the actual square (now a day pixels are considered squares) that the pixel represents to calculate it true color from all possible source within that entire square?

I am thinking that this is how we come up with colors on edges of shapes in scanline rendering and was wondering whether the same could be applied to ray tracing.

There is a picture which I hope better represents what I am trying to ask here. Should we only consider the pixels to be single points? Or are we to consider pixels as *large* areas?

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

**Tags:** raytracing, pixels

> **Comments:**
> **username_1**: This article "A pixel is not a square"(http://alvyray.com/Memos/CG/Microsoft/6_pixel.pdf) would be helpful to your understanding of a pixel.  
> **username_2**: @username_1 fun reading but quite misleading. I do love how it starts with "This is not a religious issue" and then pretty much makes it into one.  
> **username_3**: afaik, pixels are considered as areas, that is why we have the concept of multiple samples per pixel and it's a way of implementing anti aliasing.  
> **username_0**: @username_1 Interesting read, but when you calculate an image you want to make it perfect. He's mixing the display of the result with the result and he's complaining about the positioning (_pixel center_), which does make some algorithms easier to handle. As the wandering warrior says, it's useful to consider a pixel as being a small square to mix partial pixels together and get _perfect_anti-aliasing. Here, though, I'm wondering about the potential effect in Ray Tracing. Maybe what I need to do is generate a bigger image and then scale it down to make sure I get the right colors...  
> **username_4**: @wandering-warrior No a pixel is a sample its no more a square than a sound samples are lines. Though, considering it a square is not a bad model, just not the best one. Evaluating the sample over better sampling is better. In fact if pixel is a area it should consider stuff outside of a square area. Because the perfect representation of a pixel is not square.  

---

## 1 answers

### Answer by username_5 on 2018-04-21. Score: 4 | Accepted answer

Yes, and there are several ways this can apply. First off though, we need to fix a misconception in your diagram. Even if pixels really were square, the volume contributing to the pixel gets wider as it gets further away from the image plane, because of perspective. For a square pixel, the volume would be a square pyramid, whose apex is at the camera. It's not quite a *regular* square pyramid, because the apex is not in the centre of the square: the outer pixels are very skewed. But pixels aren't square anyway, they're cone-shaped.

First off, some people have experimented with *cone tracing*, where instead of a single ray, you trace a cone with a half-angle determined from the area of the image covered. It's not very popular, because when the cone intersects the edge of a polygon, you need special handling for the remainder of the cone - the part that wasn't blocked by the polygon. For a square pyramid, it's a little easier, because you can change the shape of the base as parts of the pyramid are blocked, but it's still tricky and slow.

You also don't gain much from this technique compared to just *supersampling*. Even if you trace rays, you don't just trace a single ray through the centre of each pixel. You trace many rays across the area of the pixel, and use a *reconstruction filter* to take the shape of the pixel into account. This technique has many possibilities that cone tracing doesn't offer: it works better with volumes, you can jitter your samples to avoid structured artefacts, you can use full path-tracing techniques, etc.

Another area where the pixel size matters is in texture sampling. If you want to get nice texturing, you don't just take a point sample of the texture, you set some *filter width* according to the area of the texture the sample relates to. This doesn't just make your sampling more efficient by using the right mipmap level: it is required for correct sampling to avoid sampling artefacts. In a GPU fragment shader, you might use the `dFdx` and `dFdy` functions to do this. In a ray-tracer, you might have use a cone-tracing style of carrying the filter width with the ray, initially based on the level of supersampling at the camera, but updated whenever a child ray is spawned.


---

