Dan C

Hi @JamesA, Thanks for your report! This is expected behaviour when editing a Gradient, the bounding box will not be shown for the object the gradient is applied to. After editing the Gradient, switch back to the Move Tool (V) and you will see the bounding box for the object return. If you're still having trouble here, a screen recording showing your exact steps would help our team to assist further

Thanks for providing this file for me! Whilst our team performs tests with this document, can you please try unticking Hardware Acceleration at the bottom of this dialog, then restart the app as prompted. Once restarted, try zooming in your document once again and use the app as you usually would - does this stop the crashing from occurring please?

Hi @Roderic, Welcome to the Affinity Forums Thanks for your report! I can confirm I'm able to replicate this here- it appears as though the application is expecting the procedural texture to use 'RGB' based formulae, even when the UI is set to French language and shows canal vert : 2024-03-19 12-47-37.mp4 I'm a little unsure if this is expected behaviour at this time - as I can see why a user would expect 'RVB' to be used based on the channel options in the Procedural Textures dialog, however as Procedural Textures also support custom variables (including the letter 'V'), I can partially understand why the behaviour is as shown above. Therefore I'm going to raise this with our development team now, and log it as a bug if they confirm it as such. In the meantime, if you use 'G' in place of 'V' in your equations, you should find this works as shown in the tutorial!

Thanks for confirming that for me - I'm unsure which options are available for you within Affinity Edit > Preferences > Performance as it doesn't appear as though you have included a screenshot of this, however I'd recommend the following: Download the latest drivers for your NVidia 4080 (https://www.nvidia.co.uk/download/driverResults.aspx/221884/) Download the latest drivers for your Intel 14900k integrated GPU, aka UHD Graphics 770 (https://www.intel.com/content/www/us/en/download/785597/intel-arc-iris-xe-graphics-windows.html) Download and run 'DDU' to remove any previously installed GPU drivers on your system (https://www.guru3d.com/download/display-driver-uninstaller-download/) Once your system has restarted from uninstalling the drivers through DDU, install both the NVidia and Intel drivers Restart your system after installing both of these latest drivers Open Affinity Photo and navigate to Edit > Settings > Performance Set the Renderer to the NVidia 4080 GPU Untick Hardware Acceleration if it is currently enabled Restart the Affinity app Try running your HDR merge once again Does this stop the crashing from occurring please?

Hi @Alcahest, Welcome to the Affinity Forums Not to worry, your English is certainly understandable - but if you wish to post in your native language, then you are welcome to do this and our team can translate our replies. Under Affinity [Photo/Designer/Publisher] 2 > Settings > Tools (macOS) or Edit > Settings > Tools (Windows) you can enable the Synchronise Tools between documents option; However unfortunately this isn't currently supported for all tools, including the Selection tools - such as the Marquee Selection being set to the 'Add' mode, therefore this will be document independent at this time. This is logged with our development team, to add support for these selection tools to synchronise across documents in a future update, therefore I'll be sure to add your 'vote' to this now. I hope this clears things up!

Hi @AnonD, Thanks for your report! It sounds as though you are experiencing the below, known issue - Hopefully you should find that using Window > Zoom correctly returns the full Affinity app to your main display, when unplugging from your external monitor. Our team are working to fix this for a future update, as we would expect the window to automatically resize based on the currently available display(s). I hope this helps

Our team believe this to be improved within the V2.4 update for Affinity - though we're aware it is not yet completely resolved. The above Window > Zoom workaround can still be used in the meantime, but we ask that if you are still experiencing this issue within V2.4 to please create a new thread with as much information regarding your setup as possible, so our team can track this issue more closely with our developers. Many thanks for your continued patience and understanding here whilst we work to resolve this issue!

Hi @ECA, Welcome to the Affinity Forums You can download the V1 versions of the Affinity apps on macOS from the Affinity Store from the below links: Photo - https://store.serif.com/update/macos/photo/1/ Designer - https://store.serif.com/update/macos/designer/1/ Publisher - https://store.serif.com/update/macos/publisher/1/ Unfortunately however it's no longer to possible to purchase new licenses for V1 - so if you don't already have a product key for Affinity Photo V1, the only option would be to upgrade to Affinity V2, once you have a compatible macOS device. I hope this clears things up!

There's no direct option for this within the Affinity app - however you can copy your Adjustments.propcol file from one system to another to transfer these. On Windows, these can be found in the following folders: Affinity Store (MSIX) & Windows Store: %USERPROFILE%\.affinity\Common\2.0\user\ Affinity Store (EXE) : %appdata%\Affinity\Common\2.0\user\ On macOS, this file is found under: ~/Library/Group Containers/6LVTQB9699.com.seriflabs/v2/user/ I hope this clears things up

