Core Image on OS X does not allow RGBAf (32-bit floating-point) contexts anymore on El Capitan, leading to precision problems.
| Originator: | raphael | ||
| Number: | rdar://23234334 | Date Originated: | 23-Oct-2015 03:05 PM |
| Status: | Open | Resolved: | |
| Product: | OS X SDK | Product Version: | 10.11.1 (15B42) |
| Classification: | Serious Bug | Reproducible: | Always |
When running the following sample code, Core Image explicitly mentions in the logs that it refuses 32-bit floating point working format. This drastically reduces computation precision, and is a departure from what was possible to do in the last 5+ years. The header file explicitely mentions that 32-bit floating-point is supported on OS X: /* An NSNumber with a CIFormat value defining the pixel format to use for intermediate buffers. * On iOS GPU the supported values for this key are RGBA8 and RGBAh. If not specified RGBA8 us used. * On iOS CPU the only supported value for this key is RGBAf. If not specified RGBAf us used. * On OSX GPU the supported values for this key are RGBA8, RGBAh and RGBAf. If not specified RGBAh us used. * On OSX CPU the supported values for this key are RGBA8, RGBAh and RGBAf. If not specified RGBAh us used. */ CORE_IMAGE_EXPORT NSString * const kCIContextWorkingFormat NS_AVAILABLE(10_4,8_0); Here's the log output when running the sample code, which arises when setting kCIFormatRGBAf as working format (both CPU and GPU contexts). CIContext workingformat must be kCIFormatBGRA8, kCIFormatRGBA8, kCIFormatRGBAh or nil. Ignoring request for RGBAf.
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!