hobuinc / laz-perf Goto Github PK

Alternative LAZ implementation for C++ and JavaScript

License: Apache License 2.0

CMake 1.83% C++ 84.07% Shell 0.57% HTML 0.14% Batchfile 0.01% C 0.56% Python 11.88% Starlark 0.59% JavaScript 0.04% TypeScript 0.31%

laz-perf's People

Contributors

Stargazers

Watchers

Forkers

ghelobytes gadomski liuxinren vuakko pblottiere markuskuusisto sharpershape markussammallahti mevatron meshgeometry elemoine vivpan ldgeo candrsn johanvdw connormanning martinheidegger rmam-spinworks reactual jvandoesburg gajgeospatial cadcorp kylemann16 mihir3445 spaceim longervision froody leo-stan ccinc xantares ogretransporter gdt helix-re nd-pc uclaros yaoc1996 lushangkun vsautin1 bacek greehill-pimplibence oboychuk bmillikanphd jguerrer

laz-perf's Issues

Compilation error with clang on Linux: non-constant-expression cannot be narrowed

I've tested with libstdc++ and libc++, in Debug & Release build type, clang 3.9 to 11, same error:

-- The C compiler identification is Clang 11.1.0
-- The CXX compiler identification is Clang 11.1.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/clang - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Conan: called by CMake conan helper
-- Conan: called inside local cache
-- Conan: Adjusting output directories
-- Conan: Using cmake global configuration
-- Conan: Adjusting default RPATHs Conan policies
-- Conan: Adjusting language standard
-- Conan: Compiler Clang>=8, checking major version 11
-- Conan: Checking correct version: 11
-- Conan: C++ stdlib: libc++
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_EXPORT_NO_PACKAGE_REGISTRY
    CMAKE_INSTALL_BINDIR
    CMAKE_INSTALL_DATAROOTDIR
    CMAKE_INSTALL_INCLUDEDIR
    CMAKE_INSTALL_LIBDIR
    CMAKE_INSTALL_LIBEXECDIR
    CMAKE_INSTALL_OLDINCLUDEDIR
    CMAKE_INSTALL_SBINDIR


-- Build files have been written to: /home/conan/.conan/data/laz-perf/2.0.0/bincrafters/testing/build/0e71bdb5ca512e4d54ff592784bdaead9275958d
Scanning dependencies of target lazperf
Scanning dependencies of target lazperf_s
[  2%] Building CXX object source_subfolder/cpp/lazperf/CMakeFiles/lazperf_s.dir/charbuf.cpp.o
[  5%] Building CXX object source_subfolder/cpp/lazperf/CMakeFiles/lazperf.dir/charbuf.cpp.o
[  8%] Building CXX object source_subfolder/cpp/lazperf/CMakeFiles/lazperf.dir/lazperf.cpp.o
[ 11%] Building CXX object source_subfolder/cpp/lazperf/CMakeFiles/lazperf_s.dir/lazperf.cpp.o
[ 14%] Building CXX object source_subfolder/cpp/lazperf/CMakeFiles/lazperf.dir/filestream.cpp.o
[ 17%] Building CXX object source_subfolder/cpp/lazperf/CMakeFiles/lazperf_s.dir/filestream.cpp.o
[ 20%] Building CXX object source_subfolder/cpp/lazperf/CMakeFiles/lazperf.dir/io.cpp.o
[ 23%] Building CXX object source_subfolder/cpp/lazperf/CMakeFiles/lazperf_s.dir/io.cpp.o
[ 26%] Building CXX object source_subfolder/cpp/lazperf/CMakeFiles/lazperf.dir/vlr.cpp.o
/home/conan/.conan/data/laz-perf/2.0.0/bincrafters/testing/build/0e71bdb5ca512e4d54ff592784bdaead9275958d/source_subfolder/cpp/lazperf/vlr.cpp:188:28: error: non-constant-expression cannot be narrowed from type '__uint32_t' (aka 'unsigned int') to 'uint8_t' (aka 'unsigned char') in initializer list [-Wc++11-narrowing]
    reserved{}, data_type{ htole32(1) }, options{}, name{}, unused{},
                           ^~~~~~~~~~
/usr/include/endian.h:70:22: note: expanded from macro 'htole32'
#  define htole32(x) __uint32_identity (x)
                     ^~~~~~~~~~~~~~~~~~~~~
/home/conan/.conan/data/laz-perf/2.0.0/bincrafters/testing/build/0e71bdb5ca512e4d54ff592784bdaead9275958d/source_subfolder/cpp/lazperf/vlr.cpp:188:28: note: insert an explicit cast to silence this issue
    reserved{}, data_type{ htole32(1) }, options{}, name{}, unused{},
                           ^~~~~~~~~~
                           static_cast<uint8_t>( )
/usr/include/endian.h:70:22: note: expanded from macro 'htole32'
#  define htole32(x) __uint32_identity (x)
                     ^~~~~~~~~~~~~~~~~~~~~
1 error generated.
source_subfolder/cpp/lazperf/CMakeFiles/lazperf.dir/build.make:133: recipe for target 'source_subfolder/cpp/lazperf/CMakeFiles/lazperf.dir/vlr.cpp.o' failed
make[2]: *** [source_subfolder/cpp/lazperf/CMakeFiles/lazperf.dir/vlr.cpp.o] Error 1
make[1]: *** [source_subfolder/cpp/lazperf/CMakeFiles/lazperf.dir/all] Error 2
CMakeFiles/Makefile2:242: recipe for target 'source_subfolder/cpp/lazperf/CMakeFiles/lazperf.dir/all' failed
make[1]: *** Waiting for unfinished jobs....
[ 29%] Building CXX object source_subfolder/cpp/lazperf/CMakeFiles/lazperf_s.dir/vlr.cpp.o
[ 32%] Building CXX object source_subfolder/cpp/lazperf/CMakeFiles/lazperf_s.dir/detail/field_point10.cpp.o
/home/conan/.conan/data/laz-perf/2.0.0/bincrafters/testing/build/0e71bdb5ca512e4d54ff592784bdaead9275958d/source_subfolder/cpp/lazperf/vlr.cpp:188:28: error: non-constant-expression cannot be narrowed from type '__uint32_t' (aka 'unsigned int') to 'uint8_t' (aka 'unsigned char') in initializer list [-Wc++11-narrowing]
    reserved{}, data_type{ htole32(1) }, options{}, name{}, unused{},
                           ^~~~~~~~~~
/usr/include/endian.h:70:22: note: expanded from macro 'htole32'
#  define htole32(x) __uint32_identity (x)
                     ^~~~~~~~~~~~~~~~~~~~~
/home/conan/.conan/data/laz-perf/2.0.0/bincrafters/testing/build/0e71bdb5ca512e4d54ff592784bdaead9275958d/source_subfolder/cpp/lazperf/vlr.cpp:188:28: note: insert an explicit cast to silence this issue
    reserved{}, data_type{ htole32(1) }, options{}, name{}, unused{},
                           ^~~~~~~~~~
                           static_cast<uint8_t>( )
/usr/include/endian.h:70:22: note: expanded from macro 'htole32'
#  define htole32(x) __uint32_identity (x)
                     ^~~~~~~~~~~~~~~~~~~~~