No problem at all! I'm not previously familiar with RGB565 but I can verify that Affinity has always displayed '16bit' HEX values as #RRRRGGGGBBBB on both macOS and Windows - so I understand this to be the expected behaviour. I see, that's definitely interesting! Your maths appears to check out in this regard, though the app should not be displaying the HEX with this percentage conversion at all - as it simply shouldn't be possible to set RGB HEX to percentage. I wouldn't wish to give you incorrect information here - it certainly appears as though this is what is displayed, but as the behaviour itself is fundamentally unexpected/unsupported, I can't be certain that the 16bit value provided is correct or definitively represented of the colour value used in the file and therefore wouldn't want to confirm that directly, whilst the above logged issues still exist within the Colour Studio. I can verify that AFD-6355 was initially closed by our team as resolved in 2.1.0.1705, but later reopened for 2.1.0.1709 as a different method was found to cause these incorrect values to display in the Colour Chooser. Note 'AF-6355' is now converted to 'AF-2452'. I'll be sure to 'bump' this with the team for 2.4 now, as I expect the Sliders above the waterfall in the Colour Chooser to be displayed using your Colour Studio settings - though the values on the right side are unaffected by this, and should always be displayed as 8bit for RGB and Percentage for CMYK. This is the behaviour shown on Windows: AFD-6356 is a less encompassing version of AF-2421 - as the AFD issue was specific to CMYK, whereas the AF issue covered all Colour Modes in the Colour Studio. I'm unsure why AFD-6356 was missed by our team (and by me when searching for this issue internally ) however I can confirm that AF-2421 has already received an internal fix, which is awaiting our teams testing and therefore should hopefully be resolved in an upcoming update!

Thanks for verifying that for me and the screenshots provided - my apologies for the delays here! My colleague has further tested this on their M2 machine and we're still unable to replicate the exact behaviour shown in your recording, but I'm certainly glad to hear that you have been able to improve the performance on your device and are no longer experiencing this with brush previews disabled. I'll be sure to keep a note of your report however, should we see other users reporting this issue in the future it may help to determine a 'common link' or cause for this

I can confirm that the Grid update issue is specific to Windows only, however I would expect both the Spacing and Gutter input fields to offer sliders on macOS, as shown for Windows & therefore I'll get this logged with our UI team now - thanks for raising this

Hi @Habin_photo, Welcome to the Affinity Forums Sorry to hear you're having trouble! I can confirm that I've been able to HDR merge using the sample images you've provided without issue: though I did have to change the image format from .jfif to .JPG for these images to be accepted into the dialog: (this appears to be a Chrome bug, as I can see your images were uploaded in the .JPG format, so please ignore the above) I can see you are using the 'WARP' renderer setting, meaning Affinity is using your CPU and not your GPU to calculate and display the canvas, which isn't something we'd usually recommend long-term. If you expand the Renderer list, what options are shown please? For example; Many thanks in advance!

I agree, my apologies as I initially thought this was part of the trigger for this issue, but further testing when logging the issue with our developers indicated this was not necessarily required to cause this - therefore I edited my above post to remove this section. Though I could have made that clearer within the post itself, thanks for helping to confirm these findings

Hi @Mal_Rempen, Welcome to the Affinity Forums & sorry to hear you're having trouble! I'm not seeing the same crashing occurring here currently, though I do appreciate you have mentioned this does not occur for all documents, or always consistently in the same file. Are you able to attach a document here where this crash has occurred previously? (even if you cannot directly trigger the crash in the file now). If you'd like a private upload link for this, please don't hesitate to ask. Secondly, can you please navigate to Affinity Designer 2 > Settings > Performance and provide a screenshot of your settings here for me? Your crash report provided appears to indicate the app is crashing when trying to render raster elements on screen (likely the mipmaps Affinity uses to display your canvas at different zoom levels), which is consistent with your report - though unfortunately doesn't indicate much more information than this. Many thanks in advance

Thanks for your report @anto! I'm only able to replicate this issue using the Sofia Sans font, with the Black variant - using other fonts, or other variants of Sofia Sans seems to work as expected for me. Equally, as you've shown in your recording this seems to require certain glyphs to trigger the issue (seemingly 'X', as "TEST" exports correctly but "TEXT" does not), and testing at different font sizes and stroke widths seems to show this does not always occur: I'm getting this logged with our development team now

Hi @Gerarbara, Sorry to hear you're having trouble! I'm not seeing the same issue here currently - are you able to provide a quick screen recording showing this for me please? If you're unsure how to take a screen recording, please check out our FAQ linked below - Can you also please navigate to Edit > Settings > Performance and provide a screenshot of your settings here for me? Many thanks in advance

