How do I read a GeoImage into integral typed numpy arrays?

[ra-tolson]

This is another question related to migrating gips from gippy 0.3 to 1.0.

I've instantiated GeoImages using an existing file in a couple different ways, sometimes in a form that lets me specify a dtype, sometimes not. But regardless of the value of eg image.type().string(), or image[0].type().string(), the numpy array returned by image.read() is always float64. I can work around that by eg image.read().astype('uint16'), but that results in two unneeded type conversions, which hurts performance.

The band I need to process is the 16-bit QA band for landsat C1 data. float64 is obviously a type error if you try to do bit-fiddling on it (>> and & in our case).

[matthewhanson]

@ags-tolson

The underlying gippy C++ code uses templates, but in order to create Python bindings the templates need to be instantiated first into a specific type. The swig bindings should be taking account for this though by checking the data type then returning an array of the appropriate type, you can see example of some of that logic here in the swig interface file:
https://github.com/gipit/gippy/blob/master/gippy/gippy.i#L154

However, some caveats, if there is a gain or offset, or any function to be applied, then it changes the return array to double, because it can't otherwise tell what the most appropriate data type would be.

All that being said, it sounds like it's not working for some reason and just defaulting to a returning a double. I thought I had tested this quite a bit in version 1.0, since it's a rather complicated thing (multi step, first it has to get the right CImg type array, then it converts to to a numpy array on return, but without copying values and just using pointers), but sounds like it's broken somewhere.

I'll run some additional tests and see what I come up with. Thanks for bringing it up.

[ircwaves]

GeoRaster.read_raw is a work around.

[matthewhanson]

This has been resolved on develop with PR #132