[Radiance-general] Python Radiance Package

[Thomas Bleicher]

On Sat, Nov 6, 2010 at 1:59 PM, David Smith <dbs176 at gmail.com> wrote:
> Dear Radiance community,
>
> Does anybody have any interest in a generic Radiance wrapper package for
> Python? I think I'm going to make one (and make it open source), and was
> wondering if anybody had any interest, suggestions, advice, code they would
> be willing to contribute, etc.

Great idea. I would be very interested in a generic Python interface
for Radiance. I have used functionality of the Radiance tools in some
of my scripts and I always had to rewrite the relevant parts or use a
system command and process the output. I looked at the source code
with the intention to expose e. g. the scene parser or image
read/write in a Python API. Unfortunately I don't know enough C to do
that.

> I'm aiming for a 1:1 functionality but I know there are
> going to be some things that will be tough/impossible to do.
> I made what I think a simple program could be like below - it imports
> geometry, creates a series of images, manipulates and combines
> those images, then saves them.

I think that a Python API can be especially useful in interactive
applications like image viewing/analysing or even a 3D GUI or scene
editor. In these cases a 1:1 implementation of the functionality is
not so important as access to the 'raw' data (pixel values in HDR
image or polygons in an octree). You can display that information or
manipulate it Python which offers plenty of 3rd party scientific
libraries to do so. The API would offer you a more pythonic/object
oriented way to do so.

> So, yeah. Any interest?
>
> --Dave
>
> P.S. - I posted here because it's not directly related to the Radiance code,
> it would be just calling the Radiance programs and scripts.

That's a pity. I was hoping for a genuine Python API based on the C source code.

So far I have used the 'subprocess' module with Radiance binaries a
bit and I think there are a couple of problems with this:

1) Some csh scripts are not available on Windows. An abstract Python
wrapper should offer the same features on all platforms.

2) Short commands take a lot longer because you have to
convert/process the input and output of the commands to make them
useable in Python.

3) Long running commands do not give you more control or feedback than
the binaries do now (which is not a lot). Especially for GUIs it would
be nice to have feedback on the progress rpict or oconv makes.

4) Although I can see the elegance of your Python example compared to
a bash/csh script I think that the OO approach would limit the
functionality of the individual scripts. In that case you'd have to
fall back on shell scripting and can't benefit from the Python API.


Having said all that I'm sure I could contribute to a Python API
project. You can have a look at my take on 'subprocess'ing image
read/write here:

http://code.google.com/p/pyrat/source/browse/tags/wxfalsecolor/0.4.1/falsecolor2.py

and an OO wrapper for the HDR image here:

http://code.google.com/p/pyrat/source/browse/tags/wxfalsecolor/0.4.1/rgbeimage.py

I have also fragments of a pure Python scene parser and other bits
that might come in handy at some point.

Thomas