Bad Color Values?

Bad Color Values?

Hey Folks,

I'm working with a team on point clouds for autonomous NASA greenhouses in the Correll Robotics Laboratory at the University of Colorado Boulder. We're using Intel's PXC for its close-range precision, but having a problem visualizing RGB32 data in the Point Cloud Library (pointclouds.org).

I have written code to grab U,V,Z and color data and save it into a .pcd file format usable by the PCL. The depth data looks good!  See attached image, color coded by depth. However, I'm struggling to understand the best way to process the RGB32 data.  According to Intel's documentation, RGB32 data should be saved as BGRA on little endian machines.  But my typical color values look like 2502986900 or 4294967295 (see fourth column in attached data file) - which means that I have non-zero (and non-constant) values for the A byte.  Is this normal?

If not, maybe something is wrong with my color grabbing code:

  • colorSample->AcquireAccess(PXCImage::ACCESS_READ,PXCImage::COLOR_FORMAT_RGB32, &cdata); // save color data to &cdata
  • pxcU32 *RGB = (pxcU32 *)cdata.planes[0];  // get pointer to color plane
  • get color value from RGB[i];  // i is the index of a point with good depth data, so random values like RGB[2], RGB[13], ..., are saved

If my code is fine and this is normal, then it is possible that I can fix what may just be a visualization issue by changing that dynamic A byte to 0, and thus ensure that I have no values larger than 16777215 (0x00FFFFFF).

Hope this is an easy fix - thanks for your help!

Lance Legel

8 posts / novo 0
Último post
Para obter mais informações sobre otimizações de compiladores, consulte Aviso sobre otimizações.

Looks like the forum database destroyed my attachments... These are what I referenced above.

Anexos: 

Hi Lance,

I think we found the root cause this issue. The Raw color we got from the camera is RGB24 and when our framework covert RGB24 to RGB32, it hardcoded A value to 128. So, you can use following to fix it.

colorSample->AcquireAccess(PXCImage::ACCESS_READ,PXCImage::COLOR_FORMAT_RGB24, &cdata);

Please let me know if you still have this issue.

Thanks,

David

not understanding

Thanks David.

I tried changing the encoding to RGB24, however I still get 10 digit RGB values... See attached "rgb24data.txt".  I wanted to make sure that I could properly visualize RGB24 values that I specify using the Point Cloud Library, so I visualized a small cloud of points all with the color 0x33FF99 (see attached "light_blue_cloud.jpg").  This visualization is based on points from Intel's camera, and code that I used to specify the RGB byte values based on numerical 0-255 definitions for R, G, and B individually.  I provide this picture here to clearly show the RGB encoding I am searching for.

So to be very clear and simple: I need to get the 3 integer values of R,G,B from 0-255.  My problem will be solved if we can get these values.  I have specified how I am currently trying to get RGB data in the bullet points of my previous post.

Because I need to get this problem solved ASAP, I tried four additional things:

  1. Supressing the first byte (A, potentially) using a mask, so: RGB[i] = RGB[i] & 0x00FFFFF.  But as you can see in the attached file "rgb24_0x00FFFFFmask.jpg", this just makes all the colors some murky grey value.
  2. In case for some reason the problem is endianness and the bytes are actually encoded ABGR, I reversed byte ordering and then supressed the least significant byte (A, potentially), before shifting the bytes to the right.  This was, naturally, unsuccessful.
  3. In case the problem was in the data structure PXCU32, I also tried using a data structure of "unsigned _int32" for both methods above.
  4. All of the above methods for RGB32 and RGB24 specifications.

Unfortunately, I'm stuck, and hoping that someone has a better solution or quick optimization to mine.  Finally, just to fully equip any potential tweaks to my approach, I realized I was missing three fundamental lines of code that occcur before the bullet points in my previous post:

  • UtilPipeline pipeline;
  • pipeline.EnableImage(PXCImage::COLOR_FORMAT_RGB24); // in my tests for 4. above, I changed RGB24 from RGB32 at the same time for this line of code and for the AcquireAccess(... , ... , RGB24) line from my previous post
  • PXCImage *color_sample=pipeline.QueryImage(PXCImage::IMAGE_TYPE_COLOR)

Any ideas? Is there something simple I am missing that can lead me to the R, G, B integer values from 0-255?

Thank you for your support! We are working on very exciting scientific applications here that I will show results of and explain more if we can get everything properly working...

Lance

--

P.S. Just in case my attachments do not work, like last time, Intel's web support team may wish to know that I am receiving the following error for every attachment I try to upload:

An error occurred while attempting to process /en-us/file/ajax/field_attachments/und/form-ugnnWiwcV1oMWJOleZD2wstchyDiRuVSZt-7mc9J2V4: Object [object Object] has no method 'ajaxSubmit'

The attachments failed, as suspected.  I encourage the Intel PXC support team to forward the error I specified in the "P.S." above to the Intel web development team that manages the infrastructure for Intel forums.

Because I am not able to upload my attachments, and they may be useful in solving my problem (especially light_blue_cloud.jpg), I uploaded them to a secure public Dropbox link: https://www.dropbox.com/sh/92yn02duc2j1gdj/XOMpFhZT5u.

Thank you.

Lance Legel

Do you access RGB data correctly? Here is example for reading RGB32 pixel at position (x,y)

pxcBYTE b = (data.planes[0] + y*data.pitches[0])[4*x + 0];
pxcBYTE g = (data.planes[0] + y*data.pitches[0])[4*x  + 1];
pxcBYTE r = (data.planes[0] + y*data.pitches[0])[4*x + 2];

RGB data itself should be correct for both RGB24 and RGB32 formats, you can check that by debugging into RenderFrame function in the following sample:

UtilRender rraw(L"RGB32");
 UtilPipeline praw;
 praw.EnableImage(PXCImage::COLOR_FORMAT_RGB32);
 if (!praw.Init()) {
  wprintf_s(L"Failed to initialize the pipeline with a depth stream inputn");
  return 3;
 }
for (bool br=true; br; Sleep(5)) {
  if (br) {
    if (praw.AcquireFrame(true)) {
      if (praw.IsDisconnected()) {
        wprintf_s(L"Device is unplugged. Exiting ...n");
        br = false; 
      } else 
         if (!rraw.RenderFrame(praw.QueryImage(PXCImage::IMAGE_TYPE_COLOR))) br=false;
      praw.ReleaseFrame();
    } 
  }
 }

Hi Scott,

"BGRA layout on little-endia machines" documented in PerC SDK API means that for a color pixel of COLOR_FORMAT_RGB32, the corresponding four bytes in the buffer contains B, G, R, and A values respectively.

Mikhail's code shows how to access B/G/R values. The following code access A value

    pxcBYTE a = (data.planes[0] + y*data.pitches[0])[4*x + 3];

If you want to supress A value to 0, do & operation with 0xFFFFFF00.

Good Luck! 

Guozhong

Hi Scott,

"BGRA layout on little-endia machines" documented in PerC SDK API means that for a color pixel of COLOR_FORMAT_RGB32, the corresponding four bytes in the buffer contains B, G, R, and A values respectively.

Mikhail's code shows how to access B/G/R values. The following code access A value

    pxcBYTE a = (data.planes[0] + y*data.pitches[0])[4*x + 3];

If you want to supress A value to 0, do & operation with 0xFFFFFF00.

Good Luck! 

Guozhong

Deixar um comentário

Faça login para adicionar um comentário. Não é membro? Inscreva-se hoje mesmo!