Export limit errors to large plant health maps

General Help
1

Hello Community,
I have been using WebODM for some time now, and now do over 90% of my work with it. In that time, I have yet to find an issue that I haven’t been able to solve internally, via Piero’s guide or from the community until this week…

I am currently developing some mapping for a client of a property ~300 hectares (~740 acres) and I’m having issues with exporting rendered VARI mapping due to the size.

The map is quite large at 7588 images at a GSD of 5.83cm and the dataset is ~58GB.

I have calibrated the map settings to view as follows:
VARI | RGB | Rplumbo | UTM (EPSG:32754)
With a Min/ Max of -0.465/0.800
All good to this point, something that I do regularly, just not with maps this big…

Ordinarily, I would break this down into a few maps and merge them together in QGIS as a part of my workflow, but on this occasion it works better to use the viewer in WebODM for the tasks at hand.

I have been able to achieve a really good quality ortho and find the plant health viewer easier to create quick maps on this platform.

My issue:
When trying to export from the plant health viewer I am getting the following errors:
Export errors:
GeoTiff RGB: Unable to allocate 15.6 GiB for an array with shape (1, 58086, 72265) and data type float32

KLM Error: libjpeg: Maximum supported image dimension is 65535 pixels

PNG: Unable to allocate 15.6 GiB for an array with shape (1, 58086, 72265) and data type float32

JPEG RGB: libjpeg: Maximum supported image dimension is 65535 pixels

I’ve had a cruise around the topics and can’t find anything relevant to this particular issue, it all seems to be at the processing stage rather than the exporting stage. I could perhaps try a few of those suggestions, but at ~91 hours of processing time it would take a couple of weeks!
__

System:
Processor: Intel(R) Pentium(R) Gold G6405 CPU @ 4.10GHz 4.10 GHz
RAM: 128 GB (128 GB usable)
System type: 64-bit operating system, x64-based processor
Windows Pro 11
Devoted Storage: 2TB HDD (991GB available)
Graphics: NVIDIA GeForce RTX 3060 12GB

Any assistance here would be appreciated.

dp

1 Like
2

Looks like the max permissible image size for export is 65535 pixels, and you are a bit over that.

One solution might be to initially resize your images to 0.9X their original size.

2 Likes
3

Interesting, it looks like a limitation of the JPEG driver. I wonder if changing the driver to PNG WebODM/raster_utils.py at master · OpenDroneMap/WebODM · GitHub would allow the export. We could conditionally check for the dimension size and switch from JPG to PNG when necessary…

1 Like
4

Thanks Piero, I’m not too bad on the interface end of things but I am pretty rubbish with the back end code (so bad that I bought the driver after several failed attempts at doing it myself! - and to support the development…), so excuse my naïve question here, but where/how would I run this script to test it? It doesn’t look like it is constructed to run on terminal??

1 Like
5

If you are on Windows, you could try to find the raster_utils.py file from the C:\WebODM folder (in one of the subfolders), open the file with a text editor and replace these lines:

        elif export_format == "gtiff-rgb":
            compress = "JPEG"
            profile.update(jpeg_quality=90)
            band_count = 4
            rgb = True

With:

        elif export_format == "gtiff-rgb":
            compress = "DEFLATE"
            band_count = 4
            rgb = True

Then restart WebODM and try to export.

Make sure the indentation (the number of spaces) is exact when replacing the lines.

2 Likes
6

Thanks, I’ll give it a go. I have a few things running so will wait for them to process and have a crack.

1 Like
7

Thanks Gordon,
yes, that was my first observation too. I’m not so interested in compromising the resolution much more than I have already (I have already resized as part of initial processing) as my GSD is already at an average of 5.83cm. Would be good to keep it at this res for the application required.

2 Likes
8

Are you able to increase the crop at all, default crop is 3m I think, or does the area of interest extend to the existing edge of the image?

1 Like
9

Hi Piero. I gave this a try and it was unsuccessful. I got the same error:
“”*Unable to allocate 15.6 GiB for an array with shape (1, 58086, 72265) and data type float32"

For the time being, I’ll try to downscale and see what the quality is like.

1 Like
10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

11
12

Coming back to this to resolve the solution I implemented.
Having replaced the code as Piero suggested, I restarted the machine and WebODM but had no luck in exporting the files I required.

I reinstated the code and re-ran the processing at a resize of 0.8X as suggested by Gordon, this reduced my GSD from 5.83cm to 6.43cm, an increase of 0.5cm in GSD. I also left the auto boundary in order to retain the buffer I factored into the flight planning.

This option was sufficient for the resolution I required for simple exports of files for reporting on plant index subjects and for use in small maps where the resolution is not required to be as high.

I was still able to export the original project and then utilise QGIS for any high res detail work required.

Note that this workflow will require two processing tasks:

  1. High resolution outputs as required for detailed mapping and analysis - exported via the Download Assets options
  2. Resized task (in this case 0.8X to 1843px) for viewing and analysis in the WebODM viewer and exporting to PNG, RAW etc. to produce small maps and include in documents where/if required.

Thanks to Piero and Gordon for assisting in the solution.

dp

4 Likes