1

I have the following floating point number 8.8489784e-39 extracted from the PCD DATA FORMAT which represents the RGB value of one point of the point cloud.

I have to convert this to either HEX directly or to Int->RGB or whichever way. I searched the web but couldn't put anything together so far as my experience with floating-point arithmetic in javascript is fairly limited.

MJB
  • 3,934
  • 10
  • 48
  • 72
  • What algorithm should be used for the conversion? RGB values are typically 0-255 (dec) or 0-FF (hex), the value above is essentially zero. If it was metres, it's trillions of times smaller than the diameter of an electron (~1.0e-15 m). – RobG Nov 01 '13 at 02:37
  • I'm not sure, I only have the information from the link I have. check the link, they provide an example. I don't even know how I have to interpret this data. – MJB Nov 01 '13 at 02:44
  • Like @RobG said, the values they provide are very strange. If you read that site you linked to it appears that the floats are rgb values, but that really doesnt make any sense at all. – Nick Chapman Nov 01 '13 at 02:50
  • You might like to read the conversation here: [`Bug in PCD-viewer's display of color point clouds? Or am I doing something wrong? `](http://www.pcl-users.org/Bug-in-PCD-viewer-s-display-of-color-point-clouds-Or-am-I-doing-something-wrong-td2579995.html). It seems the values might be being munged: "When saving a point cloud containing an rgb field, use binary instead of ascii format. Since rgb is stored packed as a float, and storing a float as ascii can introduce variations to the smallest bits, the individual (r,g,b) values of some pixels can sometimes end up significantly altered" – RobG Nov 01 '13 at 02:51
  • Not sure how useful this is, but: JS starts messing up in the hundredths place. If any sort of math was performed, that would explain a near zero number like that. E.g. `1.15-1.14-.01 = 8.673617379884035e-18`. – Rhyono Nov 01 '13 at 03:11
  • @Rhyono—yes, that's a "feature" of the double-precision 64-bit format IEEE 754 values used by ECMAScript. But I don't think it applies here, the error is in the data already. – RobG Nov 01 '13 at 03:22
  • Wait, packing RGB into a float? Did we learn nothing from Y2K? – slebetman Nov 01 '13 at 03:53
  • well we develop applications for android as well and they use these number too, so I have to believe that they are "correct" enough to work with. – MJB Nov 01 '13 at 08:31

1 Answers1

0

So I'm guessing that's one byte each of red, green, and blue, stored in the first three bytes of a 4-byte word, which is then inexplicably interpreted as a float instead of an int.

If that's the case, then 8.8489784e-39f represents the RGB triple (90,91,96) [decimal] or #5a5b60 in web hex.

But doing that conversion in Javascript will not be easy. You could look at the conversion function decodeFloat defined here, or perhaps you can start with the answer to this question.

Community
  • 1
  • 1
Mark Reed
  • 91,912
  • 16
  • 138
  • 175
  • It seems that the values are being stored as a packed float, then converted to ASCII, which significantly changes the value. So even if your conversion is correct (and it may well be) the value has been irretrievably munged already. :-( BTW, is that trailing "f" a typo? – RobG Nov 01 '13 at 03:10
  • I copied and pasted the constant from the C program I used to decode the float, which is where the -f came from. Normally, floating-point literals in C generate double-precision values, but the trailing -f makes them only single precision. – Mark Reed Nov 01 '13 at 03:14