Theoretically, it should be 65,535 x 65,535 given you have enough memory, about 17GB.
However, creating a .NET 4.5 Console Application to test it out, it throws System.ArgumentException: Parameter is not valid.
The application is built for 64bit platform. Running on 64bit platform with 32GB of memory. Maximum resolution I've been able to get is 22,000 x 22,000 pixels.
I could not find any documentation on this.
And odd behavior is that even at 22,000 x 22,000 pixels, it doesn't always work. It sometimes works, and it sometimes throws the exception. This make me think it's related to contiguous memory allocation, but there is about 30GB of free memory.
Does anybody have any experience with this? And if I wanted to work with say, 100,000 x 100,000 pixel image and larger, what would be the best way besides implementing my own bitmap?
EDIT: The problem isn't .NET Maximum Object Size. This can be overcome by targeting for 64bit platforms, and setting the gcAllowVeryLargeObjects flag in the application config. In this way, I can get the application to consume over 15GB of memory with a single array of integers. So far, the answer seems to lie in the underlying implementation of the GDI+, but how do I get around it?
This is a GDI+ limitation imposed by Windows. GDI+ creates a memory-mapped file view for the pixel data of the bitmap. That makes it very efficient, bitmaps tend to be large and the MMF helps to keep the pixel data out of the paging file. RAM pages can simply be discarded and re-read from the file. Also rather notorious, lots of programmers have seen their Save() call fail with a wonky exception when they forgot to dispose the old bitmap.
Windows restricts how large the view on an MMF can be, in other words the amount of data in the file that can be directly addressed, as documented in this MSDN article:
The size of a file mapping object that is backed by a named file is limited by disk space. The size of a file view is limited to the largest available contiguous block of unreserved virtual memory. This is at most 2 GB minus the virtual memory already reserved by the process.
"Largest available continuous block" is the restriction in a 32-bit process, tends to hover around ~600 MB, give or take. The 2 GB limit kicks in on a 64-bit process. Technically GDI+ could bypass this limit by remapping the view. But it doesn't, the LockBits() method (also heavily used internally) would be inefficient and very awkward to use.
To use larger bitmaps you need to move to the successor of GDI+, WIC (Windows Imaging Component). Exposed in .NET through the System.Windows.Media.Imaging namespace.