• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 30 subscribers
  • Views 1602 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.

Linux/DLP4500: SDK Generates Wrong Patterns on Ubuntu 16.04-64bit

Shane
Prodigy 30 points
Part Number: DLP4500
Other Parts Discussed in Thread: DLP-ALC-LIGHTCRAFTER-SDK, DLPC350

Tool/software: Linux

Hi,

I'm new to DLP LightCrafter 4500, and recently I'm using this device to create my own structured light based 3d scanner. So I choose DLP-ALC-LIGHTCRAFTER-SDK to help me with developing it.

I've already successfully compiled the SDK with MinGW32 (32bit). Everything works well on Windows 10.

However, when I tried to migrate my code to Ubuntu 16.04 64bit, something weird happened~

In the SDK, there's one function in lcr4500.cpp : LCr4500::PreparePatternSequence. What I did is to generate my own mono-8 pattern from image data with cv::Mat format, add the pattern into sequence, and pass the sequence to the function above. Based on the source code inside, I can tell that PreparePatternSequence stacks every 3 pattern together to form a 24bit image, stores them on local disk with file name like "dlp_sdk_lcr4500_dlpc350_prepared.bin.flash_image_0.bmp", and upload them to DLP through USB.

Here is the problem: On Ubuntu 16.04, the 24bit image generated by exactly the same source code on Windows, now becomes totally a mess. The patterns are very irregular and full of random weird texture, which is far from the desired images as I can create on windows.  I double-check the original pattern data created by OpenCV and it turns out to be right cuz I print it out to verify it. So I guess what's going wrong is inside the SDK. Maybe it's OS platform related?

Any clues or explanations for this ?  Thanks for the help~

Shane

  • 0
    TI__Mastermind 20045 points
    Hello Shane and welcome to the forums,

    It obviously sounds like an OS compatibility issue. Since this was written as reference code for Windows we unfortunately do not officially support this code on Linux. Perhaps a member of the community could chime in with their experience here.

    While quickly looking at the code nothing jumps out to me that should be an issue. It's possible an OpenCV or Qt function behaves differently on different OSs and this error is manifesting itself in this part of the code. I would recommend seeing where this function call is dependent upon other other functions (specifically the library calls) and see if you can find the source of the error.

    -Kyle
  • 0 in reply to Kyle Rakos
    Prodigy 30 points
    Sorry for the late reply.
    It seems that this is where the problem lies. I'll figure that out later. For now, I have to stay on Windows and continue my work.
    Thanks~
  • 0
    Prodigy 30 points
    Hello, guys!
    I'm back here again to update the answer. I've spent some days to finally figure out where the bug is. Hope this could help someone who wants to work under Linux. And also I hope TI can update the source code to get rid of the annoying bugs..
    In source repository, locate the file named "lcr4500.cpp"
    On line 2735 in function LCr4500::CreateFirmwareImages, there are such calls:
    // Clear the images
    new_firmware_image.Clear();
    temp_firmware_image.Clear();
    // Reallocate the images
    temp_firmware_image.Create(dmd_cols,dmd_rows,Image::Format::MONO_INT);
    new_firmware_image.Create(dmd_cols,dmd_rows,Image::Format::RGB_UCHAR);

    Unfortunately, it forgets to re-initialize temp_firmware_image and new_firmware_image after clearing and reallocating. Since Windows and Linux may treat uninitialized variable in a different way, this may pose a risk to further operation. In the following parts, you can see the following calls:
    // Get the current fw pixel
    temp_firmware_image.Unsafe_GetPixel( xCol, yRow, &fw_pixel);

    // Update the fw pixel
    fw_pixel = temp_pixel + fw_pixel;
    This is exactly where the problem is. We are trying to get a pixel that's not initialized and what's even worse, we are adding something to the undefined variable.
    The solution is simple, just add "temp_firmware_image.FillImage( (int)0);" very time you do the clearing stuff. Note that there are more than one places like this that need to be fixed.
    Hope this would help~
  • 0 in reply to Shane
    TI__Mastermind 20045 points
    Thanks Shane for the followup response! I'm glad you were able to get it working.

    -Kyle