GeoTIFF files from WMS server have errors

1

Hello,

I am using the WMS service (currently testing it) and I keep getting errors from the application that reads the files. For any downloaded content of type image/tiff, gdal gives me the following information:

Warning 1: img-pierrenet-2b9.tif: TIFFReadDirectory:Sum of Photometric type-related color channels and ExtraSamples doesn’t match SamplesPerPixel. Defining non-color channels as ExtraSamples.
Driver: GTiff/GeoTIFF
Files: img-pierrenet-2b9.tif
Size is 199, 200
Coordinate System is:
GEOGCRS[“WGS 84”,
DATUM[“World Geodetic System 1984”,
ELLIPSOID[“WGS 84”,6378137,298.257223563,
LENGTHUNIT[“metre”,1]]],
PRIMEM[“Greenwich”,0,
ANGLEUNIT[“degree”,0.0174532925199433]],
CS[ellipsoidal,2],
AXIS[“geodetic latitude (Lat)”,north,
ORDER[1],
ANGLEUNIT[“degree”,0.0174532925199433]],
AXIS[“geodetic longitude (Lon)”,east,
ORDER[2],
ANGLEUNIT[“degree”,0.0174532925199433]],
ID[“EPSG”,4326]]
Data axis to CRS axis mapping: 2,1
Origin = (31.163993000000001,51.090416070349242)
Pixel Size = (0.000143449691988,-0.000089870351746)
Metadata:
AREA_OR_POINT=Area
TIFFTAG_RESOLUTIONUNIT=1 (unitless)
TIFFTAG_XRESOLUTION=1
TIFFTAG_YRESOLUTION=1
Image Structure Metadata:
COMPRESSION=DEFLATE
INTERLEAVE=PIXEL
Warning 1: TIFFReadDirectory:Sum of Photometric type-related color channels and ExtraSamples doesn’t match SamplesPerPixel. Defining non-color channels as ExtraSamples.
Corner Coordinates:
Upper Left ( 31.1639930, 51.0904161) ( 31d 9’50.37"E, 51d 5’25.50"N)
Lower Left ( 31.1639930, 51.0724420) ( 31d 9’50.37"E, 51d 4’20.79"N)
Upper Right ( 31.1925395, 51.0904161) ( 31d11’33.14"E, 51d 5’25.50"N)
Lower Right ( 31.1925395, 51.0724420) ( 31d11’33.14"E, 51d 4’20.79"N)
Center ( 31.1782662, 51.0814290) ( 31d10’41.76"E, 51d 4’53.14"N)
Band 1 Block=199x10 Type=Byte, ColorInterp=Gray
Band 2 Block=199x10 Type=Byte, ColorInterp=Undefined
Band 3 Block=199x10 Type=Byte, ColorInterp=Undefined
Band 4 Block=199x10 Type=Byte, ColorInterp=Undefined

Please notice: Warning 1: img-pierrenet-2b9.tif: TIFFReadDirectory:Sum of Photometric type-related color channels and ExtraSamples doesn’t match SamplesPerPixel. Defining non-color channels as ExtraSamples.

Currently trying to use geotools to read the files, and that format error is preventing me to use your geolocated tiff format.

Any hints/guideance on how to avoid the problem?

Thanks,

Juan

2

The way I understand the issue has to do with how your application is treating (or better yet trying to) deal with 4 band uint8 (byte) tiff. In principle, by default in case of 4 band uint8 tiff, it is trying to read it into RGBA colour space, and it is failing, as the tiff doesn’t really match this expectation.

As SentinelHub doesn’t know if the 4 bands you have are RGB+alpha, or are thery NIR + Thermal band + data Mask + coastal (not to mention you can request more or less bands), it doesn’t specify the color interpretation of the bands, but leaves it up to the user to know what each band is. For instance in QGIS, you can then assign appropriate bands to RGB and alpha bands.

If I understand correctly, this TIFFReadDirectory: Sum of ... is “just” a warning. Can you perhaps share a bit more details about your setup (e.g. gdal version, which program you are trying to use) and what you are trying to achieve?

3

