Hi,it contains the image data, and the first 2 bytes are the red pixel, as a 16bit unsigned integer. Next is red, then green, etc.Min/max raw values are specified in the DNG dictionary (in particular, min is not 0). Note that there are also gains & other metadata, and you should setup a (pretty complex) chain to obtain accurate colors in a specific colorspace.Raphael

in turn, virtualDeviceConstituentPhotoDeliveryEnabled is only supported with dual/virtual cameras, which is why I was asking this question in the first place. A virtual camera is not what I need, as they have limitations of their own (can't be fully controlled, can't shoot in RAW…), and I'm only interested in a single sensor data anyway.I guess this is a limitation of the current API. So please take my feedback (FB7377814) as a feature request. Note that use cases are real, and currently can only be implemented (without workaround) on other platforms. Thank you.

Exact same problem on Xcode 12.0 beta (12A6159). Fails very early in the target that uses an XCFramework, and I checked, there's no duplicate for that file (only referenced once). I suspect a bug in the build system. My log for reference: ProcessXCFramework /xxxxxxx/xxxxxxx.xcframework (in target 'xxxxxxx' from project 'xxxxxxx')     cd /xxxxxx     builtin-process-xcframework --xcframework /xxxxxxx/xxxxxxx.xcframework --platform ios --target-path /xxxxxxx/Build/Products/Debug-iphoneos error: “xxxxxxx.h” couldn’t be copied to “Debug-iphoneos” because an item with the same name already exists. (in target 'xxxxxxx' from project 'xxxxxxx')

Just tested Xcode 12.0 beta 2 (12A6163b), same problem.

Exact same issue, and ran through the exact same steps. Got the "Install macOS Big Sur Beta" app (beta 9), but it fails when double-clicked with this alert: "This copy of the Install macOS Big Sur Beta application is damaged, and can‘t be used to install macOS." I'd appreciate a comment from someone at Apple on how to update the DTK from 20A5299w to latest beta (currently 9), as there are all kinds of horror stories with bricked devices that I'd like to avoid (DFU modes, etc.). If there is a recommended procedure, please let us know so that we can get back to work. Thanks!

We're having the same problem with our watch app with recent watchOS10 betas (couple weeks), that is, watch app fails to receive locations as described in first post. Looks like location authorisation status gets corrupted for some reason. We've isolated this problem into a separate project (iPhone + watch app), 100% reproducible. A standalone watch app does not show this problem. On our way to file a bug report too.

watchOS 10 RC update. I had my Apple watch on 10 beta 8, with the companion app stuck in the location problem described above. Upgraded both iPhone & watch to the RC releases, uninstalled the apps, and installed & run iPhone app from Xcode, went to watch app and installed it on the watch, started there. Same problem, watch app still stuck in the location request. Killed+uninstalled both apps, reset location permissions on iPhone, restarted the iPhone (not the watch), did the installation process again (Xcode run to iPhone + watch app to reinstall on the watch), and it worked. I noticed that for companion apps, location permissions are listed on the iPhone (Settings > your app, location is first line) & not on the watch itself. When the problem occurs, that first location line is absent. My hypothesis is that something breaks the location permission of our app that reinstallation of both apps can't fix & a global reset of location permissions (+ Face ID access for all apps) is the only way out. About what breaks it, I don't know. It seems that for companion apps, the iPhone is handling the permission for both devices. I suspect that maybe installing a new version of the app on iOS from Xcode while the watch app is running might be cause, or something similar (like running the watch app directly from Xcode with the iOS still at a previous version). It is not clear if that can occur to end users that only install through App Store (no Xcode run). But if you happen to create the bug on your device, no app uninstall, no TF install, no App Store reinstall can fix it by itself. Not too sure where to go from here. Would be interesting to know (for those with shipping apps) whether end users report such issues or if it is limited to those who run it at least once through Xcode. It is also possible that the problem won't reappear starting from the RC (did not experience it yet - will report if it's back).

OK did some additional testing here. We can reproduce the problem 100% using Xcode in a separate (simple) sample app. Our app isn't shipping yet, so unsure about App Store installation (see discussion below). Using Xcode 15.0, watchOS 10.0 / iOS 17.0 (all GM versions). Corruption procedure with app absent from both devices, from Xcode, do a run directly on the watch. This also installs the iOS app as a side affect. on the watch, auth status shows 0 (NotDetermined) requestWhenInUseAuthorization() does not show the auth sheet From this, auth state is corrupt and there's no way out (no combo of uninstall / reinstall both apps & device reboot will help) - it stays broken unless you apply the reset procedure below. Other working companion apps are not affected, just this particular app. Reset procedure uninstall the iOS app (this automatically uninstalls the watch app) iPhone > Settings > General Transfer or Reset > Reset > Reset location & privacy reboot both device reinstall with iOS first & keep it on iPhone at all times. From that, any kind of installation of watch app will work (Xcode run, watch app installs) & permission problems won't re-occur. What remains unclear to me at this time as our app isn't shipping yet: other people here mentioned it happened on TF/App Store build. Did that happen for devices that were corrupt by the above procedure first, or for fresh App Store / TF installs? I suspect this could occur if the watch app is installed directly on the watch (which triggers iOS) as opposed to installed from iPhone's watch app initially. The reset procedure is not viable (ok for development, not for end users as it implies privacy sheets for all apps on the device). Another remark, I did try to reproduce it with shipping companion apps (could not so far - if you can please tell), but I noticed Strava would request all permissions on the iPhone side (watch app is blocked in modal state until that is done by user on the iPhone), which could be a workaround to ship a companion app if App Store release is also affected by this issue.

good to know there's some awareness of the problem. See also https://developer.apple.com/forums/thread/736785 Can we get an ETA of the update / expected OS version number that solves it? We've been stuck in that problem for over 7 weeks & counting, and people on that thread report that it also affects users with App Store & TF builds. It also appears to affect Apple's own apps, and as such is a major issue for all location-based companion watch apps. If you could please give us additional information about the release so that we can plan our development efforts accordingly. Thank you for your help.