THE best and most amazing plugin ever! Makes coding so much more productive, and more fun as well.
If you want one suggestion on what to improve, I'd say @mem(...). I don't needed it often, but when I'd need it, I most of the time can't get it to work. It's kind of documented, but I'm never sure: Do I put in the name of the variable? or '&variable'? or the address? or the address with 0x...? or...? and more often than not it's not working, and also not printing any error/debug information.
I think what would be useful as well is a small button that opens a menu that shows all the operators you can use, and their syntax - like a small documentation inside.
But those are just some tiny suggestions. It is incredible as it is!
This is indeed a game changer! Debugging in-memory images has always been so hard in VS. The simple power of Image-Watch visualization, combined with the efficient operators can turn hours of debugging to minutes or seconds.
Oh, I see from the help that I got to through the Image Watch window shows that the image types that this plug in has support from are not WIN32 objects. Forget it, this isn't what I'm looking for. I don't think the Extensibility section will allow for this either. :(
I cannot update Image Watch recently (from 1.5.1103.0 to 1.5.1106.0) in Visual Studio 2013. The error is related to .Net Framework: The extension 'Image Watch' requires a version of the .Net Framework that is not installed.
I think the issue is related to my installation of Visual Studio 2015 Preview which install .Net FrameWork 4.6 Preview. I think ImageWatch is not aware that I still have 4.5 installed due to 4.6 being also installed.
Thank you for this great extension.
I have various flavours of Visual Studio 10,11,12, 13 (2010, 2013, and 2015 CTP preview).
I'm getting startup failures reported without log entries and when I go to update add-ins, this add in won't update for some spurious nonsense reference to .net. I have every .net that has ever been released and pre-released. This is a good tool and a better idea. Shame it can break so easily.
thanks for reporting this. We haven't seen this in our tests yet. Could you please share some more information about your setup so we can repro?
Versions of VS installed?
Order or VS installs?
In which version of VS do you see the error message?
Did you have (an older) IW installed and working before you installed 2015?
When exactly do you get the error message (during install, VS startup, or debugger startup)?
Can you build and run a C# project in VS that targets .NET 4.5?
Update: after searching around a bit it seems that other extensions are having the same issue since they installed VS 2015. I still don't have a repro but I will find out if Visual Studio is planning to issue a fix, or if we have to change something on our end.
In the meantime, can you please try the workaround below? This has been posted on the "VSCommands" extension's forum, which had the same issue.
Rename .vsix file to .zip and open archive
<Dependency Id="Microsoft.Framework.NDP" DisplayName="Microsoft .NET Framework" Version="4.5" />
<Dependency Id="Microsoft.Framework.NDP" DisplayName="Microsoft .NET Framework" MinVersion="4.5" />
More info here: http://nakedalm.com/installing-visual-studio-2015-side-side-2013-windows-10/
Looks like the issue is related to the Update feature in the extension dialog in Visual Studio 2013. I was able to successfully update Image Watch by running the .vsix file directly (I did not do any modification to the manifest).
I also tried on a different user account (same PC). Image watch was not installed on that user account. Using the extensions dialog I failed to install (not update) Image watch for the same reason (.Net framework). I was able to install the extension with the vsix file though.
Hope this will help.
OK, we published another update yesterday.
The update has the same binaries and version number (1.5.1106). The only difference is the how the .NET dependency is specified in the manifest file. We hope that this fixes the issue.
Thanks again for reporting this.
Any plans on adding support for 64 bit integer images?
I am currently trying to use ImageWatch to visualize Eigen matrices and have it partially working for the int32, float and double types, but it fails if I want to use int64_t since 64 bit integers are not in your supported types list.
I could contribute a patch if I can get access to the source code.
Here are the partially working natvis for Eigen::Matrix types:
Please note that they only work properly for RowMajor matrices. For column major the image is displayed as if it was transposed. You can however make it look right by using the @flipd operator.
many thanks for sharing your Eigen visualizers!
At this time we don't have plans to support 64 bit integers, sorry :/. One workaround might be to interpret the data as a two-channel 32bit image and, if needed, use the @band operator to look at the "low-word" vs "high-word" image. Certainly not optimal, but maybe better than not seeing anything at all?
I have my own image format with a buffer (same logic with opencv) and a wrapper class for opencv. Old version of Image Watch was able to display my images directly from my image format by clicking at the magnifier icon next to the pointer that points to the buffer. It was also same for the wrapped format where I clicked at the icon next to the buffer pointer.
After the update, magnifier icon does not appear at all in my image format. In the wrapped format, I get [Raw] field and cv::Mat under it where the magnifier icon appears.
What has changed with the update and why do I face with this situation?
sorry to hear that. We didn't change anything that would result in what you're seeing (at least not intentionally).
Would you mind sharing the definition of your wrapper class and the .natvis file you wrote for it?
I have MSVC 2012 express and can't install Image Watch. What should I do to install it? Here is the log I get:
03.04.2015 21:00:26 - Supported Products :
03.04.2015 21:00:26 - Microsoft.VisualStudio.Pro
03.04.2015 21:00:26 - Version : [11.0,13.0)
03.04.2015 21:00:26 -
03.04.2015 21:00:26 - References :
03.04.2015 21:00:26 - -------------------------------------------------------
03.04.2015 21:00:26 - Identifier : Microsoft.VisualStudio.MPF.11.0
03.04.2015 21:00:26 - Name : Visual Studio MPF 11.0
03.04.2015 21:00:26 - Version : 11.0
03.04.2015 21:00:26 - MoreInfoURL :
03.04.2015 21:00:26 - Nested : No
03.04.2015 21:00:26 -
03.04.2015 21:00:26 -
03.04.2015 21:00:26 - Searching for applicable products...
03.04.2015 21:00:27 - Found installed product - Microsoft Visual Studio Express 2012 for Windows Desktop
03.04.2015 21:00:27 - Found installed product - Global Location
03.04.2015 21:00:27 - VSIXInstaller.NoApplicableSKUsException: This extension is not installable on any currently installed products.
Visual Studio Express does not support extensions (i.e. plug-ins, like Image Watch).
I would switch to the "Community" edition of VS: https://www.visualstudio.com/en-us/products/visual-studio-community-vs.
The Community edition is free, just like the Express editions, and it supports extensions like Image Watch.
I have a image class with protected width, height & data. They are all accessible via member functions. Is there a way to write the .natvis file so that the image can be displayed correctly during debugging?
Hi Alexanderwyx, the debugger has access to all data members regardless of their access specifiers (public/protected/private). In other words, you can access your data members in the natvis as if they were public. Is that what you meant?
I have quite similar question to one Alexanderwyx asked. I'd like to display a QImage instance from the Qt 5 library (see http://qt-project.org/doc/qt-5.0/qtgui/qimage.html for ref.) and an access to necessary data is only through member functions: width(), height(), bits() etc. Both the @mem operator and the .natvis file need member variables which in this case is problematic. Can you implement such a feature in the next release?
looking at the Qt 5 implementation I believe you should be able to visualize QImage objects with the current version of ImageWatch. QImage has a data member "d" which is a pointer to a QImageData object. QImageData has data members called "width", "height", "bytes_per_line", "format", and "data". QImage::width() simply returns d->width, so you should be able to do the same in your natvis (see example below). For pixel format, you can query QImageData's "format" member using the "Condition" attribute in the natvis.
So here's how I think your natvis could work. This example supports ARGB32 (5) and RGB888 (13) formats; you can add more, of course. Plase note that there could be errors, since I don't have a Qt build environment and couldn't test it.
<Synthetic Name="[type]" Condition="d->format==5">
<Synthetic Name="[type]" Condition="d->format==13">
<Synthetic Name="[channels]" Condition="d->format==5">
<Synthetic Name="[channels]" Condition="d->format==13">
Please let me know if this solves your problem.
Thank you Wolf for the hint. It looks like the "d" data member of QImage class is an opaque pointer and in order to force VS "see" QImageData members I must include a private header of QImage (QtGui\5.0.2\QtGui\private\qimage_p.h). Then finally Image Watch works with QImage.
The problem is with a monochrome image where the image is stored using 1 bit per pixel. A part of d->data (a row the image) indicated by d->bytes_per_line almost always contains some rubbish at the end because the data chunk rounds to bytes. Do you have any idea how to cope with this?
great to hear that QImage works now! Thanks for pointing out the privateness of qimage_p.h. I hadn't noticed that. It's a little awkward, of course, to have to include that header, but I hope the better debugging experience makes up for it :)
I can see the problem with 1-bit-per-pixel formats (QImage::Format_Mono?). Unfortunately, there's no good workaround with the current version of Image Watch, since we don't support non-integer strides. Sorry..
I just found ImageWatch and love it. Thank you. Others might be interested in supporting QImage/QPixmap without adding a private header into their build. I cannot do that. Here is a definition for QImage that will work without the private header for all the 32bpp formats:
<Synthetic Name="[channels]" Condition="(*(int*)(((char*)d)+48))==4">
<Synthetic Name="[channels]" Condition="(*(int*)(((char*)d)+48))==5">
<Synthetic Name="[channels]" Condition="(*(int*)(((char*)d)+48))==6">
If you always assume raster QPixmap objects, then you can also make a definition for QPixmap. Here is a sample entry for width:
I am using a Visual Studio 2013, update 4 & open CV 22.214.171.124 with a very simple program that loads a png file into a open CV Mat object.
In the image watch window the variable is shown & identified as cv::Mat but it is shown as invalid. Also when i hover the mouse over the variable the magnifying glass does not appear so I can not add it to the watch list.
The thing is, this extension used to work and I found it very useful. I also have this problem with VS2010 & VS2012 too!
Any suggestion as to how I might get this excellent extension working again?
sorry to hear that. Do you see this problem with all projects/solutions? Are you doing mixed-mode debugging by any chance (Windows Store App, C++/CLI project, ..)? Do you remember if you installed or updated VS or OpenCV since the last time it worked?
I first noticed it in a native C++ project. I then wrote a very simple native C++ project that only read in a png file and stored it in a cv::Mat object. Image Viewer does not work properly with both projects.
I don't think I have done an update to VS but I did install open CV 126.96.36.199, but I don't know for sure if it worked before that or not.
I was debugging an opencl related routine when, suddenly, all of my Mat's became [invalid] on the Image Watch -- it simply stopped woring. It turns out I had a float variable named cv, and after renaming it to something else, the Image Watch started working again.
thanks so much for reporting this! This is a bug.
And it's a pretty interesting one. Here is what happens: to determine the width of a cv::Mat image at address, say, 0x123456, Image Watch uses Visual Studio's debug expression evaluator to evaluate an expression like this: ((cv::Mat*)0x123456)->cols. Now, if "cv" is a variable in the current scope, the expression evaluator returns an error: "name followed by '::' must be a class or namespace name". You can repro this by typing the above expression in the Visual Studio Watch window.
It seems that casting to "::cv::Mat*" instead of "cv::Mat*" fixes the problem, although I haven't had the time to fully verify this. We'll hopefully have a fix for this soon.
Thanks again for your feedback!
could you give me a code snippet to explain, how to use and where to place an operator? I would like to use @mem operator to display image from memory:
RawImage(const unsigned char* data, int size, int width, int
unsigned char* data;
I tried this .natvis (snippet):
however, this is evaluated as "invalid image".
Thanks a lot!
since you have an image class (RawImage) you don't actually need the @mem operator. The @mem operator is used to inspect raw memory, i.e. pixel data that is not "wrapped" by a C++ object which knows about the image's format, width, height, etc.
Looking at your natvis I can see two issues. First, the [channels] string says "RGB8Packed", which is not a supported format. You should use RGB. Second, the natvis does not have a [stride] item, which is required by Image Watch.
Note that your case is very similar to the "Example 1" natvis on our help page at http://research.microsoft.com/en-us/um/redmond/groups/ivm/imagewatchhelp/imagewatchhelp.htm. It may be a good idea to start with that very example and modify it in small steps (while keeping it working) until you arrive at your "RawImage" definition.
Hope that helps!
I would expect "Zoom to Original Size" would show the image on the screen pixel perfectly, but I found that's not always the case which can be misleading.
An example: I'm viewing a 11x16 image in "original size":
Zoomed in version: http://i.imgur.com/z5QfX4T.png
If you look closely, you can see there are some grey (not purely black or white) pixels. On the original image, there are only black and white pixels, see:
Also note, that the "Original size" image is 12x18 which is clearly not really the original size, but a slightly resized size of the image.
thanks a lot for reporting this! We will consider aligning the pixels with physical pixels so that the interpolated (gray) values go away. The size difference you're seeing is related to that as well.
In the meantime I would suggest zooming in when working with such tiny images. The interpolation effect you describe becomes negligible once an image pixel covers, say, 32x32 physical pixels on the screen.