[Image-SIG] PIL and Remote Sensing

[Fredrik Lundh]

(First set of answers, to keep you going).

> Interesting stuff!

Sure is ;-)

(And with you on the team, I think we can make it even
more interesting!)

> o Does PIL always load the whole image, once it decides it needs some
>   of it?  This could make it difficult to work with very large images.

Except for a few mode/compression combos on Win32 platforms,
PIL always loads the full image.  Adding a paged or tiled access
scheme would require a major rewrite, since most operations
assume that they have direct access to image data.

But it's definitely on the todo list, and there are some clever sub-
classing tricks that can be used in some situations.  More on this in
later posts.

> o It seems that multi-band images (more than four bands) would have to
>   handled as image sequences of "L" images.  Is that correct?

"L" or "I" or "F", depending on the format.  We're using a "DataFile"
interface which supports some more advanced formats like NetCDF
and GRIB.  It basically returns an object that behaves like a list
of Image objects, and delays loading until you actually load some
image data.  More details later.

> o It appears that 16bit data can only be supported as 32 bit floating
>   point, though I understand you are considering a builtin 16bit data
>   type.  

Since 0.3a2, there's also support for 32-bit integer images (mode "I").
(not yet in the docs).  There's some more info on this format in the
CHANGES file.

Adding a 16-bit format could require some major surgery, but I haven't
ruled that one out yet.  Most modern platforms are able to crunch 32-bit
data at least as fast as 16-bit data, as long as you don't run out of memory.
On the other hand, you always run out of memory sooner or later, and
that's no fun...

> o There is no obvious way of supporting virtual file formats.  For 
>   instance, in GDB there are some formats which aren't really related
>   to files.  For instance the file "VD0" opens a socket connection to
>   another process, and accesses it's video memory as an image.  I get
>   the impression with PIL that the binary file is already opened, and
>   the handled passed into the driver.

You could subclass the Image class, and override the "load" method
for this purpose (the file format handlers are implemented in this
way).

/snip/

>Is there any work on a Python library for vector data support anywhere?

Not that I'm aware of.  We're using pretty simple stuff today to deal
with ArcInfo ungenerate files and some proprietary formats. Those
readers basically returns the vector data as a sequence of ImagePath
objects (that's an undocumented corner of PIL; read the path.c source
for details...).

Gotta run.  More stuff to follow.

Cheers /F