1 error generated.
source_subfolder/cpp/lazperf/CMakeFiles/lazperf_s.dir/build.make:133: recipe for target 'source_subfolder/cpp/lazperf/CMakeFiles/lazperf_s.dir/vlr.cpp.o' failed
make[2]: *** [source_subfolder/cpp/lazperf/CMakeFiles/lazperf_s.dir/vlr.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [source_subfolder/cpp/lazperf/CMakeFiles/lazperf_s.dir/all] Error 2
CMakeFiles/Makefile2:215: recipe for target 'source_subfolder/cpp/lazperf/CMakeFiles/lazperf_s.dir/all' failed
make: *** [all] Error 2
Makefile:148: recipe for target 'all' failed

missing pylazperfapi.cpp

Hello,

I tried to compile the source code, along to other things I did:

pip install -e "git+https://github.com/hobu/laz-perf#egg=lazperf&subdirectory=python"

and I got this error:

creating build/temp.linux-x86_64-3.4/lazperf
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -g -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC -I. -I/home/lopocs/venv/lib/python3.4/site-packages/numpy/core/include -I/usr/include/python3.4m -I/home/lopocs/venv/include/python3.4m -c lazperf/pylazperfapi.cpp -o build/temp.linux-x86_64-3.4/lazperf/pylazperfapi.o -std=c++11 -g -O0
x86_64-linux-gnu-gcc: error: lazperf/pylazperfapi.cpp: No such file or directory
x86_64-linux-gnu-gcc: fatal error: no input files
compilation terminated.
error: command 'x86_64-linux-gnu-gcc' failed with exit status 4

Thanks

Compilation fails with Visual Studio 2017

#include <algorithm> is missing in filestream.cpp:

[1/14] Building CXX object source_subfolder\cpp\lazperf\CMakeFiles\lazperf_s.dir\charbuf.cpp.obj
[2/14] Building CXX object source_subfolder\cpp\lazperf\CMakeFiles\lazperf_s.dir\vlr.cpp.obj
[3/14] Building CXX object source_subfolder\cpp\lazperf\CMakeFiles\lazperf_s.dir\lazperf.cpp.obj
[4/14] Building CXX object source_subfolder\cpp\lazperf\CMakeFiles\lazperf_s.dir\io.cpp.obj
[5/14] Building CXX object source_subfolder\cpp\lazperf\CMakeFiles\lazperf_s.dir\filestream.cpp.obj
FAILED: source_subfolder/cpp/lazperf/CMakeFiles/lazperf_s.dir/filestream.cpp.obj 
C:\PROGRA~2\MICROS~1\2017\ENTERP~1\VC\Tools\MSVC\1416~1.270\bin\Hostx64\x64\cl.exe  /nologo /TP -DWIN32_LEAN_AND_MEAN -D_CRT_NONSTDC_NO_WARNING -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_SCL_SECURE_NO_WARNINGS  /DWIN32 /D_WINDOWS /W3 /GR /EHsc  /MP2 /MT /O2 /Ob2 /DNDEBUG    /wd4068 /wd4267 /wd4250 /wd4805 /EHsc /MP2 /showIncludes /Fosource_subfolder\cpp\lazperf\CMakeFiles\lazperf_s.dir\filestream.cpp.obj /Fdsource_subfolder\cpp\lazperf\CMakeFiles\lazperf_s.dir\lazperf_s.pdb /FS -c source_subfolder\cpp\lazperf\filestream.cpp
source_subfolder\cpp\lazperf\filestream.cpp(87): error C2039: 'min': is not a member of 'std'
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\include\vector(20): note: see declaration of 'std'
source_subfolder\cpp\lazperf\filestream.cpp(87): error C2065: 'min': undeclared identifier

LAZPERF_EXPORT macro is wrong on Windows

LAZPERF_EXPORT macro is defined in lazperf.h: https://github.com/hobu/laz-perf/blob/2e3c316248fa534cdeba1b47b2e9fe1a0ecf5dca/cpp/lazperf/lazperf.hpp#L42-L47

It's broken on Windows.

If static, this macro should be empty (all OS)
If shared, this macro should be:
- Windows: __declspec(dllexport) at build time, and __declspec(dllimport) at consume time
- others OS: __attribute__((visibility ("default")))

Support variable-sized chunks

Version 1.4 Support

Add support for LAS 1.4.

The model for version 1.4 is quite different from that of 1.2, so some changes are necessary. If you're using this library and would like to discuss modifications, please respond to this ticket.

2.0: Clarify the API and install target

When you install laz-perf with CMake, there are just a few public headers installed: https://github.com/hobu/laz-perf/blob/2e3c316248fa534cdeba1b47b2e9fe1a0ecf5dca/cmake/install.cmake#L12-L20

Among these headers, io.hpp is unusable since it includes non-installed headers (las.hpp, streams.hpp and charbuf.hpp). Even with those headers (and transitive headers), it would not be usable with laz-perf shared because non-inline symbols in this header are not exported (examples executables link to static lib, hidding the issue, and they have access to private headers).

All examples and tests rely on several private headers, but the README says that we should refer to examples or tests to understand the API.

It would be nice to clarify the API, at least to show examples including only public headers (lazperf/lazperf.hpp, lazperf/filestream.hpp and lazperf/vlr.hpp), and working with shared or static laz-perf.

Moreover, CMakeLists unconditionally installs shared lib, there is no way to install static lib even if it's built. It would also be nice to allow consumers to build shared or static, not both.

Add tests for emscripten

We have tests for C++, but we've found that things on Emscripten are sometimes different for various reasons (size of types, compiler issues). It would be good to have verification that things work on Emscripten as well as a C++ compiled environment.

Laz Spec

In one of @hobu's emails to the pdal community:

[there isn't a] LAZ specification beyond the LASzip code

With Martin's passing, does it make sense to harden the laz spec and start defining it within the community and trying to have a standard similar to copc?

This would obviously be difficult without full deprecation or access to laszip (not sure the state of that) and with the current landscape of laz in the wild. However, would it make sense to standardize a 1.4.1 spec and start moving towards something?

I opened this ticket here since lazperf is now tied to pdal. However, if it should live elsewhere, feel free to let me know.

Laz files with more than 1 chunk created by lazperf-2.0.5 cause lazip to assert

In lazperf-1.4.4, there was some code to special-case the first chunk, and this had the effect of setting the size of the first chunk to the delta between the offest of the first point and the end of the chunk. See https://github.com/hobu/laz-perf/blob/1.4.4/laz-perf/io.hpp#L869-L872

In lazperf-2.0.5 however, the logic was refactored, and now the first chunk size is equal to offset - chunk_state.last_chunk_write_offset, where is chunk_state.last_chunk_write_offset=0 at the end of the first chunk. See https://github.com/hobu/laz-perf/blob/2.0.5/cpp/lazperf/io.cpp#L419-L421

This triggers an exception in laszip when decoding files with multiple chunks, but doesn't affect laz-perf since it doesn't actually check chunk sizes when decoding. See lazip code here

Proposed fix is to set chunk_state.last_chunk_write_offset = f->tellp(); in this block

Note also that since the refactor, current_chunk_index is no longer updated/used.

Finalize compressors and decompressors

Making the compressor and decompressor final allows for possible de-virtualization of compress and decompress calls.

addField() deprecation warning

The commit e0bd817 marks eb_vlr::addField() as deprecated, but it's still used in the code. When I use the code in QGIS, I get the following warning (which is a problem because in CI warnings are treated as errors):

[5/24] Building CXX object src/core/CMakeFiles/qgis_core.dir/__/__/external/lazperf/vlr.cpp.o
../external/lazperf/vlr.cpp: In constructor ‘lazperf::eb_vlr::eb_vlr(int)’:
../external/lazperf/vlr.cpp:329:18: warning: ‘void lazperf::eb_vlr::addField()’ is deprecated [-Wdeprecated-declarations]
  329 |         addField();
      |                  ^
In file included from ../external/lazperf/vlr.cpp:37:
../external/lazperf/vlr.hpp:166:25: note: declared here
  166 |     [[deprecated]] void addField();
      |                         ^~~~~~~~

Encoding incorrect for GPStime

Some GPStime sequences aren't encoded properly -- they don't match that of laszip. This can cause the decoder to detect a premature EOF and fail to read all points.

clarify licensing

I saw COPYING file is LGPL2.1, but nowhere it's said it is the license applied to the codebase.
For example, is it LGPL2 "or any later version" or strictly LGPL2 ?

Mentioning in the README (or in a separate LICENSE file) might be enough, although most guides recommend to write a short header in each source file...

Encoder doesn't know that's it's done.

The done() function on the encoder isn't idempotent. Calling done() on the encoder any time after the first should do nothing or return an error.

laszip_seek_point

Is there a way to read subsets of points? For PotreeConverter, I've been using laszip_seek_point to create multiple laszip threads, each decompressing different regions of an laz file in parallel.

Cannot pip install lazperf 1.2 from pypi

The installation of the lazperf-1.2 package available on pypi fails. It looks to me that the installation fails because the lazperf 1.2 tarball does not include the laz-perf directory (and the cpp/hpp source files that should be in there). See below.

$ virtualenv --python=python3 venv
$ source env/bin/activate
(venv) $ pip install --no-cache-dir numpy             # installs numpy 1.14.3 from pypi
(venv) $ pip install --no-cache-dir 'lazperf==1.2'
Collecting lazperf==1.2
  Downloading https://files.pythonhosted.org/packages/da/4a/9ea92d0d5133047036561299190acf47f6fadf4cfe53795d9b7e9de759af/lazperf-1.2.tar.gz (144kB)
    100% |████████████████████████████████| 153kB 105kB/s 
Requirement already satisfied: numpy>=1.11 in ./venv/lib/python3.6/site-packages (from lazperf==1.2) (1.14.3)
Installing collected packages: lazperf
  Running setup.py install for lazperf ... error
    Complete output from command /home/elemoine/src/laz-perf/python/venv/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-927_o0iy/lazperf/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-record-yvh8vshl/install-record.txt --single-version-externally-managed --compile --install-headers /home/elemoine/src/laz-perf/python/venv/include/site/python3.6/lazperf:
    running install
    running build
    running build_py
    creating build
    creating build/lib.linux-x86_64-3.6
    creating build/lib.linux-x86_64-3.6/lazperf
    copying lazperf/__init__.py -> build/lib.linux-x86_64-3.6/lazperf
    running egg_info
    writing lazperf.egg-info/PKG-INFO
    writing dependency_links to lazperf.egg-info/dependency_links.txt
    writing requirements to lazperf.egg-info/requires.txt
    writing top-level names to lazperf.egg-info/top_level.txt
    reading manifest file 'lazperf.egg-info/SOURCES.txt'
    reading manifest template 'MANIFEST.in'
    warning: no files found matching '*' under directory 'laz-perf'
    writing manifest file 'lazperf.egg-info/SOURCES.txt'
    copying lazperf/PyLazperf.cpp -> build/lib.linux-x86_64-3.6/lazperf
    copying lazperf/PyLazperf.hpp -> build/lib.linux-x86_64-3.6/lazperf
    copying lazperf/PyLazperfTypes.hpp -> build/lib.linux-x86_64-3.6/lazperf
    copying lazperf/PyVlrCompressor.cpp -> build/lib.linux-x86_64-3.6/lazperf
    copying lazperf/pylazperfapi.cpp -> build/lib.linux-x86_64-3.6/lazperf
    copying lazperf/pylazperfapi.pyx -> build/lib.linux-x86_64-3.6/lazperf
    running build_ext
    building 'lazperf.pylazperfapi' extension
    creating build/temp.linux-x86_64-3.6
    creating build/temp.linux-x86_64-3.6/lazperf
    x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -g -fdebug-prefix-map=/build/python3.6-bL6UQz/python3.6-3.6.5=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I. -I/home/elemoine/src/laz-perf/python/venv/lib/python3.6/site-packages/numpy/core/include -I/usr/include/python3.6m -I/home/elemoine/src/laz-perf/python/venv/include/python3.6m -c lazperf/pylazperfapi.cpp -o build/temp.linux-x86_64-3.6/lazperf/pylazperfapi.o -std=c++11 -g -O0
    cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
    In file included from lazperf/pylazperfapi.cpp:482:0:
    lazperf/PyLazperf.hpp:3:10: fatal error: laz-perf/common/common.hpp: No such file or directory
     #include <laz-perf/common/common.hpp>
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
    compilation terminated.
    error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
    
    ----------------------------------------
Command "/home/elemoine/src/laz-perf/python/venv/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-927_o0iy/lazperf/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-record-yvh8vshl/install-record.txt --single-version-externally-managed --compile --install-headers /home/elemoine/src/laz-perf/python/venv/include/site/python3.6/lazperf" failed with error code 1 in /tmp/pip-install-927_o0iy/lazperf/

lasindex support?

Does laz-perf support lasindex? Manly reading the spatial index LAX from an EVLR?

laz-perf (included in qgis 3.22) fails to build on NetBSD

On NetBSD 9, I got complains of redefinitions of many macros like le32toh and finally an undefined variable.

Reading portable_endian.h I see that NetBSD is treated like Dragonfly and there is renaming, while on FreeBSD and OpenBSD sys/endian.h is simply included. Only NetBSD 8 and later matter, but NetBSD got sys/endian.h in 1999, and it doesn't seem to have definitions for the target symbols in the Dragonfly case.

I'm guessing this was just an incorrect guess that NetBSD was like DragonFly, when really it seems all are similar except for DragonFly. I'm happy to submit a PR; the following diff (which github web UI refuses to attach) caused the qgis build to make vastly more progress (still running):

--- portable_endian.hpp.orig    2022-01-14 07:06:34.000000000 -0500
+++ portable_endian.hpp 2022-02-02 20:11:56.651221385 -0500
@@ -43,11 +43,11 @@
 #   define __PDP_ENDIAN    PDP_ENDIAN
 **/
 
-#elif defined(__OpenBSD__)|| defined(__FreeBSD__) 
+#elif defined(__OpenBSD__)|| defined(__FreeBSD__) || defined(__NetBSD__)
 
 #   include <sys/endian.h>
 
-#elif defined(__NetBSD__) || defined(__DragonFly__)
+#elif defined(__DragonFly__)
 
 #   define be16toh betoh16
 #   define le16toh letoh16

I'm happy to submit a PR if you are inclined to take it.

Missing file

The file pylazperfapi.cpp is missing from the repo.

can it also manipulate .las files ?

Hi, I'm looking for a decent ( C ) .las reader / writer, one that doesn't require to include half of the universe like liblas does and I must say that laz-perf is exactly what I was looking for... except that it's for .laz files.
How far is laz-perf from reading .las files ? is there any technical difficulty that prevented laz-perf from reading / writing .las files aside from it not being the point of the project at all ?
Or, maybe I just didn't looked hard enough... did I miss this part ?

I would be interested in any pointer regarding what would be left to do in order to be able to open either type of file seamlessly and if someone is interested, I will share the results once it's clean enough

"make install" also installs gtest

When using the latest master, make install will also add gtest files to installation include, lib dirs. I guess that should not be happening?

-- Installing: /home/martin/inst/laz-perf-inst/lib/cmake/GTest/GTestTargets.cmake
-- Installing: /home/martin/inst/laz-perf-inst/lib/cmake/GTest/GTestTargets-release.cmake
-- Installing: /home/martin/inst/laz-perf-inst/lib/cmake/GTest/GTestConfigVersion.cmake
-- Installing: /home/martin/inst/laz-perf-inst/lib/cmake/GTest/GTestConfig.cmake
-- Up-to-date: /home/martin/inst/laz-perf-inst/include
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/gtest-printers.h
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/gtest-param-test.h
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/internal
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/internal/gtest-string.h
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/internal/gtest-port-arch.h
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/internal/gtest-filepath.h
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/internal/custom
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/internal/custom/gtest-printers.h
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/internal/custom/gtest-port.h
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/internal/custom/gtest.h
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/internal/custom/README.md
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/internal/gtest-internal.h
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/internal/gtest-param-util.h
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/internal/gtest-type-util.h
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/internal/gtest-death-test-internal.h
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/internal/gtest-port.h
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/gtest-typed-test.h
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/gtest-test-part.h
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/gtest_pred_impl.h
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/gtest-matchers.h
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/gtest_prod.h
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/gtest-spi.h
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/gtest.h
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/gtest-death-test.h
-- Installing: /home/martin/inst/laz-perf-inst/include/gtest/gtest-message.h
-- Installing: /home/martin/inst/laz-perf-inst/lib/libgtest.a
-- Installing: /home/martin/inst/laz-perf-inst/lib/libgtest_main.a
-- Installing: /home/martin/inst/laz-perf-inst/lib/pkgconfig/gtest.pc
-- Installing: /home/martin/inst/laz-perf-inst/lib/pkgconfig/gtest_main.pc

Issue with Python package 0.0.9 from pypi

I just installed lazperf 0.0.9 from pypi in an isolated virtual env, and import lazperf fails:

(lazperf) [hookipa lopocs (refacto *%)]$ python -c 'import lazperf'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/elemoine/.virtualenvs/lazperf/lib/python3.5/site-packages/lazperf/__init__.py", line 2, in <module>
    from .pylazperfapi import PyDecompressor as Decompressor
ImportError: No module named 'lazperf.pylazperfapi

Is this a known issue?

I use Python 3.5.3 on Debian Sid.

portable_endian.hpp includes windows.h - which tends to cause several issues in including files

Including windows.h has the tendency to break code, e.g.:

https://stackoverflow.com/questions/11544073/how-do-i-deal-with-the-max-macro-in-windows-h-colliding-with-max-in-std

and often also in not easily addressable ways:

https://developercommunity.visualstudio.com/t/error-c2872-byte-ambiguous-symbol/93889

Trying to include laz-perf in PotreeConverter is a pretty difficult experience due to that. Would you accept a PR that moves the # include <winsock2.h> from portable_endian.hpp into a separate portable_endian.cpp file? As long as the include is in a cpp file, it won't cause issues.

Right now I'm having succes after replacing

 #       define htobe16 htons
 #       define htole16(x) (x)
 #       define be16toh ntohs
 #       define le16toh(x) (x)

 #       define htobe32 htonl
 #       define htole32(x) (x)
 #       define be32toh ntohl
 #       define le32toh(x) (x)

 #       define htobe64 htonll
 #       define htole64(x) (x)
 #       define be64toh ntohll
 #       define le64toh(x) (x)

with

inline uint16_t htobe16(uint16_t value);
inline uint16_t htole16(uint16_t value) {return value;};
inline uint16_t be16toh(uint16_t value);
inline uint16_t le16toh(uint16_t value) {return value;};

inline uint32_t htobe32(uint32_t value);
inline uint32_t htole32(uint32_t value) {return value;};
inline uint32_t be32toh(uint32_t value);
inline uint32_t le32toh(uint32_t value) {return value;};

inline uint64_t htobe64(uint64_t value);
inline uint64_t htole64(uint64_t value) {return value;};
inline uint64_t be64toh(uint64_t value);
inline uint64_t le64toh(uint64_t value) {return value;};

And then implementing the functions that rely on the windows api in portable_endian.cpp as follows:

inline uint16_t htobe16(uint16_t value){
	return htons(value);
}

inline uint16_t be16toh(uint16_t value){
	return ntohs(value);
}

inline uint32_t htobe32(uint32_t value){
	return htonl(value);
}

inline uint32_t be32toh(uint32_t value){
	return ntohl(value);
}

inline uint64_t htobe64(uint64_t value){
	return htonll(value);
}

inline uint64_t be64toh(uint64_t value){
	return ntohll(value);
}

Cannot pip install

I tried to install lazperf using pip but it did not work on either Windows or Linux.

I looked at the .tar.gz archive stored on Pypi and it is missing the .pxd file in lazperf folder
and it is also missing the actual laz-perf code which makes the wrapper fail to compile.

Appears platform detection for `laz-perf/portable_endian.hpp` is broken.

I'm building laz-perf on Ubuntu 14.04, and it seems that the platform detection using the host compiler defines does not work due to the Emscripten toolchain definitions.

I receive the following errors when building:

[ 42%] Building CXX object examples/CMakeFiles/readlaz.dir/readlaz.cpp.obj
cd /home/wlucas/ft/laz-perf/examples && /home/wlucas/Development/emsdk_portable/emscripten/master/em++    -s DISABLE_EXCEPTION_CATCHING=2  -std=c++11 -Wextra -Wall -Wpointer-arith -Wcast-align -Wcast-qual -Wfloat-equal -Wredundant-decls -Wno-long-long -fPIC -pedantic -stdlib=libc++ -DEMSCRIPTEN_BUILD -O3 -DNDEBUG -I/home/wlucas/ft/laz-perf/examples/../laz-perf    -o CMakeFiles/readlaz.dir/readlaz.cpp.obj -c /home/wlucas/ft/laz-perf/examples/readlaz.cpp
In file included from /home/wlucas/ft/laz-perf/examples/readlaz.cpp:6:
In file included from /home/wlucas/ft/laz-perf/examples/../laz-perf/io.hpp:45:
/home/wlucas/ft/laz-perf/examples/../laz-perf/portable_endian.hpp:113:5: error: 
      platform not supported
#   error platform not supported
    ^
In file included from /home/wlucas/ft/laz-perf/examples/readlaz.cpp:6:
/home/wlucas/ft/laz-perf/examples/../laz-perf/io.hpp:208:30: error: use of
      undeclared identifier 'le16toh'
                compressor = le16toh(compressor);
                             ^
...

I think the host detection will need to be done in the toolchain-emscripten.cmake file for this to work properly.

request: npm version for frontend use (without node core modules 'fs', 'path')

We would love to use this library in our react frontend. Unfortunately with webpack 5 all polyfill node core modules were removed making it a pain to use modules that rely on/use 'fs' and 'path' dependencies.
Is there a plan for a frontend version of this library without node core dependencies? That would be awesome.

CMake build throws error about lazperf

-- The C compiler identification is GNU 7.5.0
-- The CXX compiler identification is GNU 7.5.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PythonInterp: /usr/bin/python (found version "2.7.17")
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
CMake Error at cmake/install.cmake:22 (install):
install TARGETS given target "lazperf" which does not exist in this
directory.
Call Stack (most recent call first):
cpp/CMakeLists.txt:42 (include)

"make install" does not install las.hpp

QGIS uses a couple of structs from las.hpp, but this header and other headers that it #includes do not get installed with make install. Is it intentional (private API) or is it a bug?

#include "lazperf/las.hpp"

lazperf::las::point10 p;
lazperf::las::gpstime gps;
lazperf::las::rgb rgb;

LAZ-perf or LAZ-zip for write

Hi,

I am new to these tools, but by reading the README I understand:

that LAZ-perf makes a performance when reading LAZ especially when reading from a browser.
it is not clear if LAZ-perf browser features are only available if the LAZ was written initially with LAZperf or if it is also working with any LAZ.
it is not clear if LAZ-perf is more performant than LASzip (when building LAZ from a LAS for example) ?

Would it be please possible to clarify this and maybe put this details into the README ?

Regards

Compiler warnings with g++-4.8-2ubuntu1~14.04

Not critical, but documented here for completeness.

../benchmarks/../laz-perf/io.hpp:207:55: warning: cast from type ‘const char*’ to type ‘unsigned char*’ casts away qualifiers [-Wcast-qual]
                 version.major = *(unsigned char *)data++;
                                                       ^
../benchmarks/../laz-perf/io.hpp:208:55: warning: cast from type ‘const char*’ to type ‘unsigned char*’ casts away qualifiers [-Wcast-qual]
                 version.minor = *(unsigned char *)data++;
                                                       ^

CMake < 3.13: install TARGETS given target "lazperf" which does not exist in this directory.

I see this error in github action with windows-2016 agent, because CMake is lower than 3.13.

-- The C compiler identification is MSVC 19.16.27045.0
-- The CXX compiler identification is MSVC 19.16.27045.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Conan: called by CMake conan helper
-- Conan: called inside local cache
-- Conan: Adjusting output directories
-- Conan: Using cmake global configuration
-- Conan: Adjusting default RPATHs Conan policies
-- Conan: Adjusting language standard
CMake Error at source_subfolder/cmake/install.cmake:22 (install):
  install TARGETS given target "lazperf" which does not exist in this
  directory.
Call Stack (most recent call first):
  source_subfolder/cpp/CMakeLists.txt:32 (include)


-- Configuring incomplete, errors occurred!
See also "C:/Users/runneradmin/.conan/data/laz-perf/2.0.0/bincrafters/testing/build/970e773c5651dc2560f86200a4ea56c23f568ff9/CMakeFiles/CMakeOutput.log".

CMake minimum version should be bumped to 3.13 in top CMakeLists, or probably a better solution would be to move install commands where targets are defined, I believe it makes CMakeLists easier to understand.

Future plans for laz-perf

I been watching some of the recent pull requests and merges from @tmontaigu (really awesome BTW!) and also noticed that you've had a lot of recent work to add support to read from buffers in laspy. Do you think you'll try add laz-perf to laspy to get native LAZ io?

@hobu , also noticed you had a pull request from a few years ago to do just this, but it doesn't look like the laspy devs went anywhere with it...

Postgres 10 crashing on decompressing patch with laz-perf

I've recently rebuild my pgpointcloud setup but am running into a segfault when doing PC_Intersection(patch, geom). According to the backtrace below this seems to be traceable to the laz-perf decoder but I'm not entirely sure.
Can someone confirm that it is indeed coming from the laz-perf decoder?

I am running on a postgres 10 ubuntu package and fresh builds of:
laszip-src-3.2.9
laz-perf-1.3.0
pointcloud-1.2.0

Data in the database has been placed there before by pgpointcloud with likely the same release numbers.

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007fc15eda2535 in __GI_abort () at abort.c:79
#2  0x00007fc15eda240f in __assert_fail_base (fmt=0x7fc15ef30588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
    assertion=0x7fb9202660dc "sym < (1<<16)", file=0x7fb920266050 "/usr/local/include/laz-perf/decoder.hpp", 
    line=170, function=<optimized out>) at assert.c:92
#3  0x00007fc15edb2012 in __GI___assert_fail (assertion=0x7fb9202660dc "sym < (1<<16)", 
    file=0x7fb920266050 "/usr/local/include/laz-perf/decoder.hpp", line=170, 
    function=0x7fb920266600 <laszip::decoders::arithmetic<LazPerfBuf>::readShort()::__PRETTY_FUNCTION__> "U16 laszip::decoders::arithmetic<TInputStream>::readShort() [with TInputStream = LazPerfBuf; U16 = short unsigned int]")
    at assert.c:101
