Documentation for the window and bloom fields in lidar packets

Where’s documentation for interpreting the content of the window field in customizable packet format? Lidar Data | Ouster Sensor Docs | Documentation . How does it interact with min_range_threshold_cm ?

Why isn’t window a part of the newest RGB profiles?

How are invalid values represented when I set min_range_threshold_cm to 0? Because normally, 0 means invalid. Or is it so that measuring an actual 0 is not possible due to the distance of the projector and the window screen?

Also, what’s the `bloom` bit in legacy packet format? When did it appear? 2.5.3 docs don’t have it. Lidar Data Legacy | Ouster Sensor Docs | Documentation

What is the exact meaning of the bits in column header? Does ERR = 1 always imply STA = 0 ? What is LMW? does it mean that if this is set to 1, the laser had on-chip problems being fired? How/why could that happen? Also, does LMW = 1 imply STA = 0?

I’ve looked at the data and they look like a “continuous” grayscale image which is the whiter the more blockage is in the direction. Right?

So my initial attempt to filter-out all points with non-zero values in Window was totally wrong - there are no zeros in the Window field…

I’ve plotted the Window field values of a Dome. I took all missed rays (range = 0) and projected them to a preconfigured distance (range = max_range + delta). I copied the Window values to Intensity of this pointcloud and this is what I get.

What’s weird is the zebra-like nature of the output, I wouldn’t expect that…

Our sensor did actually have some real blockage at the top and bottom, so the whiter values there are expected. But the zebra pattern is not.

What I want to achieve is determine which rays can be safely used for clearing maps via raytracing (i.e. clear all voxels between the sensor and a predefined range). The idea is that I take all rays that did not hit anything - so those with range = 0 and without blockage. Is there a good threshold for the window values I should use?

It is probably to keep the packet size managable .. the rgb data alone adds 36 bytes per pixel.

Yeah 0 always going to be invalid since it is not possible even when you set the min_range_threshold_cm to 0.

The window detection logic is separate from the min_range_threshold_cm .. what the min_range_threshold_cm does is that it removes or drops points from the pointcloud that lesser in distance than the threshold. The window detection phase happen before that so it is not affected by the min_range_threshold_cm setting.