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

marsofearth

Members
  • Posts

    78
  • Joined

  • Last visited

Reputation Activity

  1. Like
    marsofearth reacted to DM1 in Anyone know how to apply a mask/design within a curve (like stripes [the designs] on a candy cane [the curve])?   
    You can clip vector layers by dragging the layer across the top of the other layer.
    IMG_3333.MP4
  2. Like
    marsofearth got a reaction from Ariana M in How do I cut Text or objects from another shape?   
    Hmm If I understand you correctly; you have a shape with solid fill and you have a text layer above this shape?
     
    If you wish to CUT the Text layer OUT of the SOLID fill layer,
     
    1. select BOTH the Text Layer and Shape Layer.
    2. Either Go to the Main Tool Bar and find "OPERATIONS" and select SUBTRACT
        OR Go to the Layers Menu find Geometry/Subtract
     
    Should do the trick if I understand you correctly.
  3. Like
    marsofearth reacted to MEB in AFD Beta & AFP Beta 1.3.12 Rulers & Guides   
    Hi Jim Roelofs,
    Welcome to Affinity Forums
    Affinity Designer 1.7 will bring considerable improvements to grids/guides. We have a small team here, please bear with us while we work on those improvements/close the gaps.
  4. Like
    marsofearth reacted to Ballonseide in Pixel Snapping   
    That is, of course, true, and inevitably so. But that's just the point: Affinity Photo is not a simple bitmap image editor, and neither does it just store simple bitmaps—not even for pixel layers. This is obvious because the pixels in those layers can have non-integer positions and non-integer sizes. That's the problem. If everything were just square pixels at integer coordinates, I would have nothing to complain about. What I—and apparently some other users—want is precisely an option to always place pixels at integer coordinates, for the very reason that otherwise you have to deal with fractions of pixels (and the way this is dealt with by Affinity Photo causes both visual and usability problems).
  5. Like
    marsofearth reacted to Ballonseide in Pixel Snapping   
    I don't believe this is correct. It very much depends on the pixel count of the image you're working with. I come from photography, and I can state confidently that a 5000 x 4000 pixel image scaled to 4167 x 3333 pixels does not in any way look pixelated even though the "correct" scaling size would be 4166.666666 x 3333.333333 pixels. And with small image sizes it very much depends on the goal pursued whether a result that is layed out in some (pseudo-)sub-pixel manner is more desirable or not.
     
    Also, I don't see why floating-point pixel values displayed on a whole-pixel grid should not themselves produce some aliasing. (Perhaps less.) This would only be properly prevented by having a true sub-pixel grid that had sufficient resolution not to be detectable by the viewer.
     
    The fundamental issue I see here is the whole-pixel grid that is used for display (and for export to most image formats) by Affinity Photo. Anything other than actual whole pixels must introduce some sort of oddity in the visual result. (See my previous post on that.)
     
    Edit:
     
    And also, you're right of course that some users would not be happy with whole-pixels only. (While others would. I wouldn't venture a guess on how many on either side.) That's why it's proposed to be a (default-off) option.
  6. Like
    marsofearth reacted to Ballonseide in Pixel Snapping   
    Let me put it this way: The only way to display sub-pixels is to simulate displaying sub-pixels, some way or another. Theoretically, this could be done such that the user would not notice it. But that's not how Affinity Photo works, or any other image editing software that I know of, so the point is merely academic. (Hence the qualifiers.) In practice, you have to live with significant drawbacks. I suspect for Affinity Photo a conscious decision was made to swallow some specific drawback and gain some advantage for vector- or floating point-based functions in return. What I would prefer is an option that would let the user decide what is more important to him, and enable him to work the way he needs to work.
  7. Like
    marsofearth reacted to Ballonseide in Pixel Snapping   
    This is a big problem for me as well—currently, there is simply no way to work with "whole pixels only" if this is desired/required.
     
    I also second the idea of one global check box that takes care of this. Or at least an option that can be set for individual files, if the former is too much to ask given the complex nature of the problem.
     
    I also think it is important to recognize that this not just a problem of snapping. That alone has its issues. But for example, a simple drag-resize operation on a pixel or image layer with "Move by whole pixels" snapping enabled will yield a perfectly located boundary box—and yet the content of the box can still get resized with sub-pixel precision, namely if you use one of the diagonal handles, which by default cause aspect-ratio-correct resizing of the content, usually producing non-integer pixels. (Ignoring aspect ratio by holding Shift does work around this problem—but then you effectively lose control over your aspect ratio entirely, which is even worse.)
     
    I also do not agree, as it has been suggested alsewhere, that aspect ratio-correct resizing should always use floating-point precision because otherwise the aspect ratio would not be perfectly preserved. Such precision can be required in some cases, and it's good that it's possibe to work this way; but other use cases do not require this last bit of precision and rather suffer from it. A proposed "whole pixels only" option could simply cause all pixel values in transform operations to be rounded. With anything but very small image sizes, the remaining precision will still be more than sufficient for many use cases, and the need for the whole "watching the Transform panel and correcting the undesired sub-pixel values" part would disappear completely.
     
    I really hope this will be solved in some future update, for right now it is the single biggest workflow obstacle in Affinity Photo for me—a big headache, to be honest.
  8. Like
    marsofearth reacted to Ballonseide in Pixel Snapping   
    PS to my above: Another aspect to this complex that in my opinion speaks for the need of a "whole pixels only" option is the contradiction inherent in having rasterized layers with sub-pixel values but showing them on the image not as half pixels, but as dimmed color over the whole pixel that the bounding box cuts through. (And of course, this is what is exported to pixel-based file formats as well.) Simply said, a pixel layer with size 2.5 x 2.5 pixels will in actuality be a 3.0 x 3.0 pixel layer, only the bounding box will be shown as 2.5 x 2.5 pixels (at the correct location). What this layer does to the image is display the innermost 2.0 x 2.0 pixels as one would expect, but the remaining 0.5 pixels (in each dimension) will go beyond the bounding box; to my eye, they appear like a partly transparent full-pixel addition next to the inner "normal" pixel layer. This is certainly not proper behavior, and in any case not what anyone manipulating pixels would expect. (If anything, one would expect Affinity Photo to actually work this a finer grid and display the non-whole pixels up to the boundary box, at full opacity (or whatever) and no further.)
     
    And from simply inspecting the boundary sections of sub-pixel layers one can also easily tell that this has an effect on the scaling result. A 13 x 8 layer scaled down to 10.8 x 6.6 layer looks different than the one that results from manually setting this layer to 11.0 x 7.0 pixels. (I know, aspect ratio gets changed.) I can't claim this to be objective, but visually, I greatly prefer the look of the latter, and I'd presume many other users do, too. The semi-transparent pixels at the boundary of the 10.8 x 6.6 layer just don't look like what is meant to happen when a whole-pixel layer is scaled down.
     
    Of course, all this, in the end, is simply a consequence of the fact that pixels (in any practical sense) are indivisible, as others have stressed already. Displaying non-whole pixels is inherently problematic and, to some extent, physically impossible. The current implementation in Affinity Photo is merely a workaround, not a solution to this fundamental problem.
  9. Like
    marsofearth got a reaction from GregS in What is the difference between Lanczos seperable and non-seperable.   
    Looks to me that everyones argument is proving a singular point,
    that the follow Export settings:
     
    Lanczos seperable
    Lanczos non-seperable 
     
    Has very little meaning to most designers, and do not accurately describe to designers what the end result target is for the image.
     
    Nearest Neighbour
    Bilinear
    Bicubic
     
    Are likely just as confusing for new users, but since they are established settings in other applications (photoshop for example) they confuse less people.
     
    A more descriptive setting would help clarify the obvious issues people are having.
     
    A little i. info graphic with pop-up with full description would also help inform the user what the settings end result aim is.
     
    HOWEVER:
     
     
    Ultimately when exporting an image a User generally wants to know:
     
    Quality - ( Low --- ^ --- High)
    Sharpness - (Smooth --- ^ ---- Sharp)
    File Size Result .........
     
    The actual naming of the equations used is mostly superflous to the user.
    Perhaps let advanced users choose which equation they wish to use, and normal users simply choose with a little slider Quality and Sharpness and let Affinity decide the equation.
  10. Like
    marsofearth reacted to MattP in Affinity Designer Customer Beta (1.6 - Beta 11)   
    Firstly, an explanation: So... why did Beta 11 take me such a long time to release? Well, it turns out that the released version of High Sierra showed stability issues with the Metal view mode that the High Sierra Beta didn't. I don't know why and it doesn't seem to have been fixed yet, but as such I could no longer set everyone's default view to the Metal view as they would potentially get a poor experience. We've got our existing OpenGL view there to fall back to, but it's now missing some tweaks and features that the Metal view had been given - so I just spent the last 2 weeks completely rewriting the OpenGL view mode to have parity with the Metal view. So, this new OpenGL view is now in and is set to the default for all users. I will add the legacy OpenGL view mode back in for the next Beta for customers that may suffer very specific GPU-related issues (I can't imagine there will be any, but just in case...). The new OpenGL view should be a little faster at all times and should get rid of some of the long-standing issues that people were seeing - but let me know how it goes!!!
     
    So... on with the next Beta!
     
     
    Status: Beta Release
    Purpose: New features, fixes
    Requirements: Purchased Affinity Designer
    Mac App Store: Not Submitted
    Download: Here
     
    This beta version represents a substantial change to our codebase and as much as we have tried to ensure the quality of the code, it should be considered to be not suitable for production use. This means that you should not attempt to use it for commercial purposes or for any other activity that may be adversely affected by the application failing. In addition it is definitely worth noting that files created in Affinity 1.6 may not open in 1.5 so always make a copy of your important documents before opening them in 1.6 to ensure you do not accidentally overwrite them and are unable to open them in your 1.5 version.
     
    To use this beta, simply download the file from the link given above and double-click on the file to open the installer. Follow the instructions to install the beta version. The beta sits alongside the Mac App Store version and will not interfere with it.
     
    Fixes/Improvements:
    Completely new OpenGL view (selected by default) Light-UI tweaks Pen Tool tweaked to allow a click on the selected start/end node to force a cusp Tablet input's 'Angle' and 'Tilt' are now mapped more sensibly. 'Tilt' is how far down the pen body is laid towards the device, 'Angle' is the direction formed by the pen on the device. Fix for pressure input with Pencil Tool Fix for importing Text Styles in High Sierra Fix for Colour Picker preview not disappearing correctly in High Sierra PDF export tweaks to avoid rasterising embedded documents where possible and fix colour profile issues Miscellaneous other fixes and tweaks
  11. Like
    marsofearth got a reaction from JasonVieda in Missing Font List?   
    Absolutely! ++
     
    Would be fantastic to have a panel showing all the fonts used in file, the ability to select a font and make a substitution or replacement with the option to embed or at least find in finder so a person can package the font for print setters.
     
     
     
     
  12. Like
    marsofearth got a reaction from malyKeri in Missing Font List?   
    Absolutely! ++
     
    Would be fantastic to have a panel showing all the fonts used in file, the ability to select a font and make a substitution or replacement with the option to embed or at least find in finder so a person can package the font for print setters.
     
     
     
     
  13. Like
    marsofearth reacted to Zero Zero in Designer -- Drag rulers onto the page would be helpful   
    ​As in CorelDraw it would be so helpful to click and drag in the ruler left corner and drag into position on the page. And then simply double-click in the left ruler corner to reset them. Thanks.
  14. Like
    marsofearth reacted to snowite in Resizing of Brush preview icons   
    Okay, so this is like the 3rd time I have had to redo this post.  ARRGGGGHHH.
     
    As you can see in the image, the preview of the individual brushes is really small.  Unless I missed it. I have not been able to resize it. In PS the preview image is much larger and does not require me to select the brush, test the brush on the screen, then see if I want to use it.
     
    this is win 1.5.2  I am also having the issue with the brushes when selected, I have to double click them to use them causing me to either make double images on occasion or having to wait for it to decide if it wants to print on the page.  Just fyi on that.
     
     

  15. Like
    marsofearth reacted to Peter Werner in Improved Gradient Map feature   
    The current Gradient Map feature is quite basic like the one in Photoshop, but in many ways, it could be a much more useful tool with the following additions:
     
    HSL Mode: Instead of going based only on Luminance, this would use the input hue or saturation as the lookup index. In combination with HSL blend modes, this would allow for some fantastic workflows like basically warping the color wheel to taste, similar to the "HSL Wheels" feature in Magic Bullet Colorista (Note: don't be fooled by the name of the feature, this is NOT referring to the three-way color corrector). Just use a gradient of the HSL spectrum and drag or re-define stops, set the result to "Hue" blend mode, and you have an extremely powerful color correction tool that gives you results that would be difficult to achieve in any other way.  
    Circular Editor Option: Like the Colorama filter built-into in After Effects, this makes it easy to work on maps that are supposed to start and end with the same color. In combination with an input for a number of revolutions (cycles) to use, this would also make it easy to create gradient effects where a few stops are repeated multiple times across the spectrum (like, say, alternating black-white-black-white). This would also massively improve usability in conjunction with the HSL mode option suggested above.  
    Access to swatches: This would make it easy to re-use gradients by defining them or recalling them from swatches as an alternative to using Adjustment Presets.  
    Interpolation control: Sometimes the transition from one color to the next needs fine-tuning – this is something that Affinity's gradient editor already supports, but not in the Gradient Map dialog. A Constant Interpolation setting where the color would just be constant up until the next stop would also be useful since it would eliminate the need for duplicate stops in the same position, which are really hard to select. Possibly, the curve editor could also be re-used to define falloff using a Bézier or Catmull-Rom-Spline.  
    Duplicate Stop option: Often, it is necessary to use the same color multiple times in a gradient. Adding a button for this and/or enabling Option+Drag to duplicate would be useful. Photoshop aggravatingly always inserts new stops with the same color instead of the color that is already there at that position in the gradient, but the (better) implementation of this in Affinity had the side effect that duplicating stops became harder.  
    On-image sampling: While the dialog box is open, it would be useful to highlight the value under the mouse pointer in the gradient display to be able to place a stop exactly at the desired position. Clicking in the image would insert a stop.  
    On-image highlighting: Conversely, when editing/dragging a stop in the gradient editor, an option to highlight the affected pixels in the image would be helpful. The options could be: off (nothing) all pixels that have exactly the value represented by the position of the stop (similar to focus peaking) the zone that will be affected in the image. The overlay would start at 100% intensity at the value represented by the stop and fall off to 0% on each side until the position of the next stop respectively, taking the falloff into account (see "Interpolation Control" above). Optionally, two different colors could be used to represent each side of the stop.  
    Resizable dialog box for more precision: When editing 16-bit images or editing falloff from one stop to the next or when placing stops very close to each other, it would be useful to have more room to work with. Making gradient editor dialog boxes in the application resizable would alleviate this problem.  
    Snap to Luminosity button: Sometimes, it is useful to place stops exactly at the point in the gradient that corresponds to their luminosity, especially when they are defined by selecting swatches from a color palette. Adding a button that moves all selected stops to that position would make this really quick. For instance, tinting an image with two tones while keeping black and white intact could be achieved very quickly by selecting a black-to-white preset, then adding two stop, selecting a color from the document color palette for each, and clicking that "Snap Selected Stops to Luminosity" button.  
    Ability to move start and end stops. The values before the first stop and after the last one would simply use constant extrapolation. This would eliminate the need for duplicate stops, which take longer to create and are harder to edit since all operations need to be performed twice.
  16. Like
    marsofearth reacted to Chris_K in fx - Outline Opacity   
    Hi marsofearth
     
    This seems inconsistent being the only effect that does this. I shall make sure this gets logged
     
    Thanks
  17. Like
    marsofearth got a reaction from teecityseller in fx - Outline Opacity   
    fx Panel
     
    Problem:
     
    Opacity Setting no longer seems to work on Outlines. 
     
    Why:
     
    For some product images I like to be able to apply a black inside outline when placing the product image on a dark background.
     
    Most of my product images are taken on a white or grey background and the images will sometimes have a slightly shiny edge to them that pops out a little too much on a black or dark background.  
     
    By adding a black inside outline, and reducing the opacity to about 33-50% the edge blends in nicer with a darker background.
     
     
  18. Like
    marsofearth got a reaction from Mr Lucky in What is the difference between Lanczos seperable and non-seperable.   
    I don't think anyone wants anything "Dumb" down.  Just simplified.
     
    For curious users, like those few here at the forums a simple (Advanced Option) could allow for choosing preferred mathematical algorithm.
     
    I have no problem with the export system as it stands now, I quickly researched it and tested a couple images and figured it out.
     
    However, there are plenty of extremely talented artistic people who would look at those exports and just say, HUH? Choose one randomly and be upset if the result did not match their expectation.
    So when my wife complains about such UI deficiencies, I don't roll my eyes and blame her for not understanding mathematical algorithms, I ask her what she wants the result to be and choose from there.
     
    It is really easy for Geeks to criticize average users lack of understanding of complex computer operations.
    When you explain these operations in a clear simplified explanation, often people say, "Why doesn't it just say that!"  
    And THEY are RIGHT.  No matter how far up the hackles get raised by computer programers, engineers, UI Designers. Stop blaming the user.
  19. Like
    marsofearth got a reaction from FMA in .pat files   
    I also would love to be able to open up the hundreds of .pat pattern files I have created in Photoshop and use them in Aff-Photo or Aff-Designer.
  20. Like
    marsofearth reacted to DerbyLad in .pat files   
    Hi,
     
    Is it possible in Affinity Photo to create (or even better import) .pat files as in Photoshop?
     
    I have a library created on a windows machine in Photoshop within .pat file.  
    I use this when I wish to 'fill' a selected area.  
    Is it posible to do this with Affinity Photo?
     
    I hope my question is clear but if not please ask and I will try to explain myself better.
     
    Thank you for reading
  21. Like
    marsofearth reacted to DerbyLad in .pat files   
    Hi, thank you for the reply.  Shame you can't do this as this is an essential feature for me.
  22. Like
    marsofearth got a reaction from PeanutsA in [ADe] Dimension tool   
    +1 for dimensioning tools along with "movable Ruler Origin"
  23. Like
    marsofearth got a reaction from Mediafuel in How do I cut Text or objects from another shape?   
    Hmm If I understand you correctly; you have a shape with solid fill and you have a text layer above this shape?
     
    If you wish to CUT the Text layer OUT of the SOLID fill layer,
     
    1. select BOTH the Text Layer and Shape Layer.
    2. Either Go to the Main Tool Bar and find "OPERATIONS" and select SUBTRACT
        OR Go to the Layers Menu find Geometry/Subtract
     
    Should do the trick if I understand you correctly.
  24. Like
    marsofearth reacted to Fixx in [ADe] Dimension tool   
    No, like this: 
     
    or rather, like this: 
     
    (except I use metric. Also there are lots of variety between countries how to present dimensioning.)
  25. Like
    marsofearth got a reaction from ronnyb in Why not Merge - Designer / Photo   
    Adobe does not give anyone a single all purpose app, It provides a suite of loosely compatible apps where import of AI or PS or ID files between the three only somewhat works...
     
    I prefer the idea of tightly integrating the file format between A-designer, A-photo, A-publisher  so that at some point, hopefully,  moving between apps at least appears seamless, appears as if you are still working on the same "Workbench" but simply using the tools that are needed.
     
    Adobe is the furthest from providing an all purpose app at any level.  The Affinity Suite is closer to being a convergent than Adobe is at this point.
×
×
  • 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.