#4  0x00007fb920262a2e in laszip::decoders::arithmetic<LazPerfBuf>::readShort() ()
   from /usr/lib/postgresql/10/lib/pointcloud-1.2.so
#5  0x00007fb920262458 in laszip::decoders::arithmetic<LazPerfBuf>::readBits(unsigned int) ()
   from /usr/lib/postgresql/10/lib/pointcloud-1.2.so
#6  0x00007fb920261f50 in int laszip::decompressors::integer::readCorrector<laszip::decoders::arithmetic<LazPerfBuf>, laszip::models::arithmetic>(laszip::decoders::arithmetic<LazPerfBuf>&, laszip::models::arithmetic&) ()
   from /usr/lib/postgresql/10/lib/pointcloud-1.2.so
#7  0x00007fb920261bb8 in int laszip::decompressors::integer::decompress<laszip::decoders::arithmetic<LazPerfBuf> >(laszip::decoders::arithmetic<LazPerfBuf>&, int, unsigned int) ()
   from /usr/lib/postgresql/10/lib/pointcloud-1.2.so
#8  0x00007fb9202611c8 in int laszip::formats::field<int, laszip::formats::standard_diff_method<int> >::decompressWith<laszip::decoders::arithmetic<LazPerfBuf> >(laszip::decoders::arithmetic<LazPerfBuf>&) ()
   from /usr/lib/postgresql/10/lib/pointcloud-1.2.so
