Clipboard.SetImage and larger images


  • Hi,

    According to experiments on my system, Clipboard.SetImage seems to work correctly only with images smaller than something like 1300x1000 pixels (estimation). Bigger images are put into clipboard but some other applications are not able to retrieve them (I've been testing it with Adobe Photoshop). Is this a known bug? Is there any workaround other than using System.Windows.Forms.Clipboard?

    Thanks for info, Martin

    Thursday, June 07, 2007 2:47 PM

All replies

  • If the image can be successfully retrieved by some applications, but not others, then it would seem like a bug with those applications. There may be technical limitations on the size of clipboard data, but I couldn't find any references that stated there was a specific limit for image data. Can you paste into Microsoft Paint larger images from your application?

    How are you setting the bitmap data into the clipboard?

    Does the System.Windows.Forms.Clipboard behave differently?

    I know recent versions of Photoshop can handle larger images than that pasted from the clipboard as I routinely have pasted images of my desktop which is much larger than the number you stated.
    Saturday, June 09, 2007 2:36 PM
  • I haven't had a time to thoroughly analyze it. From what I've seen on net, I had a feeling that System.Windows.Clipboard might have some serious issues so I decided to ask here first, just in case it is a known bug. What I've found out for the time being, is that Photoshop behaves consistently - i.e. never accepts images of a size larger then certain size, Paint usually works, but I cannot say for sure right know it never failed. What seems weird to me is that when I copy image of e.g. 2000x2500 pixels onto clipboard, the memory usage of my application increases about more than one hundred megabytes. Even in case of RGBA the image should not take much more than 20MB of memory, so it seems System.Windows.Clipboard.SetImage is putting the image into clipboard in many different formats and each one takes a hell of a lot of memory. Maybe the workaround would be to stop using SetImage and put the image into clipboard in one format which most image manipulation applications accept (BMP, DIB, ...?). I'll elaborate when I have time to look into it carefully.

    Sunday, June 10, 2007 6:28 PM
  • I am having the same issues. In my case, I'm copying a visual from on screen and adding it to the clipboard as a bitmap.


    It appears that it has to do with overall area, not any one dimension. Here are some sizes that work and don't work when try to copy onto the clipboard from my app and then paste into MS Paint.



    {1791,1705} = 3,053,655

    {1890,1658} = 3,133,620

    {3442,771} = 2,653,782



    {1791,1866} = 3,342,006

    {2239,1596} = 3,573,444

    {1908,1658} = 3,163,464

    {4589,771} = 3,538,119


    You can see that when the area gets to be around 3.15 million, it no longer works. And yes, the memory issue is a big problem as well. When the program first starts up and is just running, it takes ~60 MB to display large amounts of content in the visual, but then copying the visual to the clipboard causes my memory usage to jump to over 175 MB (and it doesen't go back down). In fact, it seems to jump around erratically, sometimes zooming up to as much as 800 MB, depending on the size of the visual.


    When I copy into Paint, I get the error "The information on the Clipboard can't be insterted into Paint". And sometimes I also get "There is not enough memory or resources to complete the operation. Close some programs, and then try again."


    For reference, here's the code I'm using (PageSizer is the visual I'm copying -- note it's inside a scrollviewer, hence the funny layout logic to copy everything correctly):

    private void scvPageViewer_MouseRightButtonDown(object sender, MouseButtonEventArgs e)


    RenderTargetBitmap bmpCopied = new RenderTargetBitmap((int) Math.Round(PageSizer.ActualWidth), (int) Math.Round(PageSizer.ActualHeight), 96, 96, PixelFormats.Pbgra32);


    Size szRender = new Size(PageSizer.ActualWidth, PageSizer.ActualHeight);

    PageSizer.Arrange(new Rect(new Point(0, 0), szRender));





    // any part of the visual cannot be copied if it is to the left of the scrollable window (off the right edge is fine)

    // so we must render it in the visible area and then re-render where it was previously

    PageSizer.Arrange(new Rect(new Point(-1 * scvPageViewer.HorizontalOffset, -1 * scvPageViewer.VerticalOffset), szRender));



    Can anyone tell me what's going on, and how to solve the problem?



    Wednesday, September 05, 2007 5:38 PM
  • Upon further analysis of this situation, it appears that it is not directly a problem with the number of pixels in the image. It's a limitation of memory on the machine it's running on. To copy a 1,000 x 10,000 pixel image takes a half a gig of memory. If there's enough memory on the machine to paste it, then it will work.


    However, that in and of itself IS a major problem with the Clipboard. Is there any reason why this should be taking this much memory to copy. Just going through the motions but commenting out the Clipboard.SetImage() line does not cause any memory increase. Thus the problem seems very specific to the Clipboard.


    Any ideas? Thanks in advance.


    Thursday, September 06, 2007 4:50 PM
  • So you're saying it takes 500,000,000 bytes for a 10,000,000 pixel image?  That's 50 bytes per pixel uncompressed...

    Needless to say I am having the same problem.  My PNG files save as 29kb files.  I have to disable the "copy to clipboard" feature for this version of my code.

    Has anyone found a fix for this?

    Granted, I am trying to do 3600x1681 pixels, which is overkill for any screen...but you really need that kind of res for printing a nice image!!!

    Microsoft?  Anyone?

    Why doesn't the app release the extra memory after the call to Clipboard.SetImage finishes?

    Dang it my copy-to-clipboard feature worked just fine yesterday...(and reverting my changes doesn't fix the problem!)
    Monday, October 20, 2008 6:37 PM