Radiometric interpretation of Apple ProRAW and Bayer RAW access via AVFoundation

Thanks for the precise framing — answering each in turn.

Q1 — Bayer RAW capture through AVFoundation:

Yes, third-party apps can capture Bayer RAW through AVFoundation. Both Bayer RAW and Apple ProRAW formats appear in AVCapturePhotoOutput.availableRawPhotoPixelFormatTypes. The recommended way to discriminate them is through the static query methods:

AVCapturePhotoOutput.isBayerRAWPixelFormat(_:)
AVCapturePhotoOutput.isAppleProRAWPixelFormat(_:)

Apple ProRAW is opt-in: confirm photoOutput.isAppleProRAWSupported, then set photoOutput.isAppleProRAWEnabled = true. With ProRAW disabled, availableRawPhotoPixelFormatTypes exposes only Bayer formats; enabling ProRAW adds the ProRAW format to the same array.

Device and format restrictions:

• Apple ProRAW: iPhone 12 Pro / Pro Max and later Pro models (iOS 14.3+).
• Bayer RAW: broadly available on devices that support RAW capture. Some virtual / fusion capture devices (for example, multi-cam) may not expose Bayer RAW because there is no single sensor providing the Bayer mosaic. The reliable way to check is to query availableRawPhotoPixelFormatTypes on the photo output after it's added to the configured session.

Reference: Capturing photos in RAW and Apple ProRAW formats.

Q2 — ProRAW radiometric interpretation:

The documentation describes Apple ProRAW as providing "the benefits of RAW capture" while applying "many of the multi-image fusion techniques previously unavailable to RAW workflows." The output is a DNG that preserves the editing latitude of RAW, but multi-image fusion is part of the processing pipeline.

I'm not going to speculate beyond what's publicly documented about the specifics of that fusion — which algorithms run, when they run, how they vary by scene content, or how they interact with bracketing. Those are internal details that aren't part of the public API contract.

Q3 — Exposure-proportional model across bracketed ProRAW:

For your specific research use case — Y_i(p) ≈ t_i × R(p) across brackets in non-saturated regions — ProRAW is not the appropriate format. The documented multi-image fusion in ProRAW means a decoded frame combines data from multiple source frames, and there is no public contract that the proportional relationship is preserved across brackets. I won't speculate on how fusion varies bracket-to-bracket; what I can say is that the proportional model isn't something you can rely on with ProRAW.

Standard Bayer RAW is the right tool for radiometrically rigorous HDR reconstruction. The article calls out the tradeoff explicitly: standard RAW capture "bypasses the advanced processing that the image-capture pipeline provides." For your use case, bypassing that processing is the goal — Bayer RAW gives you the predictable per-frame, exposure-proportional behavior your model needs (modulo the usual sensor effects you'll want to characterize anyway: black level, PRNU, and non-linearity near saturation).

For deeper engagement:

If you have specific questions about radiometric guarantees beyond what's in public documentation — for example, exact characterization of non-linearity at high or low ISO, or sensor-specific calibration — that would benefit from a Code-Level Support request. I can engage directly and route specifics to engineering as needed.

First, a correction to my earlier reply. I said that Bayer RAW gives you the predictable, exposure-proportional behavior your model needs. The documentation doesn't support that. It doesn't state an exposure-proportional relationship across brackets for Bayer RAW or for ProRAW.

For a fixed-ISO sequence of minimally processed sensor data, AVCapturePhotoBracketSettings accepts a Bayer RAW format. AVCaptureManualExposureBracketedStillImageSettings then sets the exposure duration and ISO of each image, up to maxBracketedCapturePhotoCount images. The documentation doesn't say whether bracketed capture supports ProRAW formats.

For ProRAW, the WWDC21 session Capture and process ProRAW images says the DNG carries a BaselineExposure tag because ProRAW adapts to each scene's dynamic range. That tag and the other rendering tags in the DNG are unique to each image. The baselineExposure documentation likewise says its default "varies with camera settings."

On your first question, several more restrictions apply. The Bayer RAW rules in AVCapturePhotoOutput.h require photoQualityPrioritization to be .speed. They also require the device's videoZoomFactor and the connection's videoScaleAndCropFactor to be 1.0. The WWDC21 session says Bayer RAW is supported only on single-camera devices, such as the wide and telephoto cameras. For 48-megapixel quad-pixel cameras, the panel in the WWDC26 Camera and Photo Technologies Group Lab explains that Bayer RAW is binned. The sensor's quad pixels are combined into a Bayer pattern. Full sensor resolution is available as ProRAW.

On your second question, I can be more definite than before. The isAppleProRAWEnabled documentation says the system "demosaics and partially processes Apple ProRAW photos. They're still scene-referred, however." The header comment for that property calls a ProRAW DNG a "Linear DNG." The WWDC21 session describes the stored values as "scene-referred and linearizable," with a LinearizationTable in the DNG that converts them to linear scene values. That session's code turns off the default look in CIRAWFilter to get linear output:

rawFilter.baselineExposure = 0.0
rawFilter.shadowBias = 0.0
rawFilter.boostAmount = 0.0
rawFilter.localToneMapAmount = 0.0
rawFilter.isGamutMappingEnabled = false
let linearRawImage = rawFilter.outputImage

If you need Apple to document how ProRAW or Bayer RAW pixel values scale with exposure time, please file an enhancement request in Feedback Assistant. Describe your use case in it, and post the Feedback number here.

Please note that filing an enhancement request does not guarantee Apple will add any requested functionality to Apple products in the future. However, with that said, filing an enhancement request is a good way to get your ideas in front of the folks who make decisions about that sort of thing. Bug Reporting: How and Why? has tips on creating your report.