[Radiance-general] Lo-o-o-ng evalglare times

Tue Apr 12 06:50:43 PDT 2016

Hi Randolph,

your header looks ok, I just wanted to be sure there are no "technical" 
reasons for the strange behavior (e.g. a tab in from of a EXPOSURE or 
multiple exposures might cause troubles.)

The trouble you run into is, that you detect a lot of glare pixels. It 
seems your selected task area is rather dark (average luminance in that 
area is 26cd/m2), that means in that case all pixels above 26*5=128cd/m2 
are treated as potential glare sources. So around 80-90% of the image is 
treated as glare source pixels and since you don't have any pixel over 
50000 cd/m2 (max is 13559) all these pixels are summarized to one glare 
source.

I don't know details about your scene (maybe you can send me also an 
example image), but I would assume that the luminance of the task area 
you have defined does not correspond to the adaptation luminance, which 
I expect to be higher in an environment with an average luminance of 636 
cd/m2.
I guess if you look at the output image, more or less everything except 
the area you have defined is treated as glare source.
If the space is used in a usual way (lets say similar like office tasks, 
computer or reading tasks), then the applied setting is not working 
properly. If the task is a computer screen, then probably you have to 
increase the luminance of the screen to 120-200cd/m2. If the 25 cd/m2 is 
realistic (e.g. you have a dark screen) then I would probably apply a 
fixed value (e.g. 2000cd/m2) as threshold for the glare source detection 
(-b 2000). Or just run evalglare without any task option, in that case 
any pixel larger than 5*636=3180cd/m2 is treated as a glare source. This 
might lead to more realistic glare sources.
In principal it is good to check which parts of the scene are detected 
as glare pixels, that's why I integrated the -c option (coloring the 
detected glare sources) from the beginning, because algorithms can 
always fail and the detection of realistic glare sources in any kind of 
scene is a rather challenging task. That's why I also have implemented 
three detection options (fixed threshold, average luminance threshold 
and the task area threshold method). In my experiments, the task area 
option worked best, but in other situations (probably like yours) it 
might be better to apply another algorithm.

With less detected pixels you have also much less calculation time, 
which was your original concern. The scenes I'm evaluating usually, the 
calculation time mostly does not exceed 30s. For the annual glare 
evaluation using DGP, I've developed another method where the generation 
of the image and the evalglare evaluation takes in average less than a 
second in total for one timestep , based on a simplified image (-ab 0) 
and daylight coefficient method to derive the illuminance at eye level 
(based on daysim, but this can be done also with the 3 or 5 phase method).

But important to know: If you expect, that the contrast between task 
(e.g. if the 25cd/m2 are "real" and people would adapt to this level) 
and background (e.g. 1000cd/m2) is a problem, then I'm afraid that none 
of the existing glare metrics will detect that properly -even if you 
adjust the parameters and glare sources are detected more realistically. 
We are currently planning experiments to overcome this problem, but this 
needs some time to improve the existing models.

Jan

On 12/04/16 05:22, Randolph M. Fritz wrote:
> Here you go. Unfortunately, the gmail's web client doesn't preserve
> tabs, but maybe this will do. If not, let me know and I will get you
> the exact file.
>
> Getinfo:
> #?RADIANCE
> CAPDATE= 2016:04:11 19:51:15
> GMT= 2016:04:12 02:51:15
> evalglare -t 500 500 0.541052 -vf screen_w.vf -d -c gc.hdr gltw0014.hdr
> evalglare 1.17 release 15.07.2015 by EPFL, J.Wienold
> VIEW= -vth -vp 1.033 0.6043 1.018 -vd -0.5 0 -0.05 -vu 0 0 1 -vh 180
> -vv 180 -vo 0 -va 0 -vs 0 -vl 0
> FORMAT=32-bit_rle_rgbe
>
> stdout:
> 1 No pixels x-pos y-pos L_s Omega_s Posindx L_b L_t E_vert Edir
> Max_Lum Sigma xdir ydir zdir Eglare_cie Lveil_cie
> 1 596380.000000 489.332038 454.899168 772.713096 4.8394297435 1.186575
> 58.877235 25.889767 1531.311361 1495.264730 13559.250000 5.358756
> -0.999743 -0.021000 -0.008520 1495.264730 520.702975 5.358756
> dgp,av_lum,E_v,lum_backg,E_v_dir,dgi,ugr,vcp,cgi,lum_sources,omega_sources,Lveil,Lveil_cie,band_avlum:
> 0.296236 636.826041 1531.311361 58.877235 1495.264730 24.791222
> 31.521862 0.000000 32.233898 772.713096 4.839430 3473.890869
> 520.702975 -99.000000
>
> stderr was blank. A BSDF proxy surface was in the image.
>
> _______________________________________________
> Radiance-general mailing list
> Radiance-general at radiance-online.org
> http://www.radiance-online.org/mailman/listinfo/radiance-general

-- 
Dr.-Ing.  Jan Wienold
Ecole Polytechnique Fédérale de Lausanne (EPFL)
EPFL ENAC IA LIPID

http://people.epfl.ch/jan.wienold
LE 1 111 (Office)
Phone    +41 21 69 30849