DVI Grayscale Format

Hi Eric,

Welcome to DLP & MEMS forum.

Syuppose if you are interested to send 24 binary frames in DVI port then you will need to pack them as explained below.

To exaplin this better let me identify each of 24 binary frames with number say 0,1,...,23. 

Input 24 individual binary frame => o/p single 24bpp RGB888 frame

binary frame - 0 = bit7 of RED

binary frame - 1 = bit6 of RED

....

binary frame - 7 = bit0 of RED

binary frame - 8 = bit7 of GREEN

binary frame - 9 = bit6 of GREEN

....

binary frame - 15 = bit0 of GREEN

binary frame - 16 = bit7 of BLUE

binary frame - 17 = bit6 of BLUE

....

binary frame - 23 = bit0 of BLUE

For example -

To send 1 binary frame then the entire binary frame data has to be populated into Red Bit0 of each pixel 1024*768. Similarly for 3 patterns then data needs to be populated into Red Bit0, Bit1 and Bit2.

Regards,
Sanjeev

Hello Sanjeev,

I thought setting it to 3 patterns would result in 3  8-bit grayscale images being displayed, since 3 patterns x 8bits/pattern = 24 bits; however, what you indicate is that it results in 3  monochrome images being displayed. So is 8-bit grayscale not possible in this mode?

Thanks,

Eric

Hi Eric,

8-bit grayscale is possible.

In my earlier explanation I was referring to binary frames and how they are to be packed. The place where I referred to 3 patterns basically meant  3 binary frames and how they will be packed.

You should be able to display 3 grayscale (8-bit) patterns from DVI port.

Note when you are sending 3 8bit patterns the packing would be as follows -

1st 8bit frame    => Red [bit7:bit0]

2nd 8bit frame   => Green [bit7:bit0]

3rd 8bit frame    => Blue [bit7:bit0]

Regards,

Sanjeev

Hello Sanjeev,

Thanks for the clarification. I now have a related question. When using the static image buffer, what api function do you use to transfer an 8-bit grayscale image to external memory. In the past I have used the DLP_Img_DownloadBitplanePatternToExtMem function to download 1-bpp images, but it is unclear how I would use that function to download 8-bit images.

Regards,

Eric

Hi Eric,

I think this particular discussion thread started to understand Strcutured Light from DVI port. In this context let me be specific to point out that "Static image buffer is NOT applicable to performing structured light from DVI port " this only applies to downloading patterns via USB.

About using DLP_Img_DownloadBitplanePatternToExtMem  API I answered to one of the user earlier under topic "Downloading 8bpp .bmp to LightCommander"

Use this link http://e2e.ti.com/support/dlp__mems_micro-electro-mechanical_systems/f/387/p/129054/462386.aspx#462386

Regards,

Sanjeev

Hello Sanjeev,

Sorry for the confusion as to which mode I am working in, but I do need to understand both modes. Now I am switching the topic back to performing structured light from the DVI port. I configured the LightCommander to structured light mode at 8-bpp with DVI input at a 60Hz frame rate, and I used a photodetector and oscilloscope to verify the widths of the 8 bits. I expected each bit to be double the length of the bit prior to it, but I found the 4 lowest order bits were all equal in length, each about 164 us. From there it was correct with each higher order bit double the length of the previous bit. Is that the way the LightCommander has implemented 8-bit grayscale mode?

Regards,

Eric

Hi Eric,

For 8bit grayscale images the display time will be doubled from lsb bit to msb bit. The bit-time for the lowest bit (bit0) starts around ~20uSec and roughly it doubles for each higher bit with highest bit (bit7) ~2495uSec for each 8bit frame.

Can you attach the LightCommander Project? Also let me know the version details. You can goto LightCommander(TM) Control Software ->Help->About LightCommander Control and copy the contents displyed.

Thanks,

Sanjeev

Hi Eric,

By the way can you load "full white" 8bit grayscale image and measure the timings?

Regards,

Sanjeev

Hello Sanjeev,

I have attached my project which includes 3 solutions, one for each of 1, 2, and 3 patterns per frame.

Here are the versions:
   API version 2.0.1

   Timeline Compiler Version 1.5.0.0

   MCU Version 2.1.5

   Hardware revision 1.0.363

The measured bit-times for all white frames are in the table below. It appears that the smallest bit-time is stuck at 162 us.

Best regards,

Eric

Eric,

Your project looks correct to me so is the LightCommander(TM) system software versions.

I shouldn't have told you to try with full white pattern as it will complicated  for bit-time measurement. This is because all the bit-planes will be shown with white back ground.

I suspect the problem with RGB888 data input to the projector because I got good reading using the same attached project.

Using - 1_Images_per_frame solution

