Ballonseide

Suggestions like these are the perfect example why some stuff in AP is just plain broken. That has got nothing to do with Adobe indoctrination (I don't care either way, I never used Photoshop). A bad workflow is just that, a bad workflow. Drawing straight angled lines on a pixel grid should be a matter of a few clicks and easy as pie. Period. If you need to first create a vector object, then rasterize it, something's already gone horribly wrong – let alone if you have to switch to an entirely different app and back again. There may be tools in AP that work better than Photoshop's, or that just work differently. I applaud that. I have no preconception on how things should work, other than that they should work and that tools need to enable me to do my work efficiently. If that requires learning or re-learning, fine. But the pixel and brush tools are not examples of that. As far as line drawing is concerned, more than half a decade after AP was first released, they're simply still not working right, to the point of being useless for some types of work, as is well-documented in this thread.

On my Mac, with AP 1.9.1, it does not. Edit: Esc toggles "Deselect" (as the History window clearly shows) which has no influence on line drawing since there is no selection involved.

Do you have your brush set to less than 100 % flow? If so, it would be expected to get a more intense blob after the second click (if the second click is above the first). Nothing to be done about that as long as we don't have the above-mentioned "Continue and constrain" modifier. Another workaround you could try is to click and undo every time (!) before you start drawing a new line. The undo breaks the "continue" chain, so after undoing you can click, hold, press shift, hold, and drag to get a straight, uniform line. This would probably win the prize for worst workflow, but if you must use AP, at least it should give the result you desire.

You'd have to add that you cannot move the mouse between the first and second click even by one pixel, otherwise you can get a non-constrained connection line between the first and second click, like this: Still really cumbersome, and I still don't get why we can't just have Shift + Alt + Drag as "Continue last stroke constrained" (and with 45° angles as well).

I have the exact same issue. Drawing a horizontal grayscale gradient on a pixel layer in an 8-bit image behaves as expected, but in a 16-bit image the gradient is dithered right there in AP. Using, e.g., the Rectangle tool and filling with a gradient, it does behave as expected (no dithering, and Color Picker tool indicates usage of appropriately fine gradations), but exporting in 16-bit TIFF again produces dithering. It seems impossible to export actual 16-bit gradients. I also have the "Dither Gradients" option unchecked, though I'm confused by the fact that it is situated unter "Performance" settings – not sure what it is supposed to do anyway. Could you elaborate on what exactly you are doing here? Say I just want to export a simple grayscale gradient to a 16-bit TIFF, how would I go about that?

The problem is that I don't see any pattern. It just sometimes fails. Just as many other tools sometimes fail or confuse me for no reason that I can discern. I've pretty much given up on trying to understand why. I'm an irregular user of AP and don't have the time (nor the nerve) to file reports every time, or watch tutorials or ask around in the forum. If stuff that seems fundamental to me doesn't seem to be working reliably (or sensibly for that matter) even years after first using the software, that indicates to me I should just suck it up and put my money elsewhere next time.

I believe the core issue here is that there is no support for constraining the line drawing – be it parallel, angled, or based on a previous trajectory. Instead, you're supposed to use the Pen tool for that (i.e. vectors), which is itself not exactly straightforward. Raster-based drawing is basically possible only slightly above MS Paint level. I share your disappointment that AP doesn't give the user the freedom to draw however he wants but requires learning the ins and outs of its often quirky special-purpose tools. Except that this duplicate-move-duplicate method doesn't work too reliably. Just now I tried to create various repeating lines in the way you described, and sometimes it would work, but sometimes AP would quickly forget the movement of the duplicated piece and duplicate the next one in-place, or somewhere unexpected.

As I wrote above, the basic straight line pixel drawing (using Shift = "Continue last stroke") was fixed in the Mac version in June 2019. What issue are you experiencing exactly?

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.

This seems to have been fixed in 1.7.0.

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.

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).

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.

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.

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.