NathanC

Hi @Paul Mc, As far as I'm aware, the official PDF 1.5 (and later PDF versions with layer support) specification details that Layers must have a name, so this would explain why you're not seeing these group-converted layers in the exported PDF since they'll be getting ignored by the PDF exporter. This isn't documented anywhere within our help, but perhaps there could be a clearer reference to this labelling requirement in the PDF export settings, I'll raise this with the docs team.

Hi @ARTGIRLJENNL Apologies for the late response, Could you confirm if you're still experiencing these export crashes after updating to the latest version of Photo 2 (v2.6.2)? If the crashes persist please supply the following: Copy of a file where you have encountered this issue Screenshot of your selected export settings Copy of recent crash report after encountering this issue. Many thanks

I wouldn't be able to confirm a fix version, but this thread is tagged with the bug ref, so if there are any further updates the Affinity info bot will automatically reply here. I've updated the issue internally to reflect that the issue is still outstanding in 2.6.2.

Hi @Natters apologies for the delayed response, The events in the crash report's backtrace indicate a problem with a Dropbox data source path. while the file itself may no longer exist on Dropbox, if there are links that are still resources still linked to a Dropbox location, this may be triggering the crash if there's a syncing problem. If possible, I'd advise moving these resources off Dropbox to a local directory and then re-linking via Resource manager to this new directory, and then confirm if the crashes persist. I'm also seeing a reference to a Preflight resource check just before the Dropbox call, so it may also be worth changing preflight from a Live to Export/Never check just temporarily.

Hi, @JustMeTrying apologies for the late response, The issue referenced in your linked thread (AF-564) is specific to grouping objects with constraints applied triggering an offset transform position when the constraint objects exist on an artboard. However, in this bug's scenario the group can be set back to it's original position, that doesn't appear to be the case for your document. Based on the provided information it's not entirely clear what initially triggered these objects to shift to these extreme positions in order for us re-produce this issue, and I've not had any success in duplicating this using constraints and symbols so far. If you're able to identify the stage at which the constrained objects offset to these positions and any steps required to re-produce the issue from scratch, this would be helpful. If not if you could supply a copy of an affected file we can investigate further. I've provided a private upload link here: https://www.dropbox.com/request/AGCZaCsmksiJ1qvaL3nW Many thanks

Hi @mailstoreguy welcome to the forums and apologies for the late reply, I've replicated and logged this partial pixel offset issue with the developers, many thanks for the sample file and detailed report.

Bem-vindo aos fóruns @Amador Se estiver a ter falhas/congelamentos totais do sistema ao tentar utilizar a ferramenta, sugiro que desative a "Aceleração de hardware", que se encontra em Editar -> Definições -> Desempenho. Após desativar, feche a interface e reinicie a aplicação quando solicitado. Este é um problema que está a ser registado internamente e sob investigação. Se também puder fornecer os dados solicitados na minha publicação abaixo, isso seria útil para nós. Muito obrigado

Hi @Paul Mc, As NMF referenced above this is a known issue specific to the RTX 50 series cards with Hardware Acceleration enabled in-app, it is advisable to keep this setting disabled until the issue is resolved. I've bumped the existing issue with your report.

Welcome to the forums @KSib, This is a known issue currently logged with the developers. The bug is specific to systems using RTX 50 series cards with Hardware Acceleration enabled in-app, so it is advisable to keep this disabled until the issue is resolved. I've bumped the existing issue with your report.

Hi @BBG3, I've replicated and logged this issue with the developers, thanks for your report.

Hi @Markus Plutonika, Can you send us a copy of the specific .afdesign file where you're encountering these issues, as well as a copy of the exported PSD file(s) for comparison so we can investigate further? I've provided a private upload link below. https://www.dropbox.com/request/Pv5YK7JXcTbDSkQzSVAt Many thanks

Bienvenue sur les forums @fred10 Afin que nous puissions approfondir nos recherches, pourriez-vous nous fournir une copie d'un document où vous avez rencontré ce problème lors de la pixellisation d'objets vectoriels, ainsi que des captures d'écran illustrant l'apparence avant/après la pixellisation sur votre appareil ? Nous pouvons vous fournir un lien de téléchargement privé si nécessaire. Merci beaucoup.

