Quantum Pixels (QP): Synchronized probabilistic pixels (SPP)

Support NatureHacker with TEEF Teeth Powder

Also known as Synchronized probabilistic pixels (SPP).  This idea combines the quantum screen idea with the moving pixel idea.  The thought is to use a probability curve to define a chance a pixel is white or black, red or blue, off or on, etc.  And then to synchronize this behavior with those around it.  So it is a 2 step process.  Of course the goal is to achieve a pixeless look.  So for example on a boundary between white and black; if pixel1's neighboring pixel(s) on the boundary happen to be white this refresh, then pixel1 would have a higher chance or 100% chance of bieng black.  So in this instance the black pixel (and white) will effectively be moving back and forth between spots. 

So like the previous blog post and the example above, based on where a pixel is located near a boundary it will have a "base probability" (BP) to be white or black.  If the pixel is several pixels back into the black side of the boudary, it will have a very high probability of bieng black.  For pixels near the boundary or right on it, they will have equal or nearly equal probabilities of bieng white or black this refresh.  Now that is the base probability.  Superimposed on that "base probability"  is a "proximity probability" (PP). What this is, is a probability inversely related to what the adjacent pixels actually pick.  So the base probability is set as soon as the screen image is decided.  Then the base probabilities of, for example, half of the pixels (randomly chosen) roll the dice and pick a color.  Next, the other half of the pixels have a proximity probability superimposed on their base probability.  So if nearby pixels roll black for this example, then the proximity probability would be higher for white.  The base probability would still be in effect though, the proximity probability would just be a modifier for the base probability.  So if the base probability for rolling white is 99.9% yet everything around it is white so the proximity probability is low, it will still most likely roll white.  Only at the boundaries will the proximity probabilities make a difference. 

Instead of half of the pixels choosing first you could have 1/3 or 1/4 or whatever.  The higher your refresh rate the fewer pixels have to choose at once.  The more rounds of selections the more diverse the results will be, but also the slower, resulting in motion blur.  This is why the number of rounds need to be adjusted based on the screens refresh rate (hz).  As you can see this will also habe the effect of screens lasting longer and reduce burn-in effects since things are constantly changing even on a static image.


This can be achieved by probability alone but not in a deterministic way.  In this iteration of the idea, the probability is more determined to make the pixel actually move rather than just going on and off or red to blue etc.  Why probability at all then, why not just make the pixel move like in the moving pixel idea? Well which direction do you make it move? That is the problem.  With the moving pixel idea you have to have it move in a path, and this takes a lot of pixel real estate.  With using synchronized probability then it can move in any direction   That is the heart of this idea.  Moving pixels that can move in any given direction while also taking up only 2 pixels (or more but the fewer the pixels the more HD the picture will be and less fuzzy)