Large images issue

Sep 6, 2010 at 8:33 AM
Edited Sep 6, 2010 at 9:18 AM

Hi everyone,

There's a problem with loading large GeoTIFF images into a map, but only when I compile DotSpatial or another application that uses compiled DotSpatial myself. So when I run binary TestForm from the website, there is no large image issue (12000x10000), but when I compile source code myself, it gives the folowing:

System.ArgumentException was unhandled  

Message=Parameter is not valid.  Source=System.Drawing  

StackTrace:       at System.Drawing.Bitmap..ctor(Int32 width, Int32 height, PixelFormat format)

I tried to debug it and located the issue in MWImageData.cs in function public override void Open() at the line _myImage = new Bitmap(temp.Width, temp.Height, PixelFormat.Format32bppArgb);

Does anyone know what could be the problem here, since this doesn't happen with binary version from this website?

 

Thanks,

Dragan

Sep 6, 2010 at 9:29 AM

Problem "solved". I've switched from debugging mode to release mode and it works now. It obviously doesn't have much to do with DotSpatial but rather with .NET itself.

Dragan

Developer
Sep 6, 2010 at 6:24 PM

The issue has nothing to do with .Net exactly.  Without using the GDAL Data Extension, the system tries to use a .Net Bitmap class or whatever in order to open your image.  The maximum in-ram file that will work (at least on most of the machines I have worked on) is about 8000 x 8000.  If you build to "Release" mode, it builds to the folder which as the GDAL extensions.  If you build to "Debug" mode, then your images will not have the benefit of GDAL since the "DataExtensions" folder is missing.  You can fix this by copying the "DataExtensions" folder and all of its contents to your new binary folder.

Editor
Sep 7, 2010 at 9:22 AM

Dear friends,

 

Does it mean that is then available the large images load supported?

 

Thanks in advanced.

Francisco J.

 

 

Sep 11, 2010 at 3:36 PM
Edited Sep 11, 2010 at 3:41 PM

Hi,

Is it actually possible to try to invoke .Net Bitmap class as an alternative when GDAL is not present? Shouldn't that produce an error since there classes belong to different namespaces? I found these namespaces in MwImageData class which throws exception for large images:

using System;
using System.Drawing;
using System.Drawing.Drawing2D;
using System.Drawing.Imaging;
using System.Runtime.InteropServices;
using DotSpatial.Geometries;
using System.Windows.Forms;

It seems like GDAL is not used here...

Thanks,

Dragan

Developer
Sep 11, 2010 at 5:43 PM

You have correctly identified a very important aspect of our extensible data provider design.  Most non-extensible code would, for instance, add a direct reference to GDAL.  This would then prevent the possibility of having any other data support libraries for images.  You would also be forever limited to whichever of the windows/linux/mac platform or x86 or 64 environment you initially chose.  I do take advantage of the .Net image classes for display purposes using GDI+ drawing regardless of how the data is accessed.  If you use the GDAL library, which at this moment means you must build DotSpatial for windows x86, the classes in the data extension library directly reference GDAL.  They then use GDAL to access the part of the image you are trying to display.  However, as far as DotSpatial is concerned, it simply has an implementation of the "IImage" interface or whatever.  As long as the class can return the .Net bitmap representation for the extents that the map wants to display at that moment, DotSpatial doesn't care what you have to do to get that information.

Currently, for rasters (not images), things are a little more complicated.  I am creating an uncompressed image file with pyramids in the same file location.  This is a cop-out and I understand that everyone wants image generation on the fly that also happens to be correctly symbolized and somehow magically draws really fast as well.  So far the test approaches for creating the hillshades and other characteristics that we love about raster representations seem to take enough time that we would have to think very carefully about adopting true on-the-fly raster representations.  It's something on the drawing board to re-assess down the road.  This is mainly because even if super-sized images are currently supported, what isn't supported is having a large number of layers of smaller images.  This would quickly tap out the ram because the app is not smart enough to consider it's global memory when deciding whether to keep an image in memory or load from the file.

Sep 14, 2010 at 2:09 PM

