I'm running evalglare on some 1000x1000 5-phase method output files, and
getting runtimes in the 15+ minute neighborhood. Is this plausible? Or is
there something serious wrong here?
···
--
Randolph M. Fritz || [email protected]
Try running getinfo on one of the images. How long is the header?
Andy
···
On Apr 9, 2016, at 5:00 PM, Randolph M. Fritz <[email protected]> wrote:
I'm running evalglare on some 1000x1000 5-phase method output files, and getting runtimes in the 15+ minute neighborhood. Is this plausible? Or is there something serious wrong here?
--
Randolph M. Fritz || [email protected]
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
Hi Randolph,
it's hard to tell without additional information - calculation time depends on so many factors, mainly on the amount of glare pixels found AND on the parameters you are submitting to evalglare.
But 15min is VERY unusual with this size of the image.
run it with the -d option and write also a checkfile with -c . Please post then the full header of the checkfile (output of getinfo, please keep all characters of including all tabs and spaces) and the output you get on standard output.
Do you create the image with a proxy geometry?
Jan
···
On 10/04/16 02:00, Randolph M. Fritz wrote:
I'm running evalglare on some 1000x1000 5-phase method output files, and getting runtimes in the 15+ minute neighborhood. Is this plausible? Or is there something serious wrong here?
--
Randolph M. Fritz || [email protected] <mailto:[email protected]>_______________________________________________
Radiance-general mailing list
[email protected]
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
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.
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_rgbestdout:
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.000000stderr was blank. A BSDF proxy surface was in the image.
_______________________________________________
Radiance-general mailing list
[email protected]
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
Thanks. I didn't think to light the screen, duh, despite just having read
that piece of the man page multiple times. To save recalculation I will
probably start using "-b 750" or "-b 1000" instead, which is about five
times the brightness of your typical LCD.
For the annual glare evaluation using DGP, I've developed another method...
Have you published this method yet?
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
Ouch! Yes, that makes sense.
Thank you very much.
Randolph