<h2>This is perfectly possible</h2>

<p>Although the difference may not especially noticeable, I would expect sampling taking into account the exact <a href="https://en.wikipedia.org/wiki/Pixel_geometry" rel="noreferrer">pixel geometry</a> to give a slightly more accurate image. You just need to offset your pixel centres per colour component according to the (average) location of the subpixel(s) of that colour. Note that not all pixel layouts have a one to one correspondence between pixels and sub pixels.</p>

<p>For example, <a href="https://en.wikipedia.org/wiki/PenTile_matrix_family#PenTile_RGBG" rel="noreferrer">penTile RGBG</a> has twice as many green subpixels as red and blue, as this image from Wikipedia shows:</p>

<p><a href="https://en.wikipedia.org/wiki/PenTile_matrix_family#/media/File:Nexus_one_screen_microscope.jpg" rel="noreferrer"><img src="https://i.sstatic.net/oB5Rn.png" alt="Close up image of RGBG pixel geometry"></a></p>

<p>I am not aware of any technical reason that would prevent this being used to produce arbitrary full colour images. In fact a colourful scene will have less noticeable colour artefacts than black on white text, which makes the colour differences hardest to camouflage.</p>

<h2>Fonts are rendered on demand</h2>

<p>The relevant difference between rendering a raytraced scene and rendering fonts is that fonts tend to be rendered on demand, and can take into account the screen being used. Contrasting with this, a raytraced scene is often prerendered and then displayed on many different types of screen (with different pixel geometry). For example, displaying your raytraced image on a webpage will prevent tailoring it to a specific monitor type.</p>

<p>If you were designing a realtime raytracing program and you had access to check the pixel geometry of the monitor, then you could raytrace to the specific sub pixel layout. However, offline raytracing that produces a still image can only be tailored to a single type of pixel geometry, which will then make the image look <em>worse</em> on any other pixel geometry. You could work around this by rendering a set of different images and choosing the appropriate one when it is later displayed on a particular type of monitor.</p>

<h2>There is unlikely to be a long term benefit</h2>

<p>So there is no reason you couldn't develop sub pixel rendering for a raytracer, but it means taking into account an aspect of the monitor that is not always known. Another thing to bear in mind is that you will be developing this software for a shrinking market. Sub pixel rendering is useful for screens that have relatively low resolution. As more and more screens (even mobile screens) are approaching such high resolution that the human eye cannot detect the difference made by sub pixel rendering, your work is likely to be more of theoretical interest than practical use.</p>

CC BY-SA 3.0
2015-09-03T18:30:18.223Z
Playing devil's advocate, if possible to do color subpixel rendering (i'm a skeptic!), it seems like it could be useful in VR situations, where they struggle to have sufficient resolution.  Perhaps on (non retina?) phones or tables as well?
Alan Wolfe
CC BY-SA 3.0
2015-09-03T18:36:03.860Z
@AlanWolfe yes but its also 3 times as expensive to render
joojaa
CC BY-SA 3.0
2015-09-03T18:39:14.930Z
yeah for sure, that's true. There are some situations where that isn't a problem though.  For instance, I know of a couple algorithms where you don't need to shoot rays for every pixel every frame.  It seems like this could also have play in rasterized graphics btw.  Again, i am not convinced color subpixel rendering is a real thing, but ya know, IF! :P
Alan Wolfe
CC BY-SA 3.0
2015-09-03T19:10:56.147Z
@AlanWolfe I don't understand your doubts. All images are already rendered with sub pixels, but the colours are misaligned by between a third and a half of a pixel. I can't see how correcting that misalignment would fail to produce a higher quality image. Do you have any specific concerns (which might make a good question...)?
trichoplax is on Codidact now
CC BY-SA 3.0
2015-09-03T20:02:04.447Z
@trichoplax Quality would riase at the cost of portability and simplicity. Not a good trade if the quality increase is minuscule. Its more important to know the color profile of the device than this.
joojaa
CC BY-SA 3.0
2015-09-03T21:57:48.737Z
@joojaa I agree that the effort is unlikely to be worth it. I'm just asserting that it is possible. My final section is meant as advice to not work on this unless there is a purely theoretical interest.
trichoplax is on Codidact now
CC BY-SA 3.0
2015-09-03T23:02:28.283Z
@joojaa There's no reason it would be 3x as expensive to render. You wouldn't need to shoot 3x the number of rays; you'd just apply 3 different weights when accumulating the rays into the framebuffer. Effectively, you're using a different antialiasing kernel for each color channel.
Nathan Reed
CC BY-SA 3.0
2015-09-03T17:28:50.833Z
2015-09-03T17:43:37.623Z
2015-09-03T17:43:37.623Z
trichoplax is on Codidact now
<p>Sure, you <a href="http://new.ics.ele.tue.nl/~dehaan/pdf/90_jsid2003.pdf">can use subpixel rendering for arbitrary images.</a>  However, subpixel rendering is really a generic 2D image processing technique &mdash; it has nothing to do with ray tracing specifically.  You could just as well use it with any other 3D rendering method, or even with a simple 2D drawing, photograph or even video.</p>

