brightness threshold calculation might be bogus

[ksmoore17]

In Threshold, both the Rust and numpy implementation use perceived_brightness from some random calculation i found online.

rust

pierogis/src/pymodule.rs

Lines 76 to 78 in a1fb442

	let pixel_value = (pixel_array[0] as f64) * 0.299
	+ (pixel_array[1] as f64) * 0.587
	+ (pixel_array[2] as f64) * 0.114;

np

pierogis/src/pyrogis/ingredients/seasonings/threshold.py

Lines 94 to 96 in a1fb442

	intensities_array = np.sum(
	pixels * np.asarray([0.299, 0.587, 0.114]), axis=2
	)

This other random calculation I found online is better
https://stackoverflow.com/a/56678483

Make sure that the speed of this change is reasonable.

As far as Sort using Threshold, I think something is not quite right and the results are not as dazzling as I remember them. It could be beneficial to sort the upper thresholded pixels separate from the lower thresholded.

There was a decision made that the thresholds ultimately meant "sort contiguous pixels above upper or below lower" instead of "... below upper and above lower" which may or may not be in line with other pixelsort implementations. "Inclusive" vs "exclusive" could be a simple toggle on Sort and/or Threshold and flip the values of the boolean array.

[ksmoore17]

I think this is still ok for now, but I will leave it open because it would be fun to change. I was worried that the calculations were boof bc sort seemed off, but I think sorting pixels w/ brightness between the thresholds is the more common way to pixel sort.