orthophoto-png option does not work with multispectral

[rrowlands]

When processing a multi-spectral dataset and including the --orthophoto-png odm option the following error is output from gdal:

[INFO]    running gdal_translate -of png "/datasets/rededge-p-palmtree/odm_orthophoto/odm_orthophoto.tif" "/datasets/rededge-p-palmtree/odm_orthophoto/odm_orthophoto.png"  -b 3 -b 2 -b 1 -a_nodata 0 --config GDAL_CACHEMAX 23.6%

Warning 6: PNG driver doesn't support data type Float32. Only eight bit (Byte) and sixteen bit (UInt16) bands supported. Defaulting to Byte

Which is to suggest that perhaps ODM needs to perform rescaling on the tif before piping it through GDAL, as per: https://gis.stackexchange.com/questions/244073/unable-to-convert-3-band-spacenet-dataset-geotiff-image-to-either-jpg-or-png-wit

I have seen this occur on about 4 different multispectral datasets, including rededge-p data. The orthophoto.tif file renders perfectly fine in QGIS so I know it's not an issue with the orthophoto.

[rrowlands]

I have capacity to work on this ticket and will hopefully get a PR submitted in the next few days.

[rrowlands]

I have a first-rev for a solution on this committed here:

https://github.com/terraframe/ODM/commit/286f309629c2399f102a60ec9f218566d34c2d42

however I am not sure how to get the correct scaling statistics from GDAL. If I use the caclulated stats from GDAL (left image) the colors are quite off, however if I take the exact same command and take the calculated stats from QGIS (right image), the image renders perfectly.

From what I can tell it doesn't seem to be an issue with band ordering (since I have tried it both ways) or with "nodata values" interfering with stat calculations (since GDAL says novalues do not intefere with stat calculations). I am also a little confused as to why the min values are often negative. I don't think it's an issue with GDAL using 'approximated' stats either since I have also tried passing in "False" to "ComputeRasterMinMax", as well as using the '-mm' flag with 'gdalinfo'.

Here is the command used to generate the image on the left: gdal_translate -of png -scale_1 -0.07342134416103363 0.2565867304801941 -scale_2 -0.17259874939918518 0.5052850246429443 -scale_3 -0.08037516474723816 0.2551434636116028 "odm_orthophoto.tif" "odm_orthophoto.png" -b 3 -b 2 -b 1 -a_nodata 0 --config GDAL_CACHEMAX 13.950000000000003%

And the image on the right: gdal_translate -of png -scale_1 -0.014940895140171 0.22726792097092 -scale_2 -0.02099672332406 0.21704776585102 -scale_3 -0.0093740895390511 0.18056628108025 -b 3 -b 2 -b 1 -a_nodata 0 ./odm_orthophoto.tif ./odm_orthophoto_qgisstats.png

@pierotofy / @smathermather Do you guys have any ideas as to what I did wrong here?

[pierotofy]

I'm not sure this approach will work, you will end up rescaling (stretching) the RGB channels for all outputs, even non-multispectral outputs.

Personally, I think that there's limitations to gdal_translate and writing a proper function using rasterio might be the way to go to handle all cases. Similar to how WebODM handles exports: https://github.com/OpenDroneMap/WebODM/blob/master/app/raster_utils.py

[rrowlands]

@pierotofy Would this be something that you or your team would have any availability to work on?

[pierotofy]

Probably not in the near term.