Thanks. Could you briefly explain how imageByInsertingTiledIntermediate should be used here? Is it intended to replace my explicit render-to-texture/cache barrier, while still requiring me to build the lower-resolution intermediate branch myself?

Thanks, that clarifies the scene-linear behavior. It looks like your previous reply with the more detailed description of how isHighlightRecoveryEnabled affects the boost curve, GainTableMap, and gamut mapping has disappeared. Could you re-post that description?

Thanks, that helps. For a macOS app interactively editing large RAW images, would you generally recommend leaving memoryTarget unspecified so Core Image can use its macOS scaling behavior, or explicitly setting a larger value when the app knows it is rendering large images / filters with significant ROI expansion?

Thanks, that helps. Is it fair to describe isHighlightRecoveryEnabled as a behavior switch that modifies other rendering stages, rather than as an independent image adjustment? For scene-referred linear output, should it generally be disabled?

Thanks, that clarifies the RAW 9 behavior. Could you also clarify the intended API path for non-RAW images? Should non-RAW images generally be loaded through CIImage rather than CIRAWFilter? If so, is there an equivalent to isDraftModeEnabled for CIImage initialization? If CIRAWFilter is also acceptable for non-RAW images, is there a way to get the expandToHDR behavior available through CIImage options?

Thanks. What is the default memoryTarget on macOS? Also, should memoryTarget be tuned for interactive editing contexts with cacheIntermediates enabled, or is it mainly intended for export/batch render contexts?

Thanks Could you also respond to the memoryTarget questions?

Thanks, that clarifies compileTime. What should I look at in the graph dump to determine whether an intermediate was reused from Core Image’s intermediate cache rather than rendered again?

Thanks Could you briefly describe what despeckleAmount does and what artifacts it is intended to remove? What should I set it to for linear output?

I use this API from Swift, so I’d like to make sure my code handles this safely even though I haven’t seen the crash myself. Do you know which OS versions or Photos library states are affected by this nullability mismatch? For nil or empty originalFilename values, is there another source for the original filename?

Thanks, that makes sense. Does PHPhotoLibraryPersistentChangesObserver provide any coalescing/backpressure guarantees, or should I still debounce notifications and prevent overlapping fetchPersistentChanges(since:) calls? With PHPhotoLibraryChangeObserver I currently treat the callback only as a wake-up signal, debounce bursts of notifications, then call fetchPersistentChanges(since:) once after a quiet window. When migrating to PHPhotoLibraryPersistentChangesObserver, should I expect one notification per persistent history update, coalesced notifications, or just “history advanced, fetch when convenient” semantics?

Thanks To make sure I implement your recommendation correctly: my plan is to persist both identifiers, use PHObject.localIdentifier as the current-library operational identifier for normal PhotoKit interactions, and keep PHCloudIdentifier.archivalStringValue as the durable recovery identifier. If the stored localIdentifier stops resolving, I would map the stored PHCloudIdentifier back to a current localIdentifier, update my stored localIdentifier, and continue using that for local PhotoKit operations. Does that match the intended use of the identifier pair? For a visible PHAsset in the current library, should cloudIdentifierMappings(forLocalIdentifiers:) always be expected to produce a PHCloudIdentifier? If it can fail, are there known non-deletion cases I should handle besides the asset no longer existing/resolving? In that situation, should the app still track the asset by localIdentifier and retry cloud identifier mapping later, or should the asset be excluded because it cannot be given a durable PHCloudIdentifier?

Thanks. Resolving the security-scoped bookmark works for triggering the mount, so I mainly wanted to confirm this was the recommended approach. The only issue I encountered was that I had to resolve the bookmark on a detached task as it was blocking while the network volume mounts.

Since generationIdentifierKey is tied to the inode, should I assume that after safe-save/rename-over the replacement file will have a different generationIdentifierKey even if the resulting file contents are byte-identical to the old file? In which cases is UF_TRACKED normally set on a file?

Thanks, that makes sense. In my app the user first moves items into an app-level trash, and “empty trash” already requires confirmation. Based on your answer, I’ll treat Finder Trash as best-effort: attempt trashItem first, fall back to immediate deletion if it fails, and only remove the database entries for files where one of those operations succeeded.