Why are there returns with echo width of zero (in RIEGL full waveform LiDAR)?

84 views
Skip to first unread message

Martin Isenburg

unread,
Aug 11, 2019, 7:27:41 AM8/11/19
to LAStools - efficient command line tools for LIDAR processing, PulseWaves - no pulse left behind
Hello,

in recent days I regularly come across LAS or LAZ data that has been flown by a RIEGL scanner and that seems to have the "return echo width" or "return pulse width" stored in the user data field with the units being one tenth of a nano second.

First off, I hope you realize how awesome it is to have this information included your LiDAR deliveries. Several of my clients were not aware that that this additional information was there. Below a lasinfo report that creates a number of histograms (part of my standard quality checking routine).


lasinfo -i U3725591.laz ^
           -cd ^
           -histo intensity 256 ^
           -histo user_data 1 ^
           -histo point_source 1 ^
           -histo gps_time 10 ^
           -odix _info -otxt

One interesting part of the user data histogram is its beginning. You may know that an outgoing laser pulse has from a typocal RIEGL scanner a width of around 4 to 5 nanoseconds. Hence we expect the returning echos to have a pulse width that starts somewhere around there, However, the histogram also shows echo widths that are much shorter as you can see below.

user data histogram with bin size 1.000000
  bin 0 has 182664
  bin 17 has 5
  bin 18 has 4
  bin 19 has 7
  bin 20 has 15
  bin 21 has 27
  bin 22 has 58
  bin 23 has 104
  bin 24 has 149
  bin 25 has 226
  bin 26 has 413
  bin 27 has 590
  bin 28 has 812
  bin 29 has 1270
[...]

I explained myself those shorter width as being multi-peaks in close proximity to each other and that this must be an artifact of the waveform decomposition where the removal of other peaks from a multi-peak shortens the remaining one to below the width of the outgoing pulse. In order to look at only those returns with an unusually short echo width I ran this command:

lasview -i U3725591.laz ^
             -keep_user_data_below 20 ^
             -points 20000000 ^
             -color_by_flightline

This is interesting (see first screen shot). At first glance one may think those strips follow the flight trajectory of the aircraft. But this is not the case as obvious in the next visualization of all returns from only the single flight line 1295 obtained with

las2las -i U3725591.laz ^
            -set_classification 0 ^
            -o U3725591_clean.laz

las2las -i  U3725591_clean.laz ^
            -keep_user_data_below 20 ^
            -filtered_transform ^
            -set_classification 8 ^
           -o U3725591_marked.laz 

lasview -i U3725591_marked.laz ^
             -keep_point_source 1295 ^
             -points 20000000 ^
             -color_by_classification

Now look at the second screen shot where all returns with an echo width shorter than 20 are red. One can see that the majority of them are forming fuzzy iso-contour like pattern. Maybe they are formed by returning echos that have similar ranges (e.g. have a similar distance between optical center of laser scanning unit and reflected surface (aka a similar round-trip time for the photons from plane to terrain and back)). MTA analysis artifacts? I'm sure there are some folks on this list that can shed some light on these echo pulse width. 

Regards,

Martin @rapidlasso 

U3725591_info.txt
RIEGL_echo_width_zero_or_below_2ns_1.png
RIEGL_echo_width_zero_or_below_2ns_2.png
Reply all
Reply to author
Forward
0 new messages