Is WPF be able to manipulate large bitmaps where GDI+ cannot due to memory limitations?
I have bitmaps that are 10,000x10,000 easily, and could even be much larger than that. Worst case I think I can break the single bitmap into large tiles and work with that I guess.
I basically need to do four things
Take an set of tiled images
Put all of those tiles into a single bitmap
Convert the bitmap to black and white
Scan the bitmap looking for changes from black to white
I know how to do these things in GDI+, but the problem I am running into is that the size of my bitmap is too large for the machine I am using, and it causes the program to crash, and I cannot make the image any smaller, so I am hoping that WPF will be able to succeed where GDI+ has failed me.
I don't think WPF will be able to help you here.
Why do you want to use bitmap object? You may as well work with an two-dimensional array of bytes or doubles (or any other type, depending oh what accuracy and range do you need), especially if you work with one channel only. Bitmaps have accessor methods (GetPixel and such) with huge computational overhead, working with arrays is by orders of magnitude faster (I know from personal experience), the only issue is that you can't display them as they are (you would have to convert the array back into image, which is fairly simple). But since you seem to want to do some sort of analysis on the data, I think array would be much more suitable for your needs.
I can post code samples detailing conversion from bitmap (either WPF or WinForms) to array an back if you want.
But remember, that 32bit .NET application can use approximately 1.2-1.4 gigabytes of memory - you have to fit in this space or you start getting OutOfMemory exceptions.
I eventually decided that the best course of action was to only work with the tiles, and then have an array that holds the actual information about each tile that I need. Given the number of tiles, it was the only sensible thing I could do.
Like CommanderZ said. Its Windows PRESENTATION Foundation, not Windows Image-manipulation Foundation.
You should try to either find some kind of image-manipulation library, but looking at size of your image, then doing everything yourself might be only way.
Especialy, you probably wont be able to work with bitmap as a whole, so you are going to work with tiles. Then it becomes problematic if you need to work with neighboring pixels. But I guess you should look into this yourself.
Related
can anyone give me a quick comparison what are pros and cons of System.Windows.Media.Imaging.WriteableBitmap compared to System.Drawing.Image?
Why I'm asking because I have an program/api where I can basically choose between which one I want to use.
I know that not both can bind to the same controls for instance, but I'm interested a bit more in terms whats "under the hood".
The api I want to use is for displaying "realtime"/"fast" images and therefore have a fps of about 20-30 (if this matters somehow for the comparison).
Well in case you want to go low level (well its still c# not c++) but the writeable bitmap allows for locking of the bitmap data, to run some unsafe code against it (usually graphics stuff needs super fast dirty trick logic processing )
So if you plan to go low level, work with pointers and stride, then i would go for it. BTW you can create functions to exchange formats, if all you want to do is displaying an image, maybe rotate or flip it or thinking about displaying stream data into an an image i'd choose the other one.
I need to speed up my image viewer, and wondering if I should be looking into creating my own DirectX control to do so.
My image viewer displays medical images. They can be pretty large. We're talking 55mb when it comes to mammography. The pixel data is 16bit greyscale stored in a ushort array. Without getting into the gory details, my current approach is loading the pixel data into an ImageSource, and using the WPF Image control.
I've never done anything with DirectX. Is it worth diving into it? Would it be any faster than the native WPF stuff? If so how significantly? Or, should I just forget about DirectX and look into areas where I can improve my current approach?
Before somebody says so, I know WPF utilize DirectX. I'm wondering If removing the WPF layer and writing the DirectX myself will improve performance.
I have some experience drawing multi-gigabyte satellite and chart imagery. Working with imagery around 55MB should probably work okay even without trying to optimize it too much. You haven't really given enough detail to recommend one alternative over the other, so I will give my opinion on the pros and cons.
Using 2D windows APIs will be the simplest to implement and should always be fast enough if you don't need to rotate and simply want to display an image and zoom and pan around. If you treat it as one large image the performance will not be as good when you zoom out if you are drawing with halftoning to give a nice smooth image. This is because it will effectively have to read all 55mb of image every time it draws.
To get around this performance issue you can make multiple bitmaps, effectively mip-mapping your image. As you zoom out you can pick the reduced resolution image closest to the resolution you are trying to draw . If you are not familiar with mip-mapping here is a Wikipedia link:
http://en.wikipedia.org/wiki/Mipmap
Implementing it with DirectX will be 10x as difficult. Different graphics hardware has different maximum texture sizes. Most likely you will need to break your image up in to multiple textures to draw and you will also have to keep track of render states, viewing matrices, etc.
However, if you do use DirectX, you can implement lots of real-time photo adjustments You can do real-time rotation by simply adjusting view matrices. You can do real-time contrast, brightness, gamma, and sharpness easily in a pixel shader.
There are two other API's I might suggest. If you are willing to limit yourself to Vista or later then Direct2D would be a little simpler than Direct3D. Also if you ever will need to implement it on a non-windows platform I would suggest using OpenGL instead. My current project is in Direct3D because a few years ago when we started it OpenGL was falling behind and I didn't forsee the popularity of Android devices. I now wish we had used OpenGL instead.
Try profiling to see where WPF is spending its time. Are you displaying the images at their native resolution? If not it might be worthwhile to do some preprocessing and create 1/2 resolution versions.
I'm developing depth processing (Xbox Kinect, Asus Xtion, etc) applications using OpenNI.
I need a really simple and fast way of drawing on a Windows form when new depth data is available from the sensor (30 or 60 fps depending on resolution).
Currently I'm invalidating a double-buffered panel from a seperate thread when the data becomes available, and then setting pixels of a bitmap in the panel's paint method, yielding a predictably awful 5fps.
System.Drawing.Graphics seems to lack a fast way to set individual pixels, unless anyone can instruct otherwise.
I literally just need to set pixel colours, so would like to avoid using third party high speed rendering APIs if possible, and ideally use something as native as possible.
Does anyone have any suggestions?
If you're using Bitmaps, then you should use LockBits and UnlockBits to access the data directly in memory. In C#, you can get some extra performance by using unsafe code blocks and pointers.
See this link for more information: http://web.archive.org/web/20150227183132/http://bobpowell.net/lockingbits.aspx
image.SetPixel() is very slow when you are replacing many pixels per frame and you need many frames per second.
It will be a lot faster when you use a WriteableBitmap and call CopyPixels
This way you can fill the array with pixel data using multiple threads and simply blit the array to the image in a single call.
EDIT
Note that WriteableBitmap is a WPF class. If you are bound to WinForms you might need to create your own implementation. WPF/WinForms/GDI interop: converting a WriteableBitmap to a System.Drawing.Image?
You could try my LINQ image processing library to work with your "buffer-bitmaps". It uses an accessible LINQ syntax but is very performant for large bitmaps. It is available on Nuget as a single file include in your project.
Hope that helps!
I have a .NET GDI+ bitmap object (or if it makes the problem easier a WPF bitmap object) and what I want to to is shift the whole lot by dx,dy (whole pixels) and I would ideally like to do it using .NET but API calls are ok.
It has to be efficient bacause its going to be called 10,000 times say with moderately large bitmaps.
I have implemented a solution using DrawImage - but its slow and it halts the application for minutes while the GC cleans up the temp objects that have been used.
I have also started to work on a version using ScrollDC but so far have had no luck getting it to work on the DC of the bitmap (I can make it work buy creating an API bitmap with bitmap handle, then creating a compatible DC asnd calling ScrollDC but then I have to put it back into the bitmap object).
There has to be an "inplace" way of shifting a bitmap.
mikej
Have you found the Graphics.FromImage method? That will let you manipulate the bitmap directly. I'm not sure what you're using with DrawImage, but Graphics.DrawImage should let you copy an area of the bitmap onto itself (and apply a shift in the process).
Alternatively, given a Graphics object, you can use Graphics.GetHdc, ScrollDC and Graphics.ReleaseHdc.
Do you just want to move the whole graphic? DrawImage has x,y parameters to do that. I'm probably not interpreting your question correctly.
As an aside, GDI is not going to be efficient period when you're working with 10,000 images. If you want anywhere near real-time performance you're going to have to either rework your algorithm or look into a 3D API (like DirectX or OpenGL) or possibly both.
Sorry if my question wasn't too clear.
All I'm trying to do is in place scroll a bitmap i.e. do a shift operation.
For example, a method like Scroll(B,1,0) would shift the entire bitmap B one pixel to the right.
I've got reasonable solution using both DrawImage and the ScrollWindowEx API call which is about 10 time faster.
I'm still trying to work out how I could do something faster using WPF.
I've written up my solution to the problem at Scrolling a bitmap but I'm still not sure that there isn't a better way and if it might be better done in say WPF?
I'm trying to visualise a graph and allow people to play with it. I found the excellent Graph# library that can create an initial layout so that part is covered. Now I need to make a control that actually draws it and provides the necessary interactivity.
Graph# comes with a nice visualiser itself, however I don't like it because it is written in WPF (while my app is WinForms), and because I want to add some more interactivity options, which would require quite a remake of it anyway.
The graphs I'm drawing will routinely be pretty large, at about 100 vertices and the same amount of edges (the graphs will be trees 99% of time). That means that the resulting rendering can be up to 2000px by 2000px and even more. The users should be able to zoom in and out, scroll, highlight and drag vertices and edges, and get some popups with additional info when hovering the cursor above a vertex.
I'm worried that the standard System.Drawing might not be able to deliver a decent speed for this. I would like the dragging/zooming/scrolling operations to be smooth, and the popups should open with a little animation as well. Something like 20fps should be a necessity.
I know I can try to speed things up by pre-rendering a lot of the elements and keeping them as bitmaps in memory - but that would probably take up lots of RAM, and I'm still not sure if it would deliver the necessary performance.
What are your thoughts?
"Premature optimization is the root of all evil"
GDI+ can be great for your needs. Don't go and buy 3rd party libraries before you know you even need them.
I've done a thousand polygons on a 1000x800 pixel bitmap and redrawn it completely at over 100 frames per second, using just GDI+
That being said, if you have a lot of drawing to do, and your resolution is big.. Some of the 3rd party drawing libraries can go WAY beyond what managed GDI is capable of.
I recommend leaving Graph# alone, and just hosting it in your Windows Forms application.
The performance you will receive will be much better than trying to reimplement it in System.Drawing.
GDI+ will be plenty fast enough for what you're doing, especially if (as it sounds from your description) everything you're drawing is rectangles and vertical/horizontal lines. Polygons and non-linear shapes are a bit slower, but not much (the speed difference is partially dependent on the SmoothingMode of your Graphics object). Drawing cached Bitmaps with resizing is also quite fast, although it can slow down significantly if you use a high-quality InterpolationMode setting.
As a benchmark, I wrote a .Net Compact Framework GPS application for Windows Mobile that rendered about 10,000 lines on the screen in realtime. This only achieved a frame rate of a few frames per second, but the processing power on a Smartphone is, of course, way less than a modern PC.