We Keep Coding

Enable OpenCL with OpenCvSharp

I am using OpenCvSharp to despeckle an image (GaussianBlur + AddWeighted). It take ~1-2 second for a relatively small image (1000*1500 pixels), depending of the GaussionBlur ksize parameter. Apparently OpenCV can make use of OpenCL to leverage the graphic card power. So, I wonder why it is so slow with a quite recent graphic card (GTX 960).
Is there a OpenCvSharp setting to enable OpenCL?
(I tried Cv2.SetUseOptimized(true) with almost no, if some, change)

Part of my GUI is slow

I ran into a problem with my GUI.
My GUI has multiple parts in it.
The first one is for an image (from 500x500 to 3000x3000 and it has to update up to 4 times each seconds)
The second one is the main menu
The third one has buttons with options regarding the image. I am not showing all of them at once, I scroll through several menus and i render only the ones who are visible. (An example for the otpions is the pixelsize of the image)
I display the image inside a Viewbox which is 800x800px big. I stretch the image inside of the box with Stretch="{Binding Path=StretchMode}"
The Image I get is some kind of stream. I get multiple Images each second.
Now when I display an image, the first GUI part works fine (regardless of the image size) but the others sometimes have a heavy framedrop. I will give some examples:
Example 1:
The image is 500x500 pixel big. I can work without a framedrop and the whole gui updates correctly.
Example 2:
The image is 1500x1500 pixel big. I can work without a Framedrop and the whole gui updates correctly.
Example 3:
The image is 2500x2500 pixel big. The Image updates fast but the rest of the GUI have framedrop from 60 fps to fps and sometimes even to 1 fps.
My thoughts about this problem were:
Hardware is at its limit. But a look on the Taskmanager and CPU/RAM analysis with Visual Studios says it is allright.
It is too much to render for the GUI because 3000x3000 is big and 4 times each seconds is not slow either. After a test with loaded (I loaded them from a hdd-drive) 3000x3000 images (Same Datatype) it worked fast and without problems.
Too much changes of the GUI at once. I tried the Software with only 5 updates. Still the same problem.
Microsoft Prism event not occuring. This wasn't it either because it comes inside the Controller and is Raising the changes if there is a change. (I have a logger which writes logfiles and it is raising the Change event more than the GUI is really changing)
Usage of a different datatype. Possible but i tried out several. (BitmapSource, BitmapImage and WriteableBitmap)
Outsourcing some rendering options in another thread. Still no change.
I hope you can give me some ideas why the GUI has this behaviour.
If you need code, please tell me.
I am not using a VM.
The problem occurs on Windows 7 64 bit and Windows 8.1 64 bit (not testet on Windows 10)
My hardware differs. The problem appears on my laptop (Intel i7-4702MQ #2.2 Ghz, 8 gb ddr ram, intel board graphics) and on workpc's with different specs (the highest are: Intel Xeon with 3.5 Ghz, 128 GB DDR4 Ram and a Titan X and a 4k Monitor)

EDIT: Apologies, stack doesn't have my score high enough to comment, so comment-ish content here instead.
EDIT1: Process explorer (from Sysinternals) should be used perhaps as a low-hanging fruit to see what (if any) video resources have a high consumption. there is a tab/area in process explorer for looking at graphic resources. In process explorer you can do a 'select columns' and add GPU resources for easy viewing. Might be a good angle to try.
I would venture a guess at this point that we are dealing with a
An ETW trace with DPC data might be helpful. Also you don't mention if you are in a VM or not, a VM would make taskmanager reflect inaccurate resource consumption on CPU.
An example of how to collect such a trace is here: https://blogs.technet.microsoft.com/jeff_stokes/2012/09/18/how-to-collect-a-trace-for-audio-or-video-problems-in-windows-7/
In any event, I suspect you are looking at kernel drivers or IPC/DPC issues rather than just raw CPU consumption here. More data needs to be provided I think. (hardware specs, OS used, VM/not).

Direct video buffer access

when I comes to rendering things on screen using video card, only three options are available, if I understand correctly. These are
DirectX (or XNA)
OpenGL
Windows Driver Kit and creating minimal implementation of graphics driver
I have very little experience with DirectX or OpenGL, but from what I know you have to write a pixel shader program that tells rendering pipeline what to do with each pixel. These shaders are programmed in HLSL. But as far as I know, neither DirectX, nor OpenGL is able to return a pointer to a memory that I could write some byte[] buffer to from my C# program and get it rendered. Or am I mistaken here?
WDK might be a better choice, because it would be possible to implement absolutely minimal implementation of graphics driver that does nothing but returns pointer to a memory where I could write RGB data. So at one hand I could get rid of all the abstraction DirectX or OpenGL provides (and which I don't need), but at the other complexity of driver development is not exactly a time-saver.
Also, from what I have found while searching more information on this, in the old days of DOS there was an address 0B00 or similar that allowed developers to draw directly onto screen buffer. It's gone of course and no longer usable I guess, but I have read for compatibility reasons this memory spaces are still reserved. Is it possible to utilize this somehow?
What is the easiest way to get access to video memory from C# so I can write directly onto screen? Does DirectX or OpenGL provide such functionality, that would enable me to directly copy and array of bytes somewhere and get it rendered?

By using OpenGL's or Direct3D's built-in texture rendering capabilities, you can copy the pixel data from client side memory to server side memory and then have it render the texture on screen.
Note: With client side memory I mean the memory accessible from the program (on the CPU and in the RAM) and with server side memory I mean the memory on the graphics card. This has nothing to do with networking

Is it smart building an OpenGL C# application to replace GDI

I have developed a quite large application using MFC. Naturaly, I used GDI for drawing, CCmdTarget for event routing, and the document-view architecture.
It was a convenient development path.
Now, the client is interested in converting this application to .Net.
I would prefer (and they too) writing the new product in C#.
The application displays and interacts with thousands of graphic objects, so
I figured going with GDI+, although seems natuaral, can cause performance issues,
So I am thinking of using OpenGL, specifically - OpenTK - as the graphics library (it's 2D).
I know that OpenGL works differently that these Windows APIs, which rely on Invalidation of portion of the screen. OpenGL has a rendering loop which constantly draws to the screen.
My question is:
Is this an acceptable way to go, thinking of:
performance - will the users need special graphics cards (hardware?). It is graphics intensive, but it's not a high-end game
printing and print preview - are these things complex to achienve?
multiple selection and context menus
Is this library goes well inside windows forms?

I don't think so. Use WPF if you can or DirectX if you can't.
I know it might not be fair but if I'm programming on .NET (microsoft) on windows (microsoft) I'd rather use DirectX ... which is also from microsoft.
As a side note: don't reinvent the wheel. Recoding user controls in open-gl can be very time consuming, if you do make sure you have a good reason.

In my experience developing CAD-like software, the benefits of OpenGL and DirectX are fast depth testing, smooth rotation and panning, lighting and powerful texture capabilities. Obviously there are other benefits but, despite what most tutorials would lead you to believe, implementing a rendering system using either of these APIs is a significant undertaking and should not be taken lightly.
Specifically:
If it is a 2D app and you already have it implemented in GDI then switching to GDI+ will be much easier. Additionally, on modern hardware, 2D GDI or GDI+ can be about as fast as 2D OpenGL or DirectX. And ultimately, the end-user probably won't notice the difference, especially with double buffered support in GDI+.
You do not need (and probably don't want) a continuous rendering loop for your app. In OpenGL and DirectX you can explicitly invalidate the window when your scene changes.
If you go with OpenGL or DirectX you will need to consider putting your objects into display lists or vertex arrays (buffers) for fast drawing. This is not difficult but managing objects in this way adds complexity to the system and will most likely significantly change the architecture of your rendering system.
Printing in either OpenGL or DirectX can also be tedious. On the one hand you can render to a bitmap and print that out. However, for high quality images you may want vectorized images instead, which are difficult to produce with either of these rendering frameworks.
I would also stay away from writing GUIs in OpenGL or DirectX...unless you're really looking for a challenge ;~)
Finally, and this is just an annoyance from an install perspective, the Managed DirectX run-time library that must be installed on the user's machine is around 100 MB.

I have no experience with C#, but I have once built a layer system for a drawing program that used openGL for rendering.
To make this layer I asked openGL for the current framebuffer and converted it to an image to use as a texture under the current canvas. So I guess from there its pretty easy to go to printing and print preview.

Direct X and Open GL much faster than GDI+.

You can also use an TAO framework as an alternative to OpenTK.

Rendering graphics in C#

Is there another way to render graphics in C# beyond GDI+ and XNA?
(For the development of a tile map editor.)

SDL.NET is the solution I've come to love. If you need 3D on top of it, you can use Tao.OpenGL to render inside it. It's fast, industry standard (SDL, that is), and cross-platform.

Yes, I have written a Windows Forms control that wraps DirectX 9.0 and provides direct pixel level manipulation of the video surface.
I actually wrote another post on Stack Overflow asking if there are other better approaches: Unsafe C# and pointers for 2D rendering, good or bad?
While it is relatively high performance, it requires the unsafe compiler option as it uses pointers to access the memory efficiently. Hence the reason for this earlier post.
This is a high level of the required steps:
Download the DirectX SDK.
Create a new C# Windows Forms project and reference the installed
Microsoft DirectX assembly.
Initialize a new DirectX Device object with Presentation Parameters
(windowed, back buffering, etc.) you require.
Create the Device, taking care to record the surface "Pitch" and
current display mode (bits per pixel).
When you need to display something, Lock the backbuffer
surface and store the returned pointer to the start of surface
memory.
Use pointer arithmetic, calculate the actual pixel position in the
data based on the surface pitch,
bits per pixel and the actual x/y pixel coordinate.
In my case for simplicity I am sticking to 32 bpp, meaning setting a pixel is as simple as: *(surfacePointer + (y * pitch + x))=Color.FromARGB(255,0,0);
When finished drawing, Unlock the back buffer surface. Present the surface.
Repeat from step 5 as required.
Be aware that taking this approach you need to be very careful about checking the current display mode (pitch and bits per pxiel) of the target surface. Also you will need to have a strategy in place to deal with window resizing or changes of screen format while your program is running.

Managed DirectX (Microsoft.DirectX namespace) for faster 3D graphics. It's a solid .NET wrapper over DirectX API, which comes with a bit of performance hit for creating .NET objects and marshalling. Unless you are writing a full featured modern 3D engine, it will work fine.
Window Presentation Foundation (WPF) (Windows.Media namespace) - best choice for 2D graphics. Also has limited 3D abilities. Aimed to replace Windows Forms with vector, hardware accelerated resolution-independent framework. Very convenient, supports several flavours of custom controls, resources, data binding, events and commands... also has a few WTFs. Speed is usually faster than GDI and slower than DirectX, and depends greatly on how you do things (seen something to work 60 times faster after rewriting in a sensible way). We had a success implementing 3 1280x1024 screens full of real-time indicators, graphs and plots on a single (and not the best) PC.

You could try looking into WPF, using Visual Studio and/or Expression Blend. I'm not sure how sophisticated you're trying to get, but it should be able to handle a simple editor. Check out this MSDN Article for more info.

You might look into the Cairo graphics library. The Mono project has bindings for C#.

Cairo is an option. I'm currently rewriting my mapping software using both GDI+ and Cairo. It has a tile map generator, among other features.