[QGIS-Developer] Raster pipeline issues

[Martin Dobias]

Hi Nyall

thanks for your thoughts!

On Thu, Apr 16, 2020 at 6:09 AM Nyall Dawson <nyall.dawson at gmail.com> 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