Processing RAW files using CIRAWFilter slows down after opening a few different images

Is there some cleanup required if you are opening multiple different RAW files - I am seeing a slow down each time I open a new file and things grind to a halt after opening 5 or 6 files, one after the other - even allowing some time between opening them.

Currently I have a single view with a CAMetalLayer and a single Renderer and CIContent - should I be creating a new CAMetalLayer, render and CIContext each time a new image is opened ?

Alternately is there some way to clear the cache or something to maintain performance.

Answered by DTS Engineer in 909825022

If you're opening 48-megapixel ProRAW files on iPhone, the full-resolution decode alone can use more memory than iOS allows the app. Setting the CIRAWFilter scaleFactor property to match the size you display kept memory low in my testing.

On an iPhone 18 Pro Max with iOS 27.0 (24A427), I opened 13 different 48-megapixel ProRAW files one after another with CIRAWFilter. I rendered each one with a single CIContext into a 1920 by 2560 Metal texture. With the default scaleFactor of 1, the app exceeded its memory limit during the first file. The debugger reported EXC_RESOURCE, "high watermark memory limit exceeded", with a limit of 3,377 MB. The same test with 12-megapixel files completed without a problem, and memory stayed flat across all 13 files.

With scaleFactor set to fit the view, about 0.32 for these files, all 13 files opened. The footprint stayed between about 600 and 800 MB, and render times didn't change from file to file. The documentation says a value less than 1 "results in a smaller output image" and that "Setting this value can greatly improve the drawing performance." It doesn't describe memory use, so those figures are my measurements. On a Mac with M5 Max running macOS 27.0.1 (26A434), the same change reduced the footprint from about 4.2 GB to about 1.0 GB.

func makeImage(url: URL, viewPixelSize: CGSize) -> CIImage? {
    guard let filter = CIRAWFilter(imageURL: url) else { return nil }
    // Decode at the size you display instead of the full sensor resolution.
    let native = filter.nativeSize
    let longSide = max(native.width, native.height)
    let shortSide = min(native.width, native.height)
    let scale = min(1, min(max(viewPixelSize.width, viewPixelSize.height) / longSide,
                           min(viewPixelSize.width, viewPixelSize.height) / shortSide))
    filter.scaleFactor = Float(scale)
    return filter.outputImage
}

Your single CIContext matches the CIContext documentation, which says "it is not recommended to create many CIContext instances." There's no need to recreate the layer, renderer, or context for each image. Releasing the previous file's CIRAWFilter and CIImage was the only cleanup the test needed. In these tests, clearCaches() made no measurable difference while the context was in use.

If a feature needs full-resolution images, the com.apple.developer.kernel.increased-memory-limit entitlement asks for a higher limit. Its documentation notes that "An increased memory limit is only available on some device models." It points to os_proc_available_memory() for checking how much memory is available.

If this doesn't match what you see, please mention your platform, device, and image size, and post the code that opens each file.

If you're opening 48-megapixel ProRAW files on iPhone, the full-resolution decode alone can use more memory than iOS allows the app. Setting the CIRAWFilter scaleFactor property to match the size you display kept memory low in my testing.

On an iPhone 18 Pro Max with iOS 27.0 (24A427), I opened 13 different 48-megapixel ProRAW files one after another with CIRAWFilter. I rendered each one with a single CIContext into a 1920 by 2560 Metal texture. With the default scaleFactor of 1, the app exceeded its memory limit during the first file. The debugger reported EXC_RESOURCE, "high watermark memory limit exceeded", with a limit of 3,377 MB. The same test with 12-megapixel files completed without a problem, and memory stayed flat across all 13 files.

With scaleFactor set to fit the view, about 0.32 for these files, all 13 files opened. The footprint stayed between about 600 and 800 MB, and render times didn't change from file to file. The documentation says a value less than 1 "results in a smaller output image" and that "Setting this value can greatly improve the drawing performance." It doesn't describe memory use, so those figures are my measurements. On a Mac with M5 Max running macOS 27.0.1 (26A434), the same change reduced the footprint from about 4.2 GB to about 1.0 GB.

func makeImage(url: URL, viewPixelSize: CGSize) -> CIImage? {
    guard let filter = CIRAWFilter(imageURL: url) else { return nil }
    // Decode at the size you display instead of the full sensor resolution.
    let native = filter.nativeSize
    let longSide = max(native.width, native.height)
    let shortSide = min(native.width, native.height)
    let scale = min(1, min(max(viewPixelSize.width, viewPixelSize.height) / longSide,
                           min(viewPixelSize.width, viewPixelSize.height) / shortSide))
    filter.scaleFactor = Float(scale)
    return filter.outputImage
}

Your single CIContext matches the CIContext documentation, which says "it is not recommended to create many CIContext instances." There's no need to recreate the layer, renderer, or context for each image. Releasing the previous file's CIRAWFilter and CIImage was the only cleanup the test needed. In these tests, clearCaches() made no measurable difference while the context was in use.

If a feature needs full-resolution images, the com.apple.developer.kernel.increased-memory-limit entitlement asks for a higher limit. Its documentation notes that "An increased memory limit is only available on some device models." It points to os_proc_available_memory() for checking how much memory is available.

If this doesn't match what you see, please mention your platform, device, and image size, and post the code that opens each file.

Processing RAW files using CIRAWFilter slows down after opening a few different images
 
 
Q