Both APIs are used for writing a Gain Map HDR image, i.e, an SDR RGB image that contains an auxiliary single-channel gain map image that contains the HDR information. You can and should use an 8-bit format for this kind of image, e.g., RGBA8. The format Apple mentioned in the 2023 video (they called it ISO HDR) is for storing an HDR image directly (without an SDR representation). For that, you'd need more than 8 bit because the range of color values in an HDR image is much larger. However, it seems the industry is moving towards the SDR + gain map standard introduced by Adobe last year, which Apple is now also adopting. I would assume that they won't pursue the ISO HDR format much further, as it's not as compatible and takes more space.

Same here. ✋

A UIImage is a wrapper that can be backed by different types of images. The ciImage property is only set when the UIImage was created from a CIImage using CIImage(image:). In most cases, however, a UIImage is backed by a CGImage. If you want to create a CIImage from a UIImage, you should always use the CIImage(image:) initializer and never rely on the ciImage property.

You have to import CoreImage.CIFilterBuiltins explicitly to get access to the type-safe filters. Did you do that?

It could be a problem that you are getting the currentDrawable outside the Operation. If your rendering can't keep up with the draw requests, the operations will pile up while also holding locks on the view's drawable. Instead, you could get the view's drawable inside of the operation and discard the whole draw operation if the view is not yet read.

Have you exported the image from Photos to check with another app if the background is really white? It might be that Photos just visualizes transparency with white.

Hi J, Thanks for the response! Yes, Apple Intelligence is enabled on my Mac. When I run the app as "real" Mac Catalyst app, it's actually working. I filed FB16077581 for this, including a very minimal sample project. The following should be enough when added to a new iOS app project: struct ContentView: View { @State var playgroundVisible = false var body: some View { Button(action: { playgroundVisible.toggle() }, label: { Label("Show Image Playground", systemImage: "apple.image.playground") }) .padding() .imagePlaygroundSheet(isPresented: $playgroundVisible) { url in print("Image generated: \(url)") } } }

Feedback filed: FB16090123

There is also an API that has an optional soureImage instead of the URL: imagePlaygroundSheet(isPresented:concepts:sourceImage:onCompletion:onCancellation:)

More countries will be supported in April. Regardless, Apple Intelligence is only be available on iPhone 15 Pro and newer.

It turns out this issue is most notable for Mac Catalyst apps that use the Mac Idiom. We built a small package that provides a better alternative to the system default Image Playground: BetterImagePlayground. See screenshots on GitHub for comparison.

You can easily test Apple Intelligence features in the EU on an iPad. You just have to set the system and Siri language to English (US) and sign in with a US Apple account under iCloud → Media & Purchases. It even works with sandbox accounts! So if you don’t have a US account, you can easily create a sandbox one in App Store Connect. Also note that Apple Intelligence is available on macOS in Europe without the need for a US Apple account. You just have to set the languages to English.

There is a newish API for deferred photo processing, which makes the whole capture process seem much faster. That's probably what the Camera app is doing under the hood. Check out this WWDC session for details.

What do you mean by "calling back to the CPU" exactly? The main CPU load of Core Image actually comes from the filter graph optimization CI does before the actual rendering. And unfortunately there is not much you can do to speed this up.

Did you find the root cause and/or a solution for the problem? I can't reproduce the issue myself, but we have users reporting freezes of our apps that might be related to this issue.