How Does a P3-Configured AVCaptureDevice fit the 10-bit Color Data into the 8-bit 32BGRA Pixel Format?

Title says it all basically. When you configure an

AVCaptureDevice
to return pixels with a P3 colorspace (which Apple says is 10-bit, and recommends using a 16-bit pixel format to contain), your only pixel format output choices are still only
kCVPixelFormatType_32BGRA
and the two planars.


So I don't understand how you're being returned deeper color data, that needs 10-bits with the same 8-bit format??


And they explicitly state that it is possible to take P3 video (though discouraged for playback compatibility reasons).


Maybe only when you use a

AVCaptureMovieFileOutput
, and do not receive the raw pixel buffers? That's all I can think.

Replies

Any help would be greatly appreciated, as I‘m looking for the same information. Apple’s developer documentation isn’t helpful.

Not sure if this answers your question, but I have been able to attach a AVCaptureVideoDataOutput() to my capture session and successfully receive pixel buffers in the P3 color space, frame by frame; during the capture, you can see the device's activeColorSpace is P3_D65. Is that what you are trying to do? I did not have to explicitly specify a pixel format but instead relied on automaticallyConfiguresCaptureDeviceForWideColor and made sure to set session.sessionPreset = .photo, which provides a "hint" that I am not actually planning to use this for video. (Note: I also attached a AVCapturePhotoOutput() and did *not* attach a AVCaptureMovieFileOutput to the session.)


To be clear, the components in this P3 color space will still be between 0 and 1 until/unless you convert it to extended RGB color space. When converting to extended RGB, you need to make sure to use a pixel format like kCIFormatRGBAh (full float) that can handle negative values and those > 1.0.

Right I have done this too. Forcibly configured the AVCaptureDevice to use P3 colorspace, and it reports that it's in P3 mode. But it is a fact that P3 is a 10-bit color format, yet the only pixel output options are 8-bit. So it really makes no sense? What they say is happening literally can not be happening (aka returning 10-bits of color in an 8-bit color format).


The point of P3 is that it is not only wider, but mainatins the same pixel density. Which means that... the wider it space, the more discrete color values. So there literally must be more bits to allow for all the new permutation values. So an 8-bit format allows 2 ^ 8 = 256 options, whereas 10-bit, 2 ^ 10, 1024. (not to imply there are 1024 options.. but that amount of space).


If you check out the wikipedia page for P3, it says "DCI-P3 has a 25% larger color gamut than sRGB"... thus needs 25% more permutation values needed.


And if you watch the P3 videos from WWDC, they recommend using a 16-bit format.


I want to start using P3, and switch my camera and media over on our app... but am unable to until Apple makes sense of this lol.

still really hoping we get some comment from Apple here

Were you able to resolve this? I am also struggling with the same issue.

nope! kind of blows my mind how this was completely overlooked??


keep hoping it'll magically be fixed in iOS12

help apple 🙂

I can confirm that the only pixel format types as reported by AVCapturePhotoOutput.availablePhotoPixelFormatTypes are:

- kCVPixelFormatType_420YpCbCr8BiPlanarFullRange

- kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange

- kCVPixelFormatType_32BGRA


By the way: I have found a pixel format that has 'WideGamut' in its name. It's called kCVPixelFormatType_30RGBLEPackedWideGamut. It seems to allocate 10-bit to each channel, which would be in line with Apple's specification about P3 being 10-bit. Unfortunately, the documentation is very lacking: https://developer.apple.com/documentation/corevideo/1563591-pixel_format_identifiers/kcvpixelformattype_30rgblepackedwidegamut?language=objc. On the other hand, you can't even select this format in the first place.


For now, I assume that when using kCVPixelFormatType_32BGRA, the 'native' 10-bit P3 values are simply downscaled to fit into 8-bit. It will still be the P3 RGB colorspace as opposed to sRGB - you only lose some accuracy.