Jump to content

Casey Muratori

  • Content Count

  • Joined

  • Last visited

About Casey Muratori

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  • 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.