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.
Part Number: DLP2010EVM-LC
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) ?
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Kyle Rakos:
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:
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.
In reply to 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.
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 ?
In reply to Guillaume STRUB:
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.
Here is what I got testing the RGB565 image you provided:
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?
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.