Thanks! I understand much better the concept now. It's really practical and extensible. Can you please tell me where (or how) should I import GDAL in my application so it doesn't use .net bitmap classes instead? I tried by putting plugins folder to my release folder but it still doesn't invoke GDAL functions. On the other hand, when I compile DotSpatial itself (not my application that uses DotSpatial) in Visual C#, it invokes GDAL without a problem.

Regards,

Dragan

Developer
Sep 14, 2010 at 3:41 PM

Ok, so rather than embedding the plug-in concept into the map itself, we decided that it would be appropriate to create a component called the "AppManager" which helps support extensibility.  That makes it more optional, in case you want to take control over where the application looks for extensions, etc.  Simply drag and drop an AppManager onto your project.  It will appear in the bottom portion.  For GDAL, that's all you have to do.  For getting other plug-ins to work, you should set the various properties on the AppManager to whatever components you have in your setup.  If you are using a Map, Legend, ToolStrip, menustrip, status strip, ribbon etc.  Then other people's DotSpatial Apps should be able to work in your project.

Sep 14, 2010 at 9:50 PM

It works great! I use GeoTIFF image as a background to show radio coverage in my application. Beside loading really large images, it's much easier now to load georeferenced image directly using GDAL.

Thank You so much for your help!

Dragan

Editor
Sep 14, 2010 at 10:12 PM

Dear friends,

 

What are the definitive steps that you use to load GDAL images using a custom application with a map and legend control?

I have to load a big MrSID and ECW image, and follow getting memory exceptions.

Thanks you very much.

Francisco J.

Developer
Sep 14, 2010 at 10:51 PM

First just run the TestViewer program in the DotSpatial library and see if it can open the images you are talking about.  Be prepared that it will probably want to "create pyramids" for very large SID or ECW images.  Ironically, those formats are actually very good at hosting pyramids, so eventually I want to migrate away from using our MapWindow pyramid file in DotSpatial, but there are many files that either don't support pyramids, or else don't allow fast access to a small part of the detailed image because of a file-wide compression technique.  You should end up with an mwi and mwh file in the directory.  It is this raw, uncompressed image file with pyramids that MW is currently using to handle viewing large images.  Anyway, if all is working then you should be able to see the image no problem.  If the TestViewer program can open the images, then you are just having problems with getting GDAL working.  If you are developing on a 64 machine, please make sure that your project is set to build in x86 mode, and not "AnyCPU" because even though the rest of MapWindow is 64 capable, the C# linkages I am using for GDAL are currently only built for the x86 framework and if you are running in 64 mode, you will not be able to dynamically link to the GDAL libraries.  Make sure you are running on windows, and not on mac or linux.  We don't yet have a set of GDAL libraries with linkages for those frameworks.  Assuming you have done all that, as mentioned above, drag and drop an AppManager component onto your form in the designer.  No further setup is needed, but if you don't have an AppManager, it won't automatically load the data extensions.  Next, make sure you have a copy of the GDAL folder with all its various dependent C++ libraries copied from either the zipped downloadable binaries or the DotSpatial\Framework 4.0\Release folder in either the Plugins or "Apps" subdirectory that is in your release or bin folder or wherever your executable binaries are ending up.

 

That should be all there is to it.

 

Ted

 

Editor
Sep 15, 2010 at 7:17 AM

Many thanks Ted,

 

I cannot open the ECW with a size of 250 MB using the TestViewer. I work in x86 mode.

 

I work with ECW and MrSID files because the number of individual files is very long.

 

Thanks in advanced.

 

Francisco J.

Developer
Sep 15, 2010 at 3:10 PM

If you try to load too many layers into memory, you will definitely have a problem, but a 250 MB ECW should just be handled largely out of memory.  We could be looking at a bug in the code.  For instance, if I am drawing many bitmaps, but am not disposing them somewhere and calling GC.Collect, then we still may encounter memory issues.  You probably can't attach a file that large to the forum.  We need a way for me to get access to the file so that I can debug the problem (probably this weekend).  Do you have a way to post the image so I can access it?

Ted

 

Editor
Sep 15, 2010 at 9:59 PM

Dear Ted,

 

Many thanks for your reply.

 

I will try to upload the image and I'll send to you the link to download it.

 

Thanks in advanced.

 

Francisco J.

Editor
Sep 16, 2010 at 9:23 AM

Please Ted, try to download from this link:

 

