• State TI Thinks Resolved
  • Locked Locked
  • Replies 17 replies
  • Answers 2 answers
  • Subscribers 29 subscribers
  • Views 3234 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DLP2010EVM-LC: DLPC347x Splash Pattern Issue and Questions

Guillaume STRUB
Intellectual 300 points

Part Number: DLP2010EVM-LC

Hello all,

I have been working on understanding how the Splash Pattern mode works and how to use it.

Image artifact issue

One of the major issues I found with this mode is that there are some processing artifacts impacting some of the image bit planes.

I am using the following test card, in which the green channel is mapped to the upper byte of a splash screen data word and the red channel is mapped to the lower byte.

As you may see from the projected splash patterns (8-bit mode, 1 pattern), in addition to the artifacts, there is a 3-bit shift between the expected bit location and what the DLPC347x chipset interprets. This may however easily be fixed when generating the splash image data, but the documentation does not state which bits from the image are used in which bitplane when projecting in 8-bit splash pattern mode.

The image processing artifacts are especially visible when projecting a single bitplane (1-bit mode, 1 pattern):

When using the 8-bit mode and projecting 2 patterns (not photographed here), the red source image patterns are projected correctly, while the green source image patterns are distorted.

Also, there is no such issue when projecting in standard Splash Screen Mode:

To me, it seems that even though the image processing algorithms (LABB, CAIC) are disabled, some processing is still taking place and producing artifacts on the projected image. If I enable LABB processing, the artifacts become much worse but still only affect the green source patterns (and not the red ones !), even with all sliders maxed out.

What are the possible workarounds for this problem ? Right now I only need to project static 8-bit 2D patterns, so I could live with only using the "red" channel from my images - unfortunately the only way to display that would be to use the 8-bit mode with 2 patterns with a blanked out "green" channel, but this induces heavy flicker !

I also have a couple questions regarding this mode :

- Is it possible to pause and manually advance the pattern sequence, as in the Internal Pattern Mode ?

- Is it possible to specify a single pattern to expose from a given splash screen (i.e. display an arbitrary bitplane or only the second 8-bit pattern) ?

- Is it possible to disable the linear image scaling algorithm (i.e. use nearest-neighbor interpolation) ?

Best regards,

