clipka <ano### [at] anonymousorg> wrote:
> Am 24.03.2017 um 00:14 schrieb muyu:
>
> > For each leaf, 0.4957 is scatted directly. 0.4409 is transmitted and scatted. So
> > as I understood, I should not use any filter. The two sides diffuse is the right
> > choice. Am I right?
>
> Yes, you are.

For different wavelength, reflectances and transmitances vary a lot. Is it
possible to set different value for different channels? I can save the radiosity
data and reuse for other wavelength? My objective is to save the render time for
different channels.

>
> > So it means 20 times of recursion is not enough? Is it
> > possible to set larger value.Now for me, the rendering time is still
> > acceptable.
>
> If building your own modified POV-Ray binaries is an option, you could
> edit the definition of DEPTH_MAX in `source/core/lighting/radiosity.h`.
>

Thanks. I build my own POV-Ray and change the DEPTH_MAX to 20000. Then the
recursion limit comes to be 255. Is it right?

Surprisingly, the reflectance increases very very silightly even when I set
recursion at 255. Here is the setting of the radiosity. I am wondering if I can
further increase the reflectance. It is still 5 to 10% underestimate. Still some
light is not absorbed?

#version 3.7;
global_settings {
   assumed_gamma 1.0
   ambient_light 0.0
   adc_bailout 0.0
   max_trace_level 200

   radiosity {
      count 1500
      error_bound 0.1
      recursion_limit 100
      always_sample on

      gray_threshold 0.00
      brightness 1.0
      normal on
   }
}


Here it the *.ini file. I output the image as *.png. The transfer is linear? The
setting of Antialias impacts the result...the Antialias_gamma = 1.0 or 0.0?

Antialias = on
Antialias_Threshold = 0.0
Antialias_Depth = 5
Antialias_Gamma = 1.0
Input_File_Name = "canopy_ERE_NIR.pov"
File_Gamma = 1.0

width = 4000
height = 4000

Pov-ray uses radiosity to simulate the diffuse light. Compared with Monte Carlo,
physically we should get very similar result?


Thanks again.

Shouyang

Post a reply to this message

Am 31.03.2017 um 19:08 schrieb muyu:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 24.03.2017 um 00:14 schrieb muyu:
>>
>>> For each leaf, 0.4957 is scatted directly. 0.4409 is transmitted and scatted. So
>>> as I understood, I should not use any filter. The two sides diffuse is the right
>>> choice. Am I right?
>>
>> Yes, you are.
> 
> For different wavelength, reflectances and transmitances vary a lot. Is it
> possible to set different value for different channels? I can save the radiosity
> data and reuse for other wavelength? My objective is to save the render time for
> different channels.

Currently the colours for reflectance and transmittance are both tied to
the pigment.


> Thanks. I build my own POV-Ray and change the DEPTH_MAX to 20000. Then the
> recursion limit comes to be 255. Is it right?

Something in that ballpark, at any rate.


> Surprisingly, the reflectance increases very very silightly even when I set
> recursion at 255. Here is the setting of the radiosity. I am wondering if I can
> further increase the reflectance. It is still 5 to 10% underestimate. Still some
> light is not absorbed?

A maximum recursion setting of 255 should be more than enough; I'm a bit
at a loss where the remaining light is swallowed -- are you sure your
reference is correct?


> Here it the *.ini file. I output the image as *.png. The transfer is linear? The
> setting of Antialias impacts the result...the Antialias_gamma = 1.0 or 0.0?

When using `File_Gamma=1.0`, PNG output does indeed use linear transfer.

