I need a gradient filled rectangle but not noisy/dithering between shades

[frank26080115]

I draw a rectangle, choose the fill to be a gradient from black to white, the noise is set to zero on both ends.

The resulting rectangle is still noisy

Tried this with both small rectangles and really really 3000px wide rectangles, with document set to 8 bit, 16 bit, and 32 bit HDR modes

I understand that it is mixing (dithering) the shades together to give the illusion of having more shades than what is possible

But... I don't want that, I want each shade to be a solid vertical line

Attached screenshot, I am trying to get the result on the top half of the screenshot, but within Affinity, under 16 or 32 bit processing

Thanks

[Ron P.]

Try disabling Dither Gradients in Preferences>Performance. See if that gets you what you want.

[GarryP]

In addition to Ron P.’s suggestion above, it’s a little bit difficult to see what you mean in your screenshot – the difference is hard to see at first, at least for me on my screen.
Does the example in my attached screenshot show what you want?
Also, do you want this to be specified at the layer/gradient-level rather than an all-or-nothing application level?
And, if so, how many ‘separations’ would you want and how could that be specified by the user?

[NotMyFault]

If your need the final result in bitmap / pixel, use a procedural texture filter to create gradients.

Even if you deactivate "dither gradient", as soon as you rasterize / flatten / export to pixel formats, you get this unwanted dithering / noise effect.

prfect bw gradient.afphoto

Edited December 31, 2021 by NotMyFault

[NotMyFault]

There is another bug with gradient fills:

If you use RGB/8, and a 256x256 sized rectangle with a gradient from pure black 0/0/0 to pure white 255/255/255, you would expect to get 256 steps from 0 to 255, in increments of 1, for every step into x direction.

What you actually get is 0-127, and 127-254. this is off by 1 in the 2nd half, and value 127 is used for two columns / x-positions. One of the many "rounding errors" in Affinity apps.

Almost impossible to spot with human eye, but detectable when you inspect the numbers and pixel peep.

You can see this better in Photo using histogram and info panel.

 

 

bw gradient off by one.afphoto

[R C-R]

2 hours ago, NotMyFault said:

What you actually get is 0-127, and 127-254.

Maybe I am not checking this correctly but in your file according to the AP Info panel I seem to be getting the full range of 0 to 255 (for either layer) & I do not see 127 used in 2 adjacent steps.

[NotMyFault]

44 minutes ago, R C-R said:

Maybe I am not checking this correctly but in your file according to the AP Info panel I seem to be getting the full range of 0 to 255 (for either layer) & I do not see 127 used in 2 adjacent steps.

A screenshot (showing the same panels like mine, scope, layers and info panel) would help.

And check which layer is active.

don’t forget Windows / Mac platform differences of Affinity apps.

[R C-R]

2 hours ago, NotMyFault said:

A screenshot (showing the same panels like mine, scope, layers and info panel) would help.

The Scope panel looks very similar to yours, but I guess I do not know what it is supposed to show. To me, mine looks like a straight line without a 'bump' or discontinuity anywhere on it.

Below are some Info panels but I can't take a screenshot with the X position of the target shown in the panel (because I have to move the pointer into the panel to use the Mac screenshot feature) so you will just have to trust me that in each of them the X position is in the 127, 128, & 129 px respectively:

   

To make the target position as accurate as possible, I set vertical guides at 127, 128, 129, & 130 px, zoomed in to about 40,000% & placed the target midway between each pair for the screenshots.

Not shown, but I also added a guide at 254, & when I moved the target half way between that & the edge of the document, the RGB values were all 255.

[lacerto]

On 12/31/2021 at 7:56 PM, NotMyFault said:

If you use RGB/8, and a 256x256 sized rectangle with a gradient from pure black 0/0/0 to pure white 255/255/255, you would expect to get 256 steps from 0 to 255, in increments of 1, for every step into x direction.

You do get. The problem is that a gradient must be defined so that the end stop is placed minus 1 px off the width (or height) of the gradient, since the exact position defines the start x (or y) of the pixel, so the first stop placed at x = 0 defines the color of the pixel at x = 0 to 1 (1st pixel in the row = RGB 0,0,0), and last stop at x = 2554 the color of the pixel at x = 2554 to 2565 (256th pixel in the row = RGB 255, 255, 255).

