Casey Muratori

That is the ultimate sadness :( - Casey

Did this end up getting fixed? - Casey

Cool. I feel like this should presumably be a high-priority item, since this means people are generally getting blurry images all the time and might not even realize it? Thanks, - Casey

I normally only use Affinity Photo on my main Windows machine, but I installed it on another Windows machine here that has recording software on it so I could try to record the video you requested. In so doing, I stumbled upon what the issue actually is! It is not related to the document or the workflow, actually - it is related to the monitor setup. I installed it on a third Windows machine just to verify, and the pattern seems to hold: When using Affinity Photo on machines with a single monitor, pixel alignment works as expected. It is only when I use Affinity Photo on a machine with multiple monitors that this problem occurs. It may also be the case that the monitors must have different resolutions, but I do not have any machine with two identical monitors so I am unable to test that. Is it possible that the pixel-snapping code is actually not snapping properly when multiple monitors are involved? Perhaps if the monitors have different DPIs as well? Are you able to reproduce this there now? You do not need to do anything special at all, you can just: Install Affinity Photo on a machine with two monitors that have substantially different resolutions (say, one is 1920x1200 and one is 3840x2160). Create a new document (say, QFHD). Hit the PRT SCR key to capture the desktop. Select "New From Clipboard" from the file menu to create a second document with the image. Pixel-exactly select a rectangular shape using the rectangle select tool (say, the Affinity logo button in the upper left). "Copy Flattened" to copy the rectangle. Switch back to the empty QFHD document. "Paste" to paste the Affinity logo. The pasted rectangle should be obviously off-pixel alignment (the edges will be blurred, and the marquee doesn't line up with the document pixels). I believe I can now definitely say this is a bug, because it happens on a completely clean install of the latest Affinity Photo download right out of the gate, no preference changes necessary, no prior usage of the software necessary, no particular files necessary, etc. - Casey

I am encountering a weird bug when trying to cut-and-paste pixel-aligned rectangular regions from one image to another in Affinity Photo 1.8.3. This bug seems to be present in at least all 1.8.x versions that I had, so it is not specific to 1.8.3. Whether it goes back further than the 1.8 branch is anyone's guess. If I open two images, one completely blank (literally nothing, so rgba all 0) and the other an RGB image with no alpha, then use the rectangle select tool to select a rectangular region in the RGB image, CTRL-C to copy, switch to the blank image, then CTRL-V to paste, I get weird partial alpha at the edges of the selection in the paste. These appear to be because of sub-pixel alignment, but I copied a pixel-aligned region and pasted pixel-aligned as well... and in fact, I have the "whole pixel" alignment enabled the whole time, so it shouldn't be possible for me to be off-pixel alignment unless I'm misunderstanding the intended behavior of that feature. If I then turn off whole pixel alignment and slide the pasted region slowly, I can manage to get it back into alignment and the partial transparency resolves itself mostly (although it still may be slightly wrong). What is going on here? Is this some sort of bug with whole-pixel alignment that nobody noticed? Or am I doing something weird? Thanks, - Casey

That is very good news! - Casey

That is the ultimate sadness. - Casey

So, there have been two updates since this bug was reported, but I did not see any mention of it being fixed in the announcement posts. Has this been fixed or is it still in there? - Casey

I wanted to add another symptom of this bug, just to make sure all the "hidden stuff doesn't work" problems are fixed when this gets addressed: If you create a solid shape, such as a rectangle, this is exported/imported correctly to/from PSD when the "Preserve editing" setting is used. However, if you _hide_ the solid shape, it may now get silently corrupted (seemingly randomly) in one of two ways. Way 1: The shape becomes a "fill" layer and fills the entire document (rather than just the region inside the solid shape). Way 2: The shape becomes a "fill" layer with a "shape" clipping layer underneath it, but the shape clipping layer (for some reason) has a slash through it and it appears to be non-functional. Again, this suite of bugs is really, really bad and causes artists to lose work all the time. I really hope it is going to be a high-priority fix because it's the most critical kind of bug an art package can have (silent data corruption) - Casey

Awesome, thanks! - Casey

Not sure how to elaborate on this, but when importing PDFs into Affinity Photo (or any Affinity package, actually), they appear to import properly for most of the underlying PDF elements, but any elements that have been "filled in" as part of PDF's form-filling capabilities are noticeably absent. Thus is you take a PDF with form-filled elements and view it in a PDF viewer, you will see things (like names in blanks, checked boxes, etc.) that are simply not there when imported into Affinity Photo at al. - Casey

I'm not sure exactly how to explain what is supposed to happen verbally, but mathematically you have a pixel of the form (color, alpha) where "color" is a vector (RGB, CMYK, whatever your encoding is) and "alpha" is an encoding of the range [0, 1] that (in this case) represents brush coverage of the pixel that was painted by a previous brush stroke. An "alpha-aware fill" or "anti-aliased fill" is one where _all reachable pixels_ in the flood region with an alpha less than 1 have their original value of (color, alpha) replaced with (alpha*color + (1 - alpha)*fill, 1), where "fill" is the color with which you've filled the region. Another way to say this is that an alpha-aware fill behaves as if you had filled the underlying region first, _and then_ painted the brush stroke over it. No "tolerance" value is needed in this scenario - a tolerance of 0 will still fill the region exactly correctly, because you are not asking it to expand to any neighboring colors. You are literally only filling exact matches for the _color_ part of the component, you're just extending into pixels whose alpha was partial. Not sure how to describe this any other way, but I can post code for it if the devs really don't know what I'm talking about, but would assume any graphics programmer would immediately understand what I'm saying. - Casey

Slight update: I cannot be 100% sure, since I have not done enough testing yet, but it _appears_ that if you change the PSD export setting from "accuracy" (the default) to "preserve editing", it seems like this behavior is at least mitigated. Is it possible that some part of the "accuracy" setting accidentally removes layer contents that are marked as invisible? - Casey

A keyboard shortcut to that option is a good idea, I will try that. I still think it is probably better, though, if there is a way to create one directly in the layer window using a button, as this is fairly standard practice in most packages. - Casey

Neither of those two things is what I'm talking about. Tolerance does not properly handle antialiased edges, it simply expands the region that will be filled (thus destroying the antialiasing). As for the paintbrush options, those do not affect the paint bucket, do they? - Casey

At the moment, it would appear that Affinity Photo cannot create a layer group by itself. You must select (at least one) existing layer or layer group and then ask to have it grouped, thus creating a layer group. This can be annoying when you are trying to set up a structured file, because you may strictly want to add some root groups with nothing in them at the outset, and it isn't immediately clear how you would ever do this without grouping and ungrouping layers for no reason several times. - Casey

When attempting to draw shapes with a brush and then fill them in with a color, such as when doing ink-and-paint, you need a tool that will properly "re-fill" the partial alpha pixels on the interior edges of the brushstroke. Photoshop et al typically have an option for this on the paintbucket, such as "Antialias" or something similar. I could find no similar feature in Affinity Photo, which makes it kind of impossible to use for ink-and-paint, since just flooding in the solid color regions would have to be done manually by the artist instead of being a single click. - Casey

Hi there, We are (unfortunately) stuck with a PSD workflow here, and will never be able to change away from that. Although Affinity Photo generally works well with PSDs, unfortunately there seem to be two very severe bugs with it where, for some reason, it only saves layers that are marked as visible. This leads to a ton of lost work. Here are explicit repro cases for both bugs, both of which are 100% reliable on our machines with the default settings for Affinity Photo: Bug #1 - General PSD export bug where layer existence is saved, but layer contents are lost Create a new file. Create two pixel layers, A and B. Draw an "A" shape on A, and a "B" shape on B. Set A to visible and B to invisible. Use File->Export to save to a PSD with the default settings. Close the file with File->Close Load the file with File->Open and note that although layer A and B both exist, layer B's image is gone (it is an empty layer). Bug #2 - Save-over-imported bug where both existence and contents are lost In General preferences, turn on "Enable save over imported PSD files". Create a new file. Create two pixel layers, A and B. Draw an "A" shape on A, and a "B" shape on B. Ensure both A and B are set to visible. Use File->Export to save to a PSD with the default settings. Close the file with File->Close Load the file with File->Open and note that A and B both exist and have their proper contents. Set layer B to invisible. Save the file with File->Save (automatically overwriting the old PSD) Close the file with File->Close Load the file with File->Open and note that while A still exists, B is now completely gone - it does not even exist, let alone have pixel data. Based on this behavior, it would seem like there is perhaps some kind of hidden option (or one we missed?) that tells the PSD export process to skip things which do not contribute to the final image. We would suggest that this should, at the very least, default to "off" if it is going to be an option :) - Casey