`Antialias_Gamma` is not the colour space in which oversampling averages
are computed (that's always done in linear colour space) but rather the
colour space in which it is tested whether colours of adjacent pixels
are different enough to warrant oversampling. The default value should
be fine.

> 
> Antialias = on
> Antialias_Threshold = 0.0
> Antialias_Depth = 5
> Antialias_Gamma = 1.0
> Input_File_Name = "canopy_ERE_NIR.pov"
> File_Gamma = 1.0
> 
> width = 4000
> height = 4000
> 
> Pov-ray uses radiosity to simulate the diffuse light. Compared with Monte Carlo,
> physically we should get very similar result?

I think we should get virtually identical results, plus/minus some noise
(white noise in case of Monte Carlo, lower-frequency noise in case of
radiosity).

Post a reply to this message

> > Surprisingly, the reflectance increases very very silightly even when I set
> > recursion at 255. Here is the setting of the radiosity. I am wondering if I can
> > further increase the reflectance. It is still 5 to 10% underestimate. Still some
> > light is not absorbed?
>
> A maximum recursion setting of 255 should be more than enough; I'm a bit
> at a loss where the remaining light is swallowed -- are you sure your
> reference is correct?

The reference is the esemble of several radiative transfer model based on Monte
Carlo. (RAMI-online, http://romc.jrc.ec.europa.eu/Home.php)

If Pov-ray is physically un-biased, consistent results are expected (right?). A
slight 5 to 10% underestimate is found. I guess there are two possibilities:

1) Still some light is not absorbed. Possible?

2) The calibration factor may be wrong. I simulated the reference panel and set
the diffuse as 1.0. The value is the same over different viewing angles. But I
found that when I increased the height of the light source, the value may change
from 239 to 240 (why?). Then the reflectance in the scene is caculated by diving
this calibration factor. Is this the right way?

Thanks a lot for your patience.

Shouyang

Post a reply to this message

Am 03.04.2017 um 11:26 schrieb muyu:

> 2) The calibration factor may be wrong. I simulated the reference panel and set
> the diffuse as 1.0. The value is the same over different viewing angles. But I
> found that when I increased the height of the light source, the value may change
> from 239 to 240 (why?). Then the reflectance in the scene is caculated by diving
> this calibration factor. Is this the right way?

I'm not sure I really understand what you are doing there.


If you are multiplying the `diffuse` parameters by 240/255, then you are
doing it wrong: The parameters should be set to the actual reflectance
and transmittance, /not/ "calibrated" somehow.


Also, if you place a light source of colour `rgb <1,1,1>` with no light
fading at a reasonably far distance directly overhead a planar surface
with `pigment { rgb <1,1,1> }` and `finish { diffuse 1 specular 0
ambient 0 }`, you should get a result brightness of 100% (corresponding
to an encoded pixel value of 255), /not/ something around 95%
(corresponding to an encoded pixel value of about 240).

As for the distance-dependency of the brightness, you might be measuring
off-center, and seeing a dip in brightness due to the light impinging
non-vertically; this dip is smaller the further away you place your
light source.

An alternative to a far-away light source would be a parallel light source.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 03.04.2017 um 11:26 schrieb muyu:
>
> > 2) The calibration factor may be wrong. I simulated the reference panel and set
> > the diffuse as 1.0. The value is the same over different viewing angles. But I
> > found that when I increased the height of the light source, the value may change
> > from 239 to 240 (why?). Then the reflectance in the scene is caculated by diving
> > this calibration factor. Is this the right way?
>
> I'm not sure I really understand what you are doing there.

I am simulating the canopy reflectance under different solar and camera
configurations.

The incident solar radiation is parallel but not always nadir. For instance, I
set the light source (zenith anglen 20 degree)
light_source{<0,36.397,100> color rgb<0,1,0> parallel}

Then for a planar surface with optical properties `finish { diffuse 1 specular 0
ambient 0 }`, I got reflectance 239 (or 240 when the light source is moved
further away). This value was considered as the calibration factor (f) for
reflectance 1.0.

Then for given camera configuration, I render the image of the targetting canopy
with the same light source. Then the encoded pixel value of the image was
averaged (color) and divided by the calibration factor instead of 255 to get the
canopy reflectance (Ref), i.e. Ref = color/f.

Or it should be Ref = color/255 + (1 - f/255) ?


Great thanks again.

Shouyang

Post a reply to this message

On 04/03/2017 10:14 AM, muyu wrote:
> clipka <ano### [at] anonymousorg> wrote:
>
> Great thanks again.
>
> Shouyang
>

Just thinking aloud and perhaps you've covered it with Christoph at some 
point, but there is both the angle of the light original & derived rays 
relative to the surface and the camera ray angle relative to the 
surface. Are you using a perspective camera or an orthogonal one?

My instinct would be to measure via an orthogonal ground camera up into 
the canopy representation for some area below the canopy unless you are 
trying to match some specification for the camera from your reference 
set up and result.

I wonder some too about the edges, the range, of your canopy discs given 
you are sometimes setting the parallel light source at some offset 
angle. In other words are you sure light is not bleeding in faster at 
the edges of the representation when the light isn't perpendicular to 
your canopy representation and measurement plane?

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 04/03/2017 10:14 AM, muyu wrote:
> > clipka <ano### [at] anonymousorg> wrote:
> >
> > Great thanks again.
> >
> > Shouyang
> >
>
> Just thinking aloud and perhaps you've covered it with Christoph at some
> point, but there is both the angle of the light original & derived rays
> relative to the surface and the camera ray angle relative to the
> surface. Are you using a perspective camera or an orthogonal one?

