Hi, I have been trying to capture the EXIF metadata using JS from the images while selecting them in a web-app using simple file/photo picker. There's an option to adjust the original datetime for any image in iOS photos app and that's where my query starts. Whenever and image with adjusted date is selected in the browser using the photo picker, the image being given to the browser contains the adjusted date as the original date without any metadata tag containing the original timestamp from the image. Is there any way to capture the original timestamp in a web-app from the image even after it's timestamp is adjusted in IOS photos app? Also, if I may ask what might be the intended reason for this functionality since I could not get hands on something concrete and convincing about this, specially considering that we are able to adjust the timestamp to a value way ahead in the future as well. Any help and support is highly appreciated!

Hi everyone, I’m working on a camera app as a learning project and have reached a point where I’m trying to better understand the intended architecture for Live Photo capture using AVCapturePhotoOutput. The app currently supports: Live Photos Depth data Location metadata Multiple lens presets on a virtual multi-camera device Everything is working well, but I’m now thinking about capture throughput and rapid shutter presses. Right now, my implementation is fairly conservative. I wait for a Live Photo capture to finish processing and importing before allowing another capture. This is reliable, but it doesn’t feel particularly camera-like when compared to Apple’s Camera app. One observation from field testing caught my attention: I took a Live Photo, immediately switched lenses, then took another Live Photo. When I viewed the first Live Photo later, the movie portion included the lens-switching actions that occurred after I pressed the shutter. That made me realize that I may be thinking about the capture lifecycle incorrectly. My questions are: When using AVCapturePhotoOutput with Live Photos enabled, what is the earliest point at which a capture can be considered “safely secured”? Is it expected that apps wait for PhotoKit import to complete before accepting another Live Photo capture request? If supporting rapid sequential shutter presses, is the recommended approach to queue capture requests and process them one at a time? Are there any best practices around lens changes or camera reconfiguration while a Live Photo is still being captured or processed? I’m not looking for details about the implementation of Apple’s Camera app. I’m mainly trying to understand the recommended approach when working with the public AVFoundation APIs. I’d appreciate any guidance, documentation references, or examples from developers who have worked through similar problems. Thanks!

Providing a response and feedback to this: https://origin-devforums.apple.com/forums/thread/827311 and https://developer.apple.com/forums/thread/827043?page=1#889020022 I have a created a feedback/bug report with ID FB22823733 Feedback Report: I have created a feedback report as well like recommended with this ID: FB22823733, with more elaborate images of my implementation, also see here More clarity: Yes, this is for an iOS app(iOS 18+) but testing and debugging on Xcode(MacOS 15.7.7, M4 24GB), which traps or hangs on getting to [PhotogrammetrySample] even while using the lazy sequence and the contentsOf as specified in your docs. I also tried using the PhotogrammetrySession folder run but its still failed with : CoreOC.PhotogrammetrySession.Error 6 and I understand to mean alignment failed. What can be done or do you guys expose any functions that can be used to aid, or handle these internally, can't find any internally. The ObjectMasks are actually segmentation masks from an ML algorithm . To replicate try calling PhotogrammetrySession(input: [PhotogrammetrySample]) with contentsOf as captured on your documentation, even with like 30 image set or is there something I'm missing.

I'm implementing PHBackgroundResourceUploadExtension to back up photos and videos to our cloud storage service. During testing, I observed that iCloud-optimized photos (where the full-resolution original is stored in iCloud, not on device) do not upload. The upload job appears to silently skip these assets. Questions: Is this behavior intentional/documented? I couldn't find explicit mention of this limitation. If the device only has the optimized/thumbnail version locally, does the system: - Automatically download the full-resolution asset from iCloud before uploading? - Skip the asset entirely? - Return an error via PHAssetResourceUploadJobChangeRequest? For a complete backup solution, should we: - Pre-fetch full-resolution assets using PHAssetResourceManager.requestData(for:options:) before creating upload jobs? - Use a hybrid approach (this extension for local assets + separate logic for iCloud-only assets)? Environment: iOS 26, Xcode 18