Thanks for the answer @batic. I am using GeoTools (https://www.geotools.org/), which seems to be picky. I am building a small application to analyse satellite images.

I am able to see everything fine with QGIS; and my application works fine if I request png formats… but I need the geographical information found on the TIFF file.

I think this is more a problem for GeoTools: it needs to be less picky, more “universal”, and able to read TIFFs with different channels. I was wandering if there was a way in which I could set up the WMS service to send a tiff that wouldn’t raise the warning/break GeoTools.

Thanks,

Juan

4

So, I received the following analysis from the GeoTools team:

Hi Juan,
As reported by Jody, your TIFF data seems not properly formed.

In the past years, any RGB+4TH band (ie. RGB-IR, RGB-NIR) has been handled as RGBAlpha which obviously isn’t right.
So the GT imageio-ext TIFF is nowadays properly parsing additional TIFF Tags to make sure that IR isn’t handled as a transparent band and so on.

The TIFF Specifications reports some info about SamplesPerPixels,Extrasamples and their relationship, i.e:

SamplesPerPixel
Tag = 277 (115.H) Type = SHORT
The number of components per pixel.
This number is 3 for RGB images, unless extra samples are present.
See the ExtraSamples field for further information.

ExtraSamples Description of extra components.
Tag = 338 (152.H) Type = SHORT N = m
Specifies that each pixel has m extra components whose interpretation is defined by one of the values listed below. When this field is used, the SamplesPerPixel field has a value greater than the PhotometricInterpretation field suggests. For example, full-color RGB data normally has SamplesPerPixel=3. If SamplesPerPixel is greater than 3, then the ExtraSamples field describes the meaning of the extra samples. If SamplesPerPixel is, say, 5 then ExtraSamples will contain 2 values, one for each extra sample. ExtraSamples is typically used to include non-color information, such as opacity, in an image. The possible values for each item in the field’s value are: 0 = Unspecified data 1 = Associated alpha data (with pre-multiplied color) 2 = Unassociated alpha data

It might be the case that the sample TIFF doesn’t respect some of these considerations.
Whilst GDAL might be fail-tolerant reporting that warning (Warning 1: TIFFReadDirectory:Sum of Photometric type-related color channels and ExtraSamples doesn’t match SamplesPerPixel. Defining non-color channels as ExtraSamples),
the GeoTools TIFF Reader (actually the Imageio-ext-tiff reader) isn’t.

Checking your data, the TIFF Tags report:
Photometric = 0 (MinIsBlack) so it seems like a GrayScale image
BitsPerSample = 8,8,8,8 so it’s actually a 4 bands image.
SamplesPerPixel = 4 (4 bands indeed)
but no extraSamples are provided

So I think that it’s struggling with having a gray image with 3 additional unknown samples per pixel.

Do you have any additional knowledge about what is the content of this data and what do their bands represent?

Please, let us know.

Regards,

Daniele Romagnoli
daniele.romagnoli -at- geosolutionsgroup.com
Senior Software Engineer
GeoSolutions Group

5

Yeah, that pretty much confirms what I was saying.

Unfortunately, SentinelHub service cannot know if you are requesting back a true RGB(+A) image, or is it something else (e.g. B05,B06,B8a,B11 from Sentinel-2). So the decision that 8-bit 4channel image has to be RGBA generally does not hold true.

Could you please share the WMS call with me (with last half of instanceId masked)? (you can also DM me)

6

Sure, here it is:

https://services.sentinel-hub.com/ogc/wms/b9ca1adf-3c10-48c1-xxxxxxxxxxxxxxxx?FORMAT=image%2Ftiff&CRS=EPSG:4326&STYLES=&LAYERS=TRUE-COLOR-S2L2A&REQUEST=GetMap&SHOWLOGO=false&BBOX=51.072442,31.221085977411132,51.09041607034924,31.249632466116697&VERSION=1.3.0&SERVICE=WMS&TRANSPARENT=FALSE&RESX=10m&RESY=10m

Thanks again for looking into this.

Juan

7

And here is the layer definition on the dashboard (removed all links):

{

"id": "TRUE-COLOR-S2L2A",
"title": "TRUE COLOR S2L2A",
"description": "Based on bands 4,3,2",
"styles": [
	{
		"name": "default",
		"description": "Default layer style",
		"dataProduct": {
			
			"id": 752,
			"name": "TRUE_COLOR.RGB",
			"description": "True color image by mapping the red, green and blue input bands. Value = B04,B03,B02 - RGB visualization.",
			"evalScript": "//VERSION=3\n\nlet minVal = 0.0;\nlet maxVal = 0.4;\n\nlet viz = new HighlightCompressVisualizer(minVal, maxVal);\n\nfunction evaluatePixel(samples) {\n    let val = [samples.B04, samples.B03, samples.B02];\n    val = viz.processList(val);\n    val.push(samples.dataMask);\n    return val;\n}\n\nfunction setup() {\n  return {\n    input: [{\n      bands: [\n        \"B02\",\n        \"B03\",\n        \"B04\",\n        \"dataMask\"\n      ]\n    }],\n    output: {\n      bands: 4\n    }\n  }\n}\n\n",
			
				
			"baseProduct": "TRUE_COLOR",
			"visualization": "RGB",
			"scriptVersion": 3,
			"listed": true,
			"additionalData": {
				"preV3EquivalentId": 85
			}
		}
	}
],
"orderHint": 8,



"defaultStyleName": "default",
"datasourceDefaults": {
	"upsampling": "BICUBIC",
	"mosaickingOrder": "mostRecent",
	"temporal": false,
	"maxCloudCoverage": 2,
	"previewMode": "PREVIEW",
	"type": "S2L2A"
},
"userData": {}
8

Up to my best knowledge, this may be solved by adding a color interpretation manually. For example, using rasterio it looks like this:

import rasterio
from rasterio.enums import ColorInterp

with rasterio.open('path/to/file.tif', 'r+') as src:
    src.colorinterp = tuple(ColorInterp.undefined for i in range(src.count))
    out = src.read()

At least for me, I don’t get these warnings like this.