image wrapper class proposal
Thomas Bleicher
I have been working on a wrapper class for Radiance HDR images. I have
uploaded the current work in progress to my web site
https://sites.google.com/site/tbleicher/radiance/python-radiance
(see "attachements" at the bottom of the page). For those of you who
don't want to head over there right now I have copied my introduction
and comments below.
Regards,
Thomas
RGBEImage - Radiance Image wrapper
=============================
So, after the first excitement about a Python Radiance module has
calmed down a bit I sat down and examined the HRD image code I had
written before for falsecolor2.py and wxfalsecolor. In the process of
adapting the existing image class for more general purposes I made a
few observations:
* As discussed the class implements wrappers around Radiance binaries
using the subprocess module.
* Most methods return a new image instance. This doesn't seem very
pythonic or object oriented but it is closer to the way the existing
image tools would be used.
* Methods take an options string that is passed through to the binary.
If you know how to use the original tool you therefore know how to use
the image method. How far options should be checked for validity and
how this could be implemented in the module is a matter of further
discussion once the structure of the module has more shape.
* Following the discussion on file sizes I have implemented a fairly
ambitious memory model: If an instance was created from a (potentially
large) file it will return instances based on (temporary) files. If
the instance was created in memory (from raw data or float values) it
will return in-memory instances. Some tools require the input to be a
file. If such a tool is called for an in-memory instance a temporary
file is created. When the instance is deleted the file will also be
removed from the file system. I'm sure the implementation needs more
work but on the whole that's the idea.
Things that need further discussion:
*) Do we want a more pythonic/OO style for the API (act on the image
data itself instead of returning a new image instance) or should we
follow the functional approach of the original Radiance binaries?
*) Should we solve the current inconsistencies of the Radiance command
line options or should we stick close to original?
*) Where should common functions within the module be implemented (i.
e. the creation of pipes)?
The files below are work in progress but show how a simple wrapper
could be done. Some of the methods are more limited than the
corresponding Radiance tool (see pcomb for example) but at the moment
I have no idea how to solve this. I have also kept methods to access
the (r,g,b) values of a pixel although this could require a lot of
memory. "Use at your own risk!", I suppose.
The file rgbeimage.py has a demo routine at the end which will create
an image with various processes and display it using ximage if you are
on a Unix system. On Windows it will just save the file to the current
working directory and display the file name. I think some features I
use require Python 2.6. One of the unit tests in test_rgbeimage.py
requires the ImageMagick identify tool on your system and in your
search path. If that's not found one of the tests will fail. I have in
general not dealt with the location of binaries and assume that all
the tools are in your search path.