Hi all, I hope this is the right place to post this query. (My apologies if
not!)

I am attempting to use a pigment function to multiply the colour values of a
somewhat sizeable set (1024) of previously rendered images, by a colour value
from another source (different for each image in the set), and average the
results together.

(I have rendered the same scene 1024 times with a single light source in
different locations arranged in a hemisphere, and want to multiply each image
with the colour value at the corresponding location from an HDR image. In this
way I can see my scene with any lighting I want, without having to re-render
the geometry.)

According to the documentation the "average" pigment type only supports up to
256 pigments to average. Since I need to be able to do more than that I wrote a
function to calculate it with a loop.

So far, all is good.

The problem occurs when the colour value for any channel (R, G, B) exceeds 1.0 -
the value for that channel seems to wrap back around to 0.0 and this is causing
strange colour banding effects. I will post an image to p.b.i when I get home
from work in a few hours.

So my question is - how do I preserve my large colour values? For example, the
uffizi light probe available from Paul Debevec's gallery has very large colour
values and the banding is rather extreme.

I have already tried setting the output file type to .HDR (+FH) but it does not
help. I am using the 3.7 beta by the way.

Any help would be greatly appreciated!

- sooperFoX

Post a reply to this message

sooperFoX napsal(a):
> Hi all, I hope this is the right place to post this query. (My apologies if
> not!)
> 
> I am attempting to use a pigment function to multiply the colour values of a
> somewhat sizeable set (1024) of previously rendered images, by a colour value
> from another source (different for each image in the set), and average the
> results together.
> 
> (I have rendered the same scene 1024 times with a single light source in
> different locations arranged in a hemisphere, and want to multiply each image
> with the colour value at the corresponding location from an HDR image. In this
> way I can see my scene with any lighting I want, without having to re-render
> the geometry.)
> 
> According to the documentation the "average" pigment type only supports up to
> 256 pigments to average. Since I need to be able to do more than that I wrote a
> function to calculate it with a loop.
> 
> So far, all is good.
> 
> The problem occurs when the colour value for any channel (R, G, B) exceeds 1.0 -
> the value for that channel seems to wrap back around to 0.0 and this is causing
> strange colour banding effects. I will post an image to p.b.i when I get home
> from work in a few hours.
> 
> So my question is - how do I preserve my large colour values? For example, the
> uffizi light probe available from Paul Debevec's gallery has very large colour
> values and the banding is rather extreme.
> 
> I have already tried setting the output file type to .HDR (+FH) but it does not
> help. I am using the 3.7 beta by the way.
> 
> Any help would be greatly appreciated!
> 
> - sooperFoX
> 
> 
as for the average, you can nest multiple averages. Average each 256 of 
the 1024 and then group the four results together.
as for the wrapping, I've got no idea

Post a reply to this message

Jan Dvorak <jan### [at] centrumcz> wrote:
> as for the average, you can nest multiple averages. Average each 256 of
> the 1024 and then group the four results together.

I don't know in advance how many I will need, and if it is not a multiple of 256
there would be too little weighting on the final set.

Anyway the averaging part works fine - the problem is with the function/pigment
colour mapping beforehand. See below.


> as for the wrapping, I've got no idea

I figured out WHY it is doing that - this is the code to map the function to a
colour. It is called 3 times - once for red, green and blue, for each image in
the set before it is averaged.

  pigment {
    function { Fn(x, y, z) }
    color_map {
      [ 0 color Color1 ]
      [ 1 color Color2 ]
    }
  }

....so if the value of the function is more than 1 it will wrap back to the first
colour in the color_map. I have confirmed this is what is happening with
Photoshop's colour eyedropper tool.

Now - HOW do I fix it? I don't want to add a million [ x color Color2*x ]
rows...


- sooperFoX

Post a reply to this message

pigment {
     function { Fn(x, y, z) / 1000 }
     color_map {
       [ 0 color Color1 ]
       [ 1 color Color2 * 1000 ]
     }
   }

I'm not sure I completely understand your process but this might at least
set you on the right track. The 1000 can be as large as it needs to be.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

"Slime" <fak### [at] emailaddress> wrote:
> pigment {
>      function { Fn(x, y, z) / 1000 }
>      color_map {
>        [ 0 color Color1 ]
>        [ 1 color Color2 * 1000 ]
>      }
>    }
>
> I'm not sure I completely understand your process but this might at least
> set you on the right track. The 1000 can be as large as it needs to be.

Thanks, Slime, that works wonderfully!

The theory is that if I pre-render every possible angle for a light source, then
I can multiply each angle's image by the colour of the light coming from that
angle (which I read directly from an HDR image map) and add the images together
and I end up with pretty much the same result as if I'd used the image map as a
sky sphere.

The advantage is that once I have my pre-rendered images I can change the
lighting and it takes less than a minute to combine and render all the images,
instead of however many hours it might take to render the complete scene each
time.

Of course it take several hours to render the set.. :) It's a trade-off. But you
can store away the set for later use, then if you get a new light probe and want
to see how it might looks for a scene you can find out very quickly.

I got the idea from an article on Paul Debevec's site where he actually built a
"light stage" that does exactly this, but in the real world - you put a live
object (e.g. a person) inside the thing, take lots of photos with light coming
from different directions, then you can composite the object into a synthetic
scene and re-light to any specifications.

http://www.debevec.org/Research/LS/

The site seems to be down right now, but you can still find the text by typing
'Light stage' into google and using the cache link.

- sooperFoX

Post a reply to this message

sooperFoX wrote:

> The problem occurs when the colour value for any channel (R, G, B) exceeds 1.0 -
> the value for that channel seems to wrap back around to 0.0 and this is causing
> strange colour banding effects. I will post an image to p.b.i when I get home
> from work in a few hours.

I know Slime already gave you a fix for this, but in case you run into 
more related problems, and for future reference, I give you this little 
clippit. This will ensure that f(x,y,z) will not exceed a value of one:

function{
  select(
  f(x,y,z)-1,
  f(x,y,z),
  1)
}


Sam

Post a reply to this message

stbenge <stb### [at] hotmailcom> wrote:
> sooperFoX wrote:
>
> > The problem occurs when the colour value for any channel (R, G, B) exceeds 1.0 -
> > the value for that channel seems to wrap back around to 0.0 and this is causing
> > strange colour banding effects. I will post an image to p.b.i when I get home
> > from work in a few hours.
>
> I know Slime already gave you a fix for this, but in case you run into
> more related problems, and for future reference, I give you this little
> clippit. This will ensure that f(x,y,z) will not exceed a value of one:
>
> function{
>   select(
>   f(x,y,z)-1,
>   f(x,y,z),
>   1)
> }
>
>
> Sam

Except that this clips the value at 1, which may not be the desired solution
under certain circumstances (i.e., you don't want them clipped).  In this case
the values need to be scaled to be within the 0-1 range rather than simply
clipped.

-tgq

Post a reply to this message