[Radiance-dev] Ray Parameters

[Greg Ward]

Hi Marcus,

I think what you are trying to do would be better accomplished by  
applying a white-balancing step to the rendered image in a post- 
process.  The reason we don't notice color bleeding as much in real  
life is that our eye adjusts to the overall color balance in a  
space.  When we look at an image on a computer monitor or printed  
page, our eyes are mostly adjusted to the color of the surround, not  
the image, hence any color cast in the image gets interpreted as an  
overall shift.  To compensate for this, you should pick out some area  
that you think should be white in the image, measure its color (using  
ximage or whatever) and adjust all the image values by this color  
using pcomb or pfilt.

Let's say you measure an RGB value of a gray patch as (0.53,.91,.67)  
indicating a greenish tint.  You could apply pfilt to the image thus:

     pfilt -er `ev .91/.53` -eb `ev .91/.67` -1 orig.pic > corrected.pic

This will bring the red and blue channels into line with the green  
channel, adjusting the exposure setting at the same time in order to  
maintain luminance calibration.  This is a very crude form of white  
balancing.  For a better method, see the following paper:

     http://www.anyhere.com/gward/papers/egwr02/

If this really doesn't satisfy your needs, then I'll give you some  
hints of what to do in the code, but it's a fair amount of work  
you're looking at for dubious benefits.

-Greg

> From: "Marcus Jacobs" <marcdevon at hotmail.com>
> Date: August 13, 2005 1:44:23 PM PDT
>
> Dear Group
>
> I am seeking to make a minor modification of the Radiance source  
> code to solve an issue that I am having with my renders. The issue  
> that I am trying to resolve is the color shift (i.e. color  
> bleeding) that occurs. My goal is to allow for me or anyone else to  
> wishes to utilize the added functionality to gain some artistic  
> control on the amount of color bleeding that occurs without  
> invalidating the physical accuracy of the result. I have been able  
> to accomplish this in RADZILLA by utilizing its alternate ambient  
> material. I have an idea which may accomplish the same goal in  
> classic Radiance.
>
> In rayinit.cal there are many variables (i.e. Dx, Dy, Dx, Lu, Lv,  
> etc.) that are available to the user for use in function files.  
> What I would like to do is to gain control of the ray type  
> parameter (rtype) defined in ray.h. The basic concept is that in a  
> function file associated with colorpict or colorfunc, if the ray  
> type is equal to anything excluding an ambient ray, the color will  
> remain unchanged. If the ray type is an ambient ray, the color  
> could be defined by the user.  I have created my own function  
> file ,colorshift.cal, which would define the ambient color of a  
> material as:
>
> red = (1- B4) * grey(B1,B2,B3) + B4*B1;
> green = (1- B4) * grey(B1,B2,B3) + B4*B2;
> blue = (1- B4) * grey(B1,B2,B3) + B4*B3;
>
> where B1, B2, B3, B4  is the color's red, green, blue components  
> and color bleeding factor (detemined by the user) respectively.  
> This will have the effect of desaturating the color according to  
> the color bleedig factor without altering its overall reflectance  
> (i.e. grey(r,g,b) will remain constant). I have done some research  
> in func.h and func.c to see how I might gain some control over the  
> ray type parameter. I have not had much luck in completely  
> understanding how the code works. I am assuming that many of the  
> standard parameters listed in rayinit.cal are extracted in the  
> function chanvalue. One problem that I am having is that I can find  
> where this particular function is being called elsewhere in the  
> source code. Any insight as to how to accomplish my goal would be  
> greatly appreciated.
>
> Regards,
>
> Marcus Jacobs
>