#9  0x00007fb920260b9e in laszip::formats::dynamic_decompressor_field<laszip::decoders::arithmetic<LazPerfBuf>, laszip::formats::field<int, laszip::formats::standard_diff_method<int> > >::decompressRaw(char*) ()
   from /usr/lib/postgresql/10/lib/pointcloud-1.2.so
#10 0x00007fb920259c1e in laszip::formats::dynamic_field_decompressor<laszip::decoders::arithmetic<LazPerfBuf> >::decompress(char*) () from /usr/lib/postgresql/10/lib/pointcloud-1.2.so
#11 0x00007fb920257d64 in LazPerfDecompressor::decompress(unsigned char*, unsigned long) ()
   from /usr/lib/postgresql/10/lib/pointcloud-1.2.so
#12 0x00007fb9202574f1 in lazperf_uncompress_from_compressed () from /usr/lib/postgresql/10/lib/pointcloud-1.2.so
#13 0x00007fb920256f83 in pc_patch_uncompressed_from_lazperf (palaz=0x55e6f8560cc0) at pc_patch_lazperf.c:96
#14 0x00007fb92025705b in pc_pointlist_from_lazperf (palaz=<optimized out>) at pc_patch_lazperf.c:77
#15 0x00007fb9202536b5 in pc_pointlist_from_patch (patch=patch@entry=0x55e6f8560cc0) at pc_pointlist.c:130
#16 0x00007fb92024a395 in pcpatch_unnest (fcinfo=0x55e6f8537d08) at pc_access.c:589
#17 0x000055e6ec765e8b in ExecMakeFunctionResultSet (fcache=0x55e6f8537c98, 
    econtext=econtext@entry=0x55e6f85371d8, isNull=<optimized out>, isDone=isDone@entry=0x55e6f8537c80)
    at ./build/../src/backend/executor/execSRF.c:579
