Scale numbers to be <= 255?

Question

I have cells for whom the numeric value can be anything between 0 and Integer.MAX_VALUE. I would like to color code these cells correspondingly.

If the value = 0, then r = 0. If the value is Integer.MAX_VALUE, then r = 255. But what about the values in between?

I'm thinking I need a function whose limit as x => Integer.MAX_VALUE is 255. What is this function? Or is there a better way to do this?

I could just do (value / (Integer.MAX_VALUE / 255)) but that will cause many low values to be zero. So perhaps I should do it with a log function.

Most of my values will be in the range [0, 10,000]. So I want to highlight the differences there.

Answer 1

I could just do (value / (Integer.MAX_VALUE / 255)) but that will cause many low values to be zero.

One approach you could take is to use the modulo operator (r = value%256;). Although this wouldn't ensure that Integer.MAX_VALUE turns out as 255, it would guarantee a number between 0 and 255. It would also allow for low numbers to be distributed across the 0-255 range.

EDIT:

Funnily, as I test this, Integer.MAX_VALUE % 256 does result in 255 (I had originally mistakenly tested against %255, which yielded the wrong results). This seems like a pretty straight forward solution.

Answer 2

The value you're looking for is: r = 255 * (value / Integer.MAX_VALUE). So you'd have to turn this into a double, then cast back to an int.

Answer 3

In general (since it's not clear to me if this is a Java or Language-Agnostic question) you would divide the value you have by Integer.MAX_VALUE, multiply by 255 and convert to an integer.

Answer 4

This works! r= value /8421504;

8421504 is actually the 'magic' number, which equals MAX_VALUE/255. Thus, MAX_VALUE/8421504 = 255 (and some change, but small enough integer math will get rid of it.

if you want one that doesn't have magic numbers in it, this should work (and of equal performance, since any good compiler will replace it with the actual value:

r= value/ (Integer.MAX_VALUE/255);

The nice part is, this will not require any floating-point values.

Answer 5

The "fairest" linear scaling is actually done like this:

floor(256 * value / (Integer.MAX_VALUE + 1))

Note that this is just pseudocode and assumes floating-point calculations.

If we assume that Integer.MAX_VALUE + 1 is 2^31, and that / will give us integer division, then it simplifies to

value / 8388608

Why other answers are wrong

Some answers (as well as the question itself) suggsted a variation of (255 * value / Integer.MAX_VALUE). Presumably this has to be converted to an integer, either using round() or floor().

If using floor(), the only value that produces 255 is Integer.MAX_VALUE itself. This distribution is uneven.

If using round(), 0 and 255 will each get hit half as many times as 1-254. Also uneven.

Using the scaling method I mention above, no such problem occurs.

Non-linear methods

If you want to use logs, try this:

255 * log(value + 1) / log(Integer.MAX_VALUE + 1)

You could also just take the square root of the value (this wouldn't go all the way to 255, but you could scale it up if you wanted to).

Answer 6

The best answer really depends on the behavior you want.

If you want each cell just to generally have a color different than the neighbor, go with what akf said in the second paragraph and use a modulo (x % 256).

If you want the color to have some bearing on the actual value (like "blue means smaller values" all the way to "red means huge values"), you would have to post something about your expected distribution of values. Since you worry about many low values being zero I might guess that you have lots of them, but that would only be a guess.

In this second scenario, you really want to distribute your likely responses into 256 "percentiles" and assign a color to each one (where an equal number of likely responses fall into each percentile).

Answer 7

For a linear mapping of the range 0-2^32 to 0-255, just take the high-order byte. Here is how that would look using binary & and bit-shifting:

r = value & 0xff000000 >> 24

Using mod 256 will certainly return a value 0-255, but you wont be able to draw any grouping sense from the results - 1, 257, 513, 1025 will all map to the scaled value 1, even though they are far from each other.

If you want to be more discriminating among low values, and merge many more large values together, then a log expression will work:

r = log(value)/log(pow(2,32))*256

EDIT: Yikes, my high school algebra teacher Mrs. Buckenmeyer would faint! log(pow(2,32)) is the same as 32*log(2), and much cheaper to evaluate. And now we can also factor this better, since 256/32 is a nice even 8:

r = 8 * log(value)/log(2)

log(value)/log(2) is actually log-base-2 of value, which log does for us very neatly:

r = 8 * log(value,2)

There, Mrs. Buckenmeyer - your efforts weren't entirely wasted!

Answer 8

If you are complaining that the low numbers are becoming zero, then you might want to normalize the values to 255 rather than the entire range of the values.

The formula would become:

currentValue / (max value of the set)

Answer 9

Note that if you want brighter and brighter, that luminosity is not linear so a straight mapping from value to color will not give a good result.

The Color class has a method to make a brighter color. Have a look at that.

Answer 10

The linear implementation is discussed in most of these answers, and Artelius' answer seems to be the best. But the best formula would depend on what you are trying to achieve and the distribution of your values. Without knowing that it is difficult to give an ideal answer.

But just to illustrate, any of these might be the best for you:

• Linear distribution, each mapping onto a range which is 1/266th of the overall range.
• Logarithmic distribution (skewed towards low values) which will highlight the differences in the lower magnitudes and diminish differences in the higher magnitudes
• Reverse logarithmic distribution (skewed towards high values) which will highlight differences in the higher magnitudes and diminish differences in the lower magnitudes.
• Normal distribution of incidence of colours, where each colour appears the same number of times as every other colour.

Again, you need to determine what you are trying to achieve & what the data will be used for. If you have been tasked to build this then I would strongly recommend you get this clarified to ensure that it is as useful as possible - and to avoid having to redevelop it later on.

Answer 11

Ask yourself the question, "What value should map to 128?" If the answer is about a billion (I doubt that it is) then use linear. If the answer is in the range of 10-100 thousand, then consider square root or log.

Another answer suggested this (I can't comment or vote yet). I agree.

r = log(value)/log(pow(2,32))*256

Answer 12

I figured a log fit would be good for this, but looking at the results, I'm not so sure.

However, Wolfram|Alpha is great for experimenting with this sort of thing:

I started with that, and ended up with:

r(x) = floor(((11.5553 * log(14.4266 * (x + 1.0))) - 30.8419) / 0.9687)

Interestingly, it turns out that this gives nearly identical results to Artelius's answer of:

r(x) = floor(255 * log(x + 1) / log(2^31 + 1)

IMHO, you'd be best served with a split function for 0-10000 and 10000-2^31.