LERC MRF outputs no statistics / empty histogram after latest OptimizeRasters update

[coscratcliff-blip]

Hello,

I'm running into an issue after updating OptimizeRasters and wanted to check whether this is a known problem or if there is a configuration change I may be missing.

We originally implemented our Image Server workflow with Steve Lambert in 2022, primarily supporting a UAS orthomosaic service. Our process automates optimization from GeoTIFF inputs to MRF outputs using LERC compression.

After updating to the latest version of OptimizeRasters, MRF outputs generated with LERC compression no longer appear to calculate valid statistics. In ArcGIS Pro, the resulting rasters show empty histograms and do not display.

For comparison, if I switch the configuration to generate MRFs using JPEG compression (same inputs and workflow), the outputs display correctly and include valid statistics.

Environment:

ArcGIS Pro 3.3
Input: GeoTIFF (SiteScan UAS orthomosaics)
Output: MRF with LERC compression
OptimizeRasters: latest GitHub version (post-update regression)

Has anyone else seen this behavior with LERC outputs, or is there a known change in how LERC MRFs should be generated or interpreted in the latest version?

Thanks in advance.

[lucianpls]

@coscratcliff-blip
It should be part of OptimizeRasters, but as a quick fix you can run "gdalinfo -stats" or even "gdalinfo -hist" on the MRFs after they get created, it will compute and store statistics for further use.

[coscratcliff-blip]

Hi Lucian,

Thank you for the quick response. In this case the issue doesn’t appear to be missing statistics, but rather that LERC-compressed MRFs are producing an invalid output. Even after forced computation via GDAL the raster isn't displaying. I've attached some files for reference.

optimzeraster_MRF_LERC_log.txt
gdal_stats_hist.txt

Clicking and dragging an MRF with Jpeg compression in, it displays immediately.

[lucianpls]

@coscratcliff-blip

Oh, in that case it's likely to be caused by Lerc2 version incompatibility.
MRF/gdal can be built with various Lerc2 library releases. By default, the Lerc2 library writes in the "latest known" format, which isn't readable by previous versions. So if the OR is using a newer version and you're trying to read them with an older version of Pro, it would be unable to read the pixels.

As quick fixes/checks:

• Use INTERLEAVE=BAND. In that mode MRF forces a specific (old) Lerc2 version to be written, which should be readable.
• Use Lerc V1 (OPTIONS=V1:1). That version is deprecated in the Lerc2 library so it doesn't change, it should also be compatible to everything. V1 is slightly slower and has a few limitations over Lerc2, but it still covers most use cases.

[coscratcliff-blip]

Putting "-co INTERLEAVE=BAND" in the GDARL_Translate_UserParmaters when manually running the script tool produced an MRF that is visible. Thank you! I wasn't exactly sure how to write the syntax for Lerc V1 (OPTIONS=V1:1) and couldn't find the documentation for it. Is using one preferable over the other?

[lucianpls]

Lerc2 band separate is likely better than V1. To use Lerc1 use "-co OPTIONS=V1:1" in the same field as the one you're using.

Here's the explicit interleave filed, from the Grid_to_MRF_Lerc.xml template:

<!--how the data is stored as Pixel interleave or band interleave. For cloneMRF the value should be the same as input (Def: Pixel)-->
<Interleave></Interleave>

[coscratcliff-blip]

Thank you very much for all of your help!

[lucianpls]

CC @tmaurer3

[tmaurer3]

See OSGeo/gdal#14676 .

[lucianpls]

@Chamlika
Can you look into this? It might be related to the issue found in gdal, sounds like the MRF compiled in OR needs the same fix? Or possibly it's more complicated, since it's the reader (gdal in ArcGIS) that would need patching?
Possibly a simpler fix would be to use an older version of Lerc the library in OR.

[lucianpls]

Hm... It's not likely that changing the Lerc library to an older one in OR would fix this issue.

[tmaurer3]

When was OptimizeRasters updated? There was a Lerc install in raster core on May 19 that introduced a small bug that could cause the Lerc encode to fail. (But only for very special cases, such as a tile has exactly 1 valid pixel.) The fix for this went in today. This would have affected CRF write, not MRF write (I believe). If you think this might have been the cause, update your OptimizeRasters again tomorrow or later (if it depends on raster core).

[abhiataero]

@coscratcliff-blip can you share the sample data with me i can repo the issue on my side and make a required fix for this.

@tmaurer3 Optimizer raster was updated with Pro 3.6 release

[coscratcliff-blip]

@abhiataero I got permission to share one of our Sitescan .tifs. Do you have a fileshare you prefer I upload to. If not I can upload it to azure and share it.

[abhiataero]

@coscratcliff-blip please upload to azure share and send me the link

[coscratcliff-blip]

@abhiataero I'm sorry this took so long, been a busy couple weeks.
Link to download sample UAS Tiff