#18 0x000055e6ec77f3ef in ExecProjectSRF (node=node@entry=0x55e6f85370c8, continuing=continuing@entry=0 '\000')
    at ./build/../src/backend/executor/nodeProjectSet.c:166
#19 0x000055e6ec77f4b4 in ExecProjectSet (pstate=0x55e6f85370c8)
    at ./build/../src/backend/executor/nodeProjectSet.c:96
#20 0x000055e6ec781e2d in ExecProcNode (node=0x55e6f85370c8) at ./build/../src/include/executor/executor.h:250
#21 CteScanNext (node=0x55e6f8538c18) at ./build/../src/backend/executor/nodeCtescan.c:103
#22 0x000055e6ec764b89 in ExecScanFetch (recheckMtd=0x55e6ec781d10 <CteScanRecheck>, 
    accessMtd=0x55e6ec781d40 <CteScanNext>, node=0x55e6f8538c18) at ./build/../src/backend/executor/execScan.c:97
#23 ExecScan (node=0x55e6f8538c18, accessMtd=0x55e6ec781d40 <CteScanNext>, 
    recheckMtd=0x55e6ec781d10 <CteScanRecheck>) at ./build/../src/backend/executor/execScan.c:164
#24 0x000055e6ec781e2d in ExecProcNode (node=0x55e6f8538c18) at ./build/../src/include/executor/executor.h:250
#25 CteScanNext (node=0x55e6f853a1e8) at ./build/../src/backend/executor/nodeCtescan.c:103
#26 0x000055e6ec764b89 in ExecScanFetch (recheckMtd=0x55e6ec781d10 <CteScanRecheck>, 
    accessMtd=0x55e6ec781d40 <CteScanNext>, node=0x55e6f853a1e8) at ./build/../src/backend/executor/execScan.c:97
#27 ExecScan (node=0x55e6f853a1e8, accessMtd=0x55e6ec781d40 <CteScanNext>, 
    recheckMtd=0x55e6ec781d10 <CteScanRecheck>) at ./build/../src/backend/executor/execScan.c:164
#28 0x000055e6ec781e2d in ExecProcNode (node=0x55e6f853a1e8) at ./build/../src/include/executor/executor.h:250
#29 CteScanNext (node=0x55e6f853c028) at ./build/../src/backend/executor/nodeCtescan.c:103
#30 0x000055e6ec764d39 in ExecScanFetch (recheckMtd=0x55e6ec781d10 <CteScanRecheck>, 
    accessMtd=0x55e6ec781d40 <CteScanNext>, node=0x55e6f853c028) at ./build/../src/backend/executor/execScan.c:97
#31 ExecScan (node=0x55e6f853c028, accessMtd=0x55e6ec781d40 <CteScanNext>, 
--Type <RET> for more, q to quit, c to continue without paging--
    recheckMtd=0x55e6ec781d10 <CteScanRecheck>) at ./build/../src/backend/executor/execScan.c:147
#32 0x000055e6ec76acdc in ExecProcNode (node=0x55e6f853c028) at ./build/../src/include/executor/executor.h:250
#33 fetch_input_tuple (aggstate=aggstate@entry=0x55e6f853b9e0) at ./build/../src/backend/executor/nodeAgg.c:695
#34 0x000055e6ec76cf58 in agg_retrieve_direct (aggstate=0x55e6f853b9e0)
    at ./build/../src/backend/executor/nodeAgg.c:2362
#35 ExecAgg (pstate=0x55e6f853b9e0) at ./build/../src/backend/executor/nodeAgg.c:2173
#36 0x000055e6ec781e2d in ExecProcNode (node=0x55e6f853b9e0) at ./build/../src/include/executor/executor.h:250
#37 CteScanNext (node=0x55e6f854a938) at ./build/../src/backend/executor/nodeCtescan.c:103
#38 0x000055e6ec764d39 in ExecScanFetch (recheckMtd=0x55e6ec781d10 <CteScanRecheck>, 
    accessMtd=0x55e6ec781d40 <CteScanNext>, node=0x55e6f854a938) at ./build/../src/backend/executor/execScan.c:97