Through the Photos framework, we can access (and thus backup) resources the user created in Photos, such as Adjustments.plist, AdjustmentsSecondary.data, .aae files and more. Is there any way to restore those resources back into the Photos library? (e.g., similar to dropping a combination of .heic and .mov file to restore a Live Photo)

I'm implementing a PHBackgroundResourceUploadExtension to back up photos and videos from the user's library to our cloud storage service. Our existing upload infrastructure uses chunked uploads for large files (splitting videos into smaller byte ranges and uploading each chunk separately). This approach: Allows resumable uploads if interrupted Stays within server-side request size limits Provides granular progress tracking Looking at the PHAssetResourceUploadJobChangeRequest.createJob(destination:resource:) API, I don't see a way to specify byte ranges or create multiple jobs for chunks of the same resource. Questions: Does the system handle large files (1GB+) automatically under the hood, or is there a recommended maximum file size for a single upload job? Is there a supported pattern for chunked/resumable uploads, or should the destination URL endpoint handle the entire file in one request? If our server requires chunked uploads (e.g., BITS protocol with CreateSession → Fragment → CloseSession), is this extension the right mechanism, or should we use a different approach for large videos? Any guidance on best practices for large asset uploads would be greatly appreciated. Environment: iOS 26, Xcode 18

I would like to use the memory limit during interactive editing on iOS to decrease jetsam risk. However, I'm unsure of what to set it to. Do you have a recommendation as a fraction of physical memory? I have set the extended virtual memory entitlement, but I don't know what fraction of physical memory (or more) that entitlement enables - perhaps I should use a larger memory limit for M1-based iPads?

Thanks for adding CoreML into the Apple RAW decoder. I'm excited with what it can bring. But I'm having a number of issues with it. My code base is written in Objective-C, and I'm using my custom MTKView. Now when I enabled RAW 9 support, the render is extremely slow (instant vs seconds). The UI would appear to hang with a spinning color wheel. It feels like CoreML processing is being delegated in the rendering thread, which runs on the main queue. How can I improve performance? As someone has reported, there is a black horizontal line in the middle of the image. The image that I was testing came from Fuji X-T5. If I enable EDR (Extended Dynamic Range), RAW 9 stops rendering, and will return ANE error. My app does HDR rendering of RAW files. I cannot get something like Sony A7R IV ARW image to load. Same ANE error. Is there a memory setting I need to tweak? When I render the X-T5 image, the colors appear to be overly saturated, which is different from the result of RAW 8. I cannot speak for the color rendering of other types of RAW files. I was told code base with Catalyst (and perhaps Swift) works without issue, other than being slow (except for large RAW files), but there seems to be an issue with Objective-C?

My app currently supports display and editing of RAW files in HDR mode (Extended Dynamic Range). I came across 2 issues: In HDR mode, if I am using the default boostAmount = 1.0, then some of the highlight colors will shift. Like a clear blue sky becomes a light gray / light purple sky. I've to set boostAmount = 0.0 to avoid this problem. Is this a bug or is there a way to keep the Apple colors and not having this issue? The Shadow and highlight filter does not appear to work correctly in HDR mode, I've it hooked up in the linearSpaceFilter. Would be nice if you guys can introduce a spatial aware shadow & highlight filter.

What is the difference (if any) between RAW 9 and RAW 9.DNG in terms of quality, noise reduction, and color?

Are color differences expected for any cameras? I have heard some reports, but have not seen it myself. If it's not expected, then I can get those people to file bugs.

Is the memoryLimit option mentioned in WWDC26 session 305 the same option as CIContextOption.memoryTarget? The session says the default memory target on iOS is 256 MB. What is the default memoryTarget on macOS? Also, the session recommends the Extended Virtual Addressing entitlement for interactive RAW editing. That entitlement does not appear to be available for macOS, so does Core Image automatically use a larger intermediate cache budget on macOS? Should memoryTarget be used only for export contexts, or can/should it also be tuned for interactive editing contexts with cacheIntermediates enabled? Thanks!

