The best way to understand something is getting your hands dirty…
So let’s try again: first a sample image color-toned in RTdev.
Quite striking difference, in my opinion. The only thing changed between them is the working profile, shown in the image. Those are screen captures, so both images have suffered the same conversion to the display profile.
Note how different are all the colors, not only the most saturated. You can say the sRGB is mostly a desaturated version, but I can see different hues, not desaturated hues.
Now a simple explanation with it’s own flaw, that I will comment later:
This is a CIELuv graph, which shows colors in a more perceptual way than the traditional CIExy diagram.
Here I have hand-plotted approximately the same coordinates (RGB values) in both color spaces (smaller triangle is the sRGB gamut; bigger triangle is the ProPhoto gamut), and you can easily see how much different the resulting colors are.
The drawback of this example is that RGB values can’t be plotted in this diagram (nor in the CIExy diagram) straight away, as the RGB color model is three-dimensional, and the diagrams are just a 2-D projection of the real 3-D coordinates. So the points I have plotted shouldn’t really be that far away. But I think you can get the idea anyway.
The point is, no matter what the maths are behind the Color toning tool behavior, after you have applied some toning to your image, if you change the Working profile the colors of the toning also change.
Similarly, if you apply certain sRGB coordinates in an image where RT expects e.g. ProPhoto coordinates, you won’t get the hue you expect.
And almost everybody in the Internet thinks, works and talks in sRGB terms (even RT defaults to sRGB in several places), so most probably the patches and images you will find published all over the web will be encoded in sRGB, unless stated.
You may think that this is an RT bad behavior, but I truly think this is how it should work, but (a big but) it lacks some way of specifying to which color profile and to which color model the coordinates you enter pertain.
Hardcoding an assumption that all the custom coordinates will be given in sRGB, and then automatically convert them into the proper working profile would be flawed from the start, because that way you would never be able to use toning hues outside the sRGB gamut.
Hope it makes more sense now.
@Thanatomanic, sorry but I can’t understand what the algorithm does with the color values (the value entered in the O field). I only said what I think RT does based on «this is what I see, so this is what most probably RT is doing».