Writing HF2 files does not work as expected.

[homme]

I would expect gdal_translate to be able to convert GeoTiffs to HF2 format consistently. This is not the case however, as shown by the following commands and outputs based on the file input-ok.tif (data files attached).

input-ok.tif looks like this when opened in QGIS (v2.18.7):

After running the following command...

gdal_translate -of HF2 input-ok.tif output-bad.hf2

I would expect output-bad.hf2 to look like this when viewed in QGIS:

However, it looks as follows:

Interestingly, the following produces the expected output:

gdal_translate -of HF2 input-ok.tif output-ok.hf2 && \
gdalinfo -stats output-ok.hf2

The difference being that gdalinfo creates the sidecar XML file.

Unfortunately, reducing input-ok.tif by 1 pixel in size (to create input-bad.tif) means that even running gdalinfo -stats on the output HF2 file produces the unexpected output (output-bad.png). This is the difference between running gdalinfo on the good (old) and bad (new) output files:

.info

@@ -1 +1 @@
 Driver: HF2/HF2/HFZ heightfield raster
 Files: output.hf2
-Size is 908, 551
+Size is 907, 550
 Coordinate System is:
 PROJCS["WGS 84 / Pseudo-Mercator",
     GEOGCS["WGS 84",
@@ -25 +25 @@
     EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs"],
     AUTHORITY["EPSG","3857"]]
 Origin = (776826.722000000067055,5765238.115000000223517)
-Pixel Size = (1.651542951541877,-1.652012704173526)
+Pixel Size = (1.653363836824723,-1.655016363635659)
 Metadata:
   VERTICAL_PRECISION=0.010000
 Corner Coordinates:
@@ -35 +35 @@
 Lower Right (  778326.323, 5764327.856) (  6d59'30.57"E, 45d53'59.76"N)
 Center      (  777576.523, 5764782.986) (  6d59' 6.32"E, 45d54'10.00"N)
 Band 1 Block=256x1 Type=Float32, ColorInterp=Undefined
-  Minimum=0.000, Maximum=3323.809, Mean=2352.065, StdDev=1137.781
+  Minimum=0.000, Maximum=3323.809, Mean=2350.277, StdDev=1138.947
   Unit Type: m
   Metadata:
     STATISTICS_MAXIMUM=3323.8090820312
-    STATISTICS_MEAN=2352.0650599358
+    STATISTICS_MEAN=2350.276635773
     STATISTICS_MINIMUM=1.1754943508223e-38
-    STATISTICS_STDDEV=1137.7808914636
+    STATISTICS_STDDEV=1138.9468957056

[homme]

Input file that sometimes works.

[homme]

Input file that never works.

[homme]

What input-ok.tif looks like when viewed in QGIS.

[homme]

Expected output when viewed in QGIS.

[homme]

Actual output when viewed in QGIS.

[Jukka Rahkonen]

There is something in the histogram but you can't use a viewer like QGIS for evaluating 32bit imagery. Data must be scaled for viewing and when you say that input-bad never works it is just that QGIS does not automatically view it right. I converted your file as

gdal_translate -of HF2 input-bad.tif output-bad.hf2

QGIS shows output-bad.hf2 pretty well when I set the min-max values in range 2600-3200 from the image layer properties. What fools QGIS is probably the large number of cells in the first bucket coming from the large no-data area.

The HF2 driver manual does not speak anything about nodata ​http://www.gdal.org/frmt_hf2.html. It may be that the format does not support nodata at all. If this is the case this ticket is invalid.

[homme]

Hi Jukka, thanks for looking into this - setting the appropriate range values for QGIS works for me too. I dug into the ​HF2 documentation further and it does indeed appear that the format has no support for NODATA.

[Even Rouault]

In 38231:

HF2 creation: copy source information (including nodata) into PAM if needed (refs #6885)