Feature Request: Runtime Custom Visualization & Texture Filtering Control #215
Description
Hi everyone,
First of all, I really admire the approach taken in this library with the GPU-based raster reprojection and native tiling - it is a fantastic architecture.
We are currently maintaining our own solution for COG visualization (gisat/deck.gl-geotiff), but we are very interested in potentially migrating to use deck.gl-raster in the future. However, we have identified two key features that are currently preventing us from doing so, and I wanted to ask about your roadmap for them.
1. Runtime Custom Visualization
Currently, it seems deck.gl-raster relies heavily on visualization styles that are saved directly within the GeoTIFF/COG file. For our use cases, we need the ability to define custom visualizations dynamically at runtime (e.g., custom pixel-by-pixel filtering, band combinations, dynamic thresholding, and coloring) without modifying the source file.
We implement this in our current architecture by processing pixel data on the fly (see our architecture docs here).
I noticed in your README that "spectral band math" and "pixel filtering" are listed under "Soon". Could you share if there is a plan or timeline for enabling these custom visualization pipelines? This would be a major enabler for us to switch.
2. Texture Filtering Control (Nearest vs. Linear)
We also need the ability to control texture filtering, specifically to disable texture smoothing (blurring) when zoomed in. For scientific data analysis, preserving the "sharp" pixel edges using Nearest Neighbor interpolation is often critical.
In our current implementation, we handle this by passing textureParameters to the layer, toggling between linear and nearest based on user preference:
// Example from our CogBitmapLayer.ts
textureParameters: {
minFilter: blurredTexture ? 'linear' : 'nearest',
magFilter: blurredTexture ? 'linear' : 'nearest',
},Is there an option to expose these texture parameters in COGLayer?
Thank you for your work on this library!