Page MenuHomePhabricator

Generate appropiate previews for grayscale (Geo)TIFFs
Open, Needs TriagePublicBUG REPORT

Assigned To
None
Authored By
PantheraLeo1359531
Sat, Feb 7, 8:53 PM
Referenced Files
F71735231: grafik.png
Sat, Feb 7, 8:53 PM
F71735267: grafik.png
Sat, Feb 7, 8:53 PM
F71735224: grafik.png
Sat, Feb 7, 8:53 PM
F71735269: grafik.png
Sat, Feb 7, 8:53 PM

Description

Steps to replicate the issue (include links if applicable):
When uploading TIFFs (like GeoTIFFs) that have grayscale

What happens?:
Commons generates flat white previews, although the pixels have information. This error may lead to deletion requests by unexperienced users.
(see: https://commons.wikimedia.org/wiki/File:DGM1_-_Bayerische_Vermessungsverwaltung_502_5523.tif

grafik.png (823×1 px, 118 KB)
vs.
grafik.png (572×1 px, 130 KB)

or https://commons.wikimedia.org/wiki/File:Vermont_Open_Geospatial_Elevation-2004_320cm_ASPECT.tif
grafik.png (850×922 px, 136 KB)
vs
grafik.png (680×1 px, 516 KB)
)

What should have happened instead?:
It should generate previews similar to the appended screenshots shown in QGIS

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):
Firefox/QGIS

Event Timeline

The scale is usually like from a depth map. Black or white stands for higher or lower elevation. It is done in grayscale.

Is the issue that depth is like a 32 bit number so of the range isn't normalized everything appears white?

Is the issue that depth is like a 32 bit number so of the range isn't normalized everything appears white?

Yes, this is the reason. File systems also do not generate correct thumbnails for such files. Even after loading into a GIS you often have to set the scale manually to see anything. A huge problem are NA values whose definition is not part of the TIFF but written in some metadata text file.

It feels a bit weird to apply some normalization blindy. Like if the tiff file had metadata indicating it was a GeoTiff file and not a normal black and white image that would be one thing, but it seems like correcting this has the potential to do the wrong thing for normal images.

This tiff does have some interesting aspects that make them identifiable (according to exiftool)

First of all, exiftool sees this as a specific type of tiff called big tiff. Apparently this is a 64bit tiff format, with version number 43 instead of 42. TIL

File Type : BTF
File Type Extension : btf
MIME Type : image/x-tiff-big

But there's also some GDAL specific annotations that this uses.

Geo Tiff Directory : (Binary data 252 bytes, use -b option to extract)
Geo Tiff Double Params : (Binary data 61 bytes, use -b option to extract)
Geo Tiff Ascii Params : (Binary data 22 bytes, use -b option to extract)
GDAL Metadata : <GDALMetadata>. <Item name="STATISTICS_MAXIMUM" sample="0">360</Item>. <Item name="STATISTICS_MEAN" sample="0">180.46708646829</Item>. <Item name="STATISTICS_MINIMUM" sample="0">-1</Item>. <Item name="STATISTICS_STDDEV" sample="0">108.74945819918</Item>. <Item name="STATISTICS_VALID_PERCENT" sample="0">47.46</Item>. <Item name="MAX_Z_ERROR" domain="IMAGE_STRUCTURE">.01</Item>.</GDALMetadata>.
Subfile Type : Reduced-resolution image
GDAL No Data : -3.4028234663852886e+38

If I understand the various online docs correctly, the GDAL Metadata has the min and max you need to do the normalization, but I'm not entirely sure what commands you would have to run to do so and I couldn't easily find this on the web. So more information is needed, and even then. it's a pretty limited use case, to expensive time.