Announcing Radiance 3.7 release

Hi All,

I have put together an official release of Radiance 3.7 on the LBNL Radiance server at:

     http://radsite.lbl.gov/radiance/framed.html

I think Peter Apian-Bennewitz is on vacation, so it will take a week or two before radiance-online is updated. I have compiled under Mac OS X, Linux, and FreeBSD, though I expect there will be the usual binary/library compatibility issues to sort out.

Be sure to check out the new mksource and rtcontrib programs, and let me know if you run into any serious compile or runtime issues on your platform. A list of significant changes since the previous 3.6 release last October is listed below.

Enjoy!
-Greg

···

================================
Changes between Radiance 3.6 and 3.7:

Changed default temporary directory from /usr/tmp, which doesn't exist
on a lot of systems these days, to /tmp.

Eliminated many unused files and programs from the distribution, including
the following programs that were being built but no longer used:
     oki20 - printer driver for OkiMate 20 printer (B&W)
     oki20c - printer driver for OkiMate 20 color printer
     pcwarp - intended as more general substitute for macbetcal,
             but never quite worked
     ra_avs - convert to & from AVS image format
     ra_bn - convert to & from Barneyscann format
     ra_pr - convert to & from 8-bit Sun rasterfile format
     ra_pr24 - convert to & from 24-bit Sun rasterfile format
     thf2rad - convert GDS "things file" to Radiance scene format
If anyone is still wanting any of the above programs, let us know and we'll
reinstate it.

Added script to convert to/from ICT's Poskanzer Float Map, which I don't
care to support officially due to its machine-dependent byte order.

Fixed bug that caused incorrect reporting of non-surface in set when
mixing meshes and instances. (Thanks to Jack de Valpine for discovery.)

Fixed innacuracy in calculation of diffuse transmission in the presence
of pure specular (Fresnel reflection) using "trans" material. Thanks
to Christoph Reinhart for pointing out the error.

Made internal change to tone-mapping library to use structure pointer
rather than stack, making code re-entrant and more up to modern standards.

Added -pd option to handle depth-of-field blur in rpict. This requires
that the view directon (-vd option) include focal distance information,
which is now preserved by the various view file routines, and reported
by the vwright command.

Added DBLUR variable to ranimate and pmdblur script to handle simultaneous
motion and depth-of-field blurring. Thanks to Visarc for funding this work.

Added setting of focus distance in rvu ("focus" command) and rholo
('f'/"frame" command).

Changed default remote shell in ranimate to "ssh" rather than "rsh",
which has been abandoned on most Unix systems due to security issues.

Fixed behavior of source primitive using illum with no alternate
material. These now become transparent so one can see the sky or
light-probe background for use in image-based lighting. Previously,
the user needed to specify the background glow as the alternate
material for a distant illum source to behave properly. (This still
works.)

Fixed some minor problems and inconsistencies with 16-bit/channel
TIFF i/o in ra_tiff.

Created mksource program to generate distant sources for improved
image-based lighting with light probes.

Added -oM option to rtrace to report material (rather than modifier)
for cases where actual material is aliased or further up modifier chain.

Rearranged the way ray contributions are computed so that it might be
possible to use rtrace to derive daylight coefficients and optical
transfer functions. The new -oTW option of rtrace produces color
contribution weights for each ray, which combined with the -ti (or -tI)
option permits the contribution of selected surfaces or sources to
be determined. Using the -oTW option, one should also specify
options "-dt 0 -aa 0 -as 0" for optimal results. In particular,
one cannot expect reasonable tallies with -ab >= 1 and irradiance
caching on (-aa > 0).

The same code modifications included a change to the indirect computation
with caching switched off (-aa 0). Whereas before, the number of secondary
rays after the first bounce were half of the previous generation, they are
now determined by the surface reflectance, making for a better and faster
calculation. It should now be possible to compute many bounces with -aa 0,
which used to be prohibitively expensive.

Added -T option to xshowtrace to trace rays to light sources.

Added meta2bmp program to produce BMP files from metafile graphics.

Increased maximum number of input pictures in pcomb and pcompos to 512.

Created rtcontrib program for computing ray contribution coefficients.
This tool may be used to do standard optical ray tracing or daylight
coefficient calculations for annual simulations, among other uses.

Implemented Russian roulette ray termination with -lr <= 0.
Made -lr -10 the default in rtcontrib and rtrace.

Added -if and -of options to total for binary i/o (following rcalc mold).

Added -u rendering option for pure Monte Carlo sampling.
(Got rid of -DMC compile option, which this makes superfluous.)

Changed -t option of rlam to accept strings as well as single characters.

Fixed truly ancient bug in bounding box computation for cones, which
could (and did) cause missing segments.

Added -z option to normtiff to output LZW-compressed files.

Greg Ward wrote:

Added -pd option to handle depth-of-field blur in rpict. This requires
that the view directon (-vd option) include focal distance information,
which is now preserved by the various view file routines, and reported
by the vwright command.

From the man page, this new feature completely replaces pdfblur. So there's no need to render multiple images and average them together? I haven't seen any other mention of this new feature. Does rpict simply trace multiple rays for the one pixel?

Does it adapt e.g points in focus only require a few rays, but points out of focus require more rays over the area of confusion (or whatever it's called) ?
That would improve the efficiency/speed over the laborious pdfblur method.

Oh, and thanks to everyone involved in the development of Radiance. It's amazing!

bye

Hi Ian,

Greg Ward wrote:

Added -pd option to handle depth-of-field blur in rpict. This requires
that the view directon (-vd option) include focal distance information,
which is now preserved by the various view file routines, and reported
by the vwright command.

From the man page, this new feature completely replaces pdfblur. So there's no need to render multiple images and average them together? I haven't seen any other mention of this new feature. Does rpict simply trace multiple rays for the one pixel?

It's not a complete replacement, as pdfblur is quite a bit faster. Also, rpict will not as a rule send multiple samples per pixel. To get such a behavior, you have to increase the initial image resolution and downsample more with pfilt.

Similar to motion blur, best results are usually obtained through a combination of pdfblur and the new -pd option. There is also a new script to do combined motion and depth-of-field blur, as the two are not really separable. It's called pmdblur, and it's man page is the best place to get details.

Thanks is due to Jack de Valpine of Visarc, who funded this addition, along with support in ranimate that now provides motion and depth-of-field blurring as an option.

Does it adapt e.g points in focus only require a few rays, but points out of focus require more rays over the area of confusion (or whatever it's called) ?
That would improve the efficiency/speed over the laborious pdfblur method.

The technique is not adaptive, but it takes advantage along with everything else of rpict's selective rendering of samples based on image coherence (the -ps and -pt options).

-Greg

Gregory J. Ward wrote:

Hi Ian,

It's not a complete replacement, as pdfblur is quite a bit faster. Also, rpict will not as a rule send multiple samples per pixel. To get such a behavior, you have to increase the initial image resolution and downsample more with pfilt.

Ah yes, oh course. I should avoid asking questions before breakfast :stuck_out_tongue:

Thanks is due to Jack de Valpine of Visarc, who funded this addition, along with support in ranimate that now provides motion and depth-of- field blurring as an option.

Thanks Jack!

bye