Hi Nyall thanks for your thoughts!
On Thu, Apr 16, 2020 at 6:09 AM Nyall Dawson <[email protected]> wrote: > > > > 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. Indeed - and one more optional resampling in the raster reprojector :-) > > 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 > > [...] > > 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. Yeah I know what you mean, and you are right, we will probably need to live with both resample-before-rendering and resample-after-rendering because of the different results... At least because everyone now is used to resample-after-rendering approach. But apart from that, I am not sure if I can see what is the use case where one would prefer resample-after-rendering - do you have any use case in mind? > 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. Exactly! > > - 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. Good point - but I am optimistic here that it should not be difficult. > Ok, so we expect to see this done by May then? :D :-) As Tim suggested, if this kind of rework is something that QGIS developers would find useful, it may be interesting to have that done within a grant - I suspect this can be a long journey with many edge cases, but it would be worth it (better visual quality, less code, faster). Especially I would love to see if someone with much better raster skills (looking at Even now :-) ) would be up for this challenge - and maybe to do a critical review of other parts of the raster pipeline too... 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
