Unexpected behaviour with CIKernel

I made this example to show the problem. It takes 1 pixel from texture by hardcoded coordinate and use as result for each pixel in shader. I expect that all the image will be in the same color. When images are small it works perfectly, but when I work with big images it has strange result. For example, here image has size 7680x8580 and you can see 4 squares:

Here is my code

kernel vec4 colorKernel(sampler source)
{
    vec4 key = sample(source, samplerTransform(source, vec2(100., 200.)));
    return key;
}

Here is how I init Kernel:

override var outputImage: CIImage? {
        return colorFillKernel.apply(
                extent: CGRect(origin: CGPoint.zero, size: inputImage!.extent.size),
                roiCallback:
                {
                    (index, rect) in
                    return rect
                },
                arguments: [
                    inputImage])
    }

Also, this code shows image properly, without changes and squares:

vec2 dc = destCoord();
return sample(source, samplerTransform(source, dc));

On a public documentation it says "Core Image automatically splits large images into smaller tiles for rendering, so your callback may be called multiple times." but I can't find ways how to handle this situations. I have kaleidoscopic effects and from any this tile I need to be able to get pixel from another tile as well...

Solution

I think the problem occurs due to a wrongly defined region of interest in combination with tiling.

In the roiCallback, Core Image is asking you which area of the input image (at index in case you have multiple inputs) you kernel needs to look at in order to produce the given region (rect) of the output image. The reason why this is a closure is due to tiling:
If the processed image is too large, Core Image is breaking it down into multiple tiles, renders those tiles separately, and stitches them together again afterward. And for each tile Core Image is asking you what part of the input image your kernel needs to read to produce the tile.

So for your input image, the roiCallback might be called something like four times (or even more) during rendering, for example with the following rectangles:

CGRect(x: 0,    y: 0,    width: 4096, height: 4096) // top left
CGRect(x: 4096, y: 0,    width: 3584, height: 4096) // top right
CGRect(x: 0,    y: 4096, width: 4096, height: 4484) // bottom left
CGRect(x: 4096, y: 4096, width: 3584, height: 4484) // bottom right

This is an optimization mechanism of Core Image. It wants to only read and process the pixels that are needed to produce a given region of the output. So it's best to adapt the ROI as best as possible to your use case.

Now the ROI depends on the kernel. There are basically four scenarios:

Your kernel has a 1:1 mapping between input pixel and output pixel. So in order to produce an output color value, it needs to read the pixel at the same position from the input image. In this case, you just return the input rect in your roiCallback. (Or even better, you use a CIColorKernel that is made for this use case.)
Your kernel performs some kind of convolution and not only requires the input pixel at the same coordinate as the output but also some region around it (for instance for a blur operation). Your roiCallback could look like this then:
```
let inset = self.radius // like radius of CIGaussianBlur
let roiCallback: CIKernelROICallback = { _, rect in 
    return rect.insetBy(dx: -inset, dy: -inset) 
}
```
Your kernel always needs to read a specific region of the input, regardless of which part of the output is rendered. Then you can just return that specific region in the callback:
```
let roiCallback: CIKernelROICallback = { CGRect(x: 100, y: 200, width: 1, height: 1) }
```
The kernel always needs access to the whole input image. This is for example the case when you use some kind of lookup table to derive colors. In this case, you can just return the extent of the input and ignore the parameters:
```
let roiCallback: CIKernelROICallback = { inputImage.extent }
```

For your example, scenario 3 should be the right choice. For your kaleidoscopic effects, I assume that you need a certain region or source pixels around the destination coordinate in order to produce an output pixel. So it would be best if you'd calculate the size of that region and use a roiCallback like in scenario 2.

P.S.: Using the Core Image Kernel Language (CIKernel(source: "<code>")) is super duper deprecated now. You should consider writing your kernels in the Metal Shading Language instead. Check out this year's WWDC talk to learn more. 🙂