Welcome to the forums @Scientist, Unfortunately, the file is not recoverable by any standard methods available to us, so it will need logging with the developers for further investigation into what's caused this issue. It's possible that the team may be able to recover your file, but this isn't guaranteed or something we're able to provide a timeframe for. If you could answer the questions in the FAQ below to the best of your knowledge we can then get this logged: Many thanks

Welcome to the forums @Limmuel June, Can you provide a sample document where you can re-produce these issues with transform origin? Try clicking anywhere within the Document/Canvas Window so it's in focus and try these shortcuts again. Here's a few things to check/try: Close any unnecessary applications that are running in the background, and also close any document tabs you're not currently working on in-app. In Edit -> Settings -> Performance ensure that your RAM usage limit is set to the same as your system's RAM capacity. In Edit -> Settings -> Performance try toggling Hardware Acceleration off, restart the app and compare.

Hi @Alex_M, I believe I have isolated the issue down to the Masks. Many of the adjustment inherent mask layers are corrupted when the RGB/16 colour conversion takes place causing these blocky areas to appear when the mask corrupts. This is a known issue currently logged with the developers, I've bumped the issue with your report. Before RGB/16 conversion (Mask Isolation view on Levels): After:

Welcome to the forums @hunterr, Just for 100% clarification, can you confirm the specific import method you're using when encountering this document naming issue? Open Document Import Document Import From Photos I'm assuming it's 'Import Document', we've recently logged an issue relating to PSD losing it's file name using this import method, so it's likely related.

Hi @quig451, I'm observing the same unusable 32 bit file in Photo 2. Just to confirm before I log this, what TIFF export/save settings were defined in Pixinsight to generate this file?

To workaround the output profile bug I'd recommend keeping the RAW engine on serif labs, but the help guide linked below gives a comparison of the two engines for your reference. https://affinity.help/photo2/English.lproj/pages/Raw/raw.html

Thanks @larafino, It's an unusual problem specific to Canon .CR3 RAW files and the Apple (Core Image RAW) Engine, if you change this to the 'Serif Labs' engine and then close and re-open your .CR3 file you should then be able to edit the output Profile Pre-develop. It appears to be fairly inconsistent as to whether it's possible to change the output profile with Apple Core's engine selected, on Nikon's .NEF files I can change this, but on a .DNG or .CR3 it's not possible. I'll get this logged with the developers for further investigation, as this appears to be a regression over 2.5.7.

Hi @LEB, Was the text insert that periodically changed any sort of dynamic text field like a running header or cross reference? Can you provide a copy of the document, or a sample document where this issue can be replicated? I've added an optional private upload link below. https://www.dropbox.com/request/jOeoKDMCLkYL2xFKBh1P Many thanks

Welcome to the forums @Synrey, This is a known issue with resource manager on larger files currently logged with the developers, I've bumped the existing issue with your report.

Hi @larafino, Could you upload a copy of a RAW file where you've encountered this issue? I'm unable to replicate this on an identical M1 Mac Mini running Sequoia, the profile option and ability to change the output remains accessible on all RAW files I've checked. If you could also provide a screenshot of your develop assist settings that would be helpful. Thanks!

Hi @Paul Hodson, This is an issue we're currently aware of and investigating internally. The issue appears to be isolated to certain devices with OpenCL enabled in Photo 2 and the Windows 11 24H2 update. If you disable Hardware Acceleration under Edit -> Settings -> Performance and then restart the app, this should hopefully prevent the system freezes. If you could also provide the information requested on my post below we would be grateful. Many thanks

Hi @ronnieVB, Layer effect parameters cannot be adjusted in embedded documents, this is a known issue on Windows currently logged with the developers that I've bumped with your report. As a workaround, if you switch the policy from embedded to linked, you should find the FX can be adjusted in the linked file.

Hi @Alex_M, I can see in your signature your system has an RTX 50 series card, there is a known issue with OpenCL and 50 series cards causing significant raster corruption issues while working in-app and exporting, best to keep OpenCL disabled until the issue is resolved as it can produce a range of unexpected issues specifically on 50 series cards.