EDIT2: BTW surt, this report is still accurate after your posted fix for ptoing's error below.
I think I found
a bug -- entered 3 in the middle field, left others at 2. In the link, you can see that the result is clipped.. and also there don't appear to be 2**3 == 8 distinct Green levels, rather, there are still 4 distinct levels and they are used .. improperly? Well, the result doesn't quite make sense when you look at it, that's for sure.
testing some other values:
2, 3, 3 looks correct
2, 2, 3 does not
3, 2, 2 looks correct
1, 2, 3 does not
3, 2, 1 does not
3, 1, 2 does not
2, 3, 1 does not (wow, very not)
2, 1, 3 does not
I've looked over the code, but nothing jumped out at me as being wrong in a way that would cause this effect.
(also, your code has caused my opinion of JavaScript to rise. Doing that in that little code? It ain't NumPy, but it's pretty good.)
FWIW, the levels readout always appears correct, so those arrays must be populated correctly. The image metrics also seem to be correct (although I haven't tried with super corner cases like ptoing).. So I guess that the bug is about the arrays being indexed incorrectly.
I'm not sure what you mean. They only effect how the number of levels (which can be calculated from a bit depth) are evaluated at 8-bit per channel.
Well, to my mind, bits per channel is a compact way of specifying levels per channel -- 2 means 2**2 == 4 levels, 4 means 2**4 == 16 levels, etc. Which is why it made sense to me that the setting for how these N intensities were mapped to the 0..255 continuum would be shared between them -- bpc is just a different notation for entering number of levels.
Yes, the current formatting is an improvement.
The Levels readout to help easily tweaking custom levels is helpful, too.