I can't get CoreImage to render an HDR image file with correct colors to a CAMetalLayer on macOS 14. I'm comparing the result with NSImageView and the SupportingHDRImagesInYourApp 'HDRDemo23' sample code, which use CVPixelBuffer. With CAMetalLayer, the images are displayed as HDR (definitely more highlights), but they're darker with some kind saturation increase & color shift. Files I've tested include the sample ISO HDR files in the SupportingHDRImagesInYourApp sample code. Methods I've tried to render to CAMetalLayer include: Modifying the GeneratingAnAnimationWithACoreImageRenderDestination sample code's ContentView so it uses HDRDemo23/example-ISO-HDR-images/image_01.heic, loaded using CIImage(contentsOf:) Creating a test AppKit app that uses MTKView and CIRenderDestination the same way. I have NSImageView and the MTKView in the same window for comparison. Using CIRAWFilter > CIRenderDestination > IOSurface > MTKView/CAMetalLayer All these methods produce the image with the exact same appearance; a dark HDR image with some saturation/color shift. The only clue I've found is that when using the Metal Debugger on the test AppKit app, the CAMetalLayer's 'Present' shows the 'input' thumbnail is HDR without the color shift, but the 'output' thumbnail looks like what I actually see. I tried changing the color profile on the layer to various things but nothing looked more correct. I've tried this on two Macs, an M1 Mac Studio with an LG display, and a MacBook Air M2. The MacBook Air shows the same color shift, but since it has less dynamic range overall there isn't as much difference between NSImageView and MTKView.

Related APIs: CAMetalLayer, WantedExtendedDynamicRangeContent, potentialEDRHeadroom, currentEDRHeadroom, [UIScreen mainScreen].brightness. Premise: I am a Video Player developer. The information I got from Apple’s development documentation about currentEDRHeadroom is that if I set WantedExtendedDynamicRangeContent = YES on a View, then the value of currentEDRHeadroom will be increased according to the current system brightness by a ratio that is not less than the brightness of potentialEDRHeadroom. This is not a problem when at least ios16. Question: Device: iPad pro 12.9 2022 model, iPadOS 17.2. turn off Reference Mode, turn off Night Shift mode, turn off automatic brightness (not turning it off actually has the same result), use the same picture or video. step: (1): Set [UIScreen mainScreen].brightness to 1.0 (or use system tools to adjust the system brightness to 100%), create the UIView where CAMetalLayer is located and set its parameter WantedExtendedDynamicRangeContent=YES, Start rendering. At this time, the potentialEDRHeadroom is always equal to 16 (this has always been the case in the iPad Pro 12.9 2022 model, which should be set by the hardware). At this time, the value of the currentEDRHeadroom is about 3.7-3.9, which means it can provide standard 100% brightness 3-4 times the brightness, My picture at this time is that there are no over exposure of pixels in the entire picture. (2): Set [UIScreen mainScreen].brightness to 0.8 (or use system tools to adjust the brightness to 80%) or lower, such as 50%, create the UIView where CAMetalLayer is located and set its parameter WantedExtendedDynamicRangeContent=YES, At this time, I set [UIScreen mainScreen].brightness to 1.0 (or use system tools to adjust the brightness to 100%). Now the maximum value of currentEDRHeadroom can only be about 1.79. My pictures is that the entire picture or video has over exploded pixels. Bug or Feature: I have the impression that this problem did not exist in iPadOS 16, and from Apple's documentation and the courses in Developer.app, there is no mention that the range of currentEDRHeadroom is related to the system brightness before creating CAMetalLayer. The documentation and tutorials talk about real-time system brightness. I want to know if this is a bug in iOS 17.2 or will it be designed this way in the future?

Hello everyone 👋 Occasional Apple developer yet first time poster Flo here. I've had this idea floating around my head for a while now, to develop a little toy that would make use of Apple's XDR displays, i.e. the one in my MBP. So essentially, I'm trying to do real-time 3D graphics utilising the HDR colour space, but I don't have the motivation to learn the bare metal Metal graphics API. SceneKit, so I figured, would allow me to explore the EDR-rendering pipeline, since to my knowledge they all (SpriteKit, RealityKit etc.) use Metal under the hood anyway. As per the WWDC '21 - Explore HDR rendering with EDR presentation, all I had to do was set a few properties on my view's underlying CAMetalLayer to enable EDR rendering for my macOS app. However, the SceneKit template in Xcode seems to be instantiating my view with a CALayer by default and when I try to replace it with a CAMetalLayer nothing gets rendered to the screen / window. Am I oversimplifying things? All I want to do is display a bunch of colours that are brighter than reference white :< If this is possible at all, I would appreciate any pointers. Thanks for reading 🙏

I use a 14pro device, and the system is iOS16. According to the instructions of WWDC22, I integrated related attributes in my program. When playing HDR video, print the value of headroom, which is usually 1 and does not change. Later, I used the official program Radiance to detect whether the EDR was activated, but the actual performance is that there is no difference in the sample picture, only occasionally there is a change. At this time, I started my own program and found that the value of headroom will change, which is greater than 1. But I personally feel that the probability of this kind of EDR being activated is relatively small. Is this a system bug? I am very confused, because according to the documentation, the amount of code to enable EDR is actually very small, and it seems very simple.