<p>Thus, I'd say that "subpixel rendering for ray tracing" is really conflating two distinct problem domains that are best treated separately.  About the only relevant connection is that, if you're ray tracing the scene in real time and know that the resulting image is going to be drawn on the screen using subpixel rendering, you can use this information to optimize the pixel density (and aspect ratio) of the intermediate image (e.g. using 3x horizontal pixel density for a typical RGB LCD screen).</p>

<hr>

<p>A potential source of confusion may be that, on current computer system, subpixel rendering is commonly used only for text, and is typically integrated into the font rendering code.  The main reasons for this are arguably historical, but it's also where the biggest payoffs (in terms of visual improvement and readability) typically are.</p>

<p>Also, due to the way text tends to consist of simple and repetitive vector shapes, integrating the subpixel rendering into the font renderer offers some extra optimization opportunities over just rendering the text into a high-resolution buffer and then postprocessing it.</p>

<p>That said, I fully expect that eventually, as technology matures, we'll move to a system where subpixel rendering is simply done transparently by the GPU, or possibly by the screen itself.</p>

<p>(This will most likely require applications that want to make full use of this feature to deal with physical pixels that are smaller, and not necessarily the same shape as, the "logical pixels".  But then again, we're already moving in that direction with high-DPI screens.)</p>

CC BY-SA 3.0
2015-09-04T17:17:42.007Z
Tervetuloa! Yes your point is valid, id say that the system or hardware has to do this as only the system can in future realisticallt be aware of the orientation of screen and the organisation of colors on screen. Preferably the screen itself would do this.
joojaa
CC BY-SA 3.0
2015-09-03T21:46:36.893Z
2015-09-03T21:46:36.893Z
Ilmari Karonen
<p>In font rendering, it is common to use <a href="https://en.wikipedia.org/wiki/Subpixel_rendering">subpixel rendering</a>.  The basic idea here is to break the pixel into its RGB components and then compute a value for each separately.  Since each component is smaller than the entire pixel, higher quality antialiasing is possible.</p>

<p>There is an obviously analogous way to do the same for a ray tracer.  You do reconstruction filtering on each subchannel separately.</p>

<p>I was surprised that, however, I couldn't really find reference to ray tracers doing this.  Especially if you're already doing spectral rendering, this seems like an obvious thing to do.  There's <a href="http://wscg.zcu.cz/wscg2012/full/E03-full.pdf">this paper</a> from a journal I've never heard of which seems to be related.  But overall, subpixel rendering just doesn't seem to be a common thing to do.  My question: <strong>why not</strong>?</p>

CC BY-SA 3.0
2015-09-03T18:28:39.267Z
Will your subpixel-rendered images still look okay if viewed on screens in a portrait orientation?
jamesdlin
CC BY-SA 3.0
2015-09-11T02:00:10.627Z
as an engineer I would never agree to implement such a... broken idea. EXCEPT if I'm sure the display is totally fixed. like an appli for iPhone 5S. Using this technique generates broken images from screens using reversed patterns, or different arrangements.
v.oddou
<raytracing><antialiasing><subpixel-rendering>
Subpixel Rendering for a Ray Tracer
geometrian
# Subpixel Rendering for a Ray Tracer

(Asked by: username_0 on 2015-09-03)

In font rendering, it is common to use [subpixel rendering](https://en.wikipedia.org/wiki/Subpixel_rendering). The basic idea here is to break the pixel into its RGB components and then compute a value for each separately. Since each component is smaller than the entire pixel, higher quality antialiasing is possible.

There is an obviously analogous way to do the same for a ray tracer. You do reconstruction filtering on each subchannel separately.

I was surprised that, however, I couldn't really find reference to ray tracers doing this. Especially if you're already doing spectral rendering, this seems like an obvious thing to do. There's [this paper](http://wscg.zcu.cz/wscg2012/full/E03-full.pdf) from a journal I've never heard of which seems to be related. But overall, subpixel rendering just doesn't seem to be a common thing to do. My question: **why not**?

**Tags:** raytracing, antialiasing, subpixel-rendering

> **Comments:**
> **username_1**: Will your subpixel-rendered images still look okay if viewed on screens in a portrait orientation?  
> **username_2**: as an engineer I would never agree to implement such a... broken idea. EXCEPT if I'm sure the display is totally fixed. like an appli for iPhone 5S. Using this technique generates broken images from screens using reversed patterns, or different arrangements.  

---

## 2 answers

### Answer by username_3 on 2015-09-03. Score: 14

## This is perfectly possible

Although the difference may not especially noticeable, I would expect sampling taking into account the exact [pixel geometry](https://en.wikipedia.org/wiki/Pixel_geometry) to give a slightly more accurate image. You just need to offset your pixel centres per colour component according to the (average) location of the subpixel(s) of that colour. Note that not all pixel layouts have a one to one correspondence between pixels and sub pixels.

For example, [penTile RGBG](https://en.wikipedia.org/wiki/PenTile_matrix_family#PenTile_RGBG) has twice as many green subpixels as red and blue, as this image from Wikipedia shows:

[![Close up image of RGBG pixel geometry](https://i.sstatic.net/oB5Rn.png)](https://en.wikipedia.org/wiki/PenTile_matrix_family#/media/File:Nexus_one_screen_microscope.jpg)

I am not aware of any technical reason that would prevent this being used to produce arbitrary full colour images. In fact a colourful scene will have less noticeable colour artefacts than black on white text, which makes the colour differences hardest to camouflage.

## Fonts are rendered on demand

The relevant difference between rendering a raytraced scene and rendering fonts is that fonts tend to be rendered on demand, and can take into account the screen being used. Contrasting with this, a raytraced scene is often prerendered and then displayed on many different types of screen (with different pixel geometry). For example, displaying your raytraced image on a webpage will prevent tailoring it to a specific monitor type.

If you were designing a realtime raytracing program and you had access to check the pixel geometry of the monitor, then you could raytrace to the specific sub pixel layout. However, offline raytracing that produces a still image can only be tailored to a single type of pixel geometry, which will then make the image look *worse* on any other pixel geometry. You could work around this by rendering a set of different images and choosing the appropriate one when it is later displayed on a particular type of monitor.

## There is unlikely to be a long term benefit

So there is no reason you couldn't develop sub pixel rendering for a raytracer, but it means taking into account an aspect of the monitor that is not always known. Another thing to bear in mind is that you will be developing this software for a shrinking market. Sub pixel rendering is useful for screens that have relatively low resolution. As more and more screens (even mobile screens) are approaching such high resolution that the human eye cannot detect the difference made by sub pixel rendering, your work is likely to be more of theoretical interest than practical use.

> **Comments:**
> **username_4**: Playing devil's advocate, if possible to do color subpixel rendering (i'm a skeptic!), it seems like it could be useful in VR situations, where they struggle to have sufficient resolution.  Perhaps on (non retina?) phones or tables as well?  
> **username_5**: @username_4 yes but its also 3 times as expensive to render  
> **username_4**: yeah for sure, that's true. There are some situations where that isn't a problem though.  For instance, I know of a couple algorithms where you don't need to shoot rays for every pixel every frame.  It seems like this could also have play in rasterized graphics btw.  Again, i am not convinced color subpixel rendering is a real thing, but ya know, IF! :P  
> **username_3**: @username_4 I don't understand your doubts. All images are already rendered with sub pixels, but the colours are misaligned by between a third and a half of a pixel. I can't see how correcting that misalignment would fail to produce a higher quality image. Do you have any specific concerns (which might make a good question...)?  
> **username_5**: @username_3 Quality would riase at the cost of portability and simplicity. Not a good trade if the quality increase is minuscule. Its more important to know the color profile of the device than this.  
> **username_3**: @username_5 I agree that the effort is unlikely to be worth it. I'm just asserting that it is possible. My final section is meant as advice to not work on this unless there is a purely theoretical interest.  
> **username_6**: @username_5 There's no reason it would be 3x as expensive to render. You wouldn't need to shoot 3x the number of rays; you'd just apply 3 different weights when accumulating the rays into the framebuffer. Effectively, you're using a different antialiasing kernel for each color channel.  

---

### Answer by username_7 on 2015-09-03. Score: 9

Sure, you [can use subpixel rendering for arbitrary images.](http://new.ics.ele.tue.nl/~dehaan/pdf/90_jsid2003.pdf) However, subpixel rendering is really a generic 2D image processing technique — it has nothing to do with ray tracing specifically. You could just as well use it with any other 3D rendering method, or even with a simple 2D drawing, photograph or even video.

Thus, I'd say that "subpixel rendering for ray tracing" is really conflating two distinct problem domains that are best treated separately. About the only relevant connection is that, if you're ray tracing the scene in real time and know that the resulting image is going to be drawn on the screen using subpixel rendering, you can use this information to optimize the pixel density (and aspect ratio) of the intermediate image (e.g. using 3x horizontal pixel density for a typical RGB LCD screen).

---

A potential source of confusion may be that, on current computer system, subpixel rendering is commonly used only for text, and is typically integrated into the font rendering code. The main reasons for this are arguably historical, but it's also where the biggest payoffs (in terms of visual improvement and readability) typically are.

Also, due to the way text tends to consist of simple and repetitive vector shapes, integrating the subpixel rendering into the font renderer offers some extra optimization opportunities over just rendering the text into a high-resolution buffer and then postprocessing it.

That said, I fully expect that eventually, as technology matures, we'll move to a system where subpixel rendering is simply done transparently by the GPU, or possibly by the screen itself.

(This will most likely require applications that want to make full use of this feature to deal with physical pixels that are smaller, and not necessarily the same shape as, the "logical pixels". But then again, we're already moving in that direction with high-DPI screens.)

> **Comments:**
> **username_5**: Tervetuloa! Yes your point is valid, id say that the system or hardware has to do this as only the system can in future realisticallt be aware of the orientation of screen and the organisation of colors on screen. Preferably the screen itself would do this.  

---

