To enable EDR rendering, all we do is to set the colorPixelFormat to MTLPixelFormatRGBA16Float (note: RGBA, not BGRA) and wantsExtendedDynamicRangeContent to YES. We don't change the colorSpace since it is already set to extended linear sRGB when setting the other properties. As soon as we render pixel values outside [0...1], the screen switches to EDR mode and the potential and current HDR headroom adjust accordingly.

Also filed as FB12119140. Thanks!

I think this is a design decision from Apple's side. You are not supposed to set the pixel brightness to more than 8x the current brightness of the screen. Otherwise, you could "blind" the user with very bright pixels, even though they set the screen to be dim.

Please provide a bit more context, e.g., what is the byte order info and pixel format you are setting?

Every time you render a CIImage with a CIContext, CI does a filter graph analysis to determine the best path for rendering the image (determining intermediates, region of interest, kernel concatenation, etc.). This can be quite CPU-intensive. If you only have a few simple operations to perform on your image, and you can easily implement them in Metal directly, you are probably better off using that. However, I would also suggest you file Feedback with the Core Image team and report your findings. We also observe a very heavy CPU load in our apps, caused by Core Image. Maybe they find a way to further optimize the graph analysis – especially for consecutive render calls with the same instructions.

Filed as FB12389932. Thanks!

Can you please upload some screenshots to show what "corrupted" means? Thanks!

Hmm, this is really hard to debug without seeing the actual filters. But if I would need to guess, I'd say the implementation of the ROI callback (passed when calling the CIKernel) is wrong. I can also recommend using a MTKView for displaying a CIImage instead of using Core Graphics. There is a sample from Apple showing how to do that.

Filed as FB12901757. Thanks for looking into this!

FB12914857. Thanks for looking into this!

Also filed as FB12966266, including a demo project. Thanks for looking into this!

Filed under FB13121690. Thanks for looking into this!

You can also access the tip through the configuration. I think you can simply add a button to your tip layout that invalidates the tip when tapped: Button(action: { configuration.tip.invalidate(reason: .tipClosed) }, label: { Image(systemName: "xmark") })

Filed as FB13168973. Thanks!

The issues seem to have been fixed on iOS 17.1 beta 2. Thanks a lot!