On Thu, 16 Apr 2020 at 07:46, Martin Dobias <[email protected]> wrote: > > Hi all > > With the recent addition of contour renderer of rasters I have > realized there are artifacts coming to the renderer from the earlier > stages (the raster data provider mainly). Another issue is that raster > resampling (nearest neighbor / bilinear / bicubic) is only applied at > the end of raster processing pipeline (i.e. after the contour renderer > has been run), which does not really help for contours to get smooth > contour lines (rather one gets some pixelated blurry output). > Moreover, hopefully I am not the only one seeing occasional subtle > "jumps" of raster data when zooming/panning map, which I would account > to some small math errors in the QGIS raster code.
I agree that the current approach has issues. I'm glad to see this getting wider attention! > Looking at the GDAL raster data provider in QGIS, there's quite some > code complexity, with copying of data between temporary buffers and > dealing with limitations that existed in GDAL < 2.0 (e.g. non-integer > source windows). Frustratingly, we've actually got 3 different sources of resampling happening during raster rendering: 1. Internal resampling happening inside gdal 2. A very coarse resampling run happening inside QgsGdalProvider::readBlock 3. The raster pipeline resampling, which happens **after** the renderer. > I am wondering what people think about simplifying the QGIS raster pipeline: > - get rid of the last stage of the pipeline - resampling - and make it > responsibility of data providers (i.e. GDAL) to return resampled data It's important to note that these are two very different things. I recently did some work on the resampler to avoid edge effects, and in my initial experiments I attempted moving the resampling right up to the provider level, exactly as you describe. The results however are HUGELY different vs the current resample-after-rendering approach. Unfortunately I junked the code from this early approach or I could show screenshots, but I'll try to describe it in words :p Imagine a lower-resolution float raster being resampled up to a higher resolution (e.g. zoomed in past 1:1). You might be taking 100x100 pixels from the gdal provider, then applying a discrete color ramp to these, before resampling up to 1000x1000 for render. The results will be a blurry version of the discrete colors - i.e. the "Hard" boundaries between color mapped pixels are "softened" when enlarging this 100x100 colored block out to 1000x1000. The other approach is to do the resampling first, in gdal. What we get then is 1000x1000 pixels of resampled float values to begin with, smoothly interpolated from the 100x100 original pixels. This is then rendered using the discrete color ramp, and then rendered without further resampling or smoothing. What you get here looks more like smoothed contours of the discrete color bands, with NO color smoothing of the rendered pixels. The result looks much higher resolution (because we are interpolating the floating point values on a 1000x1000 grid), but the "boundaries" between the discrete color values are "hard" and have no antialiasing. I honestly think there's valid use cases for both pre-render vs post-render resampling as a result. We can't directly replace the current post-render approach with a forced pre-render approach without people getting VERY different rendering of their existing projects. That said, the benefits of pre-render are huge, including that we can instantly expose all of GDAL's inbuilt resampling mechanisms (adding average, mode, max, min, median, q1, q3 mechanisms). The results are also more accurate, because we are doing a single resampling run vs 3. And, for some purposes, it results in a more visually pleasing render. > - get rid of the reprojector stage of the pipeline - and again make it > responsibility of data providers (i.e. GDAL) to return already warped > data This sounds like a good idea, BUT we'd need to be very careful that any transformation happening inside GDAL correctly uses the same coordinate operation as you'd get if the transformation was done on the QGIS side. I.e. you'd have to evaluate the coordinate operation using the transform context, pass this to GDAL, and make sure that GDAL also has access to the same proj search paths as QGIS does. > - any other raster data provider not being able to do it internally > would just use GDAL routines > My hope is that we could get rid of a lot of raster related code and > at the same time use GDAL's optimized code even more. I am not saying > I will be working on this anytime soon Ok, so we expect to see this done by May then? :D Nyall , but I would be interested to > hear what others think about the current state of the raster pipeline > :-) > > Cheers > Martin > _______________________________________________ > QGIS-Developer mailing list > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