Hi @NotMyFault, Thanks for your report! I would expect the Opacity Variance setting to affect the Curve Start / End caps - as you're seeing with Size Variance, therefore I've logged this as a bug with our development team now. I hope this helps

AFAIK it's the first selected curve which will be converted to a selection in this instance, however; I understand this to be a V1 iPad issue only, as in V1 Desktop or V2 Desktop/iPad you're unable to convert the multi-selection of Curve objects to a Selection, which is the correct & expected behaviour

Hi @Nadar, Sorry to see you're having trouble! It's hard to tell from your screenshot - but if you have 2/multiple separate 'Curve' objects selected when using the 'to Selection' option for the Pen Tool, only one of the selected Curve objects will be converted, which can cause the selection to appear differently from the Curves you have shown. Is this happening for you in any document, or only the one shown in your screenshots? If this is only occurring in the above file, can you please check the Layers Studio and confirm how many Curve objects are shown/selected here please? Many thanks in advance

Hi @Peterey, Thanks for your report & screen recording provided! I can confirm I've been able to replicate this issue here and have logged it with our team now, to be resolved ASAP. I hope this helps

Hi @Jakes, Welcome to the Affinity Forums & sorry to hear you're having trouble! Unfortunately I'm not seeing this issue occur here currently - can you please confirm for me: Does this happen when exporting any file to HDR, or only a certain one? Are you able to export to a different location (such as directly to your desktop) without the app crashing? Are you able to export to a different format without the app crashing? Can you please navigate to Edit > Settings > Performance and provide a screenshot of your settings here for me? Many thanks in advance

Many thanks for providing that for me! I can confirm that I'm seeing the same issue here and checking with our team it appears as though this has since been logged with our development team to be resolved ASAP. I'll be sure to 'bump' this development report with your thread now, our apologies for any inconveniences in the meantime

Hi @Hangman, Thanks for your report! I can confirm that I've been able to identify a few bugs here - as the behaviour differs across platforms. Firstly, to verify, the expected behaviour of the Colour 'Wheel' option should always display the HEX value in 8bit, regardless of the 'Slider' settings. This means that if you change your 'Slider' RGB HEX setting to 16bit, it's expected for you to see different HEX values when selecting the same colour, using the 'Wheel' vs the 'Sliders. If you'd like to see the 'Wheel' option offered with a 16bit display of the HEX value, this would make for a good feature request. However, I am able to replicate the following on macOS, which is both incorrect and inconsistent with Windows: Colour Studio Colour Sliders Change mode to RGB Using the menu, change this from 8bit to 16bit view Change mode to RGB HEX ⚠Note this is now also using 16bit Colour Studio Colour Sliders Change mode to RGB Using the menu, change this to Percentage view Change mode to RGB HEX ⚠Note this is now also using Percentage, which shouldn't be possible - the HEX values are also incorrect due to this. Colour Studio Colour Sliders Change mode to RGB Using the menu, change this from 8bit to 16bit view Change mode to CMYK ⚠Note this is now also using 16bit, which shouldn't be possible It appears as though the setting 'follows' the Colour mode on macOS in 'Slider' view. On Windows, each Colour mode option has a setting independent of the other colour modes, which is the behaviour I'd expect on macOS. I believe this is the crux of your above report, as Colour modes are being displayed incorrectly in 'Slider' mode, though my first point still applies in regards to the 'Wheel' view and setting RGB HEX to 16bit in 'Slider' view. In my testing, I also found the following issues on Windows: Colour Studio Colour Sliders Change mode to RGB HEX Using the menu, change this from 8bit to 16bit view Change mode to RGB Change mode to RGB HEX ✔Note that 16bit setting is retained, as expected Colour Wheel Colour Slider ⚠Note this is now reset to 8bit Colour Studio Colour Sliders Change mode to HSL / LAB Using the menu, change this from 8bit to 16bit view or Percentage ✔Note that colour values do not change ⚠Note these Colour modes should not offer 16bit / Percentage menu options Colour Studio Colour Sliders Change mode to LAB / Greyscale Select/pick any colour ⚠Note the colour value is displayed with 3 decimal places I hope this helps & if I've missed or misunderstood part of your above report, please don't hesitate to let me know

Hi @Bebebebenny, Thanks for your report! I do not mind admitting that I'm not personally technically knowledged enough in this area to directly confirm if this is a bug, or expected behaviour when using the Halftone Filter with the settings shown above. However, I can certainly understand why you would believe this to be incorrect based on the rendered results, therefore I'm getting this logged with our development team for further investigation and consideration as to how this filter should react, given the settings provided. I hope this helps