Mismatch between raster pixel values and returned colormap

We’re relying on data returned from the /colormap endpoint to show approximate raw raster values upon hovering over a point in a frontend application. However, for a small number of pixels in almost every tile, the pixel color doesn’t match any of the entries returned from /colormap. The “invalid” color is usually off by 1 on one of the three r,g,b components from the nearest legend entry. This seems like a bug but I’m not sure what might be causing it.

Example (the three marked pixels are the ones where no colormap entry can be found for the pixel value queried from the image):

I checked the details of some of those raster cells.

For point A:

• the raw value is 0.513400018215179
• the raster color is rgb(246,245,249)
• the nearest entry in the colormap JSON is raw value 0.5118110236220472 - but the color for that is rgb(247,245,249) (red component is off by 1)

For point B:

• the raw value is 0.713100016117096
• the raster color is rgb(244,243,248)
• the nearest entry in the colormap is raw value 0.7086614173228346 but the color for that is rgb(245,243,248) (again, red off by 1)

Interestingly, the raster tile color values match the colormap values stored in purples_rgba.npy. So it seems that it’s the JSON coming from the /colormap endpoint that has distorted values.

See result of querying /colormap?colormap=purples&stretch_range=[0,10]:

{
"colormap": [
//...
		{
			"value": 0.4330708661417323,
			"rgba": [
				247,
				246,
				250,
				255
			]
		},
		{
			"value": 0.47244094488188976,
			"rgba": [
				247,
				245,
				249,
				255
			]
		},
		{
			"value": 0.5118110236220472,
			"rgba": [
				247,
				245,
				249,
				255
			]
		},
		{
			"value": 0.5511811023622047,
			"rgba": [
				246,
				244,
				249,
				255
			]
		},
		{
			"value": 0.5905511811023622,
			"rgba": [
				246,
				244,
				249,
				255
			]
		},
		{
			"value": 0.6299212598425197,
			"rgba": [
				245,
				243,
				248,
				255
			]
		},
		{
			"value": 0.6692913385826772,
			"rgba": [
				245,
				243,
				248,
				255
			]
		},
		{
			"value": 0.7086614173228346,
			"rgba": [
				245,
				243,
				248,
				255
			]
		},
		{
			"value": 0.7480314960629921,
			"rgba": [
				244,
				242,
				248,
				255
			]
		},
		{
			"value": 0.7874015748031495,
			"rgba": [
				244,
				242,
				248,
				255
			]
		},
// ...
]
}

Compare with corresponding fragment of the purples_rgba.npy file:

// ...
11: 247, 246, 250, 255
12: 247, 245, 249, 255
13: 246, 245, 249, 255
14: 246, 244, 249, 255
15: 245, 244, 249, 255
16: 245, 243, 248, 255
17: 245, 243, 248, 255
18: 244, 243, 248, 255
// ...

The JSON contains rgb values that do not exist in the colormaps.

For context. we’re setting the following in the config, but not sure if it’s relevant:

PNG_COMPRESS_LEVEL = 0
RESAMPLING_METHOD = "nearest"
REPROJECTION_METHOD = "nearest"

[mz8i]

@dionhaefner I’m sorry, the error was on my side - I overlooked a non-standard mechanism in which our app was caching the old responses in local storage, so it didn’t work despite updating. I’ve now double-checked all colour scales we use, and the responses for all match the .npy files exactly. Apologies again for the confusion and thank you for fixing this.

[dionhaefner]

To me it seems that the more sensible approach would be to go the other way round: generate a raw value for each of the colormap array elements, thus ensuring all possible colors are included in the JSON. Perhaps this will cause the raw values to be spaced slightly unevenly, but this seems less important here.

Keep in mind that /colormap takes a num_values parameter, so in general that is not possible. But I agree that, for num_values=255, the output should ideally match the colormap file exactly.

I have identified the issue and will push a fix in a few minutes.