#39 ExecScan (node=0x55e6f854a938, accessMtd=0x55e6ec781d40 <CteScanNext>, 
    recheckMtd=0x55e6ec781d10 <CteScanRecheck>) at ./build/../src/backend/executor/execScan.c:147
#40 0x000055e6ec75e9b3 in ExecProcNode (node=0x55e6f854a938) at ./build/../src/include/executor/executor.h:250
#41 ExecutePlan (execute_once=<optimized out>, dest=0x55e6f8524aa8, direction=<optimized out>, numberTuples=1, 
    sendTuples=<optimized out>, operation=CMD_SELECT, use_parallel_mode=<optimized out>, 
    planstate=0x55e6f854a938, estate=0x55e6f8536e28) at ./build/../src/backend/executor/execMain.c:1723
#42 standard_ExecutorRun (queryDesc=0x55e6f8524af8, direction=<optimized out>, count=1, 
    execute_once=<optimized out>) at ./build/../src/backend/executor/execMain.c:364
#43 0x00007fc15fc09075 in pgss_ExecutorRun (queryDesc=0x55e6f8524af8, direction=ForwardScanDirection, count=1, 
    execute_once=<optimized out>) at ./build/../contrib/pg_stat_statements/pg_stat_statements.c:889
#44 0x000055e6ec769b37 in postquel_getnext (es=0x55e6f8524778, es=0x55e6f8524778, fcache=0x55e6f8514da8, 
    fcache=0x55e6f8514da8) at ./build/../src/backend/executor/functions.c:1169
#45 fmgr_sql (fcinfo=0x55e6f7736d58) at ./build/../src/backend/executor/functions.c:1159
#46 0x000055e6ec75b131 in ExecInterpExpr (state=0x55e6f77368c0, econtext=0x55e6eddf1608, isnull=<optimized out>)
    at ./build/../src/backend/executor/execExprInterp.c:650
#47 0x000055e6ec77f09e in ExecEvalExprSwitchContext (isNull=0x7ffd688ec637 "", econtext=0x55e6eddf1608, 
    state=0x55e6f77368c0) at ./build/../src/include/executor/executor.h:308
#48 ExecProject (projInfo=0x55e6f77368b8) at ./build/../src/include/executor/executor.h:342
#49 ExecNestLoop (pstate=<optimized out>) at ./build/../src/backend/executor/nodeNestloop.c:241
#50 0x000055e6ec75e9b3 in ExecProcNode (node=0x55e6eddf14f8) at ./build/../src/include/executor/executor.h:250
#51 ExecutePlan (execute_once=<optimized out>, dest=0x55e6f6f91288, direction=<optimized out>, numberTuples=0, 
    sendTuples=<optimized out>, operation=CMD_SELECT, use_parallel_mode=<optimized out>, 
    planstate=0x55e6eddf14f8, estate=0x55e6eddf12b8) at ./build/../src/backend/executor/execMain.c:1723
#52 standard_ExecutorRun (queryDesc=0x55e6eea34e98, direction=<optimized out>, count=0, 
    execute_once=<optimized out>) at ./build/../src/backend/executor/execMain.c:364
#53 0x00007fc15fc09075 in pgss_ExecutorRun (queryDesc=0x55e6eea34e98, direction=ForwardScanDirection, count=0, 
    execute_once=<optimized out>) at ./build/../contrib/pg_stat_statements/pg_stat_statements.c:889
#54 0x000055e6ec8a11fc in PortalRunSelect (portal=portal@entry=0x55e6ede53698, forward=forward@entry=1 '\001', 
    count=0, count@entry=9223372036854775807, dest=dest@entry=0x55e6f6f91288)
    at ./build/../src/backend/tcop/pquery.c:932
#55 0x000055e6ec8a2788 in PortalRun (portal=portal@entry=0x55e6ede53698, count=count@entry=9223372036854775807, 
    isTopLevel=isTopLevel@entry=1 '\001', run_once=run_once@entry=1 '\001', dest=dest@entry=0x55e6f6f91288, 
    altdest=altdest@entry=0x55e6f6f91288, completionTag=0x7ffd688eca00 "")
    at ./build/../src/backend/tcop/pquery.c:773
#56 0x000055e6ec89e4fa in exec_simple_query (
    query_string=0x55e6eddf61f8 "SELECT PC_Intersection(pa,geom) FROM tmptom.blocks a INNER JOIN ahn3_pointcloud.vw_buildings b ON PC_Intersects(a.geom, b.pa) WHERE blockid = '0363100012073393';")
    at ./build/../src/backend/tcop/postgres.c:1122
#57 0x000055e6ec89fcd8 in PostgresMain (argc=<optimized out>, argv=argv@entry=0x55e6edd9a870, 
    dbname=<optimized out>, username=<optimized out>) at ./build/../src/backend/tcop/postgres.c:4117
#58 0x000055e6ec82cdd3 in BackendRun (port=0x55e6edd920b0) at ./build/../src/backend/postmaster/postmaster.c:4402
#59 BackendStartup (port=0x55e6edd920b0) at ./build/../src/backend/postmaster/postmaster.c:4074
#60 ServerLoop () at ./build/../src/backend/postmaster/postmaster.c:1756
#61 0x000055e6ec82dc52 in PostmasterMain (argc=5, argv=<optimized out>)
    at ./build/../src/backend/postmaster/postmaster.c:1364
#62 0x000055e6ec5cbd29 in main (argc=5, argv=0x55e6edd37c00) at ./build/../src/backend/main/main.c:228

laz-perf can't open the files it creates for compressed point-format > 5

When writing point-format > 5, laz-perf sets the compressor field of laz_vlr to 3 (see code). When reading however, there is an explicit requirement that compressor == 2 (see code). Commenting out the check causes a crash. This means that any laz file generated by laz-perf with point-format > 5 requires laszip to decompress it.

Error encoding a value of INT_MIN

An assertion is raised when trying to encode the value INT_MIN

laz-perf python api documentation

Hi Howard,

If this implementation is more powerful than LASzip I would like it to read .laz files in my experiments. Could you maybe provide some guidance on how to use the python interface. From the tests I understand the usage for .bin files, but tests for .laz seem to be missing.

Hope to hear from you!

Tom

Compiling of laz-perf.js

Hi!

Is there any manual how to build laz-perf.js library? Or maybe it can be downloaded from somewhere?

Thank you in advance!

Python setup.py import numpy while having as dependency

In laz-perf/python/setup.py the numpy module is imported whilst also being an installation dependency. This means that if lazperf is in a dependency chain, such as a requirements.txt, then the installation will fail. A possible solution would be to remove numpy from setup.py but this may not be easy in this use case. Looking at it briefly, would it be possible to move the setup() call to the top of the file so that numpy loads the dependency before the import?

In my situation I can reproduce by installing the module in a docker instance before numpy is installed. You should also be able to reproduce with a fresh virtualenv of Python installation.

This is the error that is produced in my situation:

  Downloading https://files.pythonhosted.org/packages/07/e9/2020d50b7c9465831f6246812c382b03cff14c5b4708b53cbebd1d2e61c1/lazperf-1.3.tar.gz (186kB)
    ERROR: Command errored out with exit status 1:
     command: /usr/local/bin/python -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-whuivcst/lazperf/setup.py'"'"'; __file__='"'"'/tmp/pip-install-whuivcst/lazperf/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info --egg-base pip-egg-info
         cwd: /tmp/pip-install-whuivcst/lazperf/
    Complete output (5 lines):
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-install-whuivcst/lazperf/setup.py", line 11, in <module>
        import numpy
    ModuleNotFoundError: No module named 'numpy'
    ----------------------------------------
ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.

portable_endian license

Currently, the portable endian license file does not carry a license.
The version below however clearly states that it is in the public domain, which was confirmed by the author panzi/mathfun#1 .
Perhaps it is better to link to this file (and merge emscripten changes back?).

https://gist.githubusercontent.com/panzi/6856583/raw/1eca2ab34f2301b9641aa73d1016b951fff3fc39/portable_endian.h

Incorrect read/write of copc VLR

The copc VLR code doesn't properly handle gpstime_maximum.

Need to disable the autzen tests

