On VS2015 there is this error:

src\LercLib\Lerc.cpp(1541): error C2065: 'greater': undeclared identifier
src\LercLib\Lerc.cpp(1541): error C2062: type 'double' unexpected
src\LercLib\Lerc.cpp(1568): error C2039: 'greater': is not a member of 'std'
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\string(17): note: see declaration of 'std'
src\LercLib\Lerc.cpp(1568): error C2065: 'greater': undeclared identifier
src\LercLib\Lerc.cpp(1568): error C2062: type 'double' unexpected

I fixed it by adding

#include <functional>

std-greater.txt

Latest Windows decoder "Lerc.dll" has some artifacts when generating heights data for the surface. It generates unwanted holes and bumps while decoding some tiles as shown in the following pictures.

Did not test on Mac & Linux yet but it could be the same for these libraries too.

the readme for this project mentions that the version is now at Lerc2 v3. i recommend the following:

1. take advantage of git/github tags and releases
2. maintain a Changelog.md
3. use Semantic Versioning to denote breaking changes and other alterations to the code.

doing this would give outside developers a much better understanding of what is going on with the project.

Trying to build the static library I get the error

install: cannot stat src/LercLib/BitSuffer2.h

This is a typo, it should be src/LercLib/BitStuffer2.h

presenting a chart demonstrating some benchmarks would be an extremely valuable way to put a point on what the format is all about in a succinct way.

http://developers.arcgis.com/javascript/samples/layers_raster/

Filter down temperatures and then pan:

@jgravois @tmaurer3

@tmaurer3

The documentation says that lerc_computeCompressedSize is optional. But the size returned but lerc_encode may be less that what is needed for successful decoding, no way to know what that value is without calling lerc_computeCompressedSize.
I found out the hard way.
Can we have lerc_encode() return the actual number of bytes needed by decoder, aka the return from lerc_computeCompressedSize?

We're using lerc on Android devices. We periodically see unaligned access errors on 32-bit devices (ABI armeabi-v7a) arising from the assignments

    int height = *((const int*)ptr);  ptr += sizeof(int);
    int width  = *((const int*)ptr);  ptr += sizeof(int);
    double maxZErrorInFile = *((const double*)ptr);

in Lerc::GetLercInfo lines 154-156. At the moment we are avoiding the errors by using memcpy instead of pointer casting:

    int height;
    memcpy(&height, ptr, sizeof(int));
    ptr += sizeof(int);
    int width;
    memcpy(&width, ptr, sizeof(int));
    ptr += sizeof(int);
    double maxZErrorInFile;
    memcpy(&maxZErrorInFile, ptr, sizeof(double));

Can you incorporate this as a fix? I can provide a pull request if you'd like.

Trying to find a given Lerc github release is very difficult with daily releases published of the same runetimecore version. Is there a reason it is rebuilt daily? Can it be removed from the release tags except for actual version changes?

the doc not Introduction how write the compress result to file and the lerc data structure.

I have write the pLercBlob to file，but the lerc file need the header,
the code
` for(int i=0;i<numBytesBlob;i++)

outfile.write((char*)&pLercBlob[i],sizeof(pLercBlob[i]));

outfile.close( ); `

./src/LercLib/fpl_Lerc2Ext.cpp:469: doble ==> double
./src/LercLib/include/Lerc_c_api.h:264: occurence ==> occurrence
./OtherLanguages/js/dist/LercDecode.js:434: compatiblity ==> compatibility
./OtherLanguages/js/src/Lerc.ts:554: compatiblity ==> compatibility

Leaflet doesn't appear to give us any built in tile caching.

@patrickarlt would it be feasible for us to try and leverage leaflet-virtual-grid for this?

It would be very helpful if the CMakeLists.txt, instead of hard-coding SHARED on the add_library command, instead honored the standard convention of using an option BUILD_SHARED_LIBRARIES (the default can be ON). This would allow a user/site to easily override the default in order to build static libraries if they need it.

The idiom for doing this is simply:

# Make an option, defaulting to shared libs, but allow -DBUILD_SHARED_LIBS=OFF
option (BUILD_SHARED_LIBS "Build shared libraries (set to OFF to build static libs)" ON)