bw gradient off by one_FIXED.afphoto

But I can reproduce the dithering problem (when the gradience is created by using the gradient fill tool, whenther applied on a vector or pixel layer), as soon as the layer is rasterized, no matter which performance preference, rasterization algorithm and raster image format (PNG, TIFF included, compressed or non-compressed) is chosen at export time, so this seems to be a clear bug, for which the procedural texture method is a good workaround, as you showed (producing an even non-dithered gradience).

The dithering is not applied evenly, either, so e.g. in a 256 x 256px image it is done as follows (created by using division blend mode and darkened with levels), most of the bottom part of the image non-dithered:

 

[R C-R]

5 hours ago, Lagarto said:

The problem is that a gradient must be defined so that the end stop is placed minus 1 px off the width (or height) of the gradient, since the exact position defines the start x (or y) of the pixel, so the first stop placed at x = 0 defines the color of the pixel at x = 0 to 1 (1st pixel in the row = RGB 0,0,0), and last stop at x = 254 the color of the pixel at x = 254 to 255 (256th pixel in the row = RGB 255, 255, 255).

I don't think that is the right way to look at this. As I interpret it, the first pixel of the row covers the entire area between x+0 & x=1. Likewise, the last pixel in the row covers the entire area from x=254 to the edge at x= 255. So as long as the first stop is placed anywhere within that first pixel, the gradient should be fine.

At least that is how it looks to me using the original 'off by one' file, the Info panel, & a very high zoom factor to place the sample targets anywhere within the area of a rendered pixel. As soon as I move it beyond the edge of that pixel, the values increment or decrement by one, depending on which pixel edge I cross.

[lacerto]

10 minutes ago, R C-R said:

I don't think that is the right way to look at this.

Just download the file, or create one yourself to check it.

[R C-R]

17 minutes ago, Lagarto said:

Just download the file, or create one yourself to check it.

I did both. I still do not see any problems in the gradient. Among other things, your 'fixed' file seems to start the gradient in the first (leftmost) pixel, not one one pixel to the left of the document edge. I checked that by zooming in on its first stop to about 40,000%. At that zoom level, the stop appears to be placed precisely on the edge of the document. If I move it to the left or right & then back to the edge, it snaps back to that same position, which makes me wonder if it is working differently in different OSs or versions.

[NotMyFault]

6 hours ago, Lagarto said:

You do get. The problem is that a gradient must be defined so that the end stop is placed minus 1 px off the width (or height) of the gradient,

Yes, but this workaround seems a bit too much for normal users. As far as i tried, i could not use snapping for gradient nodes, so good luck positioning it correctly. Think of using a gradient swatch. It automatically stretches to the end, and causes this issue.

The forced dithering issue has been rejected by Affinity long time ago and declared „design choice“ when i remember it correct.

[lacerto]

Then watch this:

You need to have a layer that has a gradient fill applied selected (as above the Rectangle layer). As the clip shows, if you have the end stop at the image marginedge, the last pixel value will have RGB 254, 254, 254 as its color value, and the gradient will be interpolated accordingly (so that you get e.g. those double RGB 127, 127, 127 values). Btw, Photoshop behaves exactly similarly.

[lacerto]

20 minutes ago, NotMyFault said:

Yes, but this workaround seems a bit too much for normal users.

This is NOT a workaround. It is how the gradient definition control works and should work, and as it also works in Photoshop. When snapping to marginsspread and pixel alignment is on, it is easy go pass the correct definition point, but as said, the end stop must be placed before the right edge ot the image to get the definition right.

EDIT: If you have pixel alignment on, it is easy to snap the end stop at edge minus 1 so it is not "difficult", you just need to understand how the control works.

[lacerto]

10 hours ago, NotMyFault said:

The forced dithering issue has been rejected by Affinity long time ago and declared „design choice“ when i remember it correct.

Omg.

EDIT: Just see the dither exposure in my post above and try to be benevolent enough to see this as a design choice!

[NotMyFault]

