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


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Sorry, I was quoting the dimensions of an incorrect PNG. The original base64 raw data is indeed a 465x464 bitmap. Thank you for spotting my error. I have one last question regarding the px setting for the Guassian Blur within Designer. You previously recommended 3.7px to approximate the original SVG: <feGaussianBlur inkscape:collect="always" stdDeviation="1.67083" id="feGaussianBlur12229" /> Did you get the 3.7 value through a conversion factor or just eyeballing the gradient smoothness?
  2. I think you're misunderstanding, I know that the nominal resolution is ~469 × 487 px. I am referring to the raw, embedded raster data in the original SVG: xlink:href="data:image/png;base64,iVBORw0KG... Convert that base64 URI into a regular PNG (eg. online tool), and you will see the original bitmap is 1293 x 1343. This is getting downsampled unnecessarily upon import. Please could you address the basic question, is it possible to import the SVG while preserving the original raster data? If not, I will simply open a report thread to the devs. Thank you.
  3. I understand that you can use the in-app tools to recreate a smooth gradient for export. That is not the issue. The issue is importing an SVG should be non-destructive (including the raster data). The original PNG raster data specifies a 1293 x 1343 bitmap, but the import process downsamples that to 418.3 x 417.1 (basically scaling down by the nominal SVG resolution of 469 × 487 px). Consider other scenarios, where the embedded raster data is more complex and cannot be reproduced by applying a simple Gaussian blur. The downsampling is an issue, which is why I am asking if there is a way to preserve the original raster data on import. Thank you for your help so far.
  4. Is there any way to get Designer to import the raw raster data, rather than generating a new downsampled bitmap?
  5. Ah, interesting. But why does the exported SVG from Designer look worse than the original? If you look at the original SVG in a browser, the raster gradient appears smooth. If you look at the exported SVG (with no changes made after import) in the same browser, the colors appear less smooth. So it appears like color information is still being lost on import and export?
  6. I have an SVG from WikiMedia Commons: which when imported into Affinity Designer, displays significant color pixelization/banding: To check that it is not just a problem with the internal renderer, I exported the imported SVG (with no changes) at default settings and the resulting SVG also displays the banding: exported_CIE-1931_diagram_in_LAB_space.svg Can anyone tell me how to import the original SVG without any loss of color fidelity and also what settings to export at to preserve smooth gradation? Thanks a lot.
  7. Cool thanks @Novak! @Mark Ingram when/if you're rebuilding on WinUI 3.0, please consider using the iOS UI as base for WOA devices. Most ARM devices are portable in nature; tablets and 2-in-1's would really benefit from the iOS UX, especially with regards to pen and touch input. This would be a dream for AP/AD Windows users!
  8. Perhaps the team could look into using Windows Bridge for iOS as a starting point. That would allow them to keep the code in Objective C, along with some support for iOS frameworks.
  9. Would it be possible to port the iOS version to WOA/ARM64 instead? There are many tablet UI features in that would work even better on the Surface Pro X (and similar Windows tablets) than the desktop versions of AF/AD. Please consider asking the community, as I'm sure many users would appreciate an iOS port just as much, if not more. Thanks!
  10. Want to add my vote of support for this too. I know the devs have said they have no plans, but I'd like to request they at least table this for discussion in their long term plans for UI development. Having a unified touch and pen interface would be beneficial for all Affinity products, as it would deliver a consistent and intuitive experience to new users with modern devices. It might be difficult now, but I believe the long term benefits in terms of development efficiency and user experience would pay off. Thanks
  11. I am replying in-context to a moderator question, as well as expanding on @Fist of the mighty Bob's original suggestion. It should be left to the moderator's judgment how best to move the thread to the Suggestions section (eg. re-titling as necessary). By allowing the devs to see the natural progression of question -> suggestion -> detailed use-case, it provides the team a better context for them to determine the best implementation.
  12. I would like to propose adding an Indexed Color filter layer (with a loadable palette) as a new feature for AP/AD. There are many use-cases, such as fashion design as stated here, and for pixel art as I shall detail below: Here, I am editing a sprite sheet for Cammy (trying to replicate this excellent PS tutorial by Kiwi using AP). Notice the color palette is a very specific 16 colors: During the processes of cleaning up sprite art, you may wish to smooth out gradients using brush tools, then reconvert back to the original palette of 16 colors. Here you can see how smoothing the skin tones on her legs introduces new (unwanted) colors into the palette: Because AP lacks the ability to work with indexed colors, I need to export to GIMP: Convert to Indexed color, and load the 16 color custom palette: To finally arrive at back at the nice, crisp original 16 colors for final export: Ideally, what would be a killer feature in AP/AD is the ability to create a filter layer that maps colors to the closest colors within a definable set. Essentially a "dynamic" indexed color mode. This would allow pixel artists great freedom to experiment and perfect their sprites, while keeping the flexibility of liquefy and blending brushes, and without breaking workflow to export to an intermediary program. Thank you to the Affinity dev team for any consideration they may put into this feature.
  13. By default, the panel to modify Adjustment layers appears at the bottom. This creates problems when you have dual monitors in vertical layout, or if you have a floating video player in that corner (for tutorials etc.) I know you can move each Adjustment panel individually, but I would like all Adjustment panels to appear by default on the top-left and/or be able to drag it into a floating toolbar (as indicated in the screenshot). Does anyone know how to do this? Thanks!
  • 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.