I have created an MFC application using OpenCV. Currently is very basic,
just load an image or a video and playback the video.
In both cases though, I can not see any image appearing in the Image Watch.
In the built in Locals view I can see the cv::Mat structure and all its members.
I am using Visual Studio 2012 update 4.
Hi, I am using non-signalling NaNs to represent 'no pixel' in floating point images but it is producing inconsistent results when Auto-Maximize contrast is used. Sometimes it forces the image to be wholly black, sometimes it 'just works' as expected. How are they handled and could they be ignored for the purposes of maximizing the contrast? A way of specifying the 'valid' value range would be a way round this also I'd imagine.
Thanks for a great add-on, it's proving indispensable. :)
Cool, thanks. I expect similar problems occur with +-INF, DNF, and other special values. I don't expect it's worth it right now but there might be some value in visualising these special pixel states in the image preview (perhaps symbols on the pixels once zoomed in enough :)
I'm afraid your scenario is not supported in the current version.
We do support planar images, though, which means you can visualize a list of images inside one data structure as one image with different channels. However, all planes must have the same resolution and pixel format. One reason for this limitation is that it is not straightforward to display a collection of arbitrary-sized images (you could make some sort of collage, I guess, but it's tricky to get that right all the time).
The supported YUV video formats are exceptions to this rule. That's because their resolution ratios are known and simple (2x, 4x), and so we can resize the lower resolution planes and visualize everything a single image.
Back to your problem: are you referring to RGB-D images by any change? I think RGB-D is becoming quite common nowadays and we should be able to support it as a specialized format in ImageWatch (like the YUV formats).
This looks very useful. However, the viewer always shows [invalid] where the image would be disaplyed, and in the two lines next to the thumbnail.
I'm using OpenCV 2.4.2 and 2.4.6
VS2012 Update 3.
Thanks for any suggestions.
Additonal info after reading conversation with Mills back on Aug 2.
The app is a C#. We have another project that that supports C++/CLI. It is in the C++/CLI project that we create the Mat objects and use the openCV methods.
I'm beginning to think that even though I have mixed mode debugging disabled, and have enabled native code debugging in the app, Image Watch will not display an image if the Mat objects are in a C++/CLI project.
The good news is that Image Watch does support C++/CLI. However, since it builds on Visual Studio's natvis (NATive VISualizer) mechanism, you need to make sure that that works. This should never be an issue with purely native projects, but mixed mode projects require that you get a few settings right.
First, you can tell that natvis works if Visual Studio's built-in Locals window expands cv::Mat variables to something like "[width]" "[height]" etc., instead of the raw class members ("data", "step", etc).
If natvis doesn't work with your current setup, make sure to
1) Attach a purely native debugger, not a mixed one. Note that "enabling native code debugging" in the C# project properties means "managed + native = mixed", not "native only". So you may have to attach to the running process via Debug->Attach, instead of the more convenient "Debug->Start Debugging").
2) Turn off Tools->Options->Debugging->Managed C++ Compatibility Mode
3) Put "#pragma unmanaged" guards before any of your OpenCV code. This will ensure that your OpenCV code is actually native, not managed.
Let me know if that helps.
Never got it working with your suggestions a few months ago. I just updated to VS2013 so I thought I'd give it a try, since this would be really useful. Here's where I'm at now:
> expands cv::Mat variables to something like "[width]" "[height]" etc.,
> instead of the raw class members ("data", "step", etc).
VS does expand the Mat class to about 20 members including cols and rows as well as step and size. So I assume natvis is working.
> So you may have to attach to the running process via
I manually attached to my app with only the "native" debugger selected. Unfortunately, now I can't even set a break point. VS tells me that "No executable code of the debugger's target code type is associated with this line"
> Put "#pragma unmanaged" guards before any of your OpenCV code.
The compiler complains that #pragma unmanaged cannot be used because it is a managed class (C++/CLI)
Is there something else that I am missing?
sorry for the trouble :/
What you're experiencing sounds like a known Visual Studio quirk around mixed mode debugging and natvis visualizers. Here's some more information on that topic: http://social.msdn.microsoft.com/Forums/vstudio/en-US/fdbc4e51-f3f3-40bd-8fd5-369e1594ec74/debug-visualizer-support-in-mixedmode-apps-has-regressed-in-vs-2012
In your particular case, please note that natvis is *not* working if VS expands cv::Mat into the ~20 members including cols, rows, etc. If it *is* working, you will see [width], [height], etc. instead. I assume that when you attach the native-only debugger to your running app (as opposed to launching under the mixed mode debugger), natvis starts working?
The other phenomenon you're seeing is that VS cannot set breakpoints on your C++/CLI code. That's because even though that code looks like C++, it is compiled to managed (not native) code, and the native-only debugger doesn't understand that. You can, however, force the compiler to produce native code with the #pragma unmanaged directive. I believe the reason why that didn't work for you is that somewhere after your unmanaged #pragma there is code which is inherently managed, e.g. a managed class definition, or any code that uses managed references ("^")?
Here is my suggestion. Move all OpenCV code either to the end of the .cpp file, or better yet, to a different .cpp file or library altogether, which is compiled as native C++ only (no CLR). Use as small an interface as possible to call the native code from managed. This will not only enable ImageWatch (or natvis in general, e.g. for std::vector), but it may increase the performance of your app because it minimizes managed/unmanaged transitions at run-time.
Hope that helps!
we are planning to release another update within a few weeks. It will include some bug fixes and a few new features based on feedback from this forum as well as internal (Microsoft) needs.
Is there anything specific you're looking for?
Thanks for clarifying! Yeah there are a lot of interesting proposals in this forum.
From my stuff I think the "set default range of valid image values via natvis" feature would be nice to have in the next release. I guess tiled image support isn't ready yet, is it?
I cannot figure out how to specify the pixel format using the @mem operator.
I've tried this (and several other variants), but I can't get it to work:
The only method that works is to specify the number of channels, but "4" always implies RGBA. I am trying to get BGRA to work.
Is this even possible using the @mem operator?
you're right. The third argument to the @mem operator currently only parses numbers. Sorry :| We may extend it to parse strings like 'RGBA' the future, but generally, we've been thinking of the @mem operator more as a sort of fallback mechanism (as opposed to registering image structs/classes that are displayed automatically), hence the reduced functionality.
OK.. your choice of course, but I do believe it's worthwhile supporting the @mem operator in full. I don't know if you guys know of the old "imdebug" project (http://billbaxter.com/projects/imdebug/), but I did enjoy the printf-like syntax of that tool. It's quite often that I just want to image-debug a "bunch of bits", instead of a well defined structure, and being able to use an operator like @mem really fits the bill there.
Yes and no :)
The longer answer: We do have this functionality internally (see the "Custom decompression routines" thread from March 1, below). We haven't had the cycles yet to make it ready for public release, though. The feature is implemented through custom visualizer DLLs instead of .natvis files, which allows us to keep the natvis schema simple for the most common scenarios. But we need to be extra careful with the DLL feature, much more than with nativs, since these user-provided DLLs run inside the Visual Studio process and can therefore hang/crash/etc. your entire IDE. So, yes, it's planned, but it's a somewhat larger work item.
It would be really nice if you could set a default range of valid image values via the natvis, cause e.g. for 10 or 12 bit images norm8 and norm16 don't help and @scale(.., 0.00..) alters the values. But even then you always have to type it in manually. Auto-contrast doesn't work in all cases either since you may have outliers like the default initializer 0xCD the debug runtime uses or values that are defined as invalid like -9999.
As an extension of that one could even allow specifying default operations in the natvis via a synthetic node.