Guillaume STRUB

  • 0
    TI__Mastermind 20045 points
    Hello Guillaume STRUB,

    I'm sorry to hear about the issues. Thanks for your description of the problem. Let us take a look into this and we will get back to you. In the meantime here are a few initial comments and questions on your follow-up questions.
    - No, I do not think this is possible
    - This is not possible
    - Could you elaborate a little more on this request? In general we strive to achieve near pixel accurate mode.


    Thanks,
    Kyle
  • 0 in reply to Kyle Rakos
    TI__Mastermind 20045 points
    Hi again,

    Could you also confirm you are using the latest GUI at www.ti.com/.../dlpdlc-gui

    Thanks,
    Kyle
  • 0 in reply to Kyle Rakos
    Intellectual 300 points

    Hi Kyle,

    It's unfortunate that there is no API for finer-grained control of the splash pattern API. During my testing I found out that in some conditions, it was possible to freeze the current bitplane, but this was only as a result of a crash or bad commad. I hoped there was a cleaner way to do it.

    I am interested in using nearest-neighbor interpolation instead of linear interpolation as a means to save flash space, by using half-resolution splash images. When using linear interpolation, the edges are not as clear and crisp as if pixel doubling was used. Furthermore, when interpolating a black and white image, the scaler introduces grayscale levels, which result in totally different bitplane data in splash pattern mode.

    Regarding the GUI : I am using a custom implementation of the I2C API in C++, but I get the same results when using the latest GUI

    Also, I observed (since the new version lets you specify the number of patterns to display) that in 1-bit mode, some values for the setting "patterns per frame" are much more sensitive to the timing parameters that the rest of the values. For instance, when specifying the timings as PreEDT=2500, Exposure=10000, PostEDT=500, all number of patterns work, except for the following:

    • 3, 6, 14 : no image
    • 11 : very low brightness image

    Best regards,

    Guillaume STRUB

  • 0 in reply to Kyle Rakos
    TI__Expert 5485 points

    Hi Guillaume,

    Splash images are stored in one of two 16-bit image formats, RGB565 or YCbCr. This can be selected in Step 3 of the latest version of the DLPDLC-GUI's "Update Flash Image" page. For pattern projection, please ensure that the image is stored in RGB format to ensure accurate reproduction of pixel data.

    While converting an RGB888 image to RGB565 format, the GUI drops 3 (2 in case of green channel) LSbits of each color to achieve 16-bit pixel data.

    For a better understanding of how splash pattern mode works, I'd suggest you to try projecting this image on the DLP2010EVM-LC:

    This image consists of 16 stripes, 5 corresponding to the MSbits of red and blue and 6 corresponding to MSbits of green. If stored in RGB format and projected in 8-bit splash pattern mode, the images displayed would look like two 8-step horizontal ramps placed side by side.

    Hope this helps.

    Regards

    Azad

  • 0 in reply to Azad
    Intellectual 300 points

    Dear Azad,

    Thank your for your answer. Using your test pattern I indeed obtain one, or two 8-step horizontal ramps depending on the number of patterns I specify in the interface.

    However, this does not solve my issue, which is the appearance of artefacts in the splash pattern mode.

    More specifically, it seems that these artefacts appear if you have high frequency content on some bits, e.g. the RGB565 green MSbit.

    I corrected my image conversion function so that the "green" and "red" channels of my source image are mapped respectively to the first and second 8-bit patterns in splash pattern mode, taking the bit shift into account.

    Source image

    Image converted to RGB565, shown as 24-bit format (this is what the projector shows in standard splash mode) :

    On my EVM, projecting this image in 8-bit, 1 pattern mode results in a lot of artefacts on the red-colored zones from the source image, which should remain black

    Could you try this image (the directly above RGB565 image) in splash pattern mode on one of your evaluation modules ?

    Best regards,

    Guillaume

  • 0 in reply to Guillaume STRUB
    Intellectual 300 points

    Hello,

    Do you have any update on this issue ?

    Right now I can alleviate the artifact issue by reducing the bit depth of the source image (thus using 5 bits out of the 16 bits of a RGB565 splash image) but this is not a satisfying solution.

    Best regards,

    Guillaume

  • 0 in reply to Guillaume STRUB
    TI__Expert 5485 points
    Hi Guillaume,

    We've identified a bug in the GUI and are working on fixing it. We'll keep you posted.

    Regards
    Azad
  • 0 in reply to Azad
    Intellectual 300 points
    Hi Azad,
    Thank you for your answer.
    However, I would like to point out that I experience the same artifact issue whether I am using the GUI or directly controlling the EVM over I²C.
    Best regards,
    Guillaume
  • 0 in reply to Guillaume STRUB
    TI__Expert 5485 points
    Hi Guillaume,

    The bug is related to the way the GUI packs pixel data while adding splash images using the Update Flash Image feature.

    Regards
    Azad
  • 0 in reply to Azad
    TI__Expert 5485 points

    Hi Guillaume,

    Here is what I got testing the RGB565 image you provided:

    Splash Image:

    Splash pattern (8-bit, 1 pattern):

    Splash pattern (8-bit, 2 patterns) [Note this is a composite image of 2 patterns]:

    Is this what you expected?

    Regards

    Azad

  • 0 in reply to Azad
    Intellectual 300 points

    Hi Azad,

    Thanks a lot for trying the splash image on your own hardware.

    The results you posted are exactly the same as what I observe here. They exhibit artifacts which are not in the original red and green image (which I have shown in my original posting)

    For reference, this is how the test card should look when projected

    Splash pattern, 8-bit, 1 pattern :

    Splash pattern, 8-bit, 2 patterns :

    Best regards,

    Guillaume STRUB

  • 0 in reply to Guillaume STRUB
    TI__Expert 5485 points
    Hi Guillaume,

    I suspect this to be an artifact arising due to an image processing limitation of the DLPC347x controller. I'm working on confirming this with my colleagues.

    If this is indeed the case then the workaround would be to use source images with lesser high frequency pixel data. I'll get back to you with more information after confirming the details.

    Regards
    Azad
  • 0 in reply to Azad
    Intellectual 300 points

    Dear Azad,

    Thank you for your feedback regarding this issue.

    From my testing it appears that at some point the splash screen is processed as RGB565 even though in splash pattern mode it is displayed as two 8-bit images.

    Indeed, it seems that the artifacts appear when pattern data spans the R and G channels or the B and G channels ; one workaround is to limit the bit depth of the splash screen image to 3 bits (pattern MSBs on the lower 3 green bits) on the first pattern and 5 bits (blue channel only) on the second pattern.

    Maybe one could use the full 5 red bits (which correspond to the 1st pattern's LSBs) by changing the sequences used for splash pattern projection, if 8-bit projection is truly not possible ?

    Best regards,

    Guillaume STRUB

  • 0 in reply to Guillaume STRUB
    TI__Expert 5485 points
    Hi Guillaume,

    Have you tried using only the Red and Blue channels of the image and leaving the Green channel empty? I'd suggest using RGB888 images as the software converts it into RGB565 before uploading to flash.

    Please try an RGB888 image with pattern data in the Red and Blue channels only (if you haven't already).

    Regards
    Azad
  • 0 in reply to Azad
    TI__Expert 5485 points
    Hi Guillaume,

    I haven't heard back from you in some time, were you able to try my suggestion.

    I'm marking this thread resolved, feel free to re-open it.

    Regards
    Azad
  • 0 in reply to Azad
    Intellectual 300 points

    Hi Azad,

    The red-green image I used as my "reference" image is actually never sent as-is to the projector or into the DLP GUI ; it is just a convenient way to show the two separate patterns I intend to show on the projector.

    I use a Python script to convert it into a RGB565 image for updating the projector Flash ; actually I tried both using the DLP GUI and building the Splash section using Python scripts (which gives me better control over the channel mapping), but with exactly the same results wrt the artifact issue. The mapping is as follows :

    Patterns A and B A7 A6 A5 A4 A3 A2 A1 A0 B7 B6 B5 B4 B3 B2 B1 B0
    RGB 565 image G2 G1 G0 R4 R3 R2 R1 R0 B4 B3 B2 B1 B0 G5 G4 G3

    As I observed previously, artifacts can appear if a pattern uses more than one channel in the resulting RGB565 image :

    • The first pattern uses the 3 lower green bits, and the whole red channel.
    • The second pattern uses the whole blue channel, and the 3 upper green bits.

    The artifacts seem to appear when the most significant bit of the "lower" channel (i.e. R4 for the 1st pattern and G5 for the 2nd pattern) changes rapidly (e.g. in gradients).

    One workaround is to only use the "most significant channel", that is, the 3 lower green bits on the first pattern and the blue channel for the second pattern.
    Then the resulting image is free of artifacts :

    Patterns A and B A7 A6 A5 B7 B6 B5 B4 B3
    RGB 565 image G2 G1 G0 R4 R3 R2 R1 R0 B4 B3 B2 B1 B0 G5 G4 G3

    This, however, limits the bit depth one can use in the splash pattern mode.

    If the image processing issue causing these artifacts cannot be resolved, would it be possible to change the splash pattern DLP sequence in one of the following ways ?

    • Two 5-bit patterns, using only the red channel and the blue channel of the RGB565 image:
      Patterns A and B A4 A3 A2 A1 A0 B4 B3 B2 B1 B0
      RGB 565 image G2 G1 G0 R4 R3 R2 R1 R0 B4 B3 B2 B1 B0 G5 G4 G3

      or
    • Three patterns, using each channel of the RGB565 image ; i.e. one 6-bit pattern and two 5-bit patterns:
      Patterns A,B and C A2 A1 A0 B4 B3 B2 B1 B0 C4 C3 C2 C1 C0 A5 A4 A3
      RGB 565 image G2 G1 G0 R4 R3 R2 R1 R0 B4 B3 B2 B1 B0 G5 G4 G3

    Best regards,

    Guillaume Strub

  • 0 in reply to Guillaume STRUB
    TI__Expert 5485 points
    Hi Guillaume,

    Unfortunately, we don't have the bandwidth to re-work the sequences. We're working on documentation to explain a workaround to this issue, I'll let you know when this is available.

    Regards
    Azad