GSoC 2025: Improving Sampling in the Compositor

Week 3


General info because people reached out on the current status, let it be known that we’ve discussed (with @OmarEmaraDev and @izo) to reschedule the proposal and get everything but EWA done before the mid-term evaluation period. Therefore, there has been no implementation done yet for EWA, nor will it be done before the 18th of July.

We additionally had a meeting to discuss two papers in which we found that a deeper investigation is required. Since CPU and GPU implementations have to be equivalent, some papers that just introduce efficient GPU implementations may not be able to be translated to a CPU version. We decided that:

  1. Implement the Heckbert baseline
  2. Implement CPU versions of papers and decide on one
  3. Implement GPU version

Further, this week I’ve finished the UV Map node and therefore all required compositor nodes are now having the interpolation exposed to the node interface → Issue #119592 :white_check_mark:

I am working on a PR for introducing the border condition in the transform node’s UI to give the user control over how out-of-image samples will affect the computed pixel. The interface for the translation node now looks like the following and is the first node to implement the boundary condition.
image

The node now implements the border condition as follows (image is courtesy of Unity, see: Unity - Manual: Texture samplers):
image

  • On the left-hand side is the extend case, where the pixel at the border will be repeated.
  • The right image shows the repeat case, where the image is repeated outside the border.
  • The last case is the zero case, which just pads the image with zeros.

We allow the configuration of the boundary condition for both axes.

TODO Week 4:

  • Get the boundary condition PR merged
1 Like