Several tests depend on the large autzen file being present. Since that file isn't distributed as part of the repo, those tests should probably be made conditional or something.

Corrupted LAZ output with certain classification sequence

Hi,

I've extracted a specific sequence of classification values for 500 points, which results in a corrupt file being created. I haven't yet been able to reduce the test case further. The specific classification sequence is attached and the test code that produces the issue is below.

You can verify the corruption by dumping the points in the resulting testout.laz file. Also LAStools utils will notify about corruption.

The corruption occurs with GCC 5 on both Linux and Windows.

#include <iterator>
#include <vector>

#include "laz-perf/io.hpp"

namespace lz = laszip;
namespace fmt = laszip::formats;
namespace io = laszip::io;

// Run me:  <binary> <file with white-space delimited classification values as text>
int main(int argc, char** argv) {
  std::ifstream ifs(argv[1]);
  std::istream_iterator<int> it{ifs};
  std::vector<int> cls(it, std::istream_iterator<int>());

  lz::factory::record_schema schema;
  schema(lz::factory::record_item::POINT10);
  io::writer::file out("testout.laz", schema,
      io::writer::config({0.01,0.01,0.01}, {0.0,0.0,0.0}));

  char buf[sizeof(fmt::las::point10)];
  fmt::las::point10 p10;
  for(const int& cl : cls) {
    p10.classification = static_cast<unsigned char>(cl);
    fmt::packers<fmt::las::point10>::pack(p10, buf);
    out.writePoint(buf);
  }
  out.close();
}

CLS.txt

CMake configuration with gtest is incorrect

The Conda Forge builds are failing due to incorrect CMake configuration in the latest release:

CMake Error at cpp/test/CMakeLists.txt:15 (add_subdirectory):
  The source directory

    /Users/runner/miniforge3/conda-bld/laz-perf_1623102252085/work/cpp/test/gtest/gtest-02-06-2021

  does not contain a CMakeLists.txt file.

See https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=334297&view=logs&jobId=58ac6aab-c4bc-5de2-2894-98e408cc8ec9&j=58ac6aab-c4bc-5de2-2894-98e408cc8ec9&t=933f325c-924e-533d-4d95-e93b5843ce8b for detailed errors.

build issue on debian

Trying to build on Debian SID I got the following error:

 make
[  9%] Built target point10
[ 18%] Built target simple
[ 22%] Building CXX object examples/CMakeFiles/readlaz.dir/readlaz.cpp.o
In file included from /home/epinux/dev/laz-perf/examples/readlaz.cpp:6:0:
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:456:18: error: ‘function’ in namespace ‘std’ does not name a template type
     typedef std::function<void (header&)> validator_type;
                  ^~~~~~~~
