Python Radiance Package

Hmmm. Have you considered fixing up the scons scripts? Cmake doesn't work on Macs worth noticing. It has some Mac functionality, but it is very limited. (At least the best book on it now only costs $60; this is better than a few years ago when Kitware was selling the book for $200.)

···

On 2010-11-09 20:57:15 -0800, Guglielmetti, Robert said:

This leads me to another topic, that of a reliable Windows build environment for Radiance. As part of our efforts mentioned above, NREL is looking into getting a cmake-based cross-platform build env for Radiance and hosting it. The goal is to get a cmake dashboard setup for Radiance (nightly) builds. This would allow us to provide a repository for Windows Radiance binaries, updated nightly and monitored for breakage. Windows functionality is important to us for our tools mission, so we are currently scoping this effort. Stay tuned!

--
Randolph M. Fritz • [email protected]
Environmental Energy Technologies Division • Lawrence Berkeley Labs

I have posted this before to the mailing list, I know it is not nice to
double post but since there are still some questions on the Scons scripts I
re-posted everything (in one large message, with a fix or two):

This is my procedure to compile Radiance 40 HEAD with Scons:
If something is not working let me know then I can look into it.

General procedure for installation, is the one described on
Francesco's Wiki page
How to compile Radiance using the MinGW tools and Scons
http://www.bozzograo.net/radiancewiki/doku.php?id=how_to_compile_radiance_using_the_mingw_tools_and_scons

For compilation I used:
Radiance 4.0 from
http://radsite.lbl.gov/radiance/dist/rad4R0all.tar.gz(Includes
auxiliary files)
+ latest HEAD archive from
http://www.radiance-online.org/software/snapshots/radiance-HEAD.tgz
MinGW with gcc 4.5.0
Python 2.7 + scons 1.3.1 (You might also have to set the PATH variable to
Python and Scons)

Extract Radiance 4.0 and HEAD and place HEAD files over Radiance 4.0 files
overwriting the old ones.
Extracting can be done with the tools listed on the radiancewiki site
mentioned above.
or possibly also with winzip or 7-zip.