http://www.adrive.com/public/f6d29ea9b4e6a2e4b38a1d8077627d8f2ccf4b05e10303183aefb4a48eb59cea.html

 

Hope it serves to try the memory problem.

 

Thanks.

Francisco J.

Developer
Sep 16, 2010 at 4:18 PM

I was able to download the file, and will take a look at the bug the next time I get a chance.  It's probably a simple oversight.  Thanks for the help Francisco.

Nov 5, 2010 at 10:34 PM

Hi everyone,

I have to go back to this topic once again. About two months ago there was a version of DotSpatial that worked well with large images, considering great help from Shade1974 reagarding this issue. Recently I downloaded a newer version, but now any image larger than approximately 6000x6000 pixels can't be loaded. Has anyone noticed the same problem?

Thanks,

Dragan

Nov 5, 2010 at 11:10 PM

Regarding my previous post, I also tried to load the same content, this time as four smaller images, but I experience the same problem as before. Do you have any suggestions?

Thanks again,

Dragan

Developer
Nov 6, 2010 at 1:02 AM
Unfortunately, one down side I have discovered to using Interfaces as an extensibility system is that VisualStudio makes references "CopyLocal='true'" If you are in a mode where you are building GDAL library and aren't extremely careful with how it references its dependencies, it will copy the output libraries into the GDAL folder and reference the copies instead of the original. When this happens, it fails the interface test we have been using to establish if something is an extension. I may look at making that requirement softer or switch to more of a DataContract model or some other system now that HydroDesktop is upgraded to 4.0. In any case, make sure you don't have any framework dll libraries in the GDAL directory, and make sure you have the GDAL extension available in your "Data Extensions" folder.

Ted


On Fri, Nov 5, 2010 at 3:34 PM, dragandm <notifications@codeplex.com> wrote:

From: dragandm

Hi everyone,

I have to go back to this topic once again. About two months ago there was a version of DotSpatial that worked well with large images, considering great help from Shade1974 reagarding this issue. Recently I downloaded a newer version, but now any image larger than approximately 6000x6000 pixels can't be loaded. Has anyone noticed the same problem?

Thanks,

Dragan

Read the full discussion online.

To add a post to this discussion, reply to this email (DotSpatial@discussions.codeplex.com)

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Nov 6, 2010 at 11:06 AM

Hi Ted,

I've made a copy of DotSpatial binary in my /bin/release and /bin/debug folder. In those folders I deleted /Plugins/GDAL folder, so that now I only have /Data Extensions/GDAL/... where gdal binaries are. I also use Application Manager on my MainForm, along with Map control. Everything builds well and I manage to load smaller TIFFs. I've noticed a difference now - loaded images are no longer blurry, so I guess it uses GDAL extensions now. However, when I try to load those big images that I've mentioned earlier, it throws an NullReferenceException {"Object reference not set to an instance of an object."}. Here is a stack trace:

