There appear to be some places in Houdini where Red is Blue and vice versa.
See the scene and screenshots, this was tested under Hou11.0.581/Win64, 11.0.834/Win64, 11.1.118/Win64 and 11.1.206/Win32.
1) using 24-bit TGAs as textures - this only happens in OGL (tested with both NVidia & ATI cards), Mantra renders them properly, COP/File reads them correctly as well;
2) COP ChannelCopy - see pictures 2 and 3, and examples in /img/comp1 … I don't know if this is related somehow to problem #1, ChanCopy actually has the channels in its menu listed in “reversed” order - C.b, C.g, C.r (so is this a bug or just a typo in the interface?);
3) Python - CopNode.allPixels(“C”, “r”) returns the blue pixels, “b” returns the reds - see example Python COP filter in the scene;

#1 seems like a bug clearly, but what about ChannelCopy? I seem to remember that it works this way since Hou9. But CopNode has this quirk as well. So maybe these are related problems.

I believe the ChannelCopy COP simply alphabetizes the list, and alphabetically, the order of RGB is reversed I recall resolving similar issues with OpenEXR, which alphabetizes its channels in a STL map.

So this means there is actually a bug in ChannelCopy?
I mean, when I'm saying “set C.r to Input2: C.r” what it actually does is “set C.b to Input2: C.b”. I used to just select the first component on the list as R, never actually reading the name, so this went unnoticed for some time.
Is it possible that the source of this bug is the same as swapped channels in CopNode.allPixels()?