[Gdal-dev] Is there a GetRasterBandasRGB?

[Christopher Barker]

Frank Warmerdam wrote:
> Christopher Barker wrote:
>> Darn. If we write such a thing in-house, would you be interested in 
>> having it contributed? For starters, we will probably only support the 
>> formats we happen to need, but with a framework in place, it should be 
>> fairly simple to support others.
> 
> Chris,
> 
> Well, I'm not sure where this would plug in.

I have no idea. I've just started playing with GDAL, and I've been doing 
it all in Python. I do have another coder working with me that is a 
C/C++ programmer that would probably actually write it.

I just found myself starting to write a base class that represents a 
raster map, and has methods for getting information about it, and one 
thing I need (because I'm using this for a mapping engine written in 
wxPython) is to be able to get a defined portion of the image as 8bit 
RGB data. So I've written two versions of a GetSubImage() method that is 
similar to ReadRaster(), excpet that it passes back the image as RGB 
data. At this point, it allocates new memeorty for it, even if the image 
is allready in that form.

Given that I'm using Python and wxPython, I end up making multiple 
copies of the data anyway, so that's not a big deal.

As I was doing this, it dawned on me that it might be a common need. 
Indeed, there could be a lot of uses where a user might not want to know 
at all about hte internal storage method of the data. Of course, I 
happen to need RBG (which is pretty common), but I suppose if you really 
wanted to be universal, you'd want to be able to pass in any of a lorge 
number of possible binary formats into a GetSubImage function, and that 
could be a LOT of code to write!

I should look at your conversion utilities to see how you do that now.

> Would it be a virtual dataset
> on top of an existing one?  Or a RasterIO_RGB() method on the dataset class
> that tries to interprete the dataset as best it can?

I think that's what I have in mind...

> In my experience, approaches start to vary a lot when you get to turning
> non-8bit data into RGB images (scaling variations and so forth).  I'm a
> bit nervous about setting a particular approach in concrete.

Well, no one would have to use it if they didn't want to, but I'm 
confused as to the complications you're referring to. If you have data 
in CMKY or something, I guess there's a trick, or 16 bit RGB, or.. but 
in on many cases, it's pretty straightforward. So far all I've needed to 
do is the palleted format in BSB maps, and colors are defined in RGB, so 
it's pretty simple.

> Nevertheless, if you were interested in doing it in a well integrated
> fashion, I think you would need to write up an RFC for the work item.
> That would give a variety of folks a chance to comment on the approach.

Good idea. What is most likely to happen is that we'd write something 
that would fill our needs, then post that for comments, and see if there 
was enough interest to work toward making it more universal.

I hope I'll be posting more about this later....

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov