UPDATE from 06.11.2015
Since writing the original answer I installed updates for my Windows 7 x64. Now the original bug isn't there anymore but there still persists more fundamental bug which I observe in versions 8.0.4, 9.0.1, 10.0.1, 10.2 and 10.3 installed on the same system. This bug becomes evident when you look at the plots of horizontal channel intensity values generated by the code in the original answer. Below is output from version 10.3:

Original answer
I'm also on Windows 7 x64 and observe the same problem with Mathematica 10.2.
Here is a demonstration of what happens on the level of channel values. It supports Oleksandr's supposition that we have a color management issue here.
In a new Notebook I generate an image:
Image[ConstantArray[Range[0, 1, .001], {40}]]

Then I programmatically copy it as Bitmap, paste below the original and save the clipboard content in lst
(the following code should be evaluated in a Cell
placed after the output generated by the above code):
lst = Table[SelectionMove[EvaluationNotebook[], Before, EvaluationCell];
SelectionMove[EvaluationNotebook[], Previous, CellContents];
FrontEndTokenExecute[EvaluationNotebook[], "CopySpecial", "MGF"];
SelectionMove[EvaluationNotebook[], After, Cell, 1];
FrontEndTokenExecute[EvaluationNotebook[], "Paste"];
NotebookGet[ClipboardNotebook[]], {20}];
Here is how my Notebook looks afterwards:

Now I extract horizontal channel values for successive images and plot them separately for every channel:
channelData =
ImageData[ToExpression[#[[1, 1, 1, 1]]], Automatic, Interleaving -> False][[All,
20]] & /@ lst;
Column[ListLinePlot[channelData[[All, #]], PlotRange -> All,
PlotLabel -> {"Red", "Green", "Blue"}[[#]], ImageSize -> 700] & /@ {1, 2, 3}]

Indeed it looks like some color transformation is applied to image when you copy it as Bitmap which results in color degradation mainly due to clipping off color values after conversion and also due to rounding off errors.
I suppose that the FrontEnd relies upon some Windows functionality for rendering of an expression when you copy it as Bitmap. And even when what you copy is already an Image
, FrontEnd nevertheless handles it the same way.
The only workaround I can suggest is do not rely upon FrontEndToken
s for rasterization and use Rasterize
instead. Just for completeness, this answer demonstrates why we should not rely upon FrontEndToken
s even for exporting.
Workaround
In the comment William points to the thread which contains .NET
-based solution allowing to copy graphics into clipboard already in compressed PNG format with highest quality currently available in Mathematica. For your particular application the solution by Todd Gayley can be modified as follows (the following respects the styles of the selected Notebook):
Needs["NETLink`"]
CopyAsPNG[g_, opts : OptionsPattern[]] :=
CopyAsPNG[Rasterize[Style[g, Options[SelectedNotebook[]]], "Image", opts]];
CopyAsPNG[i_Image] := Module[{png, strm, dataObject}, InstallNET[];
png = ExportString[i, "PNG"];
NETBlock[strm = NETNew["System.IO.MemoryStream", ToCharacterCode[png]];
dataObject = NETNew["System.Windows.Forms.DataObject"];
dataObject@SetData["PNG", strm];
LoadNETType["System.Windows.Forms.Clipboard"];
Clipboard`SetDataObject[dataObject]]]
Checking:
ColorData["VisibleSpectrum", "Panel"] // CopyAsPNG
Paste[]

*.icc
, you will find there are a couple of them in there. These also exist in version 9 and the same slow startup problem exists in that, but the implementation is sufficiently limited that there are no other observable issues until version 10 as far as I know. $\endgroup$