C# RGBA to ARGB using shifts
When I see this question, I immediately understand what you are trying to do as a bitwise rotation (also known as a circular shift). You need to either rotate the bits in the value left by 24 or right by 8 (they yield equivalent results). As the bits are shifted off one end, they're inserted back in the other end.

Ironically, this is one of those rare cases where the code is conceptually simpler in assembly language (!) than it is in C#. The x86 processor family has two very simple instructions that accomplish precisely this feat—ROL and ROR—which rotate left and right, respectively. That means the code in assembly language is almost as simple as:

rol  value, 24


Whereas it is actually more work—and less obvious what is being done—when writing the code in C or C#. You have to explicitly notate both parts of the circular shift. The canonical form is:

public static UInt32 RotateLeft(UInt32 value, UInt32 amount)
{
    Debug.Assert(amount &lt; 32, "Attempted to rotate by more bits than are in the value.");
    return (value &lt;&lt; amount) | (value &gt;&gt; (32 - amount));
}

public static UInt32 RotateRight(UInt32 value, UInt32 amount)
{
    Debug.Assert(amount &lt; 32, "Attempted to rotate by more bits than are in the value.");
    return (value &gt;&gt; amount) | (value &lt;&lt; (32 - amount));
}


Note that I've explicitly used the UInt32 type here, instead of the short name uint. This is because I've hard-coded assumptions about the type's width, and I like things to be obvious. UInt32 is obviously always a 32-bit type. At least for me, since I bounce back and forth between languages, that's not always so obvious with uint. 

I've also thrown in an assertion to check that we're rotating by a reasonable amount. That's just an assertion, though, not an exception, because the C# language standard guarantees that the shift amount will be masked, such that only the lower 5 bits will be used (resulting in a value from 0 to 31). This means that the language protects you from the undefined behavior you would get in C by trying to shift by too many places. (Again, ironically, so does x86 assembly language.)

So this is basically the generalized form of the code that you have. A call like:

argb = RotateLeft(rgba, 24);


would essentially inline to:

argb = (rgba &lt;&lt; 24) | (rgba &gt;&gt; 8);


There is one major difference, though. I've written the code to work with unsigned types, rather than signed types. In fact, bitwise operations should always be done on unsigned types because when you do bitwise operations, you are essentially treating the value as a field of bits, rather than as a number. Using an unsigned type is not only conceptually more correct, but also saves you from bugs.

C# automatically differentiates between signed and unsigned shifts (based on the type of the value you're shifting), which is why you found that your code needed that extra mask. The result was being padded with the most significant bit of the number being shifted because that's how a signed shift works—in effect, it does a signed extension, where the sign bit (the most significant bit) is repeated to preserve the sign of the value. (Note that this distinction is only relevant for right shifts; signed and unsigned left shifts are exactly the same.)

But that's something you don't want to have to think about, and something that you wouldn't have to think about if you just follow the rule that bitwise operations imply unsigned types.

So the correct code is precisely what pgs already suggested:

public static UInt32 ToARGB(UInt32 rgba)
{
    return (rgba &lt;&lt; (3*8)) | (rgba &gt;&gt; 8);
}


But you might also want to consider Eric Lippert's advice about logical representations. It is merely an implementation detail that these color values are stored as unsigned 32-bit integers. Therefore, it would make sense to wrap that implementation detail up inside of a structure, so that the client never has to deal with the messiness.



Unfortunately, the C# JIT compiler doesn't seem to be able to produce as efficient of code here as a C compiler would. In C or C++, your function would be transformed directly into that assembly-language instruction I mentioned above. In C#, you get 4 instructions instead of that one:

mov  ecx, eax    // make extra copy of value
shl  ecx, 8      // shift that copy left by 8
shr  eax, 24     // shift original right by 24
or   eax, ecx    // combine the two



Oh well. That's still as efficient as you're going to get.