bit7 = ~7.97mSec
bit6 = ~3.98mSec
bit5 = ~1.98mSec
bit4 = 1.000mSec (1000uSec)
bit3 = 500.00uSec
bit2 = 250.2uSec
bit1 = 120.uSec
bit0 = 54.0uSec

Using - 3_Images_per_frame soltuion

bit7 - 7.95mSec
bit6 - 3.9mSec
bit5 - 2.0mSec
bit4 - 1.0mSec
bit3 - 496uSec
bit2 - 259uSec
bit1 - 120uSec
bit0 - 60.0uSec

How are you measuring individual bit-time?

For example - When you are trying 1_Image_Per_frame - You can connect PC DVI o/p and detect it as secondary monitor. Then adjust DesktopBackground (I tried on Windows Machine) to NONE adjust RGB color (0,1,0) , (0,2,0,), (0,4,0), (0,8,0), (0,16,0),(0,32,0),(0,64,0),(0,128,0)  and measure. This will help to show individual bit-plane only and measurement will be more accurate.

Note - The Green channel setting (on PC side) mapped to 1st frame,  Red channel settings (on PC side) mapped to 2nd frame and Blue channel settings (on PC side) mapped to 3rd frame.

If you are still getting same problem, you can try with another DVI source.

Regards,

Sanjeev

Hello Sanjeev,

Doing what you described above with the Windows desktop, I get the same measurements as before.

Using - 1_Image_per_frame solution

bit7 = ~8.44 mSec  (Measured from rising edge of bit7 to rising edge of next trigger)
bit6 = ~3.98 mSec
bit5 = ~1.99 mSec
bit4 = 996 uSec
bit3 = 498 uSec
bit2 = 249 uSec
bit1 = 160 uSec
bit0 = 160 uSec

I am using an external light source to illuminate the DMD and am measuring the reflected light using a photodetector and oscilloscope. Could it be that for bit-times < 160 uSec the internal LED's are used to create the gating and not the DMD?  That could explain why I see a minimum bit-time of 160 uSec and you do not.

Regards,

Eric

Hi Eric,

Answer is "No". The internal LEDs never performs the gating functionality; it is the DMD which control the light output.

The point is as long as the illumination output is not varying then based on the selected bit-width you should be able to see the changes on the photodetector.

This also makes me to think if it could be due to incorrect reading from the Photodetector at short light puleses. Just to make sure please check if the photodetector is able to read the light pulses of < 160uSec duration.

Also let me know details of the light source (wavelength) and lumens o/p by it.

Regards,
Sanjeev

Hello Sanjeev,

We are using a Thorlabs PDA100A photodetector of which the bandwidth is dependent upon the gain setting. I took some measurements with the photodetector configured to a bandwidth of 1.2 MHz, see attached. For these images the LightCommander was set to 8-bit structured light mode, video input, and 3 images per frame. The video data alternated between switching all DMD mirrors ON / OFF, so for a single image the sequence of all the mirrors would be Bit 1 ON - Bit  2 OFF - Bit 3 ON - Bit 4 OFF - Bit 5 ON - Bit 6 OFF - Bit 7 ON - Bit 8 OFF. The file 8-Bits_Alternating_1.2MHzDetector.tif shows one full image plus the start of the next image. 6-Bits_Alternating_1.2MHzDetecto.tif zooms in to the first 5 bits. From this image it is clear that the first 4 bits are all 160 us in length and that all bits reach steady state. File RisingEdge_1.2MHzDetector.tif shows only the rising edge of the first bit. (Is the ringing due to the DMD mirrors bouncing around a bit after switching?) File RisingEdge_200kHzDetector.tif also shows only the rising edge of the first bit but the photodetector is configured to 200kHz. This shows the photodetector output reaching 90% of steady state within 10us.

What is interesting is that if I switch the LightCommander to 2 or 1 images per frame, the minimum bit width is always 160us.

Regarding the light source, we are illuminating the dmd by shining a 12V dc halogen lamp (750,000 cd, 3200 K color temp) onto a white screen. I do not have a good answer for how many lumens are hitting the mirrors, but from the images I believe we have plenty of SNR.

All is well if this is how the LightCommander is supposed to operate, because I know how wide the 4 LSB's are supposed to be. However, you have indicated that the 4 LSB's should be shorter than 160us.

Best regards,

Eric

Hi Eric,

Thank you sharing the signal measurements. You brought out two things -

1) LSB bits showing the same time 160uSec when in SL mode with source from DVI.

2) 1st bit raise time shows the light measured is toggling for a duration around 12uSec and then reaching steady state.

On the #1 using our internal tool the bit timing generation showed the bit exposure chaning from ~65uSec (LSB bit) to ~8.3mSec(MSB bit). Your practical data proves it is not. I will go back and further investigate on this.

On #2 i will check with our DMD design guys and get back to you more on this. I am interested to know how important is this factor for your research or experiment? If you would like please share this information with us.

