• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 28 subscribers
  • Views 1267 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.

LCR6500 image data

Jonas Schmitz
Prodigy 55 points

Hi, I have some issues concerning the DLP-LCR6500 Evaluation Module.
Any images (bitmaps) uploaded to the device (mainly in pattern on-the-fly mode)
are converted to a splash format. In the source code of the GUI shipped with the device, I found that the header of these splash files supports other pixel formats than the 24-bit (RGB-8-8-8) used in the code. Explicitely mentioned is a 16-bit YCrCb format.
I wondered if this format could be used to reduce the amount of data uploaded to the DMD. In our application, we are exclusively using black/white pictures, so the current implementation has to upload 24-times too much data. I would be willing to adjust the code to use the mentioned 16-bit format for a 30% decrease of uploaded data, and thus a 30% increase in speed. My questions are now:

1) Is there any chance this could work? (When I tried to upload the 1-bit data which would suffice for our purposes, the DMD just didn't display anything)
2) Would the RLE compression still work? If not, the whole thing would be futile.
3) How would the image data have to look like? I think there are several conventions used for the YUV 4:2:2 format, e.g. first one large block with the Y data, then two smaller ones Cr and Cb data. Would this be recognized by the DMD?
(4) Is there maybe any way I didn't think of to efficiently upload 1-bit black/white images? Depending on the complexity of the image, it currently takes up to ~10 seconds in pattern on-the-fly mode. A reduction to e.g. one second would be more than sufficient. HDMI is not an option due to the (visible) VSYNC refresh rate.

Sorry for the wall of text and thanks in advance for any reply.

Best regards,
Jonas

P.S. I do have some other issues, but maybe it would be a good idea to discuss them in a private chat.

Otherwise, I will gladly start one or several new threads.

  • 0
    TI__Mastermind 30600 points
    Hi Jonas,

    The 16b YCrCb format is intended for video mode only. For pattern sequences, the 24b format is used.

    If you have a series of patterns that are all 1bit images (pure white and pure black) then the software will package those patterns into a 24b image. This means that if you have 24 1b patterns, you'll only have 1 24b image loaded to the device.

    How many patterns do you need to upload? Storing the patterns internally will be faster than pattern-on-the-fly mode.

    Thanks,
    Paul
  • 0 in reply to Paul Goedeke
    Prodigy 55 points
    Hi Paul, thanks for your reply.
    Yes, I am aware of the 24bit packages. Unfortunately,
    we are using an iterative procedure. In this step, only one
    pattern is uploaded at a time, because the next one isn't
    known yet.
    In a next step, we will also display a sequence of a few images (much less than 100), but I think the upload is less time critical in this situation.
    With 'faster' you are talking about the actual displaying
    and not the uploading, right? As I understood it, the internal
    images have to be included in the firmware, i.e. can't be
    changed frequently.
    Thanks,
    Jonas
  • 0 in reply to Jonas Schmitz
    TI__Mastermind 30600 points
    Jonas,

    You are correct, the images do have be included in the FW. I understand why a pre-stored pattern option won't work for you.

    I don't know of any way to speed up the upload time and I'm surprised that it's taking as long as 10 seconds to upload the images. Perhaps there is a delay introduced by your iterative procedure? Are you following the steps from Section 3.6.2 in the user's guide?

    Paul
  • 0 in reply to Paul Goedeke
    Prodigy 55 points

    Sorry for the delay, I think there is some 7/8 hour time difference between us.
    Actually, we are not using the GUI, but wrote our own implementation. It does not matter in terms of upload speed, however. Of course ten seconds is an extreme case, where large areas of the image are checkerboard-like and the compression does not help much.
    I guess we will stick to our current procedure, then, and cope with the upload time. Of course, any suggestions are still welcome!
    Thanks,
    Jonas


    By the way, there seems to be a small error in the source code: if a new PtnImage is constructed from a QImage, the splashData member stays uninitialized, which causes frequent crashes.

  • 0 in reply to Jonas Schmitz
    TI__Mastermind 30600 points
    Jonas,

    For very busy patterns, RLE compression might actually result in an image which is larger than the original, which could be causing your extended upload times.

    Which portion of the code did you find the error in? Can you provide the file name and approximately which line/function? I'll log it in our bug tracker. Thank you so much for pointing it out.

    Paul
  • 0 in reply to Paul Goedeke
    Prodigy 55 points
    Yes, I also tried using no compression, but the resulting files were much larger than the compressed ones.

    In the file 'PtnImage.h', the line 'splashData = NULL;' is missing in the constructor from QImage (ll. 98-117). This is never called in your GUI, but it took me some time to figure it out in my application. Note that I'm not a seasoned programmer, so you might want to double check this:) Adding the mentioned line solved the problem for me.
    I have another question concerning the triggering, should I open a new thread for it?
    Jonas
  • 0 in reply to Jonas Schmitz
    TI__Mastermind 30600 points
    Thanks Jonas. Yes, if you have a different question, opening a new thread would be appreciated.

    Paul