Tom Lachecki

Yes indeed

We'll check into this.

The amount of space currently used by your beta content, which will be deleted, is taken into consideration for this calculation.

As I say, this is really more of a Photoshop & Camera RAW setting (and you can turn it off in Camera RAW) for any file that has, at some stage in its past, already been touched by such software. But we'll consider an addition to our "Embed Metadata" checkbox to allow you to strip out only the Camera RAW metadata from exported JPEGs, so that you can stop this Adobe feature from being triggered.

The unsandboxed app data paths have changed in the 2.1 beta so it's possible there's a bug here in not picking up the original 2.0 paths from an unsandboxed installation.

The migration option is just for content (assets/brushes/etc) and data like document presets. It won't be able to migrate studio layout.

Hi @Ldina, Photoshop opens processed files in Camera RAW by default if an XMP sidecar file is present. So one thing to check is that you don't have a sidecar in the same directory, left over from your work with the DNG in your Adobe software. If that doesn't solve it, it is possible that Photoshop is picking up on some Camera RAW develop metadata in the JPEG; if so, it may be appropriate for us to start automatically stripping that out on export, but it's something we'll need to investigate further. You can also change your Camera RAW settings to "Disable JPEG Support" entirely.

We currently have no plans to implement it in reverse - this would be problematic in many cases. But I appreciate it would be useful!

Thanks Mike that's interesting; could be a data file got missed out. Which platform is this on?

Theoretically it should be available if any v2 release app is installed; it doesn't have to be the same app.

This is a common shortcut with some graphics drivers to alter the rotation of the screen; it isn't Affinity doing that I recommend checking your nVidia/AMD/etc settings.

It will be fixed in a forthcoming update. The reason it appeared to work in Affinity Photo 1 is that we did not have a proper date/time widget with user input until Affinity Photo 2. We were just showing the timestamp without any timezone information at all. It would appear to be correct, but if you went on holiday you'd soon realise that your computer local time was not being taken into consideration properly then either. Times in exported data would also have had the offset. It's just much more obvious now: the user input is interpreted as being in local time for convenience, so the whole widget must be timezone-aware.

Thanks - it's not setting the EXIF timezone information, but it's setting some data in the Makernotes we can start using.

Yes please

We'll take your feedback on board

This has been discussed a few times, and although I can see where you're coming from, I think it sets a precedent of marking any fonts with licensing restrictions, which isn't practical. As Walt says, most - all?! - fonts have their own varying licensing requirements, which it's already your responsibility to meet. Suddenly any fonts without this new mark would sort of appear to be unrestricted, which is not likely to be the case. It also doesn't really tell you anything that you need to know during day-to-day use, while taking up space in doing so. The Save As Package dialog does indicate that the font will be embedded in a restricted fashion, if that helps!

What exactly happens?

Heh, not a bad idea. We'll start with collapsing the space left over by hidding preferences not relevant in the current app, and see how it goes

We have something brewing for this

Thanks; that's a regression! These will be added later. 👍

Thanks! It does indeed appear to have some useful information in the Makernotes, so we should be able to start applying that to the Date Shot field during parsing (when it's missing its own timezone indicator), then everything will be fine.

It doesn't, but only the new editable date/time widget in v2 shows anything in your local time. v1 just parroted what you're seeing in the Detail tab - i.e. "whatever the camera told us" without any maths

Please provide the image in question so we can investigate. But from the Detail tab, which provides a "raw" view of the embedded information, it looks as though the EXIF data does not contain any timezone information, so we have to treat it as UTC (there is no better general solution). The time is then shown adjusted for your timezone in the editor. As such, this would be behaving as expected. However, it's possible that your Canon camera is putting timezone data someplace in the Makernotes that we don't currently parse, which may be fixable...

This ought to be fixed in the next build, thanks

This ought to be fixed in the next build, thanks