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

NotMyFault

Members
  • Posts

    6,823
  • Joined

  • Last visited

Everything posted by NotMyFault

  1. Digging deeper i think i found the root cause (in the sense of explanation): When blending 2 layers, one red and one blue, both 50% opacity, i would like to get a "clean" 50-50 mix of both colors (circle in the middle) Unfortunately this wont happen: Instead, all layers have a sequence, and the blend formula results in the upper layer becoming the double share. The top rectangle shows the result if blue layer is on top The bottom rectangle shows the result if red layer is on top I spend an hour playing with blend gamma, profiles etc but to no success. This might be technically correct / state of the art how blend ranges are defined and good old PS and Affinity implements it. Never the less it leads to unwanted results. @Dan C Can you please move this to feature requests? In case of anti-aliasing, i want the option that the aliased pixel gets blend only depending on covered pixel share, and not on layer sequence and normal alpha blend formula (which gives the upper layer an unfair/unwanted weighting advantage) There is (to my knowledge) no way to create this result with reasonable effort by any existing functions. The simplest way to achieve this behavior is that the when anti-aliasing pixels to set the opacity of the lower layer to 100% (instead of his share of pixel area). This could be an option in the layers blend range. It solves the other issue of "thin lines" when rasterizing adjacent layers. wrong blend expectations.afphoto
  2. Hi Dan, thank you for investigating. Actually it does not solve the issue: Even if deactivating the Channel Mixer, the resulting blend hue and luminosity is still off. Check by activating the HSL adjustment. When you check the contribution of red and green within the blended pixels (which is independent from transparency), you can see that it is non-linear, and red is always much larger than the expected (linear) share. E.g. using the middle pixel i expect 50% red, 50% green, and hue value 300. But the blend delivers (from memory, i cannot check on iPad) 70%red, 35% blue. The partial transparency is actually another part (maybe bigger) of the problem. But there is a separate discussion ongoing about the unwanted partial transparency. In this post, i intentionally try to focus on colors, and keep it clear from the transparency part. To summarize: when blending a pixel that blends 1/2 pixel 100% red (HSL 360/100/50, 1/2 pixel 100% blue (240/100/50), i expect RGB 50%/0/50% or HSL 300/100/50. but i get roughly RGB 70%/0/35% which is equally off in H, and L In addition i expect 100% alpha, but see that the blend formula gets 75% alpha. This bight the how it works today, but it creates unwanted issues. Again, lets forget alpha on focus on colors only.
  3. 1- how do you finish? Press enter, click somewhere else by mouse, … 2 - how do you fill? Click on swatch, use fill menu item, click on color panel, use keyboard shortcut 3 - set blend mode to overlay - again how exactly? Use only mouse an cog wheel in layers panel?
  4. Hi, i assume a bug in retail (left). Renders OK on beta (right). Windows 10 Maybe related to https://forum.affinity.serif.com/index.php?/topic/147356-blend-mode-saturation-with-hue-060-issue/&tab=comments#comment-820973
  5. I created a new post to discuss another (possible) inconsistency when alpha blending colors (based on the same causes of trouble discussed here). But this time it is not unwanted transparency, it is (possibly) wrong blend colors (too dark, and even hue differs to my expectation). Love to hear your opinion:
  6. Hi, i created a test file to check which colors are created by Affinity (Photo, Designer) when it needs to anti-alias. When checking the result, visually or by info panel (HSL picker) or using an HSL de-saturate adjustment, the blended colors seems too dark (<50% luminosity). My (possibly wrong) expectations is that when blending 100% red and 100% blue - or any mix of them - the result should show the same luminosity to look visually pleasant. The bottom part of the image shows the blend result i would expect (always 50% luminosity). Blend colors (top row) vs. my expectation (bottom row) Using HSL with saturation set to 0 to show luminosity. Blend leads to darker results. blend tester.afphoto
  7. I don't think this to be a factor. You can create the issue with any basic shape, rectangle, circle etc. The easiest way to spot: create new document. smaller size makes it easier, 40x40 px is enough create rectangular shapes with defined color (could be same color), perfectly integer sized and positioned and aligned (using transform panel and numeric input). No stroke. group them rotate group by any angle except multiples of 90° select "composite alpha" in channels panel zoom in depending on remaining eyesight (mine is quite bad) See edges clearly show "reduced" alpha blending fail by anti-aliasing.afphoto
  8. Designer on iPad forgets to apply a chosen view mode when you switch between Designer/Photo persona.
  9. @Lagarto can you provide a PNG export from CS6, using my sample file. Curious which color blend it produces.
  10. I would like to ask a Mac user to export the attached file as SVG, PDF and PNG. Please provide a screenshot of 400% zoomed using pixel view mode, showing the blue / red transition with anti-alised (blended) pixels. Please inspect in exported PNG for blended pixels with info panel, and check for green color. If present, issue is unsolved. (Below it is present, on iPad). I would like to compare the results from Mac with Windows / iPad. The green backfill makes it easier to spot than transparency. iPad has no way to easy inspect pixels for transparency (getting numeric value). Stroke Gap.afdesign
  11. @GRONDThank you for uploading the images. I fully understand and share your frustration. Only Affinity might be able to solve the underlying issue. Until then you may change your workflow to avoid the issue: I can reproduce the issue when i use pixel-layers which got scaled, or moved by fractional pixels. If i rasterize the layer after scaling / moving, the issue does not occur I can avoid the issue by using „merge visible“ instead of „merge down“ Would it be a viable option for you to not use merge down? Again, this is only proposed as a workaround, it’s no permanent solution or bugfox.
  12. I‘m on Windows and iPad, issue is present on both platforms. This problem can bite you in every situation where anti-aliasing is used, e.g. having 2 objects with identical edge curvature aligned to each other. If Affinity already found a solution for strokes on Mac, i would be interested what method they use.
  13. The thin line is probably caused by: circle and stroke are (correctly) handled as separate objects (required to have different colors etc) anti-aliasing is set to on This correctly leads to edges with partial transparency. The alpha blend formula then leads to thin line with partial transparent pixels. To better understand how this undesirable result is caused, just think of a circle and stroke is two completely separate objects: The inner circle, and the outer donut. Affinity only provides the comfort to automatically create them, and manipulate them via the UI. Currently Affinity has no option to automatically solve this issue for you, as it is strictly adheres to the basic standards. Possible mitigations / workarounds Deactivate anti-aliasing for this layer (cog wheel / blend ranges) modify the sequence / order / size / alignment of strokes to ensure that there are always fully opaque pixels in the relevant area use an additional backfill circle with adequate size below your circle I know none of these workaround will make you happy. To solve this on app level affinity would need to introduce behavior that could break compatibility with other Apps and established standards (SVG, PDF): Adjust the size of the lower object (fill or stroke) by about 1 px to cover the former partial transparency. this could be a user-selectable option per vector shape „fill partial transparent edge pixel if covered by adjacent object“ Adjust anti-aliasing to work only on outer edge of fill - stroke. Adjust anti-aliasing / blend formula to return 100% alpha for „connecting“ objects. We might raise this as feature request.
  14. Yes, with constraints: You get heavy moire and other artifacts reset of P-filter still does not work I wanted to avoid rasterizing, to be able to change the scale of the pattern layer to improve resolution / reduce artifacts
  15. Just check the usual culprits GPU Driver - try update / downgrade / Studio vs. game ready, try clean removal before install Remove any 3rd party software (https://forum.affinity.serif.com/index.php?/topic/44770-issues-caused-by-third-party-software/) Try latest Photo retail and latest beta Try latest 1.9 instead of 1.10. Some users report new OpenCL/GPU issues not seen in 1.9 Try deactivate OpenCL. Hurts performance, increases stability in some cases.
  16. I never really got how to use profiles (except pencil / pressure profile). Documentation is next to unavailable. It starts with when you enable a "neutral" profile (straight line form 0 to 1): the rendering totally changes (vs. no profile active). anti-aliasing 3D Layer FX Hoping that James will surprise us with one of his excellent tutorials.
  17. Hi, would help if you can upload the file showing the issue. Why do you set the blend mode on individual layers instead on group level? What type of objects (layers) to you use, pixel, vector, ...?
  18. Works perfectly fine on my PC. Spec see my signature. Known bug, see
  19. Hi, i try to provide some help about perspective filter as answer to this post: Unfortunately, Affinity always fails: The perspective filter does not work. After double-click to open the UI, no handles appear to adjust the filter. Reset in Perspective filter does not work. Old filter settings still visible. Affinity crashes frequently while adjusting the filter. I had to close/open Affinity and even reboot the PC multiple times to start over. Screenshot of "no handle visible" status The idea of the document is to use a curve layer to mask a simple pattern layer, in combination with nested perspective live filter, to create a cobble effect within the masked area. The pattern layer was created from the (inactive) vector shape, supported by a fill layer to get 100% opaque pixels. pattern.afphoto
  20. Hi, when enabling a profile on Layer FX, you get heavy banding. RGB/16 lossy tes.afphoto
  21. Hi, assuming you are using Photo and what you are calling an object is a pixel layer with opaque pixels (the object) surrounded by transparent pixels, extending to the complete canvas area. You can use rasterize & trim to get rid of unneeded transparent edge pixels, but limited to the rectangular bounding box. Another more complex option is to use a curve shape as clipping path. create a curve shape to define bounding curve. nest pixel layer to curve.
  22. Hi, i cannot spot any difference between the „background“ and „merged“ layers. Except at the edges, but this is caused by partial transparency. never the less, some problematic observations: The layers use fractional values for x/y position (move tool, transform panel). This is a prime source for blurry images. Resizing images is another potential cause for blurriness. Could you provide the image before resizing? It is known from other posts that especially resized layers and merge down lead to unwanted blurriness. Your file is >200 MB. If i copy the background layer and create a new file from the clipboard, merge visible and add the 2 filter layers, the result is 49MB. To investigate deeper could you please provide additional screenshots: use 100% zoom use png format (uncompressed) use full screen capture. All elements must stay at absolute identical positions 1: the state before merge where the image looks sharp 2: the state after merge visible where the image looks blurry. 3: please include the complete layer stack panel
  23. Bump. It is crashing in 1.10.0.1127 retail and Beta when OpenCL is active for a document ~2K x 2K (smaller than the brush size). It survives with long "not responding" if document is 8k x 8k, or OpenCl is inacitve. .
×
×
  • 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.