Thanks for adding CoreML into the Apple RAW decoder. I'm excited with what it can bring. But I'm having a number of issues with it. My code base is written in Objective-C, and I'm using my custom MTKView. Now when I enabled RAW 9 support, the render is extremely slow (instant vs seconds). The UI would appear to hang with a spinning color wheel. It feels like CoreML processing is being delegated in the rendering thread, which runs on the main queue. How can I improve performance? As someone has reported, there is a black horizontal line in the middle of the image. The image that I was testing came from Fuji X-T5. If I enable EDR (Extended Dynamic Range), RAW 9 stops rendering, and will return ANE error. My app does HDR rendering of RAW files. I cannot get something like Sony A7R IV ARW image to load. Same ANE error. Is there a memory setting I need to tweak? When I render the X-T5 image, the colors appear to be overly saturated, which is different from the result of RAW 8. I cannot speak for the color rendering of other types of RAW files. I was told code base with Catalyst (and perhaps Swift) works without issue, other than being slow (except for large RAW files), but there seems to be an issue with Objective-C?

Aside from setting inputScaleFactor and using cacheIntermediates, what are the most important things to do to get great interactive performance with Core Image (both when constructing a CIImage from URL and using CIRAWFilter). Perhaps CIImage lifetimes or how they are mutated? Alternatively, what patterns (again other than inputScaleFactor / cacheIntermediates) most hurt performance?

I render images using a tiled/LOD pipeline. The final render usually requests only the visible ROI at the current display scale, which works well for local filters. The difficult case is filters that need a lower-resolution full-extent or larger-extent input, such as guided filters, blurs, histograms/statistics, and reduce passes. If that dependency remains inside the same CI graph, ROI propagation can force larger-extent evaluation of the upstream image, defeating small-ROI rendering. My current approach is to render those intermediates in a separate lower-resolution CI render pass, cache the result, and feed the rendered intermediate back into the final graph. Is this the recommended architecture, or is there a better Core Image structure for expressing this kind of intermediate render/cache barrier without manually creating and rendering a separate intermediate graph? Thanks!

Could you provide a more detailed description of how isHighlightRecoveryEnabled affects the image, and how it differs from isGamutMappingEnabled? I’d like to explain these controls accurately to my users. Does highlight recovery run before or after linearSpaceFilter, and should it be disabled when generating scene-referred linear output? Thanks!

In WWDC20 it was mentioned that missing compileTime/renderTime (or no intermediate image with the dump-intermediates option) can indicate a cached intermediate. I have also seen renderTime=cacheHit on passes that are clearly rendering intermediates, and an actual renderTime is only properly shown on the final pass which always seems to equal the final time render time. In compileTime it says cacheMiss. Which fields should be considered authoritative for tracking intermediate cache hits versus actual rendering? Thanks!

Here are two additional RAW 9 bugs: Horizontal Line in RAW 9 decode: FB23076983 CIRAWFilter.scaleFactor not respected in RAW 9 for some RAW formats: FB23076984

In my testing, enabling isDraftModeEnabled improves decode performance for very large non-RAW images. Does it also affect decoding performance or quality for RAW images? Are there non-RAW formats that benefit more than others, or not at all, with draft mode? For non-RAW images, is it generally recommended to load them through CIRAWFilter or CIImage? If CIImage is preferred, is there an equivalent to isDraftModeEnabled for CIImage initialization? Conversely, if CIRAWFilter is acceptable for non-RAW images, how can I get the expandToHDR behavior that is available through CIImage options? Thanks!

When processing RAW images with CIRAWFilter's extendedDynamicRange, does the boost filter’s behavior change? How does boost handle extended range values and does boost have a limit before clamping? Also, in the RAW EDR case, should we still use the linearSpace filter or is it now fine to run filters post-boost (assuming the filters are linear-dependent and can run post-boost)