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?
Does CIImage(cvPixelBuffer:) natively interpret kCVImageBufferLogTransferFunctionKey, even though no public Apple
Log CGColorSpace exists?
When NSNull()/nil is supplied as above, does Core Image leave the Apple Log values unmanaged during crop and
affine operations?
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?
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?
Is copying kCVImageBufferLogTransferFunctionKey and the related colour attachments from source to destination
sufficient for AVAssetWriter, assuming the writer settings were obtained from
recommendedVideoSettingsForAssetWriter(writingTo:)?
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?
0
0
905