System.NullReferenceException was unhandled
  Message=Object reference not set to an instance of an object.
  Source=DotSpatial.Data.Rasters.GdalExtension
  StackTrace:
       at DotSpatial.Data.Rasters.GdalExtension.GdalImageProvider.OpenFile(String fileName) in C:\Dev\DotSpatial\DotSpatial.Data.Rasters.GdalExtension\DotSpatial.Data.Rasters.GdalExtension\GdalImageProvider.cs:line 132
       at DotSpatial.Data.Rasters.GdalExtension.GdalImageProvider.DotSpatial.Data.IDataProvider.Open(String fileName) in C:\Dev\DotSpatial\DotSpatial.Data.Rasters.GdalExtension\DotSpatial.Data.Rasters.GdalExtension\GdalImageProvider.cs:line 64
       at DotSpatial.Data.DataManager.OpenFile(String fileName, Boolean inRam, IProgressHandler progressHandler) in C:\Dev\DotSpatial\DotSpatial.Data\DotSpatial.Data\DataManager.cs:line 422
       at DotSpatial.Data.Forms.DataManagerExt.OpenFile(IDataManager self) in C:\Dev\DotSpatial\DotSpatial.Data\DotSpatial.Data.Forms\DataManagerExt.cs:line 106
       at DotSpatial.Controls.Map.AddLayer() in C:\Dev\DotSpatial\DotSpatial.Controls\DotSpatial.Controls\Map.cs:line 565
       at DotSpatial.Controls.Map.DotSpatial.Controls.IBasicMap.AddLayer() in C:\Dev\DotSpatial\DotSpatial.Controls\DotSpatial.Controls\Map.cs:line 548
       at DotSpatial.Controls.SpatialToolStrip.cmdAddData_Click(Object sender, EventArgs e) in C:\Dev\DotSpatial\DotSpatial.Controls\DotSpatial.Controls\SpatialToolStrip.cs:line 481
       at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
       at System.Windows.Forms.ToolStripButton.OnClick(EventArgs e)
       at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
       at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
       at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
       at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
       at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
       at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
       at System.Windows.Forms.Control.WndProc(Message& m)
       at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
       at System.Windows.Forms.ToolStrip.WndProc(Message& m)
       at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
       at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
       at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
       at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
       at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
       at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
       at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
       at System.Windows.Forms.Application.Run(Form mainForm)
       at RadioSpatial.Program.Main() in D:\Dev\dotNET\RadioSpatial041110\RadioSpatial\RadioSpatial\RadioSpatial\Program.cs:line 18
       at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
       at System.AppDomain.nExecuteAssembly(RuntimeAssembly assembly, String[] args)
       at System.Runtime.Hosting.ManifestRunner.Run(Boolean checkAptModel)
       at System.Runtime.Hosting.ManifestRunner.ExecuteAsAssembly()
       at System.Runtime.Hosting.ApplicationActivator.CreateInstance(ActivationContext activationContext, String[] activationCustomData)
       at System.Runtime.Hosting.ApplicationActivator.CreateInstance(ActivationContext activationContext)
       at System.Activator.CreateInstance(ActivationContext activationContext)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssemblyDebugInZone()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()
  InnerException:

It also happens with TestForm.exe application found in dotspatial binaries, without debugging messages of course.

 

Thanks again,

Dragan

 

Developer
Nov 6, 2010 at 3:18 PM

If you are brave enough to build from source, change set 171d205562dc or later (11/6/2010) should fix the null exception.  If not, keep a lookout for the next download posting, which I will post at the end of the weekend.  I will warn you that this will create a pyramid image, which will take some time to create.  You may also have trouble if you don't have write access where the file is stored.  I recommend setting a "ProgressHandler" typically by adding a DotSpatialStatusStrip and setting the "ProgressHandler" property for the map.  I really do need to make this step optional for GDAL images, since in many cases the original format is better than our default pyramid case.  I will post that as a feature request.  In the mean time, specifying a progress handler will allow you to see some progress as it attempts to create a pyramid image.  In the future, I hope to lean more on GDAL for overviews and such, but for our initial code we needed a system that could physically handle large images even if you didn't have GDAL installed.  Since many image formats don't support any form of overviews, or are in fact very compressed and the whole image needs to be decompressed just to see a small part of it, I have been continuing to use our default, uncompressed format with overviews attached, but we need to create this file, which can be objectionable in some cases.  Anyway, good luck.

Ted

 

Nov 6, 2010 at 6:13 PM

Thanks Ted,

I'll try with the latest source code. I think it would be a great feature to have an option not to make pyramid image, but just to load it directly using GDAL.

Dragan

 

 

Nov 8, 2010 at 9:42 AM

The latest build succeeds to load an image, but when mouse pointer comes over map it throws another exception:

System.NullReferenceException was unhandled
  Message=Object reference not set to an instance of an object.
  Source=DotSpatial.Data.Rasters.GdalExtension
  StackTrace:
       at DotSpatial.Data.Rasters.GdalExtension.GdalImage.Dispose(Boolean disposeManagedResources) in C:\Dev\DotSpatial\DotSpatial.Data.Rasters.GdalExtension\DotSpatial.Data.Rasters.GdalExtension\GdalImage.cs:line 378
       at DotSpatial.Data.DataSet.Finalize() in C:\Dev\DotSpatial\DotSpatial.Data\DotSpatial.Data\DataSet.cs:line 196
  InnerException:

Is there a way to disable pyramids but without direct changes in DotSpatial source code, since I have C# express edition, which can't load entire solution correctly?

 

Thanks,

