A grey cloud with nearly identical RGB (red-green-blue) intensities of (for example) 127, 128, 128 is susceptible to 
phantom colors when we start embedding bits.  127 is 01111111 in binary; any bits we embed will tend to reduce its 
intensity.  128 is 10000000 in binary; any bits we embed will tend to increase its intensity.  The bScatter algorithm 
eliminates this discrepancy.

Here's how it works: suppose we want to embed three bits in each image byte.  For each, we add a random number in the range 
0 thru 7 to the current value, embed the three bits, then subtract the same number back out.  (if we were embedding four 
bits, the random number would be 0 thru 15, etc.)

What random number do we use?  One that the program conjures up which would look truly random to an outside observer but is 
the same on extract as embed for that particular pixel-color byte, when extract password matches embed password.

Consider starting value 127, or 01111111.  If the random number is 0, we'll replace low bits 111 with three embed bits, 
with value 0 through 7.  This will reduce the value stored by 0 (if the embed bits are 111) through 7 (if the embed bits 
are 000).  But, if the random number is 1, we'll add that to the current value and get 10000000, into which we'll embed 
three bits, then subtract 1 back out.  Now the opposite is true: we'll increase the value stored by 0 (if the embed bits 
are 000) through 7 (if the embed bits are 111).

Consider starting value 128, or 10000000.  If the random number is 7, we'll add that and get 10000111, then replace low 
bits 111 with three embed bits, with value 0 through 7, then subtract 7 back out.  This will reduce the value stored by 0 
(if the embed bits are 111) through 7 (if the embed bits are 000).  But, if the random number is 0, we'll add that to the 
current value and get 10000000, into which we'll embed three bits.  Now the opposite is true: we'll increase the value 
stored by 0 (if the embed bits are 000) through 7 (if the embed bits are 111).

In each case, one particular random number will lead to a tie or reduction in the stored value for that pixel-color, and 
another random number will lead to a tie or increase.  Other random numbers will fill in the gaps in between, slightly 
tending to raise or slightly tending to lower the stored value.  Net result: no matter what the original stored value, the 
average change to it across multiple pixels will be zero.

On extract we hold the same random number for that pixel-color as when embedding, and add it to the now-stored value, then 
harvest the resulting bits.  This process has a side benefit of further obscuring the values of the bits embedded: they 
can't be known unless each random number is known.

Note that 127/128 (01111111/10000000) is not the only boundary which can lead to phantom colors.  Here are some others: 
191/192 (10111111/11000000), 63/64 (00111111/01000000), 223/224 (11011111/11100000), 159/160 (10011111/10100000),
95/96 (01011111/01100000), 31/32 (00011111/00100000), etc.  Eight more where xxx01111 -> xxx10000.