Opened 20 months ago

Closed 20 months ago

Last modified 20 months ago

#6885 closed defect (invalid)

Writing HF2 files does not work as expected.

Reported by: homme Owned by: warmerdam
Priority: normal Milestone:
Component: GDAL_Raster Version: 2.1.3
Severity: normal Keywords: HF2
Cc:

Description

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):

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

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:

Expected output when viewed in QGIS.

However, it looks as follows:

Actual output when viewed in QGIS.

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

    old new  
    11Driver: HF2/HF2/HFZ heightfield raster
    22Files: output.hf2
    3 Size is 908, 551
     3Size is 907, 550
    44Coordinate System is:
    55PROJCS["WGS 84 / Pseudo-Mercator",
    66    GEOGCS["WGS 84",
     
    2525    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"],
    2626    AUTHORITY["EPSG","3857"]]
    2727Origin = (776826.722000000067055,5765238.115000000223517)
    28 Pixel Size = (1.651542951541877,-1.652012704173526)
     28Pixel Size = (1.653363836824723,-1.655016363635659)
    2929Metadata:
    3030  VERTICAL_PRECISION=0.010000
    3131Corner Coordinates:
     
    3535Lower Right (  778326.323, 5764327.856) (  6d59'30.57"E, 45d53'59.76"N)
    3636Center      (  777576.523, 5764782.986) (  6d59' 6.32"E, 45d54'10.00"N)
    3737Band 1 Block=256x1 Type=Float32, ColorInterp=Undefined
    38   Minimum=0.000, Maximum=3323.809, Mean=2352.065, StdDev=1137.781
     38  Minimum=0.000, Maximum=3323.809, Mean=2350.277, StdDev=1138.947
    3939  Unit Type: m
    4040  Metadata:
    4141    STATISTICS_MAXIMUM=3323.8090820312
    42     STATISTICS_MEAN=2352.0650599358
     42    STATISTICS_MEAN=2350.276635773
    4343    STATISTICS_MINIMUM=1.1754943508223e-38
    44     STATISTICS_STDDEV=1137.7808914636
     44    STATISTICS_STDDEV=1138.9468957056

Attachments (5)

input-ok.tif (533.1 KB) - added by homme 20 months ago.
Input file that sometimes works.
input-bad.tif (541.0 KB) - added by homme 20 months ago.
Input file that never works.
input-ok.png (35.6 KB) - added by homme 20 months ago.
What input-ok.tif looks like when viewed in QGIS.
output-ok.png (35.9 KB) - added by homme 20 months ago.
Expected output when viewed in QGIS.
output-bad.png (4.1 KB) - added by homme 20 months ago.
Actual output when viewed in QGIS.

Download all attachments as: .zip

Change History (8)

Changed 20 months ago by homme

Attachment: input-ok.tif added

Input file that sometimes works.

Changed 20 months ago by homme

Attachment: input-bad.tif added

Input file that never works.

Changed 20 months ago by homme

Attachment: input-ok.png added

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

Changed 20 months ago by homme

Attachment: output-ok.png added

Expected output when viewed in QGIS.

Changed 20 months ago by homme

Attachment: output-bad.png added

Actual output when viewed in QGIS.

comment:1 Changed 20 months ago by 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.

Last edited 20 months ago by Jukka Rahkonen (previous) (diff)

comment:2 Changed 20 months ago by homme

Resolution: invalid
Status: newclosed

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.

comment:3 Changed 20 months ago by Even Rouault

In 38231:

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

Note: See TracTickets for help on using tickets.