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

Dan C

Staff
  • Posts

    14,023
  • Joined

Everything posted by Dan C

  1. 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!
  2. 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
  3. 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!
  4. 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
  5. 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
  6. 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!
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. Apologies, I just restarted my mac to install the latest Sonoma update and then tried this again - and have since been able to replicate the issue. I believe the trigger for this depends on your cursor placement when opening the Font switcher menu from the Glyph Browser. Clicking the font name to open the dropdown menu selects the font name as highlighted text, and then using the scroll bar triggers the dialog to immediately close. Clicking the dropdown arrow to the right of the font name, then using the scroll bar works as expected. I'll get this logged with our team now, but can you please confirm @Jonopen that this issue doesn't happen for you if you open this menu from the dropdown arrow? Screen Recording 2024-03-15 at 12.33.19.mp4 @Hangman, I believe this issue will be specific to Sonoma, as macOS have changed these dropdown menus, hence the scroll bar appears differently between our recordings! Many thanks
  20. - Please stop advising other users who should or shouldn't post here on the Affinity Forums, this is the role of the moderation team and not yourself as a user. I'd recommend following the above advice and using the 'Ignore' option if you don't wish to see certain users replies in this thread. ______________ I absolutely understand, and I appreciate you aren't the only Linux user in this boat - I am certain our team will be the first to share any information or plans we have for Linux here on the Forums, if this changes in the future
  21. Thanks for your report @Jonopen! I can confirm that I have tested this using macOS Sonoma on an M1 mac mini and I'm currently unable to replicate the issue you're reporting. Therefore can you please provide a screen recording showing this issue occurring, to ensure I am following the same steps as yourself? Can you also please confirm the device you are using for input when this happens? (ie magic mouse, USB mouse, drawing tablet etc) I can confirm this separate issue is already logged with the team, and I've 'bumped' this with them now
  22. To confirm, I am a moderator of the Affinity Forums - however I'm not a Developer or manager of the Affinity apps, therefore this decision is not mine to make. I can only provide you with the information we are provided with internally, which I will do my best to summarise below: As far as I understand, we have no current plans for a Linux version, and no current intention for this to change. We unfortunately cannot comment on your 'what if' scenarios, as not only would this be purely speculative, any such major shifts in the market would likely require a large overhaul of many software companies, including Affinity - and this isn't something that I believe any company would actively plan for or consider, based on the previous market trends. I am not aware of any current 'goal' or 'criteria' to achieve before the above changes. We are currently interested in continuing to improve and update the Affinity apps across Windows, macOS and iPadOS and are not, at this time, looking to develop for the Linux market. _________ I do not wish for this post to be seen as a 'definitive answer' as to whether we will, or won't develop for Linux in the future, as this isn't something I can personally say for certain. As you may have heard before, "You never know what tomorrow brings" and similar to your hypothetical questions in your original post, no one can ever be truly certain of the future and how the ever changing landscape of software development may move our current ideas.
  23. Again, Affinity may be the trigger of this issue - but certainly isn't the cause. As above you can find out further information on your system as to the cause of this crash at kernel level. If the PC has crashed to a BSOD, all active data is lost. This is unfortunately not something Affinity can control or change. Affinity does include an Autosave file recovery system for if the application has crashed and not the OS - though this should not be relied upon as a backup method. The app will have been unable to create or retain an 'autosave' file when the BSOD occurred, as these are temporary files which are removed when the PC restarts, in order to not retain unwanted space on your drive.
  24. Hi @LeaS, Not to worry, I've moved your thread to the correct 'Questions' section of the forums. When first launching Affinity V1, you should have been prompted if you wish to transfer your custom content from V1 to V2 - provided both apps are installed on the same device. Alternatively, within V2 you can open the My Account dialog (the 'User' icon in the top right) and sign into your Affinity ID. Once signed in you will see a list of all your compatible add-on kits, including the Inksy Street Art brushes. Installing these through the My Account dialog will make the brushes available in Affinity - though please note you will need to be in the Pixel Persona to use these in Affinity Designer. I hope this helps
  25. Hi @Rafael_Morgan, Sorry to hear you're having trouble with this document. Firstly, I understand this is an important issue to you - but please do not post a thread on the forums, email the support team and directly DM a moderator simultaneously when requiring support. This can mean multiple members of the support team are trying to solve your issue across different methods (often without being aware of the others efforts) and can actually decrease the speed at which we're able to assist. Thanks for your understanding here. Secondly, the Affinity apps aren't able to cause a 'Blue Screen of Death' in Windows, as they are user-mode applications. Only kernel-mode applications (i.e. drivers) are capable of this. Applications, including Affinity, make use of these drivers which is why it appears some "applications cause BSOD", but in reality the application itself is unable to cause this, but might have been the trigger. Inspecting your document within a HEX editor, I can see that a large amount of the data within the file is missing, indicated by a '00' HEX value: It's likely due to this BSOD that the file was not written successfully and the data corruption occurred - unfortunately our team are unable to recover completely missing data, as it simply is no longer present in the file, our apologies. As above, we recommend creating regular backups of any documents you are working on, as unexpected issues may occur and are unfortunately out of our control. I would also recommend checking the Event Viewer / System logs on your PC regarding the BSOD that occurred, as this can indicate driver / Windows corruption or in worst case scenarios can be an indication of failing hardware. I hope this clears things up and our apologies once again we can't assist further here with your file.
×
×
  • 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.