In file included from /home/epinux/dev/laz-perf/examples/readlaz.cpp:6:0:
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:677:30: error: ‘validator_type’ was not declared in this scope
     static const std::vector<validator_type>& _validators() {
                              ^~~~~~~~~~~~~~
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:677:44: error: template argument 1 is invalid
     static const std::vector<validator_type>& _validators() {
                                            ^
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:677:44: error: template argument 2 is invalid
In file included from /home/epinux/dev/laz-perf/examples/readlaz.cpp:6:0:
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp: In member function ‘void laszip::io::reader::basic_file<StreamType>::_open()’:
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:519:32: error: there are no arguments to ‘begin’ that depend on a template parameter, so a declaration of ‘begin’ must be available [-fpermissive]
      for (auto f : _validators())
                                ^
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:519:32: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated)
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:519:32: error: there are no arguments to ‘end’ that depend on a template parameter, so a declaration of ‘end’ must be available [-fpermissive]
In file included from /home/epinux/dev/laz-perf/examples/readlaz.cpp:6:0:
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp: In static member function ‘static const int& laszip::io::reader::basic_file<StreamType>::_validators()’:
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:678:25: error: ‘validator_type’ was not declared in this scope
      static std::vector<validator_type> v; // static collection of validators
                         ^~~~~~~~~~~~~~
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:678:25: note: suggested alternative: ‘_validators’
      static std::vector<validator_type> v; // static collection of validators
                         ^~~~~~~~~~~~~~
                         _validators
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:678:39: error: template argument 1 is invalid
      static std::vector<validator_type> v; // static collection of validators
                                       ^
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:678:39: error: template argument 2 is invalid
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:683:12: error: request for member ‘empty’ in ‘v’, which is of non-class type ‘int’
      if (v.empty()) {
            ^~~~~
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:691:13: error: request for member ‘empty’ in ‘v’, which is of non-class type ‘int’
       if (v.empty()) {
             ^~~~~
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:694:10: error: request for member ‘push_back’ in ‘v’, which is of non-class type ‘int’
        v.push_back(
          ^~~~~~~~~
In file included from /home/epinux/dev/laz-perf/examples/readlaz.cpp:6:0:
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp: In instantiation of ‘void laszip::io::reader::basic_file<StreamType>::_open() [with StreamType = std::basic_ifstream<char>]’:
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:460:11:   required from ‘laszip::io::reader::basic_file<StreamType>::basic_file(StreamType&) [with StreamType = std::basic_ifstream<char>]’
/home/epinux/dev/laz-perf/examples/readlaz.cpp:46:33:   required from here
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:519:6: error: ‘begin’ was not declared in this scope
      for (auto f : _validators())
      ^~~
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:519:6: note: suggested alternative:
In file included from /usr/include/c++/7/string:51:0,
                 from /usr/include/c++/7/bits/locale_classes.h:40,
                 from /usr/include/c++/7/bits/ios_base.h:41,
                 from /usr/include/c++/7/ios:42,
                 from /usr/include/c++/7/istream:38,
                 from /usr/include/c++/7/fstream:38,
                 from /home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:34,
                 from /home/epinux/dev/laz-perf/examples/readlaz.cpp:6:
/usr/include/c++/7/bits/range_access.h:87:5: note:   ‘std::begin’
     begin(_Tp (&__arr)[_Nm])
     ^~~~~
In file included from /home/epinux/dev/laz-perf/examples/readlaz.cpp:6:0:
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:519:6: error: ‘end’ was not declared in this scope
      for (auto f : _validators())
      ^~~
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:519:6: note: suggested alternative:
In file included from /usr/include/c++/7/string:51:0,
                 from /usr/include/c++/7/bits/locale_classes.h:40,
                 from /usr/include/c++/7/bits/ios_base.h:41,
                 from /usr/include/c++/7/ios:42,
                 from /usr/include/c++/7/istream:38,
                 from /usr/include/c++/7/fstream:38,
                 from /home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:34,
                 from /home/epinux/dev/laz-perf/examples/readlaz.cpp:6:
/usr/include/c++/7/bits/range_access.h:97:5: note:   ‘std::end’
     end(_Tp (&__arr)[_Nm])
     ^~~
examples/CMakeFiles/readlaz.dir/build.make:62: recipe for target 'examples/CMakeFiles/readlaz.dir/readlaz.cpp.o' failed
make[2]: *** [examples/CMakeFiles/readlaz.dir/readlaz.cpp.o] Error 1
CMakeFiles/Makefile2:165: recipe for target 'examples/CMakeFiles/readlaz.dir/all' failed
make[1]: *** [examples/CMakeFiles/readlaz.dir/all] Error 2
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2
epinux@geohab-tools:~/dev/laz-perf/build$ cd ...
-bash: cd: ...: No such file or directory
epinux@geohab-tools:~/dev/laz-perf/build$ cd ..
epinux@geohab-tools:~/dev/laz-perf$ rm -rf build/
epinux@geohab-tools:~/dev/laz-perf$ mkdir buil
epinux@geohab-tools:~/dev/laz-perf$ mv buil build
epinux@geohab-tools:~/dev/laz-perf$ cd build/
epinux@geohab-tools:~/dev/laz-perf/build$ ccmake ..


epinux@geohab-tools:~/dev/laz-perf/build$ make
Scanning dependencies of target point10
[  4%] Building CXX object examples/CMakeFiles/point10.dir/point10.cpp.o
[  9%] Linking CXX executable point10
[  9%] Built target point10
Scanning dependencies of target simple
[ 13%] Building CXX object examples/CMakeFiles/simple.dir/simple.cpp.o
[ 18%] Linking CXX executable simple
[ 18%] Built target simple
Scanning dependencies of target readlaz
[ 22%] Building CXX object examples/CMakeFiles/readlaz.dir/readlaz.cpp.o
In file included from /home/epinux/dev/laz-perf/examples/readlaz.cpp:6:0:
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:456:18: error: ‘function’ in namespace ‘std’ does not name a template type
     typedef std::function<void (header&)> validator_type;
                  ^~~~~~~~
In file included from /home/epinux/dev/laz-perf/examples/readlaz.cpp:6:0:
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:677:30: error: ‘validator_type’ was not declared in this scope
     static const std::vector<validator_type>& _validators() {
                              ^~~~~~~~~~~~~~
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:677:44: error: template argument 1 is invalid
     static const std::vector<validator_type>& _validators() {
                                            ^
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:677:44: error: template argument 2 is invalid
In file included from /home/epinux/dev/laz-perf/examples/readlaz.cpp:6:0:
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp: In member function ‘void laszip::io::reader::basic_file<StreamType>::_open()’:
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:519:32: error: there are no arguments to ‘begin’ that depend on a template parameter, so a declaration of ‘begin’ must be available [-fpermissive]
      for (auto f : _validators())
                                ^
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:519:32: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated)
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:519:32: error: there are no arguments to ‘end’ that depend on a template parameter, so a declaration of ‘end’ must be available [-fpermissive]
In file included from /home/epinux/dev/laz-perf/examples/readlaz.cpp:6:0:
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp: In static member function ‘static const int& laszip::io::reader::basic_file<StreamType>::_validators()’:
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:678:25: error: ‘validator_type’ was not declared in this scope
      static std::vector<validator_type> v; // static collection of validators
                         ^~~~~~~~~~~~~~
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:678:25: note: suggested alternative: ‘_validators’
      static std::vector<validator_type> v; // static collection of validators
                         ^~~~~~~~~~~~~~
                         _validators
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:678:39: error: template argument 1 is invalid
      static std::vector<validator_type> v; // static collection of validators
                                       ^
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:678:39: error: template argument 2 is invalid
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:683:12: error: request for member ‘empty’ in ‘v’, which is of non-class type ‘int’
      if (v.empty()) {
            ^~~~~
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:691:13: error: request for member ‘empty’ in ‘v’, which is of non-class type ‘int’
       if (v.empty()) {
             ^~~~~
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:694:10: error: request for member ‘push_back’ in ‘v’, which is of non-class type ‘int’
        v.push_back(
          ^~~~~~~~~
In file included from /home/epinux/dev/laz-perf/examples/readlaz.cpp:6:0:
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp: In instantiation of ‘void laszip::io::reader::basic_file<StreamType>::_open() [with StreamType = std::basic_ifstream<char>]’:
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:460:11:   required from ‘laszip::io::reader::basic_file<StreamType>::basic_file(StreamType&) [with StreamType = std::basic_ifstream<char>]’
/home/epinux/dev/laz-perf/examples/readlaz.cpp:46:33:   required from here
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:519:6: error: ‘begin’ was not declared in this scope
      for (auto f : _validators())
      ^~~
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:519:6: note: suggested alternative:
In file included from /usr/include/c++/7/string:51:0,
                 from /usr/include/c++/7/bits/locale_classes.h:40,
                 from /usr/include/c++/7/bits/ios_base.h:41,
                 from /usr/include/c++/7/ios:42,
                 from /usr/include/c++/7/istream:38,
                 from /usr/include/c++/7/fstream:38,
                 from /home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:34,
                 from /home/epinux/dev/laz-perf/examples/readlaz.cpp:6:
/usr/include/c++/7/bits/range_access.h:87:5: note:   ‘std::begin’
     begin(_Tp (&__arr)[_Nm])
     ^~~~~
In file included from /home/epinux/dev/laz-perf/examples/readlaz.cpp:6:0:
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:519:6: error: ‘end’ was not declared in this scope
      for (auto f : _validators())
      ^~~
/home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:519:6: note: suggested alternative:
In file included from /usr/include/c++/7/string:51:0,
                 from /usr/include/c++/7/bits/locale_classes.h:40,
                 from /usr/include/c++/7/bits/ios_base.h:41,
                 from /usr/include/c++/7/ios:42,
                 from /usr/include/c++/7/istream:38,
                 from /usr/include/c++/7/fstream:38,
                 from /home/epinux/dev/laz-perf/examples/../laz-perf/io.hpp:34,
                 from /home/epinux/dev/laz-perf/examples/readlaz.cpp:6:
/usr/include/c++/7/bits/range_access.h:97:5: note:   ‘std::end’
     end(_Tp (&__arr)[_Nm])
     ^~~
examples/CMakeFiles/readlaz.dir/build.make:62: recipe for target 'examples/CMakeFiles/readlaz.dir/readlaz.cpp.o' failed
make[2]: *** [examples/CMakeFiles/readlaz.dir/readlaz.cpp.o] Error 1
CMakeFiles/Makefile2:165: recipe for target 'examples/CMakeFiles/readlaz.dir/all' failed
make[1]: *** [examples/CMakeFiles/readlaz.dir/all] Error 2
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2

I used the default cmake settings.
This my compiler:

gcc -v

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.2.0-6' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.2.0 (Debian 7.2.0-6)

lazperf::reader objects refuse to open las format 1.0 and 1.1

On line 159 of readers.cpp, in the function for reading the header, we have the following check:

if (head12.version.minor < 2 || head12.version.minor > 4)
    return false;

In other words, if the file isn't las/laz version 1.2 through 1.4, give up on even attempting to read the header.

I assume the reason for this is because version 1.2 added the global encoding flags, in bytes which were previously marked as reserved. Theoretically, a las version 1.0 or 1.1 file that doesn't have those bytes zeroed out is an improperly formatted file. In practice, it seems to be industry standard to pretend that files that record their version as 1.0 or 1.1 are actually version 1.2. For example, I have a file which claims to be version 1.0 but which has point format 1--a theoretically invalid combination. But in my testing, lidR, PDAL, and FUSION will all open it without complaints.

Removing the check forbidding versions 1.0-1.1 and rebuilding lazperf, I am able to read version 1.0 files without issue, including the invalid file mentioned above. I don't see anything that was changed in version 1.2 that makes it dangerous to read a version 1.0 or 1.1 header as if it were 1.2--1.2 just added more options in bytes that ought to be zeroed out in well-formatted 1.0 files. In practice, this is already happening when reading version 1.2 files--the global encoding bytes are being copied uncritically from the harddrive into memory, even though only one bit has any meaning in the 1.2 specification.

If this solution is considered a bit too loose, I'd be willing to try my hand at a pull request to implement proper header10 and header11 support, which would skip the reserved bytes and not even copy them into memory (or always record them as 0). Assuming I'm not missing a good reason why those formats aren't supported by reader objects, that is.

A lot of debug output from LAZDEBUG

Currently lazperf outputs a lot of debug output from LAZDEBUG macro when reading points unless NDEBUG is defined. It would be nicer if there would be an explicit macro to enable it (e.g. LAZPERF_DEBUG) rather than just using the generic NDEBUG.

Rationale: in a project like QGIS, one wants to run debug version of the code (without NDEBUG defined) but having lazperf output so much information is not desired. I know one could define NDEBUG compile options for lazperf source files even when compiling in debug mode, but opt-in approach to enable lazperf debug output would be much nicer...

CMake: allow to add laz-perf with add_subdirectory()

When laz-perf tree is added through add_subdirectory(), CMake generation fails with Run cmake from the top level of the source tree due to https://github.com/hobu/laz-perf/blob/2e3c316248fa534cdeba1b47b2e9fe1a0ecf5dca/cpp/CMakeLists.txt#L1-L3

Indeed CMAKE_PROJECT_NAME always refers to the top level project, not the closest one (which is PROJECT_NAME). I advice to completly remove those 3 lines.

Decoding some fields with no change incorrect for 1.4 types

When encoding LAZ 1.4 and values don't change, they store no data in the compressed sub-chunk and this is indicated by a 0 sub-chunk size. When the 0 sub-chunk size is detected, no decoding should occur for changes. This applies to Z, Classification, flags, Intensity and UserData.

decompressor doesn't know when it's done

The stream API doesn't allow the decompressor know when it has consumed a stream. It depends on the user knowing how many points are being decompressed.