none
Specifying the Height of a Resize Rectangle in DrawImage RRS feed

  • Question

  • I am making a WinForms app using VS2012 c++/cli and using DrawImage to display HD images captured from a webcam.

    The images are 1920 x 1080 bitmaps that I am trying to display on a Panel control. The Panel is 240 x 135 (i.e., exactly 1/8 of the HD image).

    I am calling DrawImage as follows:

        System::Drawing::Rectangle destRect = System::Drawing::Rectangle(0,0,Cam0Panel->Width,Cam0Panel->Height);
        g->DrawImage(b,destRect);

    This should specify to draw the image at the relative 0,0 location on the panel and size the image to be 240 x 135. However, the image does not display and the app crashes.

    If I change the Height parameter to specify the Panel->Bottom (which is the absolute position in the app - ~630), the image does display and is correctly sized for width but is not correctly sized for height.

    Any idea what I am doing wrong or how to correctly resize and display the image?

    Here is a complete version of the code.

        void Cam0Panel_Paint( Object^ /*sender*/, System::Windows::Forms::PaintEventArgs^ e )
        {
            System::Drawing::Bitmap^ b = ImageWinArray[CHANNEL_SELECT0];
            Graphics^ g = e->Graphics;
    
            g->InterpolationMode = System::Drawing::Drawing2D::InterpolationMode::Bilinear;
            g->CompositingMode = System::Drawing::Drawing2D::CompositingMode::SourceCopy;
            System::Drawing::Rectangle destRect = System::Drawing::Rectangle(0,0,Cam0Panel->Width,Cam0Panel->Bottom);
    
            g->DrawImage(b,destRect);
        }

    Thanks for any help.

    Monday, March 30, 2015 10:37 PM

Answers

  • I don't know, probably you've encountered a bug on GDI+ that it overflows and writes "write protected" memory region?

    That's beyond what I can offer help for, perhaps if your company has MSDN support quota you can open a support case, save the original bitmap and send them to take a look. If this is later proofed to be a Windows bug, you should not be charged.

    Btw, just a final question what is the ->RawFormat of original bitmap? See if I can find relevant news that whether it's a published known bug.

    EDIT: Since you mentioned it's webcam image, is there possibility the image array got updated half the way while painting? How about duplicate the target bitmap object before using it for DrawImage()?

    Since for Bitmaps they usually call LockBits() before updating the pixels (for the sake of speed), it's logical that the memory could become "protected from read" half the way.


    Tuesday, March 31, 2015 6:02 AM
    Answerer

All replies

  • Maybe you should set a breakpoint to see what are the values of Panel->Bottom and Panel->Height at the time to see what is so special that cause it to crash?
    Tuesday, March 31, 2015 1:44 AM
    Answerer
  • Yeah, I did that. In addition, I have hardcoded the values as the parameters.

    Same issue.

    Tuesday, March 31, 2015 1:55 AM
  • Try to wrap the code in try...catch block and see if any hint is given on the exception messages. Exceptions that thrown from GDI+ usually also gives HResult that may give you some hint on what actually happened.
    Tuesday, March 31, 2015 2:08 AM
    Answerer
  • I did that too and no exception is being reported.

    Tuesday, March 31, 2015 2:25 AM
  • That's strange, in my experience .NET runtime seldom just crash without converting errors to exceptions. Have you tried to add a generic unhandled exception handler to your main application, or search the event log for application error events?
    Tuesday, March 31, 2015 2:31 AM
    Answerer
  • I just tried this:

                try
                {
                    g->DrawImage(b,destRect);
                }
                catch(System::Exception ^e)
                {
                    System::String ^temp;
                    temp = gcnew System::String(e->GetType()->ToString() + " exception!!!");
                    System::Windows::Forms::MessageBox::Show(temp,"Paint Run Time Error GPU Check!",MessageBoxButtons::OK,MessageBoxIcon::Error);
                }

    Nothing was reported but I still crashed when using 135 for the height. If I hardcode 636 for the height, I see an improperly sized image.

    Tuesday, March 31, 2015 2:45 AM
  • Add a global exception handler for your application in attempt to catch all unhandled exceptions, it can sometimes catch exceptions that would be missed otherwise.

    Also try to see if any exception message is written on your application log of Event Viewer.

    EDIT: See this post for reason on why the debugger won't catch the exception, and how you get around that.

    Tuesday, March 31, 2015 3:02 AM
    Answerer
  • OK.  This is getting me somewhere.  When I changed the debugging exceptions, it now reports a "SystemAceessViolation - attempting to read or write protected memory" on the DrawImage call.

    Weird that this happens depending on what value you enter for the Height.

    Any ideas on what is causing this?

    It is certainly not a referencing error (e.g., passing a pointer instead of the value pointed to) as I have hardcoded the numbers in and still see this issue.

    Is it possible that it is the bitmap itself?  Some sort of restriction on it?

    Tuesday, March 31, 2015 4:48 AM
  • I don't know, probably you've encountered a bug on GDI+ that it overflows and writes "write protected" memory region?

    That's beyond what I can offer help for, perhaps if your company has MSDN support quota you can open a support case, save the original bitmap and send them to take a look. If this is later proofed to be a Windows bug, you should not be charged.

    Btw, just a final question what is the ->RawFormat of original bitmap? See if I can find relevant news that whether it's a published known bug.

    EDIT: Since you mentioned it's webcam image, is there possibility the image array got updated half the way while painting? How about duplicate the target bitmap object before using it for DrawImage()?

    Since for Bitmaps they usually call LockBits() before updating the pixels (for the sake of speed), it's logical that the memory could become "protected from read" half the way.


    Tuesday, March 31, 2015 6:02 AM
    Answerer
  • Your questions led me to the problem.

    I neglected to initialize the array holding the images with a bitmap that would survive the scope of the initialization.

    Unfortunately for me, the error revealed itself in a weird way and could only be triggered by setting the resize amount properly.  For some reason, resizing by a large amount vertically would work.

    Once I traced this to the bitmap, I was able to track the problem down.  Talk about a frustrating error.

    Thanks for helping.

    Wednesday, April 1, 2015 6:51 AM