Jump to content
You must now use your email address to sign in [click for more info] ×

Tom Lachecki

Staff
  • Posts

    121
  • Joined

Posts posted by Tom Lachecki

  1. 9 minutes ago, debraspicher said:

    This is helpful for y'all as well because if we import everything instead of cherry-picking imports, it will offer as much opportunity to showcase bugs across various use cases. So while it's a bother, do add in as much portability as feasible. One of us will have some weird setup that will cause mayhem... no doubt... (edit) so while the convenience is very welcome, it makes our day-to-day usage in beta much more realistic...

    Yes indeed :) 

  2. 11 minutes ago, garrettm30 said:

    Curiously, the message that popped up stating “additional disk space required” showed a different amount. The first time, it showed around 176 Megabytes, while the second time it showed 916.8 MB.

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

  3. 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.

  4. 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.

  5. 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.

×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.