TI DLP® “Diamond” Pixel

Fig. 1 DLP Diamond Pixel (above) compared to test pattern (below)

TI’s DLP® WVGA (848×480) and WXGA (1280×800) microdisplays use what are commonly known as “diamond” pixels.  This article will explain what these pixels look like, their effect on image quality, and the reason behind diamond pixel.

As a side note: all the pictures of projected images were taken on a Qumi 1280×800 projector using the HDMI (digital) input driven at the “native” 1280×800 resolution to try and give the best possible source image.

Diamond Pixel Organization

Fig. 2 Diamond Pixel Column and Row Numbering

Fig. 2 Show how the “diamond pixels” are organized.  The pixels themselves are square, but they are rotated 45 degrees and fit like tiles in a zig-zag arrangement.  The Columns and row numbering are based on how the memory bit (signified by the red dot in Fig. 2) for each pixel is address.  You should notice that the columns numbering is more spread out than the row numbering.  For a WVGA (848×480) there are 608 columns [roughly 848/sqrt(2)] and 684 rows [roughly 480xsqrt(2)].  Note that if you multiple 608 x 864 you will get slightly more than 848×480 so there are roughly the same number “pixels.”  Details on this organization for the WVGA can be found in the DLP® 0.3 WVGA Series 220 DMD data sheet.   For the WXGA (1280×800) there are about 910 columns by 1136 rows (the datasheet is not publicly available).

Image Re-sampling Effect of Diamond Pixels

Fig. 3 Simplified Diamond Pixel Re-sampling

The image quality issues with diamond pixels comes from trying to “re-sample” (remap) the pixels from a normal square grid to the “diamond grid.  Fig. 3 Show shows a simplified example of the problem.  There are two black pixels labeled “A” and “B” shown.  On the left side of the figure, the green grid shows the normal/square array of pixels and it is overlaid with the the diamond grid in red.  As can be seen pixel A straddles/touches pixels 1 through 5 in the diamond grid and pixel B straddles pixels 5 though 11.   There is no really good way to map the pixels.  If you you just mapped to the nearest pixel on the diamond grid, it would cause severe jaggies, so it is best to re-sample/filter the pixels onto the diamond grid.

On the right hand side of Fig. 3, I did a simple weighting of the areas of overlap to remap the pixels.   Notice how the pixels have blurred out.  Also notice that the two black pixels end up mapping into different shapes in on the diamond grid because their relative alignment between the square and diamond grid is different.

TI’s DLP uses more complex algorithms than those used in Fig 3 that attempt to reduce the blurring by sharping (particularly in the horizontal direction) or allowing more jagged artifacts (in the vertical direction).  Any algorithm/filtering/re-sampling by necessity will be a compromise between jagged pixel artifacts and blurring. 

Fig. 4 below shows a close-up of a series of simple test patterns of a checkerboard, horizontal lines, and vertical lines with a picture of the projected image from a test pattern.    The checkerboard is pretty well obliterated in the DLP’s re-sampling process and you see what is known as a classic under-sampling problem where you see the “difference frequency” or a low resolution version of the repeating pattern.  It is also interesting is that the artifacts are different in the horizontal and vertical direction because they use different re-sampling algorithms horizontally and vertically.

Fig. 4 Closeup of Checkerboard, Horizontal Lines, and Vertical Lines compared to test pattern

Fig. 5 below shows more more of the test pattern (click on image to see all the detail – at the end of this article, I have included the whole the test image used so you can duplicate this test).   The longer lines in the test pattern are suppose to be 4 alternating black and white lines.  Where the 4 line pairs cross there are some strange effects (one of which is circled).   On vertical lines or groups of lines there is the occasional “ghost line” (some of which are pointed to with red arrows); these are as a result of the horizontal filtering/re-sampling process.   Vertical lines generally look a little better but they have that ghosts lines (“sharpening halos”) as a result of trying to keep from loosing sharpness.

The vertical re-sampling process (which shows up in horizontal lines) is much simpler and results in more jagged artifacts and less effective resolution.   You can also see in the dot in the letter “i” in the “8 Point Arial” how a single pixel blurs out over multiple pixels in the diamond grid of pixels.  Notice how all the dots in the “i’s” vary (circled in red) and in the Arial 10 point font the dots in the letters “i” even point in different directions.

Fig. 5 Diamond Pixel Projected Image of Center of Test Pattern

Why DLP Uses Diamond Pixel

