[V3] colorRampTexture with NEAREST textureFilter

[HiroyukiYANO]

Motivation

The TextureFilter of colorRampTexture is now only fixed to 'LINEAR'.
But in some case, the user may wish to use 'NEAREST' for color palette, especially using 'step' expression for raster-color.
No color interpolation is needed arround threshold value.

The attached images area drawn by following paint properties.

    'raster-color': [
            'step',
            ['raster-value'],
            'transparent', 0.3,
            '#00DCEA', 2.0,
            '#0005B9', 8.0,
            '#FFF000', 16.0,
            '#F50100'
    ],
    'raster-color-mix': [255, 0, 0, 0],
    'raster-color-range': [0, 255],
    'raster-opacity': 0.8,

Design Alternatives

Design

adding new paint property like raster-color-resampling: "nearest" | "linear" ("linear" as default)
or use existing paint property raster-resampling for raster-color-ramp.

Mock-Up

Concepts

Implementation

change L130 of draw_raster.js

from

tex.bind(gl.LINEAR, gl.CLAMP_TO_EDGE);

to

if(layer.paint.get('raster-color-resampling') === 'nearest') {
    tex.bind(gl.NEAREST, gl.CLAMP_TO_EDGE);
} else {
    tex.bind(gl.LINEAR, gl.CLAMP_TO_EDGE);
}

[mourner]

cc @rreusser

[rreusser]

Good catch, @HiroyukiYANO! I believe what you're seeing is a small misalignment in tabulated color scale texture sampling resulting from the fact that WebGL texture values are defined at the center of each pixel. I have submitted a bug fix which fixes how this sampling is performed internally and which will be released in the near future. Until then, you might try the following workaround:

"raster-color-range": [ -0.5, 255.5 ],

With this code, you should find that raster tile pixel values map precisely to raster-color expression values and no longer displays unexpected colors:

'raster-color': [
    'step',
    ['raster-value'],
    'transparent', 0, // <- precise integers should work
    '#00DCEA', 2,
    '#0005B9', 8,
    '#FFF000', 16,
    '#F50100'
],
'raster-color-mix': [255, 0, 0, 0],
'raster-color-range': [-0.5, 255.5 ],

Once the fix is released, then "raster-color-range": [0, 255] should produce the expected results.

You may also find this comment useful, in which I described some of the subtle differences in behavior which result from more of a "categorical" colorization use case instead of a continuous, quantitative color scale: #12368 (comment) Any feedback on the value or shortcomings of this feature are greatly appreciated! 🙇

Hopefully the above workaround is successful, and if so, I think it's still best to leave this issue open until the fix is released.

[rreusser]

Oh, and one small extra note is that you're very correct that a property like raster-color-resampling may be appropriate. It may ultimately prove necessary, but it's generally much much harder to remove properties than to add them later, so I'd like to explore first whether the above workaround/bugfix remedies the issue. If not, then I'm glad to further explore details and possibilities. Finally, thank you for the clear description of the issue! 🙇

[HiroyukiYANO]

Thank you for your kindly reply.
I have tried your workaround.

The result is ... almost OK.

with subtract 0.5 from original step value, then it woks fine.

'raster-color': [
    'step',
    ['raster-value'],
    'transparent', 0,
    '#00DCEA', 2 - 0.5, 
    '#0005B9', 8 - 0.5,
    '#FFF000', 16 - 0.5,
    '#F50100'
],
'raster-color-mix': [255, 0, 0, 0],
'raster-color-range': [-0.5, 255.5 ],

You can see my code example here.

[rreusser]

Ahh, thank you for the followup. I think I failed to shift the expression to compensate for the shifted raster-color-range values. Apologies for the continued workarounds and confusion, but if this yields the correct result, I think it's the appropriate solution for now, and when the fix is released, I think you will be able to get rid of the factors of 0.5 throughout.

[HiroyukiYANO]

Thank you. I got it.
I'm looking forward to releasing fixed one!