Jimmini

Just because I exaggerate it for demonstration purposes doesn't mean it's not a problem. I wouldn't have made this report if I hadn't noticed it in normal conditions. Not that adding adjustments would be an unusual thing to do. Seams at gradient stops seems like a pretty big deal to me for a professional image editing software.

I'm not looking to disable dithering though. I do want it. In fact, I wish there was more of it in various situations. The problem I'm trying to bring attention to is the artifact that this specific implementation of dithering produces. To make it more clear (hopefully), here is a comparison between various gradients: The first is simply a black to white gradient. The second one is a darker gray to a lighter gray with levels applied on top. The third is the same as the second, except there is middle gray stop at the center, which produces the issue I'm talking about, namely the seam at the stop's location. The third is supposed to look like the second, but doesn't. The levels are just used to emphasize the issue, but it happens regardless. (The fourth is just something I stumbled upon when making this comparison, which is a another issue.) GradientBug2.afdesign

Interesting. I'm actually not aware of what the most "correct" color space for interpolation is. LAB does indeed seem to come quite close to linear sRGB in your example, and you can actually use that as your document color space and it will interpolate accordingly. What I was referring to though is that, in sRGB documents, currently colors are interpolated without first applying the inverse sRGB transfer function on the stop colors, which is what I did (abusing one of my own programs) in the examples above. sRGB colors are stored in a non-linear encoding to increase precision for lower (darker) values at the expense of higher ones, as 8 bit integers are not enough otherwise, but those values should never be used for processing if a correct result is expected. I assume the rationale for doing it regardless is to have consistent results in comparison to other software. A gamma setting (like the one for blending layers) could allow both results (approximately).

First, gradient stop interpolation is currently not being done in linear space. Here is how it currently looks like: How it should look like: This doesn't only affect the distribution of the two colors being interpolated but also what colors are produced in-between: How it should look like: I thought about posting this in the bug reporting section, but as it might have artistic utility to do it this way and for compatibility reasons, I guess it fits better in here as a suggestion for an option. In fact, there could simply be a gamma setting in the gradient popup, just like in the layer blending options, which could be set to 1.0 for a "correct" interpolation. Secondly, as it is closely related, another suggestion I have is an interpolation easing option, which can produce much smoother gradients, among other things. For example, using cubic interpolation: Thanks, I hope you consider adding such options.

I understand the purpose of dithering, and I do want noise, but there shouldn't be such a sudden increase in noise that actually introduces visible seams. Such an artifact isn't needed for dithering, and seems like an implementation issue to me.

I always want gamma-correct blending, so an option to set the default gamma to 1.0 in the global preferences, just like I can for text, would be highly appreciated. Sometimes I forget setting it for each layer, only to later find out I have to adjust colors again, etc. So, any update on this?

Using Affinity Designer or Photo 1.9.2 on Windows 10, I can see an abrupt increase of noise at the position of a gradient stop, which looks like this after applying a level adjustment to exaggerate it: The noise slider is set to the minimum value for all stops. It's not extremely noticeable but still quite visible in some cases. I can reproduce it for example by simply creating a shape with a linear gradient, a black stop, a gray stop in the middle and a white stop. An example file is attached. GradientBug.afdesign

Alright, thanks a lot!

Actually I do have a question if you don't mind. Seeing that you're one of the few people who actually bothered to implement this properly, it would be very helpful if you could just briefly confirm whether I got the idea of this whole process right, so I don't base my decisions on wrong assumptions: 1) The display is roughly calibrated using OSD settings, if possible 2) Gamma curves are generated per channel that complement the prior calibration 3) A profile is created that accurately describes the transformation from CIELAB/CIEXYZ to the display's unique color space (assuming the prior calibration) 4) When the profile is installed, Windows loads the gamma curves into a table stored on the graphics card 5) Applications convert their colors to CIELAB/CIEXYZ, then to the display's color space using the transformation stored in the profile, and output it 6) The colors are automatically adjusted using the gamma table and then displayed On macOS, step 5 is done automatically system-wide. Is this somewhat correct?

I have the slight feeling Microsoft wouldn't be very interested in such a bug report heh. Actually, they do seem to have added system-wide color correction already, but I think only for HDR monitors: https://docs.microsoft.com/en-us/windows/win32/direct3darticles/high-dynamic-range#wide-color-gamut-with-automatic-system-color-management I understand why adding an option to intentionally break your own application just to have it behave like the rest of the system isn't very appealing... And you made a good point that it would really just look "correct" on my own screen. I guess I'll just work around it how you suggested when really needed. Thanks for taking the time to clear this up.

Hi, I appreciate your answer, and it seems you're right. I assumed that full color correction is done system-wide once a profile is set in the Color Management settings, but apparently only calibration curves are loaded. While that is definitely good to know, it doesn't change the fact that, as I mentioned before, colors don't match the ones in most other software, making it a pain to work with UIs, textures, screenshots, etc. So, is there a way to disable the color conversion, other than assigning my display profile to documents or disabling the profile on a system level? If not, would you consider adding such an option please? Anyway, sorry for the false alarm.

I've seen that article already. It mentions an issue with default profiles, which I'm not using, and the issue of other applications not taking the color profile of image files into account, which isn't the cause either, since even single solid color outputs from standard Windows APIs without any image files involved are displayed differently. Considering colors in Windows are inherently in sRGB space, I only work with sRGB images, and Windows is already transforming colors using the active display profile, I don't see why Affinity would need to perform any additional conversions in my case. Even if there is a good reason for it and it's not considered a bug, it effectively results in colors being displayed differently compared to how the operating system displays colors, and I would like to have an option to disable it as it makes UI design a trial and error process. Also, I just figured out that colors are displayed correctly if I use my display profile for the document, but that's obviously a bad idea.

This seems like a pretty major and obvious thing, so maybe I'm doing something wrong, but on both my computers in Affinity Photo and Designer 1.8.3.641 (and previous versions), colors are not displaying correctly when the color profiles I created for my monitors are enabled. Both hue and brightness are shifted compared to how the colors look in almost all other programs I've tested, including with images saved by Affinity Photo itself. I use the standard sRGB profile for documents and the color settings are at their defaults: Programs I've compared it to include Windows Explorer, Internet Explorer, Edge, Paint, Visual Studio, Blender, and VLC, all producing colors as expected. Only Chrome and Firefox seem to alter colors to different degrees. I've also compared it to various application programming interfaces by outputting a single color, i.e. Win32/GDI, WPF, OpenGL and Vulkan, again with colors showing correctly. Additionally, I tested it by taking a screenshot of a document opened in Affinity Photo and comparing it to the actual document: Here I made a gradient in Photo, made a screenshot of it and inserted it below the actual gradient. The red color (255, 0, 0) is made slightly pink (255, 8, 34) among other things. Apart from the color values, it also simply doesn't look like how I expect it. The only way I found to "fix" it is to disable the color profile altogether (i.e. use the default sRGB IEC61966-2.1 profile), or to enable it while Affinity Photo is running (but only until I restart the program). I'm using Windows 10, a Nvidia 650M with the latest drivers on my laptop and a 1080 Ti on my desktop PC. The color profiles were made with a X-Rite ColorMunki Display and DisplayCAL. It makes no difference whether I enable them with DisplayCAL or with the Windows Color Management dialog.

Yes, exactly.

In Affinity Photo 1.7.3.481, when switching document tab using the keyboard shortcut (Ctrl+Tab), often the wrong tab is shown. It seems like the keyboard-activated tabs are tracked separately from the ones activated with the mouse. Maybe the focus on the tab UI elements is being used to determine the next tab, which isn't being set when clicking on them?