Dragan

Developer
Nov 8, 2010 at 3:17 PM
Ok, so I fixed the null exception. I don't know what you mean by the express edition not being able to load the entire solution correctly. Did we add something to the project incompatible with express? I haven't gotten around to enabling GDAL based big-image without pyramids yet. Some GDAL formats would work well for this as they have overviews. Many, however, would not. But even if performance is bad for some image types, I agree people should have the option to not generate the pyramid image which takes up a lot of room and requires write permission to the drive. It is a feature request, but not yet implemented.

Ted


On Mon, Nov 8, 2010 at 2:42 AM, dragandm <notifications@codeplex.com> wrote:

From: dragandm

The latest build succeeds to load an image, but when mouse pointer comes over map it throws another exception:

System.NullReferenceException was unhandled
Message=Object reference not set to an instance of an object.
Source=DotSpatial.Data.Rasters.GdalExtension
StackTrace:
at DotSpatial.Data.Rasters.GdalExtension.GdalImage.Dispose(Boolean disposeManagedResources) in C:\Dev\DotSpatial\DotSpatial.Data.Rasters.GdalExtension\DotSpatial.Data.Rasters.GdalExtension\GdalImage.cs:line 378
at DotSpatial.Data.DataSet.Finalize() in C:\Dev\DotSpatial\DotSpatial.Data\DotSpatial.Data\DataSet.cs:line 196
InnerException:

Is there a way to disable pyramids but without direct changes in DotSpatial source code, since I have C# express edition, which can't load entire solution correctly?

Thanks,

Dragan

Read the full discussion online.

To add a post to this discussion, reply to this email (DotSpatial@discussions.codeplex.com)

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Nov 9, 2010 at 8:43 PM

The problem with visual studio c# express edition isn't big since it only relates to demo projects (quote: "Solution folders are not supported in this version of the application. Solution folder 'Demo Projects' will be displayed as unavailable"). The whole solution builds fine without this project.

Thanks a lot for the new binary version. It works perfectly with my big images. I develop an application for prediction of radio coverage based on ITU-R P.1546 recommendation and DotSpatial is great for presenting calculation results on a map (this is why I needed to load high-resolution TIFF images as background).

As I progress with development of my application, I will probably discover some new bugs sometimes, since this would be so normal for a big and complex project like dotspatial. Should I post them through discussion or through issue tracker? I hope my posts (usually in form of a question :)) aren't bothering and that they can contribute to DotSpatial at least a tiny bit in becoming an open source GIS standard.

Thanks again,

Dragan

Developer
Nov 9, 2010 at 9:51 PM
Generally speaking despite our desires to cater to our paying clients, active participants get the most reaction. The more involved you get to help fix the bug you find, the more likely we are to jump on it right away to try and help. Posts to the issues list are great too, but don't expect a fix right away, as most of us have real jobs and only get to play with DotSpatial during our off time.

Ted


On Tue, Nov 9, 2010 at 1:44 PM, dragandm <notifications@codeplex.com> wrote:

From: dragandm

The problem with visual studio c# express edition isn't big since it only relates to demo projects (quote: "Solution folders are not supported in this version of the application. Solution folder 'Demo Projects' will be displayed as unavailable"). The whole solution builds fine without this project.

Thanks a lot for the new binary version. It works perfectly with my big images. I develop an application for prediction of radio coverage based on ITU-R P.1546 recommendation and DotSpatial is great for presenting calculation results on a map (this is why I needed to load high-resolution TIFF images as background).

As I progress with development of my application, I will probably discover some new bugs sometimes, since this would be so normal for a big and complex project like dotspatial. Should I post them through discussion or through issue tracker? I hope my posts (usually in form of a question :)) aren't bothering and that they can contribute to DotSpatial at least a tiny bit in becoming an open source GIS standard.

Thanks again,

Dragan

Read the full discussion online.

To add a post to this discussion, reply to this email (DotSpatial@discussions.codeplex.com)

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Editor
Dec 10, 2010 at 12:42 PM

Dear Ted,

 

Is there any news about the GDAL Plugin and the Raster loading?

Is needed another gdal plugin load methodology to use large images?

Thanks in advanced.

 

Fran

Developer
Dec 10, 2010 at 3:26 PM

