Dynamic Range Matching vs. Bit-Depth Mapping

[kdamkjer]

I accidentally included a change in #42 to modify "dynamic range" to "bit-depth" in the Intensity field description. While the proposed change may not be appropriate for #35, I am curious if there should be a deeper discussion on the bit-depth mapping specified. Specifically, shouldn't the scale factor for mapping bit-depths be: (2^output-depth - 1)/(2^input-depth -1)? In the example given in the Intensity section, this would make the scale factor (65535/1023) instead of (65536/1024). This change provides the correct mapping of full-ranges regardless of whether bit-depth is increasing or decreasing (as may be the case for NRGB fields).

Further, there appears to be some confusion in the spec on whether the dynamic range is being mapped, or the bit-depth. The language of the spec states "dynamic range", but the math implies "bit-depth." To map dynamic range, shouldn't a histogram stretch or similar approach be applied prior to the bit-depth mapping? Otherwise, there is no guarantee that the bit values carry similar meaning across various files.

[rapidlasso]

The de-facto state of the "intensity" field across how different vendors are populating this field is (according to my understanding) that it has no well-defined physical meaning other than being somehow related to the amount of photons / signal energy received for that particular return. To address this RIEGL has started adding a properly defined "normalized reflectivity" that can be optionally output as an additional per return attribute using Extra Bytes. For details see this white paper here.

[kdamkjer]

@rapidlasso, I understand that "Intensity" carries no mapping to physical units much like the "RGB" and "Nir" fields. I'm not terribly bothered by this. In fact, it seems in line with imagery where, unless you have a radiometrically calibrated instrument, pixel values do not map directly to a physical unit and only relate relative to each other within an image. The text regarding mapping bit values within this section appears to partially speak to this scenario. However, the mapping provided does not fully address mapping the dynamic range and instead only address mapping bit-depth and even then provides a less than ideal mapping.

[esilvia]

I'm not sure I follow what @kdamkjer is suggesting we fix. Are you simply suggesting that the example scale factor is incorrect (65536/1024 vs 65535/1023)? You seem to be more or less correct on this point.

Or are you suggesting a wording change? I don't understand the distinction between bit depth and dynamic range well enough to understand the need for a wording change.

Strictly speaking, of course, one could scale intensities based on a full histogram range of the theoretically possible values for a radiometrically calibrated sensor, but that's a level of complexity outside the scope of the spec. A handful of LiDAR vendors do exactly that, but it's not a requirement for a valid LAS file because there's no outside standard of "correct" intensity values against which we can validate.

[esilvia]

If we do this, then it would follow that we make the same correction (65535/255) to the 16-bit RGB normalization discussion in PDRF 2 and the NIR normalization discussion in PDRF 8.

[esilvia]

Relevant: https://groups.google.com/d/msg/lastools/q0bDyuRPzbs/9SYBWtIBBQAJ