Empty data and information on the deflecting mechanism, radiometric attributes

[Ilkka Korpela]

Hi

--- extending the format to include empty data

Working in LiDAR research (basic radiometry and geometry, simulation of
sensors and vegetation backscattering), I suggest that the industry
would consider including the pulses that never triggered the WF
recorder and/or the DR circuits, depending on the system type.
This probably is also a format issue and thus relevant
to this community.

Just like pulses that pass by targets (measuring the complement of an object),
these 'empty pulses' are informative as they tell that the pulse path was
filled with something very diffuse over a depth; (specular) reflective
and inclined (possibly reflecting from somewhere outside the receiver iFOV);
and/or dark in the wavelength of the instrument.

Now, we must get our hands on the very 'early instrument files' to
access these data,
such as the SCN files with the ALS## type of sensors (Riegl have their
own more-diffucult-to-read files).

--- deflecting mechanism

Attributes that inform about the status of the deflecting mechanism
are probably of interest to those who want to correct for interior
orientation errors that affect the radiometry (e.g. location of the
illuminated
spot on the ground with respect to the iFOV of the receiver), or geometry
(e.g. filtering pulses collected while a mirror acclerated, correcting
for systematic mirror deformations). But similar to photogrammetry,
a LiDAR sensor should be so well calibrated and stable that such within-strip,
short-term calibration (cf. additional camera parameters) are not needed
by a regular user that uses standard file formats.

------ A format that sneaks a peak under the hood

I would appreciate (LAS, standard) files that have campaign and strip
level attributes
that could be utilized in radiometrically quantitative LiDAR remote sensing.
These are many and mostly obscured from the users. These have to do e.g.
in converting the received amplitude data into at-sensor radiance data and
to the reflectance factors of well-defined surfaces. Having the needed
attributes defined in a standard would perhaps motivate the sensors
manufacturers to unveil these. Now these data are obsolete, and unfortunately,
also the companies acquiring the data are 'a bit uneducated'. File format
would provoke interest to radiometry that so closely interconnects with
geometry?

Sorry for the bandwidth used. Keep up the excellent work on LAStools
and standards!

ilkka korpela, U Helsinki



--
Ilkka Korpela
http://www.helsinki.fi/~korpela

[Martin Isenburg]

Hello Ilkka,

funny that you would bring that up just now, because just today I
visited the National Chiao Tung University in Hsinchu, Taiwan where
full waveform LiDAR is an active area of research - and we talked
about the need to include the pulses with "zero return waves" in the
output because also they contain information about the scanned area.
This is already perfectly accommodated by the format and there have
already been test data sets where this was indeed the case. For
example in this PulseWaves file illustrated here

https://github.com/PulseWaves/PulseWaves/blob/master/screen_shots/optech_example1.png

which was converted from a Optech CSD/NDF file pair. You notice the
blue dots which correspond to pulses without returning waveform
because a lake was hit. Now you could argue that the Optech CSD/NDF
file pair should have also stored the many pulses across the water
body, but it seems the software outputting these Optech CSD/NDF files
was stripping pulse sequences without returning waveform and only
recorded the first and/or last pulse without a waveform. So ... it's
accommodated in PulseWaves. Whether the producers will store a pulse
without returning waves or not and if yes how many of them ... this is
really up to the producer of the PulseWaves file. It would certainly
be good if the default would be to include those pulses.

About your last point on "converting the received amplitude data into
at-sensor radiance data" the best I can do is point you to the
"normalized reflectance" Extra Bytes description in this RIEGL
whitepaper that seems to take some steps into the direction you are
pointing.

http://lastools.org/las14/Whitepaper_LAS_extrabytes_implementation_in_Riegl_software.pdf

Regards,

Martin @LaserPulseWaves

--
http://pulsewaves.org - no pulse left behind