[Gdal-dev] GDALDataset as a Base Class

[Matt Hanson]

Thanks for the link to GIL - it looks interesting.  I'm familiar with most of the DIP libraries out there but this one escaped my notice - they need to do some work on getting higher on search engines because I've scoured the net on several occasions over the last few years and never came across it.  I've used CImg quite a bit and while it challenges some normal C++ practices it's is the most complete, intuitive, easy to use IP library I've ever used.  It rivals the capabilities of the higher level IDL language (Interactive Data Language NOT Interface Definition Language) which I've used extensively since the early 90's.
 
I understand your statement, though I would not have been able to vocalize it in that manner (due to my informal programming training) but quickly realized the differences between the two and there is a stumbling block due to this very reason.   Let me explain the problem from my POV to verify I'm on the same page and my approach to get around it.  Maybe I'm oversimplifyign the problem and some of you may point out issues I haven't thought of or encountered yet.  Maybe someone has insight or different ideas.
 
Datatypes in GDAL datasets are described by the GDALDataType enumeration.   When you open a GDAL dataset the user need not know, or care, about the datatype.   The CImg class on the other hand, being a template, must have a datatype declared at compile time, such as CImg<int>.    While the GDAL method is flexible and means the user has less to worry about, when it comes to DIP, it becomes much more difficult to do things dynamically.  In fact, if I'm writing algorithms I want complete control over my data types.  Therefore my GImage class takes the template approach where the user declares the data type they want the dataset to be.   In fact, GDAL is so cool :-) that I don't even have to worry about conversion of datatypes because RasterIO does it for me.   It becomes a simple matter of looking up the proper GDALDataType enum based on the typename (using typeid(var)->name ).     Trying to make DIP funtions handle datatypes dynamically would be much more work.  There is however at least one DIP library that takes this approach, at least to some extent and that is VIPS, which I have also used quite a bit and is a very decent library.   Obviously by making GImage a template it assumes, or rather makes, all bands of the same data type - thus my previous post concerning that a couple weeks ago. 
 
The difficult issue is going from a GDALDataType enum to a typeid that can be used to create an instantiated object.  For example, if I want to create a GImage object of whatever datatype currently exists within the GDAL file.   This is useful if you want to extract and save a subset of data but keep the same datatype.   There are two solutions I see here:
 
1 - Make a non-member function not based on templates that simply copies a subset of GDAL data to a new file.  Subsequent processing would still require a user to use a GImage object, and thus specify the datatype they would like to do that processing in.
 
2 - Try and look up and return a typename based on the GDALDatatype enum.  This means parsing the file and returning a typename, then the user can use typename to instantiate a GImage object.  This is a very difficult thing to do, even if it is possible.   I think that something similar to the ideas presented here:
http://www.accu-usa.org/2000-05-Main.html
may work.   At the very least this approach requires pre-instantiated GImage classes of all the datatypes GDAL supports.  i.e.
typedef GImage<short> int16GImage;
typedef CImage<double> doubleGImage;
and so on.
 
 
So in other words this GImage class will be more like the CImg approach.  A templated DIP library, but underneath it is processing piecewise and using GDAL to actually do the I/O.
 
 
matt

________________________________

From: gdal-dev-bounces at lists.maptools.org on behalf of Mateusz Loskot
Sent: Fri 9/1/2006 4:30 PM
To: gdal-dev at lists.maptools.org
Subject: Re: [Gdal-dev] GDALDataset as a Base Class



Matt Hanson wrote:
> There are some roadblocks to combining these two libraries but I
> think I have a decent plan of attack.

Matt,
I've not analyzed CImg deeply, but AFAI understand it.
it's implemented using different paradigm than GDAL.
The former is based om meta programming (the kingdom of static
polymorphism and compile time actions), the latter is based on
dynamic polymorphism.

What Ari said a message before, mixing these two worlds
may be a challange. Certainly, it's doable,
but I doubt you'll be able to mix it directly
for example directly inheriting CImg-like types from GDAL types.

Certainly, I don't know your ideas in details, so these are only some
general assumptions.

By the way, do you know GIL, I announced it here a some time ago:

http://opensource.adobe.com/gil/

It seems to be similar to CImg.

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net <http://mateusz.loskot.net/> 
_______________________________________________
Gdal-dev mailing list
Gdal-dev at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/gdal-dev