Jump to content


  • Content Count

  • Joined

  1. Yes, the Pen tool works as a substitute for some purposes. But Pen will generate a vector object, with all that entails. This thread is about the Pixel and Brush tools and about being able to lay down lines on a rasterized layer (i. e. drawing pixels directly). This was broken before because "Continue last stroke" (when holding Shift) had erroneous behavior (at least on macOS). That was fixed in AP version 1.7.0, as I wrote above. You can now click with the Pixel/Brush tool to lay down an origin object, hold Shift, click somewhere else and get a proper line between both points. What's still missing, though, is an option to constrain a line to right angles. Right now, to draw a perfectly horizontal pixel line, you have to zoom in to 400 % or so and carefully place the second pixel at the exact same image height as the first. Very tedious. I think Shift+Alt would be an obvious candidate for this as it is not currently used, at least in the Mac version. (Or it is, but it just duplicates what Alt alone does (color picking). I don't think there's any use for having color picking on Alt+Drag and Shift-Alt-Drag as well.) Also, a visual preview of the line you're about to draw would be very useful (when holding down Shift). Right now, you're basically drawing blind – you only know what the line is gonna end up like when you've drawn it, meaning you have to do a lot of undo/retry.
  2. Indeed! And yes, you can use the Pen tool... unless you're trying to draw something exotic – like an arrow... (And no, the Arrow tool does not make it easier either.) Please fix the Brush tool's "continue last stroke" feature so we can use it for quick and basic pixel line drawing! It can't be that difficult.
  3. 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).
  4. 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.
  5. 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. 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.
  7. 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.
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. These are the Terms of Use you will be asked to agree to if you join the forum. | 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.