# If no SHARED or STATIC is specified explicitly, add_library will honor BUILD_SHARED_LIBS
add_library (mylibrary ${SOURCES})

I'm sorry I have to just leave these breadcrumbs at your door instead of submitting a proper PR that fully implements it. There's too much bureaucracy in my organization to get legal approval for a one-time, two-line patch.

Thanks for your work with this library!

timer() does not need to run in the background when printInfo is False for the functions findDataRange, _encode_Ext, getLercDataRanges, _decode_Ext.

Feature request: please consider to support also big endian architectures.

If you use <script type="text/javascript" src="https://unpkg.com/lerc"></script>, unpkg.com won't redirect wasm file.

To workaround this issue, use the following url
<script type="text/javascript" src="https://unpkg.com/lerc@latest/LercDecode.min.js"></script>

There's one recently reported case with a special categorical raster (8 bit, single band) whose max value is very small (7) and encoded using Huffman.

The lines in the public header

are ok for building a DLL with Visual Studio only, but will not work for projects using the DLL via this header without patching, nor for other compilers on Windows.

See e.g. https://stackoverflow.com/a/538179 and https://gcc.gnu.org/wiki/Visibility#Step-by-step_guide

Another macro is usually needed to distinguish between building the DLL and simply using it (it looks like MSVC and CMake on Windows will readily define LERC_EXPORTS so that could be used for convenience), and one should be testing for _WIN32, not just _MSC_VER.

Sorry, another documentation question. I will try to turn these into a FAQ or more detailed examples or something like that later and make a PR.

LERC can be used with MaxZError = 0 which makes it a lossless process. Still it does compress the data, regardless of the type. How well depends on the data of course. I tested this with GDAL so I might look at some implementation specifics but I would be surprised if it did something it is not meant to do. I tested various data types from Byte to Float32 and they all shrank.

What I read in the patent (on the page break between column 8 and 9) and the byte stream docs says that the values would not be compressed if MaxZError is 0 though so I wonder which parts of the whole LERC algorithm are still applied and when. I probably missed something but I am completely lost somehow.

Thank you!

I think it would be great if we can have some documentation on how to compile Lerc on Linux or OSX. Such as whether there are any special libraries that I need to install.

Also, I assume we can't run LercTest on OSX because of PerfTimer?

when the next generation javascript decoder is released, lets publish it to npm . i'd like to help with this.

thanks to @lucianpls, we now display elevation in meters appropriately when using the +/- zoom buttons and dragging a box to zoom in the leaflet sample, but once the map is panned by click dragging, either the elevation shows as undefined, or a value is displayed from an offset location.

I am currently reading through the patent and have a question (probably stupid and there are probably more to come :D ). I hope it is ok if I use an issue here for this.

A LERC block knows about the number of valid/non-negative pixels and then there is the bitstuffed data (which can be unpacked since we know the bits per pixel and the number of pixels). But there could be "void" pixels (~=NODATA pixels).

Looking at https://raw.githubusercontent.com/Esri/lerc/master/doc/LercEncodingSample.png there are four "void" pixels.

What happens with them when encoding? How would I know where to re-insert them in the block when unpacking if I just find 12 pixel values for the 4x4 (=16 pixels) block?

_ enable call from other languages such as python
_ no change to file format, no version change, just high level interfaces
_ clean up the folder structure for windows and Linux build support

i could be wrong, but from looking at nasa-gibs/mrf it appears that the RPM Installation instructions document the easiest way to add support for LERC to a GDAL installation. am i missing anything?

it would be an improvement to our repository here if we explained how to get LERC support in GDAL on windows/mac/linux instead of assuming folks will figure it out themselves.

https://www.npmjs.com/package/lerc

if so, i'm happy to tackle it.

Using VS2015 the files src\LercLib\fpl_EsriHuffman.cpp and src\LercLib\fpl_Lerc2Ext.cpp dot not compile, the error is:

error C2039: 'min': is not a member of 'std'

I fixed it by adding

#include <algorithm>