The “marketing spin” I have heard for the diamond pixel organization is that it can give perceptively better resolution.  But this could only be true if the source image is much higher resolution than the displayed image.  As the pictures above demonstrate, about the worst case image is to drive the Diamond Pixel with its supposed “native” resolution.

At least one real reason that the TI DLP® uses the diamond arrangement is to try and reduce the projector’s thickness.   DLP’s require “off axis illumination” which means the light comes into the mirror array non-perpendicular to the surface.  When the mirror is tilted “on,” the angle of the mirror directs the light toward the projection lens. The current DLP mirrors tilt approximately +/- 12 degrees and they tilt diagonally (at 45 degrees).

Fig. 6 Light Paths for “Square” versus “Diamond” Pixel Arrangement

With normal/square mirror arrays (left half of FIG. 6) this would mean that for light to go out of the projector the light must come from above or below projection lens.  But in order to have the illumination light come from above or below the projection lens would make the projector much thicker.   This was not an issue for DLP in RPTVs or larger data projectors, but with Pico Projectors, customers care a lot about thickness.   The “Diamond Mirror Solution” was to rotate the mirrors so that the light could be in the same plane (right half of Fig. 6) as the projected image.


While the diamond pixels address the thickness issue, they definitely hurt resolution and cause artifacts and a loss of resolution.  The obvious problem is that a single pixel on a rectangular grid will cover part of at least 4 or more pixels on the diamond grid.  So there has to be some scaling/filtering to map the pixels from the rectangular grid onto the diamond grid.   The DLP ASIC tries to combat this blurring in the horizontal direction by filtering and sharpening.  The vertical processing is simpler and results in more jaggies.