For the 2 or 1 image per frame setting do you mean all the 8bits of frame showing same timing of 160uSec?

Regards,

Sanjeev

Hello Sanjeev,

Thanks for rechecking #1.

Regarding #2, it would be nice to have confirmation that the DMD mirrors bounce a bit after switching, but this is not holding us up in any way.

Regarding what the bit times are for the 2 or 1 image per frame setting, the bit times we observe are the just the ideal times we would expect except that any bit time less than 160us has been lengthened to 160us, so the bit resulting bit time is the greater of 160us or the ideal bit time.

Regards,

Eric

Hi Eric,

I have the findings for you.

You will be able to get the bit time more than 160uSec setting only if you choose 1 image per frame at 60Hz. If you want more than 1 image per frame say 2 or 3 i would recommend you to reduce the frame rate. For example when you run at 20Hz then you can accomodate 3 images per frame where the lowest bit is exposed for duration more than 160uSec.

Please find the reasons for your observation.

#1. Ringing effect - 

[Comment] Yes this time is called Mirror cross over time. Please refer to  Table 2. Micromirror Array Optical Characteristics in the DLP5500 datasheet.

#2. LightCommander was set to 8-bit structured light mode, video input, and 3 images per frame. The video data alternated between switching all DMD mirrors ON / OFF, so for a single image the sequence of all the mirrors would be Bit 1 ON - Bit  2 OFF - Bit 3 ON - Bit 4 OFF - Bit 5 ON - Bit 6 OFF - Bit 7 ON - Bit 8 OFF. The file 8-Bits_Alternating_1.2MHzDetector.tif shows one full image plus the start of the next image. 6-Bits_Alternating_1.2MHzDetecto.tif zooms in to the first 5 bits. From this image it is clear that the first 4 bits are all 160 us in length and that all bits reach steady state.

[Comment] I tried in the lab this is again due to the external input source to LightCommander(TM) is modified by the source generator. Although the pattern you have created has alternative bits set to ZERO i.e., each pixel RGB value set to (0x55,0x55,0x55) because of the source generator color adjustment setting the actual data received is modified and this is resulting in wrong light output.

Highlighting again in 8bpp pixel mode (or call it as gray scale mode) each bit has different bit time and it increases from LSB bit to MSB bit.

FYI, attaching light output captures when all the pixel data is either (0x55,0x55,0x55) and (0xAA,0xAA,0xAA)

Yellow - Light measure from a Photo detector

Cyan - Sync O/P from Sync_0 of LightCommander

Figure(1) - RGB(0x55,0x55,0x55)

 Figure(2) - RGB(0x55,0x55,0x55) zoomed

Figure(3) - RGB(0xAA,0xAA,0xAA)

Figure(4) RGB(0xAA,0xAA,0xAA) zoomed

Recommendation for perfoming Structured Light mode from DVI port

Always ensure the digital data input to the LightCommander is gamma corrected (or linear Gamma applied) and the "Contrast" and "Brightness" setting is set to OFF/Passthrough value so the the DATA is NOT modified whatsoever then only you will be able to get the right result.

Regards,

Sanjeev

Hi

I have read through this thread and have a few questions regarding Structured Light in DVI mode.
1. What does patterns/frame mean? How is that related to frame rate? I noticed that when I set frame rate to 60Hz, I am only able to compile at 1 patterns per frame, while compile fails at 2 or more patterns per frame. However, when frame rate is set to 10Hz, I can compile at any number of patterns/frame up to 24 images/frame.

2. Can I produce gray scale images even when the solution is created for 1bpp? I am not using static image buffer, but a gray scale image from DVI input.

3. As I understand, when producing gray scale images, the bit time halves for each bit from MSB to LSB. Is there a minimum bit time? I'm guessing this corresponds to the minimum time the mirror is "ON".

Sorry if some of my questions might have been answered previously in this thread, I might have not been able to understand some of the discussions.

Thanks.

Regards,
Sze Ping
 

Hello Ping,

Please find the answers to your query.

1. Pattern/Frame - Frame here refers to full RGB 24bit frame input at the DVI port. It can accommodate 24 1bpp binary patterns or 3 8bpp grayscale patterns. You are seeing failures because you need to reduce the LED Illumination time a bit. For example - At 60Hz input, just change this time to ~100uSec from the maximum it will work. In your case from 16660us to 16500us.

2. No. The sequence or DLPC200 configuration data is pre-compiled at the time of your bpp selection. For grayscale you must create a solution with 8bpp as configuration.

3. Yes, you can back calculate. For example - at 60Hz input at DVI port, you can display 3 8bit grayscale images. So each pattern takes around 16.66/3 = 5.533mSec. So MSB bit takes around 2.5mSec you can back calculate accordingly. So LSB bit would take around 20uSec.

Regards,

Sanjeev