Discrepancies with shader-based THRESHOLD, ERODE, and DILATE Filters at higher pixel densities

[SableRaf]

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Build Process
• Unit Testing
• Internalization
• Friendly Errors
• Other (specify if possible)

p5.js version

1.7.x Beta: https://raw.githubusercontent.com/wong-justin/p5.js/shader-filters-build/lib/p5.js

Web browser and version

Chrome Version 116.0.5845.140 (Official Build) (arm64)

Operating System

MacOS Ventura 13.4 (22F66)

Steps to reproduce this

Note: this is a follow up to the conversation on #6324

Big thanks to @wong-justin, @aferriss, and @aceslowman for getting the shader-based filters up and running in p5.js

I've spotted some quirks in the outputs of filter(THRESHOLD), filter(ERODE), and filter(DILATE) when we increase the pixel density. At pixelDensity(1), things look similar to the CPU-based filter, but once we increase the density, some discrepancies start to appear in the output.

For more clarity, I've put together a demo sketch here. You can also see the differences in this generated images:

pixelDensity(1)

pixelDensity(2)

[wong-justin]

I believe these three filters will be fixed if they use the same luma calculation as the CPU version. I'll make a PR shortly

[wong-justin]

So these filters match up now, except for a few artifacts in THRESHOLD that depend on browser and pixel density. I'm not sure about the cause or solution.

	Chrome (v116.0)	(Firefox v117.0)
pixelDensity(1)
pixelDensity(2)

I know there was a weird line in the cpu filter about floor()ing the threshold, which I think I replicated in the shader. But I guess they're still not quite the same. Sources for reference:

p5.js/src/image/filters.js

Lines 201 to 222 in 9d71220

	threshold(canvas, level) {
	const pixels = Filters._toPixels(canvas);
	if (level === undefined) {
	level = 0.5;
	}
	const thresh = Math.floor(level * 255);
	for (let i = 0; i < pixels.length; i += 4) {
	const r = pixels[i];
	const g = pixels[i + 1];
	const b = pixels[i + 2];
	const gray = 0.2126 * r + 0.7152 * g + 0.0722 * b;
	let val;
	if (gray >= thresh) {
	val = 255;
	} else {
	val = 0;
	}
	pixels[i] = pixels[i + 1] = pixels[i + 2] = val;
	}
	},

https://github.com/wong-justin/p5.js/blob/85e11074602f0abecd0c10dee27c1af9caa7e70a/src/webgl/shaders/filters/threshold.frag#L4-L23

precision highp float;

varying vec2 vTexCoord;

uniform sampler2D tex0;
uniform float filterParameter;

float luma(vec3 color) {
  // weighted grayscale with luminance values
  return dot(color, vec3(0.2126, 0.7152, 0.0722));
}

void main() {
  vec4 color = texture2D(tex0, vTexCoord);
  float gray = luma(color.rgb);
  // floor() used to match src/image/filters.js
  float threshold = floor(filterParameter * 255.0) / 255.0;
  float blackOrWhite = step(threshold, gray);
  gl_FragColor = vec4(vec3(blackOrWhite), color.a);
}

[davepagurek]

For a potential source of discrepancy at different pixel densities, it looks like the graphic used to do the filter doesn't specify a density:

p5.js/src/image/pixels.js

Lines 578 to 584 in 9d71220

	this.filterGraphicsLayer =
	new p5.Graphics(
	this.width,
	this.height,
	constants.WEBGL,
	pInst
	);

So if e.g. you're on a 1x display but you have manually set the canvas at pixelDensity(2), I think that means the graphic would be outputting less pixels than expected? Or at least maybe end up with different antialiasing? Do you see the differences go away when you make the filter graphic match the density of the main canvas?

[wong-justin]

I'm a bit fuzzy about pInst and the scope of all the hidden variables in a sketch, but I thought pixelDensity() sets a global that applies to all renderers when they're created. The differences remained, and the canvas sizes and densities were the same. Example sketch: https://editor.p5js.org/jwong/sketches/HkDei0TqX

[davepagurek]

Ah yep you're right! I'm not sure what else might be the cause off the top of my head, but at least the difference now is very small, so I think it's fine to not worry about the remaining differences any more (unless someone else has other new leads.)

[SableRaf]

I agree with Dave it's close enough. Looks good to me! Nice work @wong-justin 🙌