std-min.txt

It would be helpful if we can have a sample in LercTest to demonstrate encoding/decoding of an image on disk. This way, it would help users get a better grasp of MaxZError, and its direct effect on file size and decoded image quality.

The existing 2 samples are great in that it gives users an idea of how fast Lerc is, but leaves me wanting for more of a real life example.

I'm using the Composite Bands python raster function to combine three mosaic datasets into one image service. I'm publishing this service using LERC tiles that are generated on the fly.

I'm reading the tiles using this example from @jgravois, When I log the pixel values, however, I'm only getting data from the first raster, not all three.

Is it possible to encode a multi-band image service in LERC using out of the box ArcGIS Server 10.3? For more information, see my Stack Exchange post.

Apologies if this is the wrong location to post this. Thanks!

It would be useful when sharing the LERC project and demonstrating what it does to have a gh-pages at http://esri.github.io/lerc/

This could demonstrate a comparison of LERC versus non-LERC imagery as well as enumerate LERC sources that we provide and simple steps for people to publish their own and use with our tools.

The biggest change is to allow for multiple (nDim) values per pixel. The API will change accordingly. The function calls will get an extra parameter "nDim" in addition to "nCols", "nRows", and "nBands". So an RGB image can now be represented as [RGB, RGB, ...] by setting nDim = 3 and nBands =1, or it can be represented as before as [RRRR ..., GGGG ..., BBBB ...] by setting nDim =1 and nBands = 3.
The Lerc API release version will change from 1.0 to 2.0.
There will be other improvements and updates as well.

Hi there, just wondering why Esri updates the arcgis package on PyPI, but not lerc. The PyPI lerc package is severely outdated. I understand that conda is the preferred install method, but if one pacakge is kept up to date on PyPI, then why not another?

Thanks

We need to use lerc2 tile tool in our project but I can't find javascript reader for lerc2 (even in js-lerc2 branch), so I migrated C++ implementation to TypeScript on https://github.com/lovelypeople/lerc2-js, hope it can help.

I've noticed a number of buffer overflow fixes/ UB fixes going in in the past few months. Is there any chance of an official release containing these going out?

Hi,

is I just installed 4.0.0., but I cannot import interfaces from your library. Can you please export those interfaces?

Thanks you

InBitStuffer2::BitStuff, if bitPos <= 0 and (32 - bitPos >= numBits) is False, an undefined bitshift will occur when (*srcPtr++) >> (32 - bitPos).

LERC functions which use BitStuff make this scenario impossible by returning false if numBits >= 32 before calling BitStuff. Users of the library may not do this. If that scenario is likely, could the BitStuff function be patched?

Hi all,
just wanted to draw your attention to this issue.
As it's relevant to the future adoption of LERC, I thought it might be interesting for you.

Regards, Marco

I'm creating a recipe of lerc for conan: conan-io/conan-center-index#1159

It's not really clear what names should be given to generated lib files: LercLib (in CMakeLists in master)? Lerc (in bin)?

By the way, why do you force using shared lib in build scripts? Seems to also properly work as static lib.

For example, here is how I've patched v2.1 for conan in order to support static or shared, but also to quickly fix strange things in macros related to LERCDLL_API:

--- /dev/null
+++ b/CMakeLists.txt
@@ -0,0 +1,24 @@
+cmake_minimum_required(VERSION 3.0.2)
+project(Lerc)
+
+file(GLOB SOURCES 
+  "src/LercLib/*"
+  "src/LercLib/Lerc1Decode/*"
+)
+
+add_library(LercLib ${SOURCES})
+set_property(TARGET LercLib PROPERTY CXX_STANDARD 11)
+if(BUILD_SHARED_LIBS)
+  set_property(TARGET LercLib PROPERTY CXX_VISIBILITY_PRESET hidden)
+  if(WIN32)
+    target_compile_definitions(LercLib PRIVATE LERC_EXPORTS)
+  endif()
+endif()
+
+set(HEADER_FILES include/Lerc_c_api.h include/Lerc_types.h)
+install(FILES ${HEADER_FILES} DESTINATION include)
+install(TARGETS LercLib
+  RUNTIME DESTINATION bin
+  LIBRARY DESTINATION lib
+  ARCHIVE DESTINATION lib
+)
--- a/include/Lerc_c_api.h
+++ b/include/Lerc_c_api.h
@@ -28,13 +28,7 @@ Contributors:  Thomas Maurer
 extern "C" {
 #endif
 
-#if defined(_MSC_VER)
-  #define LERCDLL_API __declspec(dllexport)
-#elif __GNUC__ >= 4
-  #define LERCDLL_API __attribute__((visibility("default")))
-#else
-  #define LERCDLL_API
-#endif
+#define LERCDLL_API
 
 
   //! C-API for LERC library
--- a/src/LercLib/Lerc_c_api.h
+++ b/src/LercLib/Lerc_c_api.h
@@ -28,8 +28,12 @@ Contributors:  Thomas Maurer
 extern "C" {
 #endif
 
-#if defined(_MSC_VER)
-  #define LERCDLL_API __declspec(dllexport)
+#ifdef _WIN32
+  #ifdef LERC_EXPORTS
+    #define LERCDLL_API __declspec(dllexport)
+  #else
+    #define LERCDLL_API
+  #endif
 #elif __GNUC__ >= 4
   #define LERCDLL_API __attribute__((visibility("default")))
 #else

For reference I've posted this issue here as well as I am using the OptimizeRasters toolkit to create rasters with LERC.

I am creating MRFs, uploaded to S3, then adding them to a mosaic dataset and publishing the mosaic dataset to Image Server on Linux.

When I add the image service to ArcGIS Pro 2.6, the rasters do not draw. When I try to use the Image Server Rest API export image command, I can't get an image to be returned.

Through troubleshooting, I've found that if I add the same mosaic dataset to Pro locally, the rasters are able to be drawn, so I don't think it's an issue with access to S3 or the rasters. If I publish the image service with rasters using the JPEG compression, the service draws fine in ArcGIS Pro from image server.

Does anyone know if Image Server should be able to serve out rasters with LERC and what I need to configure to get them to display?

I am writing a python wrapper that round-trips a numpy array through encode and decode. This wrapper works on both 2D and 3D numpy arrays, however, I get a surprising result when I compare the post-LERC results of individual bands.

I expected that if I encode and then decode a 256x256x2 array and do the same for each of the bands and stack them together that I should get identical results. However, this is not the case.

Is this incorrect?

Python test

This test fails on the last assert.

class TestLercCompressor:

    @classmethod
    def _zerror(cls, dtype: np.dtype):
        zerror = 5.0  # in unit8 space
        if np.issubdtype(dtype, np.integer):
            return dtype(zerror * (np.iinfo(dtype).max / np.iinfo(np.uint8).max))
        else:
            return dtype((zerror + 0.5) / (np.iinfo(np.uint8).max + 1))

    @pytest.mark.parametrize("dtype", [np.uint8, np.uint16, np.float32, np.double])
    def test_compress_3d(self, request, test_data_dir: Path, dtype: np.dtype):
        testname = f"{self.__class__.__name__}.{request.node.name}"
        rs = np.random.RandomState(sum(map(ord, testname)))
        if np.issubdtype(dtype, np.integer):
            raster = rs.randint(np.iinfo(dtype).min, np.iinfo(dtype).max, size=(256, 256, 2), dtype=dtype)
        else:
            raster = rs.uniform(0, 1, size=(256, 256, 2)).astype(dtype)

        z_error = self._zerror(dtype)

        raster2d = np.stack(
            [
                lerc.apply(raster=raster[..., 0], max_z_error=z_error),
                lerc.apply(raster=raster[..., 1], max_z_error=z_error),
            ],
            axis=2,
        )
        raster3d = lerc.apply(raster=raster, max_z_error=z_error)

        assert raster2d.dtype == raster.dtype
        np.testing.assert_raises(AssertionError, np.testing.assert_equal, raster, raster2d)
        np.testing.assert_allclose(raster, raster2d, rtol=0.0, atol=z_error)  # check raster2d changed
        if np.issubdtype(dtype, np.integer):
            np.testing.assert_array_less(raster2d, np.iinfo(dtype).max)
        else:
            np.testing.assert_array_less(raster2d, 1.0)

        assert raster3d.dtype == raster.dtype
        np.testing.assert_raises(AssertionError, np.testing.assert_equal, raster, raster3d)
        np.testing.assert_allclose(raster, raster3d, rtol=0.0, atol=z_error)  # check raster3d changed
        if np.issubdtype(dtype, np.integer):
            np.testing.assert_array_less(raster3d, np.iinfo(dtype).max)
        else:
            np.testing.assert_array_less(raster3d, 1.0)

        # there should be no difference between 2d and 3d
        np.testing.assert_equal(raster2d, raster3d)

C++ wrapping code using pybind11

#include "wrapLerc.hpp"

#include <pybind11/numpy.h>
#include <pybind11/stl_bind.h>

#include <LercLib/Defines.h>
#include <LercLib/Lerc.h>
#include <LercLib/Lerc_types.h>

namespace py = pybind11;

namespace {
static constexpr int LERC_VERSION = -1;  // use the latest

template <typename DataT> struct NumpyInfo {
    using NumpyT = typename py::array_t<DataT, py::array::c_style>;

    NumpyInfo() : array(), info(), data(nullptr), nDim(1), nCols(0), nRows(0), nBands(0) {}

    NumpyInfo(NumpyT inArray)
        : array(inArray), info(array.request()), data(nullptr), nDim(1), nCols(0), nRows(0), nBands(0) {
        if (info.ndim != 2 && info.ndim != 3) {
            throw std::runtime_error("LERC compression requires a 2D or 3D array");
        }
        if (info.ptr == nullptr) {
            throw std::runtime_error("The array has no data!");
        }
        data = static_cast<DataT *>(info.ptr);
        nCols = info.shape[0];
        nRows = info.shape[1];
        nBands = (info.ndim == 2) ? 1 : info.shape[2];
        if (array.size() != nCols * nRows * nBands) {
            throw std::runtime_error("Failed to correctly extract array size");
        }
    }

    NumpyInfo(const NumpyInfo &other) : NumpyInfo(std::move(NumpyT(other.info.shape, other.info.strides))) {
        // copy data into the array
        std::copy(other.data, other.data + other.array.size(), data);
    }

    NumpyInfo copy() const { return NumpyInfo(*this); }

    /// numpy array
    NumpyT array;
    /// numpy buffer protocol
    py::buffer_info info;
    /// Raw image data, row by row, band by band. This is a raw pointer, assume someone else is looking after memory
    DataT *data;
    /// number of values per pixel (for us, this is always 1)
    const int nDim;
    /// data shape
    int nCols, nRows, nBands;
};

/// Calculate the size of the required buffer size
template <typename DataT> struct LercBufferSize {
    using RasterInfo = NumpyInfo<DataT>;
    using RasterT = typename RasterInfo::NumpyT;

    static uint32_t calculate(const RasterT &raw, double maxZError) {
        RasterInfo raster(raw);
        return calculateImpl(raster, maxZError);
    }

    static uint32_t calculateImpl(const RasterInfo &raster, double maxZError) {
        LercNS::BitMask *bitMask = nullptr;  // We don't care about the mask
        uint32_t bs = 0;                     // size of outgoing Lerc blob
        auto status = LercNS::Lerc::ComputeCompressedSizeTempl<DataT>(
            raster.data, LERC_VERSION, raster.nDim, raster.nCols, raster.nRows, raster.nBands, bitMask, maxZError, bs);
        if (status != LercNS::ErrCode::Ok) {
            throw std::runtime_error("Failed to fetch the number of bytes required for the buffer");
        }
        return bs;
    }
};

template <typename DataT> struct LercCompressor {
    using RasterInfo = NumpyInfo<DataT>;
    using RasterT = typename RasterInfo::NumpyT;

    static void applyInPlace(RasterT &raw, double maxZError) {
        RasterInfo raster(raw);
        impl(raster, maxZError);
    }

    static RasterT apply(const RasterT &raw, double maxZError) {
        auto raster = RasterInfo(raw).copy();
        impl(raster, maxZError);
        return raster.array;
    }

  private:
    static void impl(RasterInfo &raster, double maxZError) {
        LercNS::BitMask *bitMask = nullptr;  // We don't care about the mask

        // --- get the buffer size
        uint32_t numBytesNeeded = LercBufferSize<DataT>::calculateImpl(raster, maxZError);

        // --- encode
        // buffer to write to, function will fail if buffer too small
        std::vector<LercNS::Byte> lercBlob(numBytesNeeded, 0);
        auto pLercBlob = lercBlob.data();

        uint32_t numBytesUsed = 0;  // num bytes written to buffer
        auto status = LercNS::Lerc::EncodeTempl<DataT>(raster.data, LERC_VERSION, raster.nDim, raster.nCols,
                                                       raster.nRows, raster.nBands, bitMask, maxZError, pLercBlob,
                                                       numBytesNeeded, numBytesUsed);
        if (status != LercNS::ErrCode::Ok) {
            throw std::runtime_error("Failed to encode data");
        }

        // --- decode
        status = LercNS::Lerc::DecodeTempl<DataT>(raster.data, pLercBlob, numBytesUsed, raster.nDim, raster.nCols,
                                                  raster.nRows, raster.nBands, bitMask);
        if (status != LercNS::ErrCode::Ok) {
            throw std::runtime_error("Failed to decode data");
        }
    }
};

template <typename DataT> void wrapLercImpl(py::module &m) {
    using LBS = LercBufferSize<DataT>;
    m.def("buffer_size", &LBS::calculate, py::arg("raster"), py::arg("max_z_error"));

    using LC = LercCompressor<DataT>;
    m.def("apply_in_place", &LC::applyInPlace, py::arg("raster"), py::arg("max_z_error"));
    m.def("apply", &LC::apply, py::arg("raster"), py::arg("max_z_error"), py::return_value_policy::move);
}
}  // namespace

namespace cppaiutils {
namespace python {

void wrapLerc(py::module &m) {
    auto mLerc = m.def_submodule("lerc");
    wrapLercImpl<uint8_t>(mLerc);
    wrapLercImpl<uint16_t>(mLerc);
    wrapLercImpl<float>(mLerc);
    wrapLercImpl<double>(mLerc);
}
}  // namespace python
}  // namespace cppaiutils

This is a general question: Is it intentional that JS decompression output is always band-interleaved, even though C++/GDAL compression input is pixel-interleaved?

Currently I had to transform from band-interleaved to pixel-interleaved if expected by geotiff.js:

https://github.com/geotiffjs/geotiff.js/blob/5816200dfb610ef11b1de9e09b214175739e9e90/src/compression/lerc.js#L40

Currently GDAL installed from Homebrew doesn't support LERC.

Is it possible to publish LERC to Homebrew, and link it with libtiff there?

See Homebrew/homebrew-core#106450 for how ZSTD support was enabled.

initial impl: branch js_lercv24

Currently when trying to pip install lerc, the published package isn't packaged correctly:

$ pip install lerc
Collecting lerc
  Using cached lerc-4.0.0.tar.gz (721 kB)
ERROR: lerc from https://files.pythonhosted.org/packages/1d/49/84f7e28247c82809417a9a2e898693da8f57b36d6a9358b146bdc0b182f0/lerc-4.0.0.tar.gz does not appear to be a Python project: neither 'setup.py' nor 'pyproject.toml' found.

Checking the package, it looks like there's an one directory too many (dist/ shouldn't be the top level):

$ wget https://files.pythonhosted.org/packages/1d/49/84f7e28247c82809417a9a2e898693da8f57b36d6a9358b146bdc0b182f0/lerc-4.0.0.tar.gz && tar tvf lerc-4.0.0.tar.gz
--2023-03-15 09:45:11--  https://files.pythonhosted.org/packages/1d/49/84f7e28247c82809417a9a2e898693da8f57b36d6a9358b146bdc0b182f0/lerc-4.0.0.tar.gz && tar tvf lerc-4.0.0.tar.gz
drwxrwxrwx  0 0      0           0 Mar 14 19:31 dist/
drwxrwxrwx  0 0      0           0 Mar 14 19:31 dist/lerc-4.0.0/
drwxrwxrwx  0 0      0           0 Mar 14 19:31 dist/lerc-4.0.0/lerc/
-rwxrwxrwx  0 0      0      526336 Jun 14  2022 dist/lerc-4.0.0/lerc/Lerc.dll
-rwxrwxrwx  0 0      0        4158 Jun 14  2022 dist/lerc-4.0.0/lerc/Lerc.lib
-rwxrwxrwx  0 0      0      951344 Jun 22  2022 dist/lerc-4.0.0/lerc/libLerc.dylib
-rwxrwxrwx  0 0      0      816528 Jun 22  2022 dist/lerc-4.0.0/lerc/libLerc.so.4
-rwxrwxrwx  0 0      0       41442 Aug 18  2022 dist/lerc-4.0.0/lerc/_lerc.py
-rwxrwxrwx  0 0      0          20 Feb 24  2020 dist/lerc-4.0.0/lerc/__init__.py
drwxrwxrwx  0 0      0           0 Mar 14 19:31 dist/lerc-4.0.0/lerc.egg-info/
-rwxrwxrwx  0 0      0           1 Mar  5  2020 dist/lerc-4.0.0/lerc.egg-info/dependency_links.txt
-rwxrwxrwx  0 0      0         410 Mar 14 18:59 dist/lerc-4.0.0/lerc.egg-info/PKG-INFO
-rwxrwxrwx  0 0      0         216 Mar 14 19:14 dist/lerc-4.0.0/lerc.egg-info/SOURCES.txt
-rwxrwxrwx  0 0      0           5 Mar  5  2020 dist/lerc-4.0.0/lerc.egg-info/top_level.txt
-rwxrwxrwx  0 0      0         410 Mar 14 18:58 dist/lerc-4.0.0/PKG-INFO
-rwxrwxrwx  0 0      0        4008 Jun 24  2022 dist/lerc-4.0.0/README.md
-rwxrwxrwx  0 0      0          38 Mar  5  2020 dist/lerc-4.0.0/setup.cfg
-rwxrwxrwx  0 0      0        1703 Mar 14 19:04 dist/lerc-4.0.0/setup.py

Looking at https://pypi.org/project/lerc/#history it looks like this was pushed out at 2023-03-15T10:36:12+0000

Compared with the existing JS, WASM should have significantly higher performance for something as compute intensive as a data/image compression.

currently a very old version is published (2.0.0)

https://github.com/Esri/lerc/tree/master/OtherLanguages/js

need to publish into npm next version with latest changes

@tmaurer3

Need to sync with upcoming Esri releases Pro 2.4 and ArcMap 10.7.1.
Minor release version update, no API changes.
Codec update from Lerc2v4 to Lerc2v5.

Hello,

One of my project is using lerc as a sub-sub dependency and I am currently unable to link it on Windows (using msys2 and MINGW) because apparently lerc doesn't provide an out-of-the-box solution to build a static library for Windows.

I've opened an issue on msys2's MinGW package repository where people are already talking about potential solutions: most of them consist of providing a way to define LERCDLL_API to nothing.

Thank you for your time and your help,
Arignir

I think this PR by @tmaurer3 introduced a small API issue: #147

By introducing the EncodeInternal template function, the compiler now fails to include exported versions of either Lerc::EncodeTempl or Lerc:: ComputeCompressedSizeTempl.

$ nm libLerc.so  | c++filt | grep "Lerc::Encode"
0000000000016260 W LercNS::ErrCode LercNS::Lerc::EncodeInternal<signed char>(signed char const*, int, int, int, int, int, int, unsigned char const*, double, unsigned int&, unsigned char*, unsigned int, unsigned int&)
00000000000190b0 W LercNS::ErrCode LercNS::Lerc::EncodeInternal<double>(double const*, int, int, int, int, int, int, unsigned char const*, double, unsigned int&, unsigned char*, unsigned int, unsigned int&)
00000000000185a0 W LercNS::ErrCode LercNS::Lerc::EncodeInternal<float>(float const*, int, int, int, int, int, int, unsigned char const*, double, unsigned int&, unsigned char*, unsigned int, unsigned int&)
0000000000016700 W LercNS::ErrCode LercNS::Lerc::EncodeInternal<unsigned char>(unsigned char const*, int, int, int, int, int, int, unsigned char const*, double, unsigned int&, unsigned char*, unsigned int, unsigned int&)
0000000000017a80 W LercNS::ErrCode LercNS::Lerc::EncodeInternal<int>(int const*, int, int, int, int, int, int, unsigned char const*, double, unsigned int&, unsigned char*, unsigned int, unsigned int&)
0000000000017f20 W LercNS::ErrCode LercNS::Lerc::EncodeInternal<unsigned int>(unsigned int const*, int, int, int, int, int, int, unsigned char const*, double, unsigned int&, unsigned char*, unsigned int, unsigned int&)
0000000000016d90 W LercNS::ErrCode LercNS::Lerc::EncodeInternal<short>(short const*, int, int, int, int, int, int, unsigned char const*, double, unsigned int&, unsigned char*, unsigned int, unsigned int&)
0000000000017400 W LercNS::ErrCode LercNS::Lerc::EncodeInternal<unsigned short>(unsigned short const*, int, int, int, int, int, int, unsigned char const*, double, unsigned int&, unsigned char*, unsigned int, unsigned int&)
000000000001a0f0 T LercNS::Lerc::Encode(void const*, int, LercNS::Lerc::DataType, int, int, int, int, int, unsigned char const*, double, unsigned char*, unsigned int, unsigned int&)

$ nm libLerc.so  | c++filt | grep "Lerc::.*Templ"
00000000000112a0 W LercNS::ErrCode LercNS::Lerc::DecodeTempl<signed char>(signed char*, unsigned char const*, unsigned int, int, int, int, int, int, unsigned char*)
0000000000015310 W LercNS::ErrCode LercNS::Lerc::DecodeTempl<double>(double*, unsigned char const*, unsigned int, int, int, int, int, int, unsigned char*)
0000000000014b00 W LercNS::ErrCode LercNS::Lerc::DecodeTempl<float>(float*, unsigned char const*, unsigned int, int, int, int, int, int, unsigned char*)
0000000000011c40 W LercNS::ErrCode LercNS::Lerc::DecodeTempl<unsigned char>(unsigned char*, unsigned char const*, unsigned int, int, int, int, int, int, unsigned char*)
0000000000013940 W LercNS::ErrCode LercNS::Lerc::DecodeTempl<int>(int*, unsigned char const*, unsigned int, int, int, int, int, int, unsigned char*)
00000000000142f0 W LercNS::ErrCode LercNS::Lerc::DecodeTempl<unsigned int>(unsigned int*, unsigned char const*, unsigned int, int, int, int, int, int, unsigned char*)
00000000000125e0 W LercNS::ErrCode LercNS::Lerc::DecodeTempl<short>(short*, unsigned char const*, unsigned int, int, int, int, int, int, unsigned char*)
0000000000012f90 W LercNS::ErrCode LercNS::Lerc::DecodeTempl<unsigned short>(unsigned short*, unsigned char const*, unsigned int, int, int, int, int, int, unsigned char*)

This means that a user of the library cannot include these template functions in their own code as it leads to:

undefined symbol: _ZN6LercNS4Lerc11EncodeTemplIdEENS_7ErrCodeEPKT_iiiiiiPKhdPhjRj

and

$ c++filt _ZN6LercNS4Lerc11EncodeTemplIdEENS_7ErrCodeEPKT_iiiiiiPKhdPhjRj
LercNS::ErrCode LercNS::Lerc::EncodeTempl<double>(double const*, int, int, int, int, int, int, unsigned char const*, double, unsigned char*, unsigned int, unsigned int&)

Is there going to be an implementation of a pure-python solution for Lerc v2?