Supported Core Image workflow for cropping/scaling Apple Log x422 buffers without converting to HLG?

We capture Apple Log video using AVCaptureVideoDataOutput with:

• AVCaptureDevice.activeColorSpace = .appleLog or .appleLog2
• kCVPixelFormatType_422YpCbCr10BiPlanarVideoRange (x422)
• AVAssetWriter for the final ProRes/HEVC recording

We need to bake spatial operations such as a centre crop and optional anamorphic desqueeze into the recorded raster. We want the result to remain Apple Log for subsequent grading; we do not want to display-transform or convert it to HLG.

Core Image/Core Graphics does not appear to expose a public Apple Log or Apple Log 2 CGColorSpace. Core Video instead identifies the signal using kCVImageBufferLogTransferFunctionKey.

Would this be the supported Core Image approach for spatial-only processing?

  let image = CIImage(
      cvPixelBuffer: sourceBuffer,
      options: [.colorSpace: NSNull()]
  )

  let context = CIContext(
      mtlDevice: metalDevice,
      options: [
          .workingColorSpace: NSNull(),
          .outputColorSpace: NSNull(),
          .cacheIntermediates: false
      ]
  )

  let outputImage = image
      .cropped(to: cropRect)
      .transformed(by: spatialTransform)

  context.render(
      outputImage,
      to: destinationX422Buffer,
      bounds: outputBounds,
      colorSpace: nil
  )

We would then copy the source buffer’s Apple Log colour and Log-transfer attachments to the destination buffer and append it to an AVAssetWriterInputPixelBufferAdaptor.

Could an Apple engineer clarify the following?

1. Does CIImage(cvPixelBuffer:) natively interpret kCVImageBufferLogTransferFunctionKey, even though no public Apple Log CGColorSpace exists?

2. When NSNull()/nil is supplied as above, does Core Image leave the Apple Log values unmanaged during crop and affine operations?

3. When rendering x422 to x422, can Core Image preserve the Log signal apart from expected resampling/rounding, or does it internally perform a colour conversion such as YCbCr → RGB → YCbCr?

4. For scaling or anamorphic desqueeze, is Apple’s recommended workflow to:

   • resample the encoded Apple Log values with colour management disabled, or
   • explicitly decode Apple Log to a linear working space, resample, and encode back using a custom Metal implementation?

5. Is copying kCVImageBufferLogTransferFunctionKey and the related colour attachments from source to destination sufficient for AVAssetWriter, assuming the writer settings were obtained from recommendedVideoSettingsForAssetWriter(writingTo:)?

6. Is there ever a supported reason to use HLG as an intermediate for Apple Log processing, or should that be avoided?

This this part, we are concerned about preserving the captured Log signal in a recording pipeline, not applying a viewing LUT or displaying Apple Log.

Next, we also support optional LUT processing with CIColorCube. Some LUTs are technical Apple Log-to-display transforms, while others expect linear or Rec.709 input. If the image is created with .colorSpace: NSNull(), we understand that the LUT receives unmanaged Apple Log code values and that the LUT itself must perform the required transfer-function and gamut conversion.

Does Core Image synthesize an Apple Log-aware input color space from kCVImageBufferLogTransferFunctionKey, or must applications implement Apple Log/Apple Log 2 decoding explicitly before using ordinary Core Image filters? Is there a supported CGColorSpace, ColorSync profile, or Core Image conversion API for this?

Additionally, what numeric range does CIColorCube receive when its source is an x422 video-range Apple Log buffer— normalized Log RGB values, or values requiring explicit video-range conversion?