Quote Originally Posted by dilettante View Post
Those ShLwAPI calls only use 0-240 for the 3 elements even though 16-bit WORD arguments are used. Weird, hmm?
That isn't the only weird thing. The fact that they are using 16-bit WORDs at all is weird. Saturation, luminance and brightness in the HSB and HSL colour spaces are usually represented with floats between 0.0 and 1. Just about any code you find online treat these components as percentages.

Quote Originally Posted by dilettante View Post
I used a hack for those oddball colors. If the "adjusted" color is black but the original color was not black... I restored the original color of that pixel and moved on to premultiply.

It seems that the ShLwAPI calls "blackhole" any colors not within their colorspace, i.e. return 0 without any other error indication.
I find this interesting. My own HSL code has no problem handling any colour in the RGB space yet ShwAPI rejects some of them. I would really love to know why it rejects them. Whatever it's doing was very beneficial in this specific case.

However, when I compare what I did in PixelPainter to what you did in this sample, there are some differences. For example, you add the hue angle from the sliders to the hue angle of the pixels whereas I just give all the pixels the slider's hue angle. You did the same for saturation. Perhaps there is something in these differences.