This answer is a bit long, since I wanted to provide context, to help explain some of the choices I made, their consequences, and what alternatives might be possible. Skip to the Implemented Solution Examples section at the end if you just want to see Python code and Blender nodes for actually solving the problem in a few ways, and notes on limitations/possible extensions.
Spatial Uniformity
Before talking about how to achieve uniformity, it might be good, first, to talk about what we mean by 'uniform':
The White Noise node returns a pseudo-random float between 0 and 1, with a uniform distribution of values. (i.e. all ranges of values of the same size occur with the same probability.)
The most limited but simplest way of interpreting this requirement is: letting I be a single large region (a set of pixels) in any single realized sample from the generated noise image (which may be 2D, 3D, 4D, etc), for any interval [a,b], we require that the number of pixels with color values inside [a,b] be proportional to the interval length, |b-a| (note: I always work over simple black-and-white images here, and usually use "color" synonymously with "black-white pixel intensity"; but the ideas all extend in the obvious way to RGBA color channels and the like).
But this suggests we can strengthen the requirement further by demanding it hold over more than one sub-region; for example, we might partition the input image I into large rectangles, and require that, within each such rectangle, pixels with values in each [a,b] occur with frequency proportional to |b-a|. Really, in principle, there's no need for us to restrict ourselves to rectangular regions, and there's no reason they must be mutually exclusive; the most general form of this requirement might say something like: let S=[S1,S2,....] be a (possibly infinite) list of sets of pixels (i.e., each Si corresponds to some arbitrary subset of the image); we might want to require uniformity on every such subset.
Sampling Uniformity
I call the above notions of uniformity spatial uniformity, because they are meant to capture the idea that we want uniformity in the distribution of values in any single 2-D image (which can be understood as a single high-dimensional sample from some input distribution, e.g. Perlin or Voronoi, etc). Note that this notion of uniformity is impossible to satisfy exactly, and becomes more and more difficult to 'reasonably' satisfy, at increasingly small scales: with, say, P possible color values in a single pixel, it is impossible to impose this kind of spatial uniformity requirement on any region Si containing fewer than P pixels (some values will always be missing; of course, we could still work to get 'closer' to uniformity, even in cases where exactly achieving it is not possible); and, the fewer pixels we have to work with, the more our joint goals of "continuity" and "spatial uniformity" are at odds with one another.
In any case, just for the sake of being precise, there is at least one other kind of uniformity we should talk about, because it may be the kind that occurs to someone looking at this problem abstractly, without being focused on graphical applications specifically: given a sequence of independent random samples of our distribution (e.g., maybe we pick new random seeds uniformly at random, and each one yields a different, independent 1-D line-of-numbers or 2-D image or 3-D volume or 4-D volume-over-time sample of our desired distribution), we could require not that uniformity holds within any single realized image, but instead that certain margins over this sampling distribution are uniform. The simplest version of this might, say, require that, in any single pixel, if we draw a large number of random seeds, that pixel must take all possible color values in [a,b] with a probability proportional to |b-a|.
This second notion of uniformity is I think less closely related to what @RobinBetts has in mind in his question, since we only ever see a single sample from our Blender noise distributions. So, it seems reasonable to demand one of the forms of spatial uniformity suggested above, rather than sampling uniformity, and so I'll focus on spatial uniformity in the following.
The Probability-Integral Transform
The probability-integral transform is a fundamental theorem in probability theory, useful for taking an initial, continuous random variable and identifying a function that, if applied to it, will convert it into a uniform random variable (an aside: inverting the ideas in this theorem also yields the ubiquitous method of inverse-transform sampling, which can be used to identify a function that, when applied to a uniform random variable, will yield samples from a distribution of interest. This method of converting uniform random variables into target random variables of interest is, for example, used extensively in the random sampling primitives implemented in numpy.)
The statement of the probability-integral transform theorem is very simple: if you have a random variable R from a known distribution, if you form its cumulative distribution function CDF_R(), then CDF_R(R) is a random variable that has a uniform distribution. CDF_R() is just the function defined by CDF_R(r) = Pr[R <= r]; you can think of CDF_R() as taking in a possible value r of R and telling you what percentage of the time R falls below r.
Or, a little more casually, we can just think of CDF_R() as converting values of R into "ranks": you feed r into CDF_R(), and it tells you the percentile-rank of r. The probability-integral transform is then just telling us: while the original input variable isn't uniformly distributed, its percentiles certainly are! Looked at this way, the probability-integral transform can be viewed as a general method for taking a non-uniform function and telling you how to remap its values to ranks, which will be uniform.
It may be worth noting that this doesn't generally work for discrete random variables, or for functions that only take values in a discrete range. For example, if we have an R that takes the values 0 with probability 0.9 and 1 with probability 0.1, then CDF_R() is the function CDF_R(r) that returns 0.9 for r=0 and 1.0 for r=1. Obviously, this isn't uniform!
The trouble here is that discrete random variables (and functions of discrete input spaces) can be "clumpy": no matter how far we zoom in on them, there's still a lot more mass on the single value 0 than on the single value 1. But this doesn't happen with continuous functions and random variables: if you zoom in close enough to a continuous function, neighboring values are arbitrarily close to one another,
essentially indistinguishable, and the probability of any single value being observed is 0. This lets us "spread the values out" by converting them to ranks, which we could not do if they were clumpy in the manner of discrete functions and random variables.
A useful observation is that the idea underlying the probability-integral transformation isn't really specific to random variables. Given any set of distinct, observed values v1, v2, ..., vk from an interval [A,B], we may want to "flatten" them to remove noticeable clumping, and we can always do this by mapping the vi to their ranks, and normalizing the ranks over [A,B]. For example, if we have observed values 0,9,10,11,12,20, over the rang [0,20], clearly there is some "clumping" in the center of this interval. But we can convert these to ranks: 0,1,2,3,4,5; and then normalize like 0,1,2,3,4,5 -> (0/5)*20, (1/5)*20, ..., (5/5)*20, which gives 0, 4, 8, 12, 16, 20---a sampling of values evenly distributed, with the central clump removed. That we can use probability-integral transform-like arguments will be useful below, because when considering all the pixels in a region Si, these aren't really independent samples from a single reference distribution (so we aren't technically approximating an independent r.v's CDF by empirically estimating what proportion of values fall below each threshold)--indeed, we need these pixels to exhibit significant correlation with one another (otherwise, we wouldn't have continuity!).
Using the Probability-Integral Transform to Approximate Uniformity
Given an input distribution (e.g., Perlin, Voronoi, etc) and a large sub-region of pixels S, we can use the ideas discussed above to compute, empirically, the rank of each pixel value in S, and then re-map pixels to their ranks, and then renormalize their ranks to the bounds of the color space. This transformation will give us spatial uniformity over S. Taking this approach is still limited in a few ways:
- Uniformity will not generally hold over arbitrary sub-regions of
S, nor regions that lie outside of S, nor regions that intersect S partially, etc, although the departures from uniformity will be smaller the closer these other regions are to the region S we used to generate our "uniformizing" ranks originally (though we can partially combat this by adding other such "regions" S', S'', etc, and averaging based on distance from each of them, if needed)
- Actual pixel values are discrete, not continuous (but we can't do much about this, and there are "enough" levels in most color spaces that we can reasonably pretend they are continuous, even though we know they're not)
- We're not trying to compute any sort of theoretically well-defined CDF exactly. An alternative approach might try to define from first principles a kind of graphical noise that obeys some form of weak or strong spatial uniformity, or might start from the exact definitions of known spatially continuous noise distributions (e.g., Perlin noise) and try to show how to transform this to achieve spatial uniformity exactly. The kinds of graphical noise distributions typically in use don't have very simple probabilistic descriptions though, so we'll settle for empirical approximations
- To implement our approximation re-mapping of color values in practice, we'll use Blender nodes, which won't allow for exactly representing the re-mapping (and instead use some kind of linear or spline interpolation, etc, depending on options), but are simple and fast
On the other hand, there are two major advantages to our approach:
- Empirically estimating how to transform from a given spatially continuous noise distribution back to a spatially uniform distribution is much easier than doing so exactly
- Starting from a known spatially continuous distribution and transforming it to have some form of spatial uniformity (rather than defining a new, spatially uniform and continuous distribution from first principles) has the very useful side effect that we'll get different results depending on which input noise distribution we "plug in" (and this will be easy/fast to switch, thanks to 1)
Implemented Solution Examples
First, an API caveat for something I haven't figured out: I'm unfortunately not sure if there's a nice way to evaluate from the Blender API the noise samplers used directly in Blender Shader nodes; the Python API definitely has directly exposed implementations of the samplers used for building textures, and of various intermediate noise utility functions, but while these overlap a bit with the distributions we can access manually in Shader nodes, there are also some differences. The scale, detail, and distortion parameters in the Noise Shader Node, for example, don't seem to be exposed when building textures from the Python API in this way, and some noise texture nodes (like the Brick Texture Shader Node) don't seem to have any BlendDataTextures analogue. Unfortunately, this means I can't keep everything purely within the Python API; I'll work around this by rendering a sample from our texture of interest from an orthographic camera to a 1 x 1 plane (which unfortunately limits this approach to 1-D and 2-D textures), with a manual Blend-file setup that looks like:
Where the plane has this very simple material setup (and you could play with this, inserting other shader nodes, altering parameter values etc, of course, to find uniformizing mappings for different noise types and parameter settings):
With this intermediate step, here's an example code snippet for generating "uniformizing" mappings from observed pixel values (in the original source noise) to what they "should" be if we want to enforce uniformity (here, in just a single target region; not attempting to achieve more complex spatial-uniformity-in-many-subregions-simultaneously, though I think it is possible to do so, with more work and at the expense of increased Shader compilation & rendering time):
import bpy
import numpy as np
import os, time
RESOLUTION = 8
DISPLAY_LIM = None
def example():
bpy.context.scene.render.resolution_x = RESOLUTION
bpy.context.scene.render.resolution_y = RESOLUTION
bpy.context.scene.render.filepath = bpy.path.abspath("//") + f"noise_example_{RESOLUTION}.png"
bpy.ops.render.render(animation=False, write_still=True)
noise_im = bpy.data.images.load(bpy.path.abspath("//") + f"noise_example_{RESOLUTION}.png")
assert len(noise_im.pixels)/4 == RESOLUTION**2, f"# noise pixels: {len(noise_im.pixels)} /4 : {len(noise_im.pixels)/4}, Resolution: {RESOLUTION}"
t0 = time.time()
sorted_bw_pix = np.sort([noise_im.pixels[4*i] for i in range(RESOLUTION**2)])
t1 = time.time()
print(f"Sorting bw pixels took {t1 - t0} secs")
cumsums = np.cumsum(sorted_bw_pix)
t2 = time.time()
print(f"Generating cumulative sums took {t2 - t1} secs")
empirical_cdf = cumsums/np.sum(sorted_bw_pix)
t3 = time.time()
print(f"Normalizing to get empirical CDF took {t3 - t2} secs")
print(f"[Method 1] Empirical CDF suggests the mapping:")
for i, (p, e) in enumerate(zip(sorted_bw_pix, empirical_cdf)):
if DISPLAY_LIM is None or i < DISPLAY_LIM:
print(f"# {i}: {p}\t->\t{e}")
increments = [empirical_cdf[i] - empirical_cdf[i-1] for i in range(1, len(empirical_cdf))]
print(f"Max CDF increment: {max(increments)}")
print(f"Min CDF increment: {min(increments)}")
print(f"[Method 2] Sorted ranks suggest the mapping:")
num_bw_pix = RESOLUTION**2
max_bw_pix = sorted_bw_pix[-1]
for i, p in enumerate(sorted_bw_pix):
if DISPLAY_LIM is None or i < DISPLAY_LIM:
print(f"# {i}: {p}\t->\t{(i/(num_bw_pix-1))}")
increments = [i/(num_bw_pix-1) - (i-1)/(num_bw_pix-1) for i in range(1, len(sorted_bw_pix))]
print(f"Max rank-based increment: {max(increments)}")
print(f"Min rank-based increment: {min(increments)}")
Here's an example of the above output loops run at impractically small 8 x 8 resolution:
>>> importlib.reload(uniformize_noise); uniformize_noise.example()
<module 'uniformize_noise' from '...uniformize_noise.py'>
Sorting bw pixels took 0.0 secs
Generating cumulative sums took 0.0 secs
Normalizing to get empirical CDF took 0.0 secs
[Method 1] Empirical CDF suggests the mapping:
# 0: 0.6274510025978088 -> 0.014787430759218456
# 1: 0.6313725709915161 -> 0.02966728295190246
# 2: 0.6352941393852234 -> 0.04463955657805201
# 3: 0.6392157077789307 -> 0.05970425163766712
# 4: 0.6392157077789307 -> 0.07476894669728222
# 5: 0.6431372761726379 -> 0.08992606319036288
# 6: 0.6431372761726379 -> 0.10508317968344354
# 7: 0.6431372761726379 -> 0.1202402961765242
# 8: 0.6431372761726379 -> 0.13539741266960484
# 9: 0.6431372761726379 -> 0.1505545291626855
# 10: 0.6431372761726379 -> 0.16571164565576615
# 11: 0.6470588445663452 -> 0.18096118358231236
# 12: 0.6470588445663452 -> 0.19621072150885857
# 13: 0.6509804129600525 -> 0.2115526808688703
# 14: 0.6509804129600525 -> 0.22689464022888206
# 15: 0.6549019813537598 -> 0.24232902102235937
# 16: 0.6549019813537598 -> 0.2577634018158367
# 17: 0.6549019813537598 -> 0.273197782609314
# 18: 0.658823549747467 -> 0.28872458483625685
# 19: 0.658823549747467 -> 0.3042513870631997
# 20: 0.658823549747467 -> 0.3197781892901425
# 21: 0.658823549747467 -> 0.33530499151708537
# 22: 0.658823549747467 -> 0.35083179374402823
# 23: 0.658823549747467 -> 0.3663585959709711
# 24: 0.6627451181411743 -> 0.3819778196313795
# 25: 0.6627451181411743 -> 0.3975970432917879
# 26: 0.6627451181411743 -> 0.4132162669521963
# 27: 0.6627451181411743 -> 0.42883549061260473
# 28: 0.6627451181411743 -> 0.44445471427301314
# 29: 0.6666666865348816 -> 0.46016635936688705
# 30: 0.6666666865348816 -> 0.475878004460761
# 31: 0.6666666865348816 -> 0.49158964955463497
# 32: 0.6666666865348816 -> 0.5073012946485089
# 33: 0.6666666865348816 -> 0.5230129397423828
# 34: 0.6666666865348816 -> 0.5387245848362568
# 35: 0.6666666865348816 -> 0.5544362299301308
# 36: 0.6666666865348816 -> 0.5701478750240048
# 37: 0.6666666865348816 -> 0.5858595201178787
# 38: 0.6666666865348816 -> 0.6015711652117527
# 39: 0.6666666865348816 -> 0.6172828103056266
# 40: 0.6666666865348816 -> 0.6329944553995005
# 41: 0.6705882549285889 -> 0.6487985219268401
# 42: 0.6705882549285889 -> 0.6646025884541795
# 43: 0.6705882549285889 -> 0.6804066549815191
# 44: 0.6705882549285889 -> 0.6962107215088585
# 45: 0.6745098233222961 -> 0.7121072094696637
# 46: 0.6745098233222961 -> 0.7280036974304687
# 47: 0.6745098233222961 -> 0.7439001853912737
# 48: 0.6745098233222961 -> 0.7597966733520788
# 49: 0.6745098233222961 -> 0.7756931613128838
# 50: 0.6745098233222961 -> 0.7915896492736889
# 51: 0.6745098233222961 -> 0.8074861372344939
# 52: 0.6784313917160034 -> 0.8234750466287645
# 53: 0.6784313917160034 -> 0.8394639560230351
# 54: 0.6784313917160034 -> 0.8554528654173057
# 55: 0.6784313917160034 -> 0.8714417748115764
# 56: 0.6784313917160034 -> 0.8874306842058469
# 57: 0.6784313917160034 -> 0.9034195936001176
# 58: 0.6784313917160034 -> 0.9194085029943881
# 59: 0.6823529601097107 -> 0.9354898338221243
# 60: 0.6823529601097107 -> 0.9515711646498605
# 61: 0.6823529601097107 -> 0.9676524954775966
# 62: 0.686274528503418 -> 0.9838262477387983
# 63: 0.686274528503418 -> 1.0
Max CDF increment: 0.016173752261201768
Min CDF increment: 0.014879852192684003
[Method 2] Sorted ranks suggest the mapping:
# 0: 0.6274510025978088 -> 0.0
# 1: 0.6313725709915161 -> 0.015873015873015872
# 2: 0.6352941393852234 -> 0.031746031746031744
# 3: 0.6392157077789307 -> 0.047619047619047616
# 4: 0.6392157077789307 -> 0.06349206349206349
# 5: 0.6431372761726379 -> 0.07936507936507936
# 6: 0.6431372761726379 -> 0.09523809523809523
# 7: 0.6431372761726379 -> 0.1111111111111111
# 8: 0.6431372761726379 -> 0.12698412698412698
# 9: 0.6431372761726379 -> 0.14285714285714285
# 10: 0.6431372761726379 -> 0.15873015873015872
# 11: 0.6470588445663452 -> 0.1746031746031746
# 12: 0.6470588445663452 -> 0.19047619047619047
# 13: 0.6509804129600525 -> 0.20634920634920634
# 14: 0.6509804129600525 -> 0.2222222222222222
# 15: 0.6549019813537598 -> 0.23809523809523808
# 16: 0.6549019813537598 -> 0.25396825396825395
# 17: 0.6549019813537598 -> 0.2698412698412698
# 18: 0.658823549747467 -> 0.2857142857142857
# 19: 0.658823549747467 -> 0.30158730158730157
# 20: 0.658823549747467 -> 0.31746031746031744
# 21: 0.658823549747467 -> 0.3333333333333333
# 22: 0.658823549747467 -> 0.3492063492063492
# 23: 0.658823549747467 -> 0.36507936507936506
# 24: 0.6627451181411743 -> 0.38095238095238093
# 25: 0.6627451181411743 -> 0.3968253968253968
# 26: 0.6627451181411743 -> 0.4126984126984127
# 27: 0.6627451181411743 -> 0.42857142857142855
# 28: 0.6627451181411743 -> 0.4444444444444444
# 29: 0.6666666865348816 -> 0.4603174603174603
# 30: 0.6666666865348816 -> 0.47619047619047616
# 31: 0.6666666865348816 -> 0.49206349206349204
# 32: 0.6666666865348816 -> 0.5079365079365079
# 33: 0.6666666865348816 -> 0.5238095238095238
# 34: 0.6666666865348816 -> 0.5396825396825397
# 35: 0.6666666865348816 -> 0.5555555555555556
# 36: 0.6666666865348816 -> 0.5714285714285714
# 37: 0.6666666865348816 -> 0.5873015873015873
# 38: 0.6666666865348816 -> 0.6031746031746031
# 39: 0.6666666865348816 -> 0.6190476190476191
# 40: 0.6666666865348816 -> 0.6349206349206349
# 41: 0.6705882549285889 -> 0.6507936507936508
# 42: 0.6705882549285889 -> 0.6666666666666666
# 43: 0.6705882549285889 -> 0.6825396825396826
# 44: 0.6705882549285889 -> 0.6984126984126984
# 45: 0.6745098233222961 -> 0.7142857142857143
# 46: 0.6745098233222961 -> 0.7301587301587301
# 47: 0.6745098233222961 -> 0.746031746031746
# 48: 0.6745098233222961 -> 0.7619047619047619
# 49: 0.6745098233222961 -> 0.7777777777777778
# 50: 0.6745098233222961 -> 0.7936507936507936
# 51: 0.6745098233222961 -> 0.8095238095238095
# 52: 0.6784313917160034 -> 0.8253968253968254
# 53: 0.6784313917160034 -> 0.8412698412698413
# 54: 0.6784313917160034 -> 0.8571428571428571
# 55: 0.6784313917160034 -> 0.873015873015873
# 56: 0.6784313917160034 -> 0.8888888888888888
# 57: 0.6784313917160034 -> 0.9047619047619048
# 58: 0.6784313917160034 -> 0.9206349206349206
# 59: 0.6823529601097107 -> 0.9365079365079365
# 60: 0.6823529601097107 -> 0.9523809523809523
# 61: 0.6823529601097107 -> 0.9682539682539683
# 62: 0.686274528503418 -> 0.9841269841269841
# 63: 0.686274528503418 -> 1.0
Max rank-based increment: 0.015873015873015928
Min rank-based increment: 0.015873015873015817
Here, the max and min "increment" sizes are used as a simple measure of "how uniform" the resulting distribution of values is. In both cases, it's pretty clear the distribution of observed values becomes much more uniform after the transformation. Arguably, I think the rank-based one should be preferred, since it is a bit simpler, faster, and exact, but the final results should be visually indistinguishable at realistic resolutions for the input noise.
An important note: this seems to be very slow on more reasonable resolutions (e.g., it took at least an hour, maybe as many as 3, on a 1080 x 1080 example I tested early on). I haven't carefully profiled it, and it could definitely be better optimized (or easily, aggressively parallelized in some places). I would recommend only using the rank-based approach (which will cut out the np.cumsum, at least), and of course commenting out or deleting the parts of this you don't actually need (e.g., prints), but -- in any case -- just be aware that this isn't particularly speedy, as written, on realistic resolutions.
All that is left to do after this is to actually encode this mapping; as @RobinBetts noted in the comments above, a standard Blender Color Ramp node is fine for this. Doing so may be a bit a tedious unless inserting new fitting points in a Color Ramp can be done programmatically, from Python (alternatively, one could fit a polynomial, spline, etc using standard numpy or scipy functions and then approximate those with Blender shader nodes; ultimately, this won't be much different from directly fitting the above mappings into a Color Ramp, though). You could also choose to just use a small subset of the overall mapping, rather than encoding all of it in your Color Ramp, if the results look OK visually from using a subset of points (and you might use, say, the rate-of-change in input pixel values to determine where you need more or fewer Color Ramp control points).
In Blender 2.83 (in case this is version-dependent), I played around a bit with the Python API access to ColorRamp nodes. It looks like controls can be added to them programmatically pretty easily; so, if desired_points = [(0.6274510025978088, 0.0), (0.6313725709915161, 0.015873015873015872), (0.6352941393852234, 0.031746031746031744), (0.6392157077789307, 0.047619047619047616), ...] is a list of (original_pixel_value, new_pixel_value) pairs as generated by (a slight modification of) my code snippet above, an existing ColorRamp Shader Node in Material.001 named ColorRamp (assumed here to be in its default state; specifically, to have 2 control points already, at position 0.0 and 1.0) could be programmatically modified to add all of the required control points, like:
for i, (old_val, new_val) in enumerate(desired_points):
print(f"Adding new ColorRamp point # {i} at position {old_val} (type: {type(old_val)})")
bpy.data.materials["Material.001"].node_tree.nodes["ColorRamp"].color_ramp.elements.new(position=float(old_val))
elems = bpy.data.materials["Material.001"].node_tree.nodes["ColorRamp"].color_ramp.elements
print(f"Desired points has {len(desired_points)} points")
for i in range(1, len(elems)-1):
print(f"Accessing point {i-1}")
new_val = float(desired_points[i-1][1])
elems[i].color[0] = new_val
elems[i].color[1] = new_val
elems[i].color[2] = new_val
This seems like a nice way to complete the final step (although, note that I haven't tried this at realistic resolutions; I would not be surprised if Blender has a practical and/or absolute limit on how many control points can be added, so some care may need to be taken in selecting a subset of control points even so).
Notable Limitations/Extensions
- behavior outside of the empirically tuned-to region
- haven't displayed examples of visual behavior, nor shown how the results may differ depending on the input node type
- ways to use simple averaging to (at the cost of a more expensive shader nodes setup) enforce uniformity over a wider selection of regions (this is pretty easy, possibly useful, and I may edit this to add an example of it later)
- if one knew how to evaluate the Shader nodes noise distributions directly in the Python API, or to re-implement them, this could be done without using rendering as complicating intermediate
- I suspect someone who knows more about OSL than I do might be able to write a custom shader node to replace the Python completely, which would be nice (and should be much faster!). Blender's built-in nodes offer pretty limited ability to combine spatially distinct pixels, unfortunately, so doing things like computing the ranks of all pixels' color values is very difficult
- in very small sub-regions, as noted above, the goals of uniformity (over the entire domain of possible color values) and continuity are in conflict: if we have just 16 pixel values, say, reorganizing them to be "uniformly distributed" is going to have lots of very large jumps. An intriguing tweak to try to get something like this to work in small sub-regions would be to maintain the empirically observed min and max pixel value in these regions, rather than normalizing to
[0,1] as the min and max color intensities. By taking this approach and using a (more expensive) Shader nodes setup designed to do smoothed averaging between neighboring regions (so that each sub-region's uniformizing-map is very strong when in that region, very weak outside of it, and smoothly declines in strength the further you are from the region's center), it is probably possible to get a stronger kind of "local uniformity" without compromising continuity
- due to the render-to-a-plane workaround, this won't work for 3-D or 4-D noise (although, you could render a bunch of 2-D slices, and then generalize the code to combine them)