Found the old post - including a workaround:

 

[lacerto]

Thanks, I had not noticed this post. Good to know about the group effect workaround, as well.

[R C-R]

27 minutes ago, NotMyFault said:

As far as i tried, i could not use snapping for gradient nodes, so good luck positioning it correctly.

Really? For me on my Mac, the gradient stops snap to document edges, or to anything else I have set in the snapping manager.

29 minutes ago, Lagarto said:

You need to have the layer that has the gradient fill applied.

I did do that. But to repeat, I am not seeing anything wrong or unexpected. Specifically, for me each of the 3 red sample targets you included shows a different RGB value (127, 128, & 129 respectively) I am not sure what moving the stop as you did in your video is supposed to show.

[lacerto]

2 hours ago, R C-R said:

if it is working differently in different OSs or versions.

It does not seem to. The first definition point must be placed at x = 0 and x < 1 if a complete gradient is wished so if it is at x = 0, it is placed correctly. Similarly, the last definition point (if a complete gradient is wished) must be placed at x = 2554 and x < 2565 to define the last pixel in the row. If it is at x = 2565, it defines the pixel value for 1 pixel past the right edge. This is logical, but many users probably think that snapping at both edges gives a full gradient. You must be able to place the stops also past the image edges (at least if e.g PS behavior is imitated).

[lacerto]

1 minute ago, R C-R said:

I am not sure what moving the stop as you did in your video is supposed to show.

Just watch the effect in the Info panel. In the start of the video (when end stop is edge minus one), the values are 127, 128, 129, in the end of the video, they are at 127, 127, 128. It shows it, instead of supposing to demonstrate any statement off the video. This is on macOS (Monterey 12.1), and the behavior is exactly same on Windows.

[R C-R]

5 minutes ago, Lagarto said:

Just watch the effect in the Info panel. In the start of the video (when end stop is edge minus one), the values are 127, 128, 129, in the end of the video, they are at 127, 127, 128.

FWIW, I can duplicate that using your file on my Mac if I snap the right gradient stop to the right edge of the document. If it is even a tiny fraction of a pixel to left of that, the gradient has no double values in it.

As (I think?) you mentioned above, this is logical because at x=255 it defines the start of one pixel past the right edge of the document.

I am not sure if that means we agree about this or what, though.

[lacerto]

2 hours ago, NotMyFault said:

Think of using a gradient swatch. It automatically stretches to the end, and causes this issue.

Yes, it is a bit confusing. In PS applying a gradient swatch is differently done and does not cause the issue, as you can apply it also on an empty pixel layer without defining the start and end positions, so the full gradient would be applied on simple click assign. As for vector objects and exporting raster objects, there exists this problem also in PS and AI. On the other hand, if you export as vectors, full gradient would be applied to the extent of the object, but when rasterized the edge pixels would often have other than exact color values of the defining gradient. Normally this does not matter, and dithering evens out rounding errors, but if exact values are aimed at, it should be possible to turn off dithering, and then some manually attended accuracy (e.g. using dimensions that guarantee even distribution of tones, and exact positioning of the gradient start and end points) is often also needed.

[JimmyJack]

On 12/31/2021 at 3:57 AM, frank26080115 said:

I draw a rectangle, choose the fill to be a gradient from black to white, the noise is set to zero on both ends.

The resulting rectangle is still noisy

Tried this with both small rectangles and really really 3000px wide rectangles, with document set to 8 bit, 16 bit, and 32 bit HDR modes

I understand that it is mixing (dithering) the shades together to give the illusion of having more shades than what is possible

But... I don't want that, I want each shade to be a solid vertical line

Attached screenshot, I am trying to get the result on the top half of the screenshot, but within Affinity, under 16 or 32 bit processing

Thanks

I've got several ways to achieve this, but let's just start with the most simple shall we (the other's aren't that hard either 😉).

Use a Fill/Pixel Layer (instead of a gradient filled shape)
This will give you the fluted look regardless of the app dither setting. You can clip or mask it if needed (vector or not).
Any export, including raster, will retain the effect.
Extra tip: if you want dynamic control of the flute sizing, add a Posterize adjustment to the gradient.