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
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:
Picture Perfect RGB Rendering Using Spectral Prefiltering and Sharp Color Primaries
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" <[email protected]>
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
You know Greg, I am always impressed with the all that you know. You are like the wise old man on top of the mountain (not that you are old).
Any solution to my problem that would allow for me to use the "stock" Radiance without any code modifications would always be preferable. One consideration that I have to make is how would the suggested technique impact renderings for surfaces that pick less color than others. I tried to employ the method that you previously suggested but I received an error message stating "exposure out of range" or something to that effect. What's cause of this error? Also, the technique that you decribed would work well if I have gray surfaces to use as a some sort of baseline. Are there any techniques that exist for performing a white-balancing if I could not select any white surfaces within a particular view?
For conceptual method that I previously suggested, why would dubious results be produced. I know that I have 0.0000001% (I am probably over estimating) of the Radiance knowledge that you have but I thought that if the overall reflectance of the material would be unchanged (i.e. grey(r,g,b)) but only the color of the material (as seen by an ambient ray) would be changed, I thought the result would remain valid. Why is this not the case?
Thanks
Marcus
···
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:
Picture Perfect RGB Rendering Using Spectral Prefiltering and Sharp Color Primaries
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" <[email protected]>
> 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
>
Marcus,
You share my admiration for the rendering master.
You asked if "there any techniques that exist for performing a white-balancing if I could not select any white surfaces within a particular view?"
One emprical technique to find the white point that I've considered implementing in Radiance scenes mimicks a traditional lens-and-film photographic technique. First render the scene in low resolution with one or more "white card" or "grey card" surfaced added to your scene temporarily within the field of view, perhaps close to the center of view...or the direction you think the viewer will be gazing most frequently...or scattered throughout the scene for a good average. Measure the white point on these temporary surface(s). Re-render the image without the "white cards" and adjust with pfilt post-processing using the pre-determined whitepoint correction factors.
This discussion probably should be moved back to the general category because it does not really involve code development issues.
-Chas
You know Greg, I am always impressed with the all that you know. You are
like the wise old man on top of the mountain (not that you are old).
Any solution to my problem that would allow for me to use the "stock"
Radiance without any code modifications would always be preferable. One
consideration that I have to make is how would the suggested technique
impact renderings for surfaces that pick less color than others. I tried to
employ the method that you previously suggested but I received an error
message stating "exposure out of range" or something to that effect. What's
cause of this error? Also, the technique that you decribed would work well
if I have gray surfaces to use as a some sort of baseline. Are there any
techniques that exist for performing a white-balancing if I could not select
any white surfaces within a particular view?
For conceptual method that I previously suggested, why would dubious results
be produced. I know that I have 0.0000001% (I am probably over estimating)
of the Radiance knowledge that you have but I thought that if the overall
reflectance of the material would be unchanged (i.e. grey(r,g,b)) but only
the color of the material (as seen by an ambient ray) would be changed, I
thought the result would remain valid. Why is this not the case?
Thanks
Marcus
···
Marcus Jacobs <[email protected]> wrote:
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:
Picture Perfect RGB Rendering Using Spectral Prefiltering and Sharp Color Primaries
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"
> 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
>
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
Hi Marcus,
Chas' suggestion of rendering small white cards into your scene at low resolution would certainly work. It would give you a pretty good idea of the color cast resulting from interreflections, which you could then correct using pfilt. However, it may not be necessary to find a white or gray surface at all, since you know what you want each surface to be based on the diffuse RGB values you've assigned to them in your material description. Simply divide the RGB's measured from the rendering into the RGB's in your input and apply this as a color correction. Say you have a diffuse surface whose reddish color cast you don't like, whose specification says it should have an RGB value of (0.35,0.21,0.47) and whose actual RGB value as measured by the 'c' command in ximage gives you back (2.15,1.1,1.5). You could balance the color of this image with:
% pfilt -1 -er `ev 0.35/2.15` -eg `ev 0.21/1.1` -eb `ev 0.47/1.5` rendered.pic > corrected.pic
You say you are getting an error about "exposure out of range," but you didn't say which program was generating this error or under what circumstances.
The reason I'm less fond of your code change suggestion is because color bleeding really does happen, and if you've modeled your surface colors correctly, your overall result will appear more realistic if you perform white balancing rather than getting rid of color bleeding altogether.
-Greg
···
From: "Marcus Jacobs" <[email protected]>
Date: August 17, 2005 11:11:01 AM CDT
You know Greg, I am always impressed with the all that you know. You are like the wise old man on top of the mountain (not that you are old).
Any solution to my problem that would allow for me to use the "stock" Radiance without any code modifications would always be preferable. One consideration that I have to make is how would the suggested technique impact renderings for surfaces that pick less color than others. I tried to employ the method that you previously suggested but I received an error message stating "exposure out of range" or something to that effect. What's cause of this error? Also, the technique that you decribed would work well if I have gray surfaces to use as a some sort of baseline. Are there any techniques that exist for performing a white-balancing if I could not select any white surfaces within a particular view?
For conceptual method that I previously suggested, why would dubious results be produced. I know that I have 0.0000001% (I am probably over estimating) of the Radiance knowledge that you have but I thought that if the overall reflectance of the material would be unchanged (i.e. grey(r,g,b)) but only the color of the material (as seen by an ambient ray) would be changed, I thought the result would remain valid. Why is this not the case?
Thanks
Marcus
Greg, Chas
Thanks for the help. I have moved this discussion to the general section as requested.
The white card method that Chas proposed was my "Plan B" if no white surfaces were available. I'll have to try the method that Greg suggested. The error message, "exposure out of range", that I receive is from pfilt.
Regarding the code modification, I am unsure if this method will work the way that I wish. If I am using a color, I could vary its hue with colorfunc but if I am using in image map with colorpict (wood floors are generally the most offending material with regard to color bleeding), I do not think that I can vary the color in accordance with a color bleeding parameter.
Thanks for all of everyone's help (including the email from cb)
Marcus