Gendaylit
To make Gendaylit compile add the following line in:
ray\src\gen\SConscript under the section PROGS = (
('gendaylit', Split('gendaylit.c sun.c',), ['rtlamps']),

Change the following line in: ray\src\common\SConscript
RTLAMPS = Split('''fropen.c rexpr.c lamps.c''')+ [getlibpath]

Dctimestep
To make dctimestep compile I had to add the following line to:
ray\src\common\SConscript under the section # build libraries:
rtall = env.StaticLibrary(target=radlib('rtall'), source=ALL)

I changed in ray\src\util\SConscript
('dctimestep', ['dctimestep.c'],
    ['rtall'])

For Gendaylit you also need a library files called: 'perezlum.cal
coeff_perez.dat defangle.dat'

Add this to ray\scr\gen\SConscript the line should be:
LIBFILES = Split('illum.cal rev.cal skybright.cal glaze1.cal glaze2.cal
perezlum.cal coeff_perez.dat defangle.dat')

Check if: progs.append(prog)
is present before this line in ray\scr\gen\SConscript:
prog = env.Program(target=os.path.join('$RAD_BUILDBIN', 'mksource'),

When compiling tmapluv.c the compiler complains about a variable
declaration that is already declared elsewhere, to solve this:

Change the include order in these files (ray\src\common\):
tmapluv.c to put "tiffio.h" above "tmprivat.h"
tmaptiff.c to put "tiffio.h" above "tmprivat.h"
tmapcolrs.c to put "rtprocess.h" above "tmprivat.h"

To compile mgf2meta:
Change in ray\scr\cv\SConscript
# meta targets
prog = env.Program(target=rbin('mgf2meta'), source=['mgf2meta.c'],
        CPPPATH=env.get('CPPPATH', []) + [os.path.join('#src','meta')],
        LIBS=['meta','rtmath','rtcont','rtmem','rterror','mgf'] + mlib)
env.Append(RAD_BININSTALL=[env.Install(env['RAD_BINDIR'], prog)])

platform/*.cfg files should be updated so that installation paths aren't
"c:\radiance3.6" or so.

For example next can be changed:
[install]
RAD_BASEDIR: c:\radiance4.0
RAD_BINDIR: bin
RAD_RLIBDIR: lib
RAD_MANDIR: man

Open cmd window on Windows
Change to ray dir
type: scons build
And after a successful build
type: scons install

···

+
after installation user has to set RAYPATH environment variable to Radiance
libraries' path.
and the PATH environment variable to Radiance bin path

For those of you interested in compiling ra_tiff and normtiff for Windows,
below are the instructions on how it could be done.

Tools:
Get tiff-3.9.4.zip from ftp://ftp.remotesensing.org/pub/libtiff/
Get MinGW + MSYS shell from http://www.mingw.org/

To open a MSYS shell: Go to C:\msys\1.0\msys.bat (or where you installed
MSYS)

Original instructions from:
http://www.gaia-gis.it/spatialite-2.4.0/mingw_how_to.html#libtiff
Only step 5 should be enough to compile libtiff (since we do not use libz
nor libjpeg)
To make it work with Radiance I had to modify the procedure a bit:

    download the latest sources: tiff-3.9.4.zip
    uncompress this zip-file
    then open an MSYS shell

cd tiff-3.9.4
./configure --enable-static --enable-logluv --disable-shared --disable-cxx
--disable-jpeg --disable-zlib --disable-pixarlog
make
make install-strip

Copy the file libtiff.a from C:\msys\1.0\local\lib to C:\..\..\ray\src\lib
(where ..\..\ points to where you extracted the Radiance source files)

To build ra_tiff add these lines to ray\src\px\SConscript:

ra_tiff = env.Program(target=radbin('ra_tiff'), source=['ra_tiff.c'],
    LIBS=['libtiff','rtpic','rtio','rtmem'] + mlib)
progs.append(ra_tiff)

In a similar way normtiff can be build:

Add this line to \ray\src\common\SConscript after the section # build
libraries:

rtall = env.StaticLibrary(target=radlib('rtall'), source=ALL)

To build normtiff add these lines to ray\src\px\SConscript:

normtiff = env.Program(target=radbin('normtiff'),source=['normtiff.c'],
    LIBS=['libtiff','rtall'] + mlib)
progs.append(normtiff)

Then proceed with building Radiance with scons.

Thanks for publishing this!

Randolph

···

On Nov 10, 2010, at 12:43 PM, Guy Vaessen wrote:

I have posted this before to the mailing list, I know it is not nice to double post but since there are still some questions on the Scons scripts I re-posted everything (in one large message, with a fix or two):

This is my procedure to compile Radiance 40 HEAD with Scons:
If something is not working let me know then I can look into it.

General procedure for installation, is the one described on
Francesco's Wiki page
How to compile Radiance using the MinGW tools and Scons
http://www.bozzograo.net/radiancewiki/doku.php?id=how_to_compile_radiance_using_the_mingw_tools_and_scons

For compilation I used:
Radiance 4.0 from http://radsite.lbl.gov/radiance/dist/rad4R0all.tar.gz (Includes auxiliary files)
+ latest HEAD archive from http://www.radiance-online.org/software/snapshots/radiance-HEAD.tgz
MinGW with gcc 4.5.0
Python 2.7 + scons 1.3.1 (You might also have to set the PATH variable to Python and Scons)

Extract Radiance 4.0 and HEAD and place HEAD files over Radiance 4.0 files overwriting the old ones.
Extracting can be done with the tools listed on the radiancewiki site mentioned above.
or possibly also with winzip or 7-zip.

Gendaylit
To make Gendaylit compile add the following line in:
ray\src\gen\SConscript under the section PROGS = (
('gendaylit', Split('gendaylit.c sun.c',), ['rtlamps']),

Change the following line in: ray\src\common\SConscript
RTLAMPS = Split('''fropen.c rexpr.c lamps.c''')+ [getlibpath]

Dctimestep
To make dctimestep compile I had to add the following line to:
ray\src\common\SConscript under the section # build libraries:
rtall = env.StaticLibrary(target=radlib('rtall'), source=ALL)

I changed in ray\src\util\SConscript
('dctimestep', ['dctimestep.c'],
    ['rtall'])

For Gendaylit you also need a library files called: 'perezlum.cal coeff_perez.dat defangle.dat'

Add this to ray\scr\gen\SConscript the line should be:
LIBFILES = Split('illum.cal rev.cal skybright.cal glaze1.cal glaze2.cal perezlum.cal coeff_perez.dat defangle.dat')

Check if: progs.append(prog)
is present before this line in ray\scr\gen\SConscript:
prog = env.Program(target=os.path.join('$RAD_BUILDBIN', 'mksource'),

When compiling tmapluv.c the compiler complains about a variable
declaration that is already declared elsewhere, to solve this:

Change the include order in these files (ray\src\common\):
tmapluv.c to put "tiffio.h" above "tmprivat.h"
tmaptiff.c to put "tiffio.h" above "tmprivat.h"
tmapcolrs.c to put "rtprocess.h" above "tmprivat.h"

To compile mgf2meta:
Change in ray\scr\cv\SConscript
# meta targets
prog = env.Program(target=rbin('mgf2meta'), source=['mgf2meta.c'],
        CPPPATH=env.get('CPPPATH', []) + [os.path.join('#src','meta')],
        LIBS=['meta','rtmath','rtcont','rtmem','rterror','mgf'] + mlib)
env.Append(RAD_BININSTALL=[env.Install(env['RAD_BINDIR'], prog)])

platform/*.cfg files should be updated so that installation paths aren't
"c:\radiance3.6" or so.

For example next can be changed:
[install]
RAD_BASEDIR: c:\radiance4.0
RAD_BINDIR: bin
RAD_RLIBDIR: lib
RAD_MANDIR: man

Open cmd window on Windows
Change to ray dir
type: scons build
And after a successful build
type: scons install

+
after installation user has to set RAYPATH environment variable to Radiance
libraries' path.
and the PATH environment variable to Radiance bin path

For those of you interested in compiling ra_tiff and normtiff for Windows, below are the instructions on how it could be done.

Tools:
Get tiff-3.9.4.zip from ftp://ftp.remotesensing.org/pub/libtiff/
Get MinGW + MSYS shell from http://www.mingw.org/

To open a MSYS shell: Go to C:\msys\1.0\msys.bat (or where you installed MSYS)

Original instructions from:
http://www.gaia-gis.it/spatialite-2.4.0/mingw_how_to.html#libtiff
Only step 5 should be enough to compile libtiff (since we do not use libz nor libjpeg)
To make it work with Radiance I had to modify the procedure a bit:

    download the latest sources: tiff-3.9.4.zip
    uncompress this zip-file
    then open an MSYS shell

cd tiff-3.9.4
./configure --enable-static --enable-logluv --disable-shared --disable-cxx --disable-jpeg --disable-zlib --disable-pixarlog
make
make install-strip

Copy the file libtiff.a from C:\msys\1.0\local\lib to C:\..\..\ray\src\lib (where ..\..\ points to where you extracted the Radiance source files)

To build ra_tiff add these lines to ray\src\px\SConscript:

ra_tiff = env.Program(target=radbin('ra_tiff'), source=['ra_tiff.c'],
    LIBS=['libtiff','rtpic','rtio','rtmem'] + mlib)
progs.append(ra_tiff)

In a similar way normtiff can be build:

Add this line to \ray\src\common\SConscript after the section # build libraries:

rtall = env.StaticLibrary(target=radlib('rtall'), source=ALL)

To build normtiff add these lines to ray\src\px\SConscript:

normtiff = env.Program(target=radbin('normtiff'),source=['normtiff.c'],
    LIBS=['libtiff','rtall'] + mlib)
progs.append(normtiff)

Then proceed with building Radiance with scons.
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

Hi Guy, Randolph, et al.:

Guy of course I recall your recent post on compiling Radiance for Windows with scons. Great work, a great follow-up to all the hard work Francesco Anselmo did years ago to get a MinGW compile. My post was in no way meant to trivialize the work you and others are doing. What we are looking to do at NREL is to create a cmake environment that is easy to maintain, that would provide nightly builds of Radiance for Windows, with a dashboard environment that would allow us to stay on top of any new changes to the code base (that seem to be coming fast and furious lately (a good thing)). I have been using Radiance for a ling time, but I can still remember the bleeding edge pain I went through in the mid 90's trying to learn UNIX sysadmin skills before I ever got to run oconv. I think a reliable repository for Windows binaries of the complete Radiance suite that keeps pace with development (which is very active these days) is important and novel. It also in no way means the scons work you have done is irrelevant.

Randolph, I'm sorry but I simply don't agree with you on your assessment of cmake. Internally, we are using cmake to keep pace with an agile development cycle involving a couple dozen software engineers, working on cross platform (Win/Mac/Linux) builds of our analysis platform. The idiot typing this email is able to maintain binaries on his OSX systems, and the Windows systems he has running on his VMs, with minimal knowledge of cmake. It's a big system, but it allows experts to allow novices to do expert things, and everywhere in between, developers of all stripes have access to source code and cross platform functionality that encourages participation.

Our intent is to offer a couple of alternatives here.

- Rob

···

____________________________
From: [email protected] [[email protected]] On Behalf Of Guy Vaessen [[email protected]]
Sent: Wednesday, November 10, 2010 1:43 PM
To: [email protected]
Subject: [Radiance-dev] Re: Python Radiance Package

I have posted this before to the mailing list, I know it is not nice to double post but since there are still some questions on the Scons scripts I re-posted everything (in one large message, with a fix or two):

This is my procedure to compile Radiance 40 HEAD with Scons:
If something is not working let me know then I can look into it.

General procedure for installation, is the one described on
Francesco's Wiki page
How to compile Radiance using the MinGW tools and Scons
http://www.bozzograo.net/radiancewiki/doku.php?id=how_to_compile_radiance_using_the_mingw_tools_and_scons

For compilation I used:
Radiance 4.0 from http://radsite.lbl.gov/radiance/dist/rad4R0all.tar.gz (Includes auxiliary files)
+ latest HEAD archive from http://www.radiance-online.org/software/snapshots/radiance-HEAD.tgz
MinGW with gcc 4.5.0
Python 2.7 + scons 1.3.1 (You might also have to set the PATH variable to Python and Scons)

Extract Radiance 4.0 and HEAD and place HEAD files over Radiance 4.0 files overwriting the old ones.
Extracting can be done with the tools listed on the radiancewiki site mentioned above.
or possibly also with winzip or 7-zip.

Gendaylit
To make Gendaylit compile add the following line in:
ray\src\gen\SConscript under the section PROGS = (
('gendaylit', Split('gendaylit.c sun.c',), ['rtlamps']),

Change the following line in: ray\src\common\SConscript
RTLAMPS = Split('''fropen.c rexpr.c lamps.c''')+ [getlibpath]

Dctimestep
To make dctimestep compile I had to add the following line to:
ray\src\common\SConscript under the section # build libraries:
rtall = env.StaticLibrary(target=radlib('rtall'), source=ALL)

I changed in ray\src\util\SConscript
('dctimestep', ['dctimestep.c'],
    ['rtall'])

For Gendaylit you also need a library files called: 'perezlum.cal coeff_perez.dat defangle.dat'

Add this to ray\scr\gen\SConscript the line should be:
LIBFILES = Split('illum.cal rev.cal skybright.cal glaze1.cal glaze2.cal perezlum.cal coeff_perez.dat defangle.dat')

Check if: progs.append(prog)
is present before this line in ray\scr\gen\SConscript:
prog = env.Program(target=os.path.join('$RAD_BUILDBIN', 'mksource'),

When compiling tmapluv.c the compiler complains about a variable
declaration that is already declared elsewhere, to solve this:

Change the include order in these files (ray\src\common\):
tmapluv.c to put "tiffio.h" above "tmprivat.h"
tmaptiff.c to put "tiffio.h" above "tmprivat.h"
tmapcolrs.c to put "rtprocess.h" above "tmprivat.h"

To compile mgf2meta:
Change in ray\scr\cv\SConscript
# meta targets
prog = env.Program(target=rbin('mgf2meta'), source=['mgf2meta.c'],
        CPPPATH=env.get('CPPPATH', []) + [os.path.join('#src','meta')],
        LIBS=['meta','rtmath','rtcont','rtmem','rterror','mgf'] + mlib)
env.Append(RAD_BININSTALL=[env.Install(env['RAD_BINDIR'], prog)])

platform/*.cfg files should be updated so that installation paths aren't
"c:\radiance3.6" or so.

For example next can be changed:
[install]
RAD_BASEDIR: c:\radiance4.0
RAD_BINDIR: bin
RAD_RLIBDIR: lib
RAD_MANDIR: man

Open cmd window on Windows
Change to ray dir
type: scons build
And after a successful build
type: scons install

+
after installation user has to set RAYPATH environment variable to Radiance
libraries' path.
and the PATH environment variable to Radiance bin path

For those of you interested in compiling ra_tiff and normtiff for Windows, below are the instructions on how it could be done.

Tools:
Get tiff-3.9.4.zip from ftp://ftp.remotesensing.org/pub/libtiff/
Get MinGW + MSYS shell from http://www.mingw.org/

To open a MSYS shell: Go to C:\msys\1.0\msys.bat (or where you installed MSYS)

Original instructions from:
http://www.gaia-gis.it/spatialite-2.4.0/mingw_how_to.html#libtiff
Only step 5 should be enough to compile libtiff (since we do not use libz nor libjpeg)
To make it work with Radiance I had to modify the procedure a bit:

    download the latest sources: tiff-3.9.4.zip
    uncompress this zip-file
    then open an MSYS shell

cd tiff-3.9.4
./configure --enable-static --enable-logluv --disable-shared --disable-cxx --disable-jpeg --disable-zlib --disable-pixarlog
make
make install-strip

Copy the file libtiff.a from C:\msys\1.0\local\lib to C:\..\..\ray\src\lib (where ..\..\ points to where you extracted the Radiance source files)

To build ra_tiff add these lines to ray\src\px\SConscript:

ra_tiff = env.Program(target=radbin('ra_tiff'), source=['ra_tiff.c'],
    LIBS=['libtiff','rtpic','rtio','rtmem'] + mlib)
progs.append(ra_tiff)

In a similar way normtiff can be build:

Add this line to \ray\src\common\SConscript after the section # build libraries:

rtall = env.StaticLibrary(target=radlib('rtall'), source=ALL)

To build normtiff add these lines to ray\src\px\SConscript:

normtiff = env.Program(target=radbin('normtiff'),source=['normtiff.c'],
    LIBS=['libtiff','rtall'] + mlib)
progs.append(normtiff)

Then proceed with building Radiance with scons.

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. 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.

The benefits of this are the flexibility of working within a higher level
scripting language. You open up the possibility of scripting complex
problems, parameteric geometry, iterative solutions, and ultimately,
adaptive design. This comes at the slight disadvantage of speed and the
flexibility of pipes, etc.

Why Python? I know it isn't as revered or speedy as C or Perl, but it has a
very simple syntax and a lot of the 3rd party tools as of late seem to be
written in Python. It's also available on all platforms and in some modeling
packages such as Rhino 5, Max (Py3dsMax), Blender, etc.

Ultimately, it could be the engine behind an OpenDX / Grasshopper like GUI
for Radiance. I'll leave that up to someone else though.

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. It's possible to
loop in C code, but I think keeping it separate and modularized is better
practice.

# Python Radiance

# Package would be called Radiance
from Radiance import rpict, obj2rad, HDRImage, RADGeometry, RadianceOptions,
ImportOBJGeometry, ViewFile, CompiledGeometry

ltg_zone1 = RADGeometry("ltg_zone1.rad")
ltg_zone2 = RADGeometry("ltg_zone2.rad")

#these would be equivalent
scene = ImportOBJGeometry("base_geometry.obj")
scene = RADGeometry(obj2rad("base_geometry.obj"))

view1 = ViewFile("view1.vf")

zone1 = CompiledGeometry(scene, ltg_zone1)
zone2 = CompiledGeometry(scene, ltg_zone2)
zone1and2 = CompiledGeometry(zone1, ltg_zone2) #add to an existing octree

opt_hq = RadianceOptions("hq.opt")

hdr_zone1 = rpict(zone1, ab=3, ad=256, ps=1, vf=view1)
hdr_zone2 = rpict(zone2, ab=3, ad=256, ps=1, vf=view1)
hdr_all = rpict(zone1and2, opt_hq, vf=view1)

from somewhere import specialrpictfunction
#this could be a function that you write that analyzes over the course of a
year or special post processing, etc.
hdr_special = specialrpictfunction(zone1and2)

hdr_scene1 = (0.6 * hdr_zone1) + (0.4 * hdr_zone2)
hdr_scene2 = (0.9 * hdr_zone1)
hdr_scene3 = (0.2 * hdr_zone1) + (hdr_zone2)

hdr_scene1.save("img1.hdr")
hdr_scene2.save("img2.hdr")
hdr_scene3.save("img3.hdr")

hdr_all.save("img4.hdr")
hdr_special.save("img5.hdr")

Hi Dave,

This is an interesting idea. I'm not very familiar with Python, so I'm going to ask some naive questions:

1) Can't you just invoke a system command line from Python? Is this how you would implement these methods?

2) What are the advantages of encapsulating Radiance tools in this way? Who do you expect will benefit?

It seems like you're just trading one syntax (the Unix command line) for another (Python objects and methods). This can be worthwhile if the syntax is easier to use or leverages capabilities of the language in new ways. Do you have an actual problem in mind that you think is best solved this way? Your example gives a flavor of what you could do, but you're not really doing anything here you couldn't do by shelling out commands and stowing the results in files instead of variables.

Can you share a little more of your broader vision? Are these just hooks for applications like Blender, or are they somehow better than the commands themselves? Do you plan to store entire images in memory, or does Python manage variables with megabytes of data in them efficiently?

Cheers,
-Greg

···

From: David Smith <[email protected]>
Date: November 6, 2010 11:59:41 AM PDT

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. 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.

The benefits of this are the flexibility of working within a higher level scripting language. You open up the possibility of scripting complex problems, parameteric geometry, iterative solutions, and ultimately, adaptive design. This comes at the slight disadvantage of speed and the flexibility of pipes, etc.

Why Python? I know it isn't as revered or speedy as C or Perl, but it has a very simple syntax and a lot of the 3rd party tools as of late seem to be written in Python. It's also available on all platforms and in some modeling packages such as Rhino 5, Max (Py3dsMax), Blender, etc.

Ultimately, it could be the engine behind an OpenDX / Grasshopper like GUI for Radiance. I'll leave that up to someone else though.

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. It's possible to loop in C code, but I think keeping it separate and modularized is better practice.

# Python Radiance

# Package would be called Radiance
from Radiance import rpict, obj2rad, HDRImage, RADGeometry, RadianceOptions, ImportOBJGeometry, ViewFile, CompiledGeometry

ltg_zone1 = RADGeometry("ltg_zone1.rad")
ltg_zone2 = RADGeometry("ltg_zone2.rad")

#these would be equivalent
scene = ImportOBJGeometry("base_geometry.obj")
scene = RADGeometry(obj2rad("base_geometry.obj"))

view1 = ViewFile("view1.vf")

zone1 = CompiledGeometry(scene, ltg_zone1)
zone2 = CompiledGeometry(scene, ltg_zone2)
zone1and2 = CompiledGeometry(zone1, ltg_zone2) #add to an existing octree

opt_hq = RadianceOptions("hq.opt")

hdr_zone1 = rpict(zone1, ab=3, ad=256, ps=1, vf=view1)
hdr_zone2 = rpict(zone2, ab=3, ad=256, ps=1, vf=view1)
hdr_all = rpict(zone1and2, opt_hq, vf=view1)

from somewhere import specialrpictfunction
#this could be a function that you write that analyzes over the course of a year or special post processing, etc.
hdr_special = specialrpictfunction(zone1and2)

hdr_scene1 = (0.6 * hdr_zone1) + (0.4 * hdr_zone2)
hdr_scene2 = (0.9 * hdr_zone1)
hdr_scene3 = (0.2 * hdr_zone1) + (hdr_zone2)

hdr_scene1.save("img1.hdr")
hdr_scene2.save("img2.hdr")
hdr_scene3.save("img3.hdr")

hdr_all.save("img4.hdr")
hdr_special.save("img5.hdr")

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:

and an OO wrapper for the HDR image here:

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

Thomas

···

On Sat, Nov 6, 2010 at 1:59 PM, David Smith <[email protected]> wrote:

Hi Dave,

This is an interesting idea. I'm not very familiar with Python, so I'm going to ask some naive questions:

1) Can't you just invoke a system command line from Python? Is this how you would implement these methods?

2) What are the advantages of encapsulating Radiance tools in this way? Who do you expect will benefit?

It seems like you're just trading one syntax (the Unix command line) for another (Python objects and methods). This can be worthwhile if the syntax is easier to use or leverages capabilities of the language in new ways. Do you have an actual problem in mind that you think is best solved this way? Your example gives a flavor of what you could do, but you're not really doing anything here you couldn't do by shelling out commands and stowing the results in files instead of variables.

I'll be interested in David's answer, but one reason I use Python scripts is that the Python subprocess module implements (relatively) platform-independent argument processing. On Unix execvp() is used, unless a shell is specifically chosen. On Windows, which doesn't have an analog of execvp(), arguments are escaped for the MS C runtime library. So scripts aren't dependent on the platform. I've used this and, in fact, it works. Also, personally, I prefer working with Python lists to csh variables, but I doubt you would!

Can you share a little more of your broader vision? Are these just hooks for applications like Blender, or are they somehow better than the commands themselves? Do you plan to store entire images in memory, or does Python manage variables with megabytes of data in them efficiently?

Well, it could be done--numpy does it, for instance. David?

···

On 2010-11-06 12:50:49 -0700, Greg Ward said:

--
Randolph M. Fritz • [email protected]
Environmental Energy Technologies Division • Lawrence Berkeley Labs

I think this is a wonderful idea - I'd be willing to
pitch in what Python coding
I can.
Python has a lot of great data-processing libraries,
and as people have noted,
it would make a much better cross-platform API to Radiance
than the command-line.
I'll take Python over shell scripting any day!
I think the first step would be for someone to write a Python API -
there are lots of ways to implement it
from just wrapping the shell commands to
closer integration,
but if you have a stable API people can get started using it
without re-writing their scripts constantly as Radiance-Python evolves.

Best,
Severn Clay-Youman
www.lesbetes.com

Well, it sounds like there is significant groundswell around this idea. I suggest that interested parties/developers organize a host site for this effort and someone (Dave?) take charge of the project. It's not something I can personally help with, and there aren't enough spare resources or Python experts at LBNL to manage such a project as far as I know. Ongoing maintenance is something to think about as well, as new Radiance releases will likely continue to have some minor changes and some major additions.

Best,
-Greg

···

From: Severn Clay-Youman <[email protected]>
Date: November 8, 2010 6:01:55 AM PST

I think this is a wonderful idea - I'd be willing to
pitch in what Python coding
I can.
Python has a lot of great data-processing libraries,
and as people have noted,
it would make a much better cross-platform API to Radiance
than the command-line.
I'll take Python over shell scripting any day!
I think the first step would be for someone to write a Python API -
there are lots of ways to implement it
from just wrapping the shell commands to
closer integration,
but if you have a stable API people can get started using it
without re-writing their scripts constantly as Radiance-Python evolves.

Best,
Severn Clay-Youman
www.lesbetes.com

Well, it sounds like there is significant groundswell around this idea.
I suggest that interested parties/developers organize a host site for
this effort and someone (Dave?) take charge of the project.

Google code projects are easy to set up and almost everyone
in this thread already has a gmail account. It may be more difficult
to find a source control system that everybody agrees on ...

Ongoing maintenance is something to think about as well,
as new Radiance releases will likely continue to have some
minor changes and some major additions.

Since everybody is happy with a simple 'subprocess' wrapper
around the Radiance binaries there shouldn't be much ongoing
maintenance. Python 2 vs 3 is more likely to cause additional
work than the Radiance interface.

However, I can see that an additional advantage of this project
could be that the remaining CSH scripts (and possibly Perl scripts)
in the main Radiance distribution get finally pythonized. In that
case should the new scripts be kept separately or should they
find their way back into the distribution?

Thomas

···

On Mon, Nov 8, 2010 at 11:36 AM, Greg Ward <[email protected]> wrote:

Hi Thomas,

From: Thomas Bleicher <[email protected]>
Date: November 8, 2010 8:58:45 AM PST
...
However, I can see that an additional advantage of this project
could be that the remaining CSH scripts (and possibly Perl scripts)
in the main Radiance distribution get finally pythonized. In that
case should the new scripts be kept separately or should they
find their way back into the distribution?

I think the scripts that come with the distribution have to be independent of third-party additions, especially ones that call legacy Radiance scripts back. Otherwise, we create a dependency loop where everything has to be synchronized between separate sources for anything to work. Such a move would require that LBNL maintain all the Python code internally, and I don't see that happening.

In general, adding functionality to Radiance through new scripts and programs is much less trouble than replacing functionality, which creates a whole host of backwards- and forwards-compatibility issues.

-Greg

If people are interested, the Labs is offering subversion server space on one of our servers. When we get the website update project a bit further along, we'll be able to give the project a page, too.

···

--
Randolph M. Fritz • [email protected]
Environmental Energy Technologies Division • Lawrence Berkeley Labs

On 2010-11-08 08:58:45 -0800, Thomas Bleicher said:

On Mon, Nov 8, 2010 at 11:36 AM, Greg Ward > <[email protected]> wrote:

Well, it sounds like there is significant groundswell around this idea.
I suggest that interested parties/developers organize a host site for
this effort and someone (Dave?) take charge of the project.

Google code projects are easy to set up and almost everyone
in this thread already has a gmail account. It may be more difficult
to find a source control system that everybody agrees on ...

Ongoing maintenance is something to think about as well,
as new Radiance releases will likely continue to have some
minor changes and some major additions.

Since everybody is happy with a simple 'subprocess' wrapper
around the Radiance binaries there shouldn't be much ongoing
maintenance. Python 2 vs 3 is more likely to cause additional
work than the Radiance interface.

However, I can see that an additional advantage of this project
could be that the remaining CSH scripts (and possibly Perl scripts)
in the main Radiance distribution get finally pythonized. In that
case should the new scripts be kept separately or should they
find their way back into the distribution?

Thomas

--
Randolph M. Fritz • [email protected]
Environmental Energy Technologies Division • Lawrence Berkeley Labs

Wow, thanks to all who replied. I'll try to address some of the raised
eyebrows now, and answer the more technical ones later.

My goal was an easier way to do some analysis that would require more
than simple shell scripts. Or rather, a way to do some things that
would probably be easier in a higher level language. I just so happen
to do a lot in Python, and I think it's a relatively simple language
to pick up, and its syntax looks like pseudocode.

Some more complicated scripts can get hard to follow with lots of
system calls, stringing together variables, or keeping track of and
deleting temporary files. I think that a Python package could be more
user friendly by making a simple interface and taking care of that
sort of thing automatically and invisibly. Also it could take
advantage of some of the more interesting Python capabilities such as
using distributed tasks (multiprocessor/multi-machine), pre-written
data processing libraries, image libraries, etc.

Since, as has been pointed out, the same code can run essentially
unmodified on any modern system that can run Radiance, there is the
possibility that this can create an easy way to exchange ideas and
create novel approaches to analysis. The architecture scripting
community is surprisingly active.

However, all I really wanted to do initially was provide a simple
interface back to Radiance, then step back and maintain/optimize it. I
hadn't given much technical thought other than it ought to at least
start out as a wrapper program. Because of the modularity of it all,
that could be changed later. I wasn't really aiming to replace things
like the csh scripts, although this would make it easy for someone to
do so if they wanted. I wanted for it to be as transparent as possible
through to Radiance proper.

Finally, I really appreciate the volunteers. I'm not a programming
novice, but I'm certainly not a guru either. Collaboration is much
appreciated.

I've registered a Google code page (for now, Mercurial, because I've
never used it and want to learn it - I hear it's like subversion with
the benefits of git) at http://code.google.com/p/python-radiance . I
think that the conversation should be continued in the
code-development thread, where it will likely get more technical.

--Dave

···

On Mon, Nov 8, 2010 at 1:33 PM, Randolph M. Fritz <[email protected]> wrote:

If people are interested, the Labs is offering subversion server space on
one of our servers. When we get the website update project a bit further
along, we'll be able to give the project a page, too.

--
Randolph M. Fritz • [email protected]
Environmental Energy Technologies Division • Lawrence Berkeley Labs

On 2010-11-08 08:58:45 -0800, Thomas Bleicher said:

On Mon, Nov 8, 2010 at 11:36 AM, Greg Ward <[email protected]> wrote:

Well, it sounds like there is significant groundswell around this idea.
I suggest that interested parties/developers organize a host site for
this effort and someone (Dave?) take charge of the project.

Google code projects are easy to set up and almost everyone
in this thread already has a gmail account. It may be more difficult
to find a source control system that everybody agrees on ...

Ongoing maintenance is something to think about as well,
as new Radiance releases will likely continue to have some
minor changes and some major additions.

Since everybody is happy with a simple 'subprocess' wrapper
around the Radiance binaries there shouldn't be much ongoing
maintenance. Python 2 vs 3 is more likely to cause additional
work than the Radiance interface.

However, I can see that an additional advantage of this project
could be that the remaining CSH scripts (and possibly Perl scripts)
in the main Radiance distribution get finally pythonized. In that
case should the new scripts be kept separately or should they
find their way back into the distribution?

Thomas

--
Randolph M. Fritz • [email protected]
Environmental Energy Technologies Division • Lawrence Berkeley Labs

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

It sounds like what you're looking to write is an enhanced version of the 'rad' program with ability to go through multiple geometries or light conditions for batch processing and comparison purposes with the additional flexibility of file naming that would be required, and maybe automatic falsecolor generation or pcond calls, rtrace data processing routines, etc.

I think the challenge would be to make it generic enough that it is still useful for all the unique scenarios that come up, but at the same time make it worth the effort of creating and maintaining this extra interface - instead of the current M.O. of any user putting to use whichever shell or scripting package they're most comforable with. There is a danger that it makes it makes Python expertise necessary to keep up to date with the most current developments, and be able customize as needed. Although maybe there's something to be said for moving toward a common cross-platform scripting language amongst the community.

I suppose it takes a little bit of effort to try it and determine if it would fit the purpose.

PS, I write this from the perspective of someone using bash and unix commands and who has (very briefly) looked into Python several times, but could never figure out why I would want to re-write the bash shell commands I'm already familiar with into Python with all the same information just within parantheses and with the word "subprocess" before it = )

···

____________________________________________________________
Electronic mail messages entering and leaving Arup business
systems are scanned for acceptability of content and viruses

Hi Chris.

It sounds like what you’re looking to write is an enhanced version of the
‘rad’ program with ability to go through multiple geometries or light
conditions for batch processing and comparison purposes with the additional
flexibility of file naming that would be required, and maybe automatic
falsecolor generation or pcond calls, rtrace data processing routines, etc.

We haven't discussed the actual nature of this package yet,
I think. My understanding was that at first it would be only
a wrapper for the Radiance binaries that would provide a
less complicated way of accessing their features from
Python.

Your idea of an enhanced 'rad' is interesting but I don't feel
that this is the main goal here. However, the Python package
should allow anyone inclined to do so to write an enhanced
'rad' without having to deal with all the gritty details of file
handling and process control.

I think the challenge would be to make it generic enough that it is still
useful for all the unique scenarios that come up, but at the same time make
it worth the effort of creating and maintaining this extra interface –
instead of the current M.O. of any user putting to use whichever shell or
scripting package they’re most comforable with.

For a start it should be very 'generic' because it only exposes
the Radiance features on a Python level. I doubt that we
can achieve all the flexibility of Radiance on a Unix shell
because that's what all the binaries are designed for. But
within a Python script you can achieve the same results
with a few more Python commands. In most cases this
will also improve the readability of the script.

There is a danger that it makes it makes Python expertise
necessary to keep up to date with the most current
developments, and be able customize as needed.

Knowledge of Python will definitely be required. It's a
Python module after all. However, all of those who have
shown an interest in the project already have done some
programming in Python and I expect that we have a fair
amount of duplicated features in our common code base.

If nothing else this project could help the known Python
enthusiasts to share parts of their code.

Although maybe there’s something to be said for moving
toward a common cross-platform scripting language
amongst the community.

Unfortunately even within the official distribution there
is already quite a spread of scripting languages:
Python/CSH for building
CSH for some scripts
Perl for other scripts
TCL/Tk for trad

I expect that it will always be true that on Unix you are
spoiled for choice of scripting environments and on Windows
most users rely on a graphical frontend like Ecotect.

PS, I write this from the perspective of someone using bash and unix
commands and who has (very briefly) looked into Python several times, but
could never figure out why I would want to re-write the bash shell commands
I’m already familiar with into Python with all the same information just
within parantheses and with the word “subprocess” before it = )

That's because you haven't discovered the beauty of
Python OO code yet. I agree that there is little benefit
in rewriting shell scripts in Python unless you do
something more with it (or you are not that familiar
with CSH/Bash programming).

Python has it's strength where you extend the basic
Radiance tools to a more complex application. That
could be an image manipulation app that combines
the various p-something tools or a script that automats
rendering and analysis of a scene with variations.

Thomas

···

On Tue, Nov 9, 2010 at 10:33 AM, Christopher Rush <[email protected]> wrote:

All:

This is an interesting idea and the excitement over supporting it is inspiring. Many of you provide a good glimpse of the possibilities with a system like this, and the path forward. I should add that at NREL we are working on an analysis platform (written in C++) for combined Radiance and EnergyPlus simulations, that provides Ruby bindings to the underlying C++ components. I don't think it's a total duplication of this effort being discussed here, and in fact it may be more what Thomas is thinking of (more of a Radiance API). It's very much in developmental stage, but I wanted to mention it nonetheless. Regardless, our emphasis is on open source, and cross platform tools here.

This leads me to another topic, that of a reliable Windows build environment for Radiance. As part of our efforts mentioned above, NREL is looking into getting a cmake-based cross-platform build env for Radiance and hosting it. The goal is to get a cmake dashboard setup for Radiance (nightly) builds. This would allow us to provide a repository for Windows Radiance binaries, updated nightly and monitored for breakage. Windows functionality is important to us for our tools mission, so we are currently scoping this effort. Stay tuned!

- Rob

Rob Guglielmetti IES, LEED AP
Commercial Buildings Research Group
National Renewable Energy Laboratory
1617 Cole Blvd
Golden, CO 80401

Hi Chris.

It sounds like what you're looking to write is an enhanced version of the
'rad' program with ability to go through multiple geometries or light
conditions for batch processing and comparison purposes with the additional
flexibility of file naming that would be required, and maybe automatic
falsecolor generation or pcond calls, rtrace data processing routines, etc.

We haven't discussed the actual nature of this package yet,
I think. My understanding was that at first it would be only
a wrapper for the Radiance binaries that would provide a
less complicated way of accessing their features from
Python.

Your idea of an enhanced 'rad' is interesting but I don't feel
that this is the main goal here. However, the Python package
should allow anyone inclined to do so to write an enhanced
'rad' without having to deal with all the gritty details of file
handling and process control.

I think the challenge would be to make it generic enough that it is still
useful for all the unique scenarios that come up, but at the same time make
it worth the effort of creating and maintaining this extra interface -
instead of the current M.O. of any user putting to use whichever shell or
scripting package they're most comforable with.

For a start it should be very 'generic' because it only exposes
the Radiance features on a Python level. I doubt that we
can achieve all the flexibility of Radiance on a Unix shell
because that's what all the binaries are designed for. But
within a Python script you can achieve the same results
with a few more Python commands. In most cases this
will also improve the readability of the script.

There is a danger that it makes it makes Python expertise
necessary to keep up to date with the most current
developments, and be able customize as needed.

Knowledge of Python will definitely be required. It's a
Python module after all. However, all of those who have
shown an interest in the project already have done some
programming in Python and I expect that we have a fair
amount of duplicated features in our common code base.

If nothing else this project could help the known Python
enthusiasts to share parts of their code.

Although maybe there's something to be said for moving
toward a common cross-platform scripting language
amongst the community.

Unfortunately even within the official distribution there
is already quite a spread of scripting languages:
Python/CSH for building
CSH for some scripts
Perl for other scripts
TCL/Tk for trad

I expect that it will always be true that on Unix you are
spoiled for choice of scripting environments and on Windows
most users rely on a graphical frontend like Ecotect.

PS, I write this from the perspective of someone using bash and unix
commands and who has (very briefly) looked into Python several times, but
could never figure out why I would want to re-write the bash shell commands
I'm already familiar with into Python with all the same information just
within parantheses and with the word "subprocess" before it = )

That's because you haven't discovered the beauty of
Python OO code yet. I agree that there is little benefit
in rewriting shell scripts in Python unless you do
something more with it (or you are not that familiar
with CSH/Bash programming).

Python has it's strength where you extend the basic
Radiance tools to a more complex application. That
could be an image manipulation app that combines
the various p-something tools or a script that automats
rendering and analysis of a scene with variations.

Thomas

···

On 11/9/10 9:35 AM, "Thomas Bleicher" <[email protected]> wrote:
On Tue, Nov 9, 2010 at 10:33 AM, Christopher Rush <[email protected]> wrote:

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

[followups directed to radiance-dev]

···

On 2010-11-09 20:57:15 -0800, Guglielmetti, Robert said:

This leads me to another topic, that of a reliable Windows build environment for Radiance. As part of our efforts mentioned above, NREL is looking into getting a cmake-based cross-platform build env for Radiance and hosting it. The goal is to get a cmake dashboard setup for Radiance (nightly) builds. This would allow us to provide a repository for Windows Radiance binaries, updated nightly and monitored for breakage. Windows functionality is important to us for our tools mission, so we are currently scoping this effort. Stay tuned!

Hmmm. Have you considered fixing up the scons scripts? Cmake doesn't work on Macs worth noticing. It has some Mac functionality, but it is very limited. (At least the best book on it now only costs $60; this is better than a few years ago when Kitware was selling the book for $200.)
--
Randolph M. Fritz • [email protected]
Environmental Energy Technologies Division • Lawrence Berkeley Labs