Hi Francisco!  I haven't seen you post in a while.  The most recent versions of DotSpatial have reasonable support for large images and rasters if you have GDAL.  We are also trying out a newer version of GDAL if you use the 4.0 libraries, which I think may have some new formats as well.  Large rasters should be supported programmatically, but you should be using the Raster<int> raster = myRaster.toRaster<int>(); method and then working with the ReadRaster and WriteRaster methods for working with particular portions of the raster image.  Large images are currently supported by creating a PyramidImage internally, so I haven't gotten around to seeing about creating a variant that can use GDAL's ability to host overviews in the case of certain image formats yet.  The ImageData object in coordination with GDAL should allow you to edit rectangular portions of an image too large to fit in memory.

If the GDAL plugin is present in the DataExtensions path and you have dragged and dropped an AppManager onto your project, you should be able to benefit from GDAL to view all sorts of image formats, but I don't think the "Create" method is supported by GDAL for very many image formats.  I think they do support "CreateCopy"... but I'm not sure that that is particularly useful.  Perhaps I am misunderstanding the limitations, but to me a "copy" has the same data values, same size, same number of bands etc.  So unless you happened to have a template with every row, column and band configuration possible sitting around somewhere, I'm not sure how you are supposed to use the "CreateCopy" to create new images that would actually be useful for people.  This is likely just related to me not knowing enough about GDAL and maybe there are some settings somewhere that allow you to update the number of rows and columns on the copy template before you call create copy or something.  Anyway, if that is the case then when a chance we can update that.

Ted

 

 

 

Developer
Dec 20, 2010 at 6:41 AM

You can create a memory raster in GDAL and WriteRaster your image data to it: 

 

Driver drv = Gdal.GetDriverByName("MEM");
outDataSet = drv.Create("", xsize, ysize, buff.Length, datatype, options);

You can then save the data set using another driver. To use GDAL directly like this you'll need the appropriate managed references but it should be able to get everything else it needs from the GDALDataExtension.

Hope this helps.

Developer
Dec 20, 2010 at 6:12 PM

This is an insteresting post Tidyup!  If you can show some sample code of how to "SaveAs" to a different driver without invoking the "create" method at some point on that driver, then we could perhaps handle the cases where the "Create" method is not supported on drivers.  (which seems to be a lot of them.).  I think I saw a post saying that most support CreateCopy.  Can you create a copy from a different driver?  Anyway, some sample code here could let us improve our raster creation process if you have the time and energy to get to the bottom of this.

Ted

 

Developer
Dec 21, 2010 at 3:51 AM
Edited Dec 21, 2010 at 3:59 AM
 

We're so far off topic now - I'm preparing for a moderator blasting!

 

Assuming I understand your question and intention correctly.

 

Yes you can - Its what puts the A in GDAL ;)  The data abstraction DataSet is independent of Driver and most drivers do support CreateCopy (AFAIK the exception is licence restricted read only drivers)

Snippet for using CreateCopy with a different driver than the one used to create the original DataSet to; a) create a generic memory DataSet and b) convert it to a file of another format using another driver:

 

//Create a generic memory raster and write the data from a managed array (buff):
Driver drv = Gdal.GetDriverByName("MEM");
dataSet = drv.Create("", xsize, ysize, buff.Length, datatype, options);
//write the raster with data from the managed array
dataSet.WriteRaster(0, 0, xsize, ysize,Marshal.UnsafeAddrOfPinnedArrayElement(buff, offset), xsize, ysize, datatype, bands, bandMap, pixelSpace, lineSpace, bandSpace);

//or simply: 
dataSet = Gdal.Open(filename, Access.GA_Update); //you'll need to set the access appropriate to the source driver types supported access

//Now CreateCopy with the driver we want the DataSet format to serialize as
Driver drvNew = Gdal.GetDriverByName(drivername);
dsNew = drvNew.CreateCopy(filename, dataSet, 0, options, progressDelegate, callbackData);
dsNew.FlushCache();

Developer
Dec 21, 2010 at 1:53 PM

Awesome!  I saw that there was create copy, but I didn't realize you could do it with a dataset that was from a different source.  When I get back we can update the code so that we can use this technique to create new rasters in cases where the "Create" option is not supported.

Ted