I am using the orthogonal camera. I do not know which is better?

> My instinct would be to measure via an orthogonal ground camera up into
> the canopy representation for some area below the canopy unless you are
> trying to match some specification for the camera from your reference
> set up and result.

I need set the camera looking downward to mimic the real set-up.
>
> I wonder some too about the edges, the range, of your canopy discs given
> you are sometimes setting the parallel light source at some offset
> angle. In other words are you sure light is not bleeding in faster at
> the edges of the representation when the light isn't perpendicular to
> your canopy representation and measurement plane?

As I know, there will be some border effect. So I set the camera looking at the
center of the canopy. I do not know exactly how pov-ray manage the parallel
light especially around the border. Thanks in advance.

Shouyang

Post a reply to this message

Am 03.04.2017 um 16:14 schrieb muyu:

> The incident solar radiation is parallel but not always nadir. For instance, I
> set the light source (zenith anglen 20 degree)
> light_source{<0,36.397,100> color rgb<0,1,0> parallel}

That definitely explains the slight difference in brightness when the
light source is close.

> Then for a planar surface with optical properties `finish { diffuse 1 specular 0
> ambient 0 }`, I got reflectance 239 (or 240 when the light source is moved
> further away). This value was considered as the calibration factor (f) for
> reflectance 1.0.
> 
> Then for given camera configuration, I render the image of the targetting canopy
> with the same light source. Then the encoded pixel value of the image was
> averaged (color) and divided by the calibration factor instead of 255 to get the
> canopy reflectance (Ref), i.e. Ref = color/f.
> 
> Or it should be Ref = color/255 + (1 - f/255) ?

It depends on what exactly you actually want to measure. I have a hunch
that what you actually need is color/255, i.e. the using zenith sun as
the reference, regardless of the sun angle you want to take a
measurement for; but that ultimately depends on the specifications of
the task you have been given.


Another potential source for error would be the averaging of the image;
depending on the software you are using, and the transfer function used
in the image encoding; it might be done on non-linear values, in which
case the result will under-estimate the value.

Post a reply to this message

> clipka <ano### [at] anonymousorg> wrote:
>> Am 03.04.2017 um 11:26 schrieb muyu:
>>
>>> 2) The calibration factor may be wrong. I simulated the reference panel and set
>>> the diffuse as 1.0. The value is the same over different viewing angles. But I
>>> found that when I increased the height of the light source, the value may change
>>> from 239 to 240 (why?). Then the reflectance in the scene is caculated by diving
>>> this calibration factor. Is this the right way?
>>
>> I'm not sure I really understand what you are doing there.
>
> I am simulating the canopy reflectance under different solar and camera
> configurations.
>
> The incident solar radiation is parallel but not always nadir. For instance, I
> set the light source (zenith anglen 20 degree)
> light_source{<0,36.397,100> color rgb<0,1,0> parallel}
>
> Then for a planar surface with optical properties `finish { diffuse 1 specular 0
> ambient 0 }`, I got reflectance 239 (or 240 when the light source is moved
> further away). This value was considered as the calibration factor (f) for
> reflectance 1.0.
>
> Then for given camera configuration, I render the image of the targetting canopy
> with the same light source. Then the encoded pixel value of the image was
> averaged (color) and divided by the calibration factor instead of 255 to get the
> canopy reflectance (Ref), i.e. Ref = color/f.
>
> Or it should be Ref = color/255 + (1 - f/255) ?
>
>
> Great thanks again.
>
> Shouyang
>
>

If your light is not dirrectly above but at an angle and pointing at a 
given point, then, placing it higher have the effect of making it closer 
to been sttaight up.

When mooving the light up, be sure that you also move it laterally in a 
proportional maner. One way would be to place it along a given axis at 
the desired distance, then use a rotate statement to actually place it 
at the desired location.
Use :
light_source{-1000*z rgb 1 rotate <75,0,0>}

Post a reply to this message

No idea if it's of any use, but I came upon this at random, and it looked
closely related.
Perhaps there's something on the site, in the source code, or the documentation
that would be of use to you in your project.

http://www.skirt.ugent.be/website/index.html

Post a reply to this message