Many of the problems with DLP’s diamond pixel are closely related to the resolution problems of Laser beam scanning that I wrote about in a previous article (see: https://www.kguttag.com/2012/01/09/cynics-guild-to-ces-measuring-resolution/).  Namely, it is the problem of trying to re-sample the original image to fit a grid or scanning process that does not match the original image.  Even if the number of “pixels” is the same, the re-sampling process hurts resolution and causes unwanted artifacts (for those engineers in the audience, it is a classic Nyquist sampling issue).

In optical terms DLP optics are “off-axis” which means the illumination of the display is not perpendicular to the imager.  Off-Axis optics are always bigger and their light path takes up more volume.  The diamond rotation keeps this volume from increasing thickness, but still the volume of a DLP optical engine tends to be bigger for the same F-number and Focal Length optics.   In general, DLP “pico projectors tend to have longer throw ratios (longer focal length lenses) and this may be due to trying to keep the optics from becoming larger.


Below is the test pattern used to create the images above on a DLP 1280×800 projector.  To use this correctly, you need to drive the HDMI input of the projector at 1280×800.

I have included a similar test pattern for WVGA (848×480) that can be used with the WVGA DLP projectors like the PK201 or  Microvision’s ShowWX/+/HDMI projectors.  Additionally, I have included a 720p (1280×720) version of the test patter in case you come across a 720p projector.

I would like to thank Paul Anderson for taking the picture of the test pattern on his 1280×800 DLP Qumi Projector that I used in this article.

1280×800 Test Pattern:

848×480 Test Pattern:

720P Test Pattern:

Karl Guttag
Karl Guttag
Articles: 244


  1. Karl ,Thanks for your detial analysis,
    I just read the DLP 3000 specification. and detect that DLP efficiency is 68%.
    one thing need your help to understand is what’s the diffraction efficiency on their spec?

    • When you considerthe DLP (or LCOS) mirror array as a whole it looks like a reflective diffraction grating. The diffraction loss is as a result of the light interfering with itself caused by discontinuity from the gap between the mirrors and by the “dimple” in the center of the pixel. The amount of diffraction loss is a function of the gaps between the mirrors, dimple size, and the wavelengths of light. As the mirrors become small and numerous, the diffraction losses become very significant.

      The more obvious loss with an array of mirrors is the “fill factor” which is simply the ratio of the area of the mirror to the area of the mirror plus the gap. In the case of the DLP 3000 spec, this is 92%. Doing some quick calculations, the DLP has a mirror pitch of 7.637 microns and to get a 92% fill factor this makes the gap ~0.311 Microns and the mirror itself is ~7.325 microns on a side (7.325^2 / 7.637^2 = 92%). It is a bit funny that they specify the mirror “pitch” and the fill factor but never directly come out and state the mirror to mirror spacing.

      As you will notice the more obvious fill factor efficiency of 92% is actually a a little better than the less obvious diffraction efficiency of 86%. It turns out that at small mirror sizes these losses are pretty close to each other. As a quick approximation, the diffraction efficiency is approximately equal to the fill factor loss (actually a bit worse). This means that the combined loss of fill factor times diffraction is greater than the fill factor squared! Since fill factor is also an area function (square law), what may seem like small differences in cell gaps has a dramatic effect on light throughput.

      Because LCOS is a “planar process” with no moving parts, the gap between pixels can be made much smaller. Currently LCOS has a gap between mirrors of about 0.2 Microns compared to 0.311 microns for the DLP. With a 7.637 Micron pitch using a 0.2 micron gap, LCOS would have a fill factor X diffraction throughput of about 90% whereas DLP is at about 79% or LCOS has about a 13% advantage.

      To go to HD resolutions, the pixels have to get much smaller making the diffraction and fill factor losses much more significant. If you keep the two mirror pitches the same as they are today (both will likely get smaller over time), then at 4.5 micron pitch LCOS diffraction x fill factor efficiency is about 83% whereas DLP will be only about 61% or LCOS will have about a 36% advantage. At a 4 micron pixel pitch, the diffraction X fill factor for LCOS throughput would be about 82% whereas DLP is only about 54% or about a 1.51X difference advantage for LCOS!

      The fill factor times diffraction is one of the big reasons that LCOS has a significant advantage over DLP going forward with small HD displays.

      • On the fill factor: I have found elsewhere that the 10.8um pitch pixel has a 0.6um gap. 10.2^2 / 10.8^2 = 89.2%, which is less than the stated 92.5% a TI employee responded was correct (http://e2e.ti.com/support/dlp__mems_micro-electro-mechanical_systems/f/94/t/5683.aspx) That 10.2um doesn’t even count the Via. Something seems off. Any insight as to whether the 0.6um gap is correct or the 92.5% fill factor is correct.

        On the diffraction efficiency. I had never considered this before, but I think it makes sense. What are you using for equations to determine this? There are a lot of variables like the angles of incidence and average wavelength to consider. And obviously how exactly you’re getting the blaze angle out of the geometry of the DLPs. Any hints on what you’re doing on this would be appreciated.

      • I don’t have the numbers for the 10.8um pitch at hand. There is always some amount of variability in what is “drawn” and what is actual plus it doesn’t take much rounding with a the square to change things a bit. Then of course you have to account for the tilting of the DLP.

        Things get really extreme as the pixel pitch goes down. I believe DLP is on the order of 0.3 Microns (plus or minus 0.01 depending on the source) for their “pico.” I used a spreadsheet calculation that is pretty rough based on some basic formulas for the diffraction. The most interesting thing I found was that as the pixel pitch approach 5 microns, the diffraction effect and the fill factor are nearly equal with diffraction being worse before 5 microns. The light losses due to diffraction and fill factor are multiplicative so this means that approximately the losses are fill factor squared. Thus you have the square of a square type effect going on so the cell gap becomes extremely important at small pixel sizes.

  2. Karl,Thanks very much for your Great answers.
    I guess the 92% fill factor is based on non operation state. it may be worse while on-state due to angle effect.
    But at another side ,DLP don’t have Liquid Crystal layer to cause Reflectivity loss.

  3. We know LCOS panel have better power consumption level compared with DLP panel.
    But no doubt TI is good at IC design and their driver IC seems have better power control.
    I believe DLP and lcos Driver IC have similar function and may have samilar power consumption .
    LCOS company should to improve their IC design further .
    Although 100mW level is meanless compared with LED power ,
    it is very important in further Embeddable products,

  4. Karl,
    We are working on a dlp based light engine that can reach 15 lm/w (led power). Is there a LCOS light engine at such efficiency available now? If so, we’d like to try it too.

    Also Bord’s question was good one. Driving system takes lots of power. A scaler easily tales 1.5w plus power. A mhl chip takes .5w.

    • I don’t think there is an LCOS with LED light engine that can get to 15 lm/W of LED power, at least one that is practical today. The problem is that the polarization conversion even with some recovery/recycling looses too much light up front. LCOS tends to win out on the overall power at lower lumen levels (say below 30 lumens).

      LCOS should eventually be more efficient than DLP with Laser light sources where the lasers inherently provide polarized light and as pixels get smaller diffraction becomes more of a factor. Frequency doubled green lasers will likely lead the way particularly at higher brightness (greater than 50 lumens). For small embedded projectors, direct green diode lasers will probably be required.

      As far as “scalers” go and power, I guess that depends on what you mean by “scaling” and the complexity of it. Syndiant’s new ASIC does simple scaling and even keystone correction and takes very little power (http://www.picoprojector-info.com/files/picoprojector/SYL2271-Product-Brief.pdf)

  5. Esta tecnología debe prohibirse POR ENGAÑO Y ESTAFA.
    Estamos hablando de un proyector con una resolución 1280×800 y una resolución “real” inferior a 800×600 nativos en square grid. INADMISIBLE, pues muchos de los usos a los que se puede destinar un proyector quedan anulados por esta flagrante falta de resolución.

    [Google Translation added by ADMIN]
    This technology should be banned BY DECEPTION AND FRAUD.
    We’re talking about a projector with a resolution 1280 × 800 resolution and a “real” less than 800 × 600 native grid square. Inadmissible, since many of the uses to which you can assign a projector are overridden by this blatant lack of resolution.

  6. Sorry for wrote in spanish. With this technology… ¿Why hd movies? ¿Why ANY HD CONTENT? The quality shown should be under REAL sd resolution. It´s a very very bad idea from TI.

    • I don’t understand why this device used the “Diamond Pixel” arrangement on the WXGA device. It has roughly the same number of mirrors, but it forces everything to be rescaled. The WXGA is going in mini-projectors (rather than pico projectors) that don’t have the need for absolute thinness of a pico. They started using diamond pixels on the WVGA (848×480) device that they were trying to shoe horn into a pico projector inside a phone and the diamomd pixel enabled a thinner optical engine. But the WXGA (1280×800) device is going into 100 to 500 lumen projectors that are way too big to fit inside a phone.

      I don’t think most people will notice the problem on movies except maybe for some occasional motion artifacts. The diamond pixel is most problematical on high resolution and high contrast images such as computer generated text and graphic. If the content is sent “natively” to the projector at a higher resolution (say 1080p), then I would think it only gets scaled one to the diamond pixel grid so it should be no worse than scaling it to a “square” grid 720p. The worst case will be if say 720P or 1280×800 native content is sent to the projector which causes what would be sharp content to be blurred and have added artifacts from the resampling onto the diamond grid.

    Here it’s about DLP: sub-pixels RGB are at the same location but multiplexed in time (colour wheel) or using 3DLP chips (and focused at the same place on the screen)
    On a OLED or LCD, sub-pixels are distinct so all this stuff in Black and White is absolutily false.

    PS: why isn’t there a 45deg lignes pattern and just pure horizontal and vertical (not very frequent in a movie) ?

  8. This is a very interesting article. It explains very clearly the mapping problems, and the underestimated difraction problem.

    I found however rather disturbing that the author, who obviously masters his subject, completely ignores the fact that the quality problem is caused only by trying to map a “cross space” native image onto a “diamond space” native image. The quality loss would be identical if the mapping was the other way around, i.e. from a native “diamond space” image onto a “cross space” display device.

    It just so happens that the chosen native image sources in the tests were generated for a “cross space”. It is reasonable in order to expose the effect in an article, it is not if it is to evaluate the intrinsic qualities of a diamond versus cross display device. What if the native image was generated in the diamond space? It is a bit like feeding a BGR LCD display (remember the very early LCD panels) with a Cleartype image generated for a RGB display: the fringes are colored. So what? Generated a BGR and everything falls back on its feet.

    I am sure the author did not mean to imply that diamond displays were intrinsicly wrong (he mentions that the number of actual pixels is unaffected by orientation), however the conclusion is at the very minimum misleading (“diamond pixels definitely hurt resolution and cause artifacts and a loss of resolution”). Most if not all comments take also that conclusion for granted.

    So let’s be quite clear: if the image was generated in the diamond space, there would be absolutely no loss of quality on a diamond display compared to a cross space generated image displayed on a cross display. If that diamond image was mapped onto a cross display, the same loss would be observed. The problem exposed in this article is simply the mismatch between the source and the display, it is NOT related to diamond pixels.

    Now the question is of course: are images generated natively for diamond displays *today*? Not quite yet, we’re still in the transition phase, a bit like for the early LCD panels, where not using an exact multiple of the native resolution showed horrible artifacts.
    However, I do not doubt that most deskptop or mobile OS will includde such algorithms soon. It took just a couple of years to have Cleartype-like technolgies take advantage of the 3-color pixels, then Pentile pixels were handled correctly, etc.

    As an example, my company moved from XGA DLPs (cross) to 1080p (cross) and is now porting a family of projectors to the WVGA DLP family (diamond). The standard ASIC shipped in the developper’s kit is almost unusable except for video input (where it performs very well, but as mentioned in the article the issue is a lot less severe for video sources). With our own control and native “diamond” image generation, we have exactly the same quality we’ve always had on our structured light. Our only concerns are of course the sharpness of the screen borders, but that’s absolutely minimal.

    • I’m not sure how seriously to take your protestations. 99.9999…..% of all images today are generated on a square grid, be that your PC, TV, or camera. I don’t see any significant movement toward generating diamond grid images as you suggests. Many (about 30) years ago I saw a paper (by Zenith I believe) that TV would be better off with diagonal grid but nobody took them up on it. And I don’t see the whole world changing in the next 30 years because TI has a diamond pixel.

      The common issue is that the projectors “lie” to the PC or TV and say that they have the native resolution of the square grid. Thus the PC/TV even if it uses a higher resolution source it first scales the source to the “native” square grid. The projector will then take the “native” image and scale it to the diamond grid causing the artifacts shown.

      Certainly if you are scaling one one space to another and do it in a single conversion, you would only encounter the scaling losses once and there would be little if any perceived difference and as you suggest diagonal lines would look better. But this assumes they don’t intermediately convert to the rectangular grid of the “native” resolution which is what any PC or TV system using an attached projector would do today to go over the standard HDMI, DVI, Displayport, or VGA connection.

      It sounds like in your case you are generating a “native” diamond structured light pattern (for some form of image/gesture recognition I assume). You are right in this case, that it does not matter and it would resolve diagonal lines better, but this is a very specialized application and not the main intended use for these displays.

      You are correct that displays often “cheat” on counting pixel resolution particularly in the color domain, the Pentile Pixel being one such example. Heck still camera “pixels” count each of the R, G, and B photo sites as a “pixel.” As you say, even with and RGB triad, the R, G, and B are perfectly misaligned which causes some resolution loss which Cleartype tries to recover by effectively controlling the intensity of the 3 colors.

      All this being true, it does not take away from the fact that the Diamond Pixel degrades significantly the effective resolution in a typical projected environment, particularly when using a high resolution native image.

      • 99.9999.. % is probably right… today. Just like the sub-pixel font aliasing capabilities of Trinitron tubes were never used, there is a market threshold that needs to be reached in order for a technology to become available and then ubquitous.

        Part of the equation is also the simplicity of the implementation, which is very favorable in this case: generating for diamond pixels is trivial on a PC. There is a minor drawback regarding memory (GPUs rasterization process is intrinsicly “crossed”, so if you want to generate a “diamond” image, you have to add a rotation to the projection matrices, which does not cost any speed but does cost in terms of memory footprint because of unused corners), but it is also a very straightforward algorithm.

        What I believe is that once the various OS implement a font-rendering algorithm which takes into account the pixel layout (as you mention, this requires the displays to “inform” the OS in some way, instead of lying to it like today), the momentum will be strong enough. Windows has laid out a superb infrastructure for things like this and much more with Direct2D. Other devices limited to OpenGL ES 2.0 will have more problems, but even with DX9/OpenGL 3 the implementation is quite straightforward, and more importantly comes at no performance penalty.

        What will be left then when you have converted user interface, video streams and 3D-rendering? Icons, and … vintage sprite-based games 🙂 Icons have already gone through a bigger revolution with their recent and massive surface inflation.

        Unfortunately, until the ball starts rolling, there will be the intermediate rectangular conversion that you mention. I don’t know what the future holds, but like I said the implementation is easy enough to hope that we will see exactly what happened for sub-pixel font-aliasing on LCD panels, with all major OS following the hardware.

        In any case, my point was not to deny the importance of the problem you mention in the article, but merely to say that it is related to an ecosystem (mismatch between traditional cross-generated images and emerging diamond-displays), not to a characteristic of the technology of diamond pixels themselves.

  9. […] For round 2 of the pico projector market, DLP and LCOS drifted away from the embedded market which wasn’t selling well and backed up (got larger) to support portable media player projectors.  The projectors required more brightness and to go brighter with LEDs meant requiring bigger microdisplays and bigger optics.   Syndiant kept the 800×600 resolution and simply made the pixels bigger.  DLP keep the pixels the same size and added more pixels to make a bigger displays, first 0.31-inch diagonal 848×480 (WVGA) and later a 1280×800 0.44-inch.    These products require larger batteries or wall plugs and more for carrying in separate bag than in your pocket.   Interestingly, DLP also rotated the mirrors 45 degrees to what they call a “diamond pixel” which causes some strange artifacts and a loss of effective resolution (the issues with diamond pixels will be discussed in a future article). […]

Leave a Reply