lerc_encode() may return a smaller size than lerc_computeCompressedSize(...) about lerc HOT 8 CLOSED

Or maybe the decoder could be changed to avoid addressing bytes outside of the written size?

from lerc.

@lucianpls Can you provide a repro case? Those sizes should be the same, otherwise it's a bug.

from lerc.

sample.zip

See attached sample. It fails to decode because the size is short one byte. I am not sure how it was created, it's one of the Esri regression samples, see https://devtopia.esri.com/ArcGISPro/RasterXI/issues/10904
I assumed it was due to the refactoring of LERC in MRF, which uses the lerc_encode() size return, as described above. The old code was using the internal API has been in use for many years previously without ever seeing this issue.

from lerc.

Well, sounds like the data in question was generated in 2016, not sure why it is failing to decode now, after the switch to the public API.
The old code (with the internal API) is here, if you want to take a look.
https://github.com/OSGeo/gdal/blame/d9b489670e6373d4931e91515897a6021a46fa4b/frmts/mrf/LERC_band.cpp

from lerc.

The test in libtiff is also suggesting that this issue does exist, see assert in line 876:

https://github.com/OSGeo/gdal/blob/master/frmts/gtiff/libtiff/tif_lerc.c

from lerc.

@lucianpls See if this branch works for you
https://github.com/Esri/lerc/tree/tmaurer3/fix_v22_decode_short_blob

from lerc.

@tmaurer3
Yes, it seems to, compiles and passes the reading test.
Can you check that I applied the patch correctly to libLERC source in GDAL, which is older? I had to merge it by hand.
lucianpls/gdal@cfdc58c

Thanks,
Lucian

from lerc.

@lucianpls Yes, looks good. Only you have this check 2x now, if (numBytes != numBytesLL). I would remove the 1st one.

from lerc.