Hi Jasper,
hi Alstan,
I guess there are several issues in that case. First of all, as Alstan
wrote, you should crop the image and provide the correct lens specification
to evalglare. Be aware that editing the header could be dangerous, because
sometimes editors add strange characters or you don't see tabs in the
header with marks the view string there as "invalid" . In case the header
is interpreted "wrong" in evalglare, the results could be really random and
could differ for more than 100% from the right ones (e.g. the calculation
of the vertical illuminance, see presentation on the Radiance workshop in
2012). The header treatment is much more robust since the evalglare version
1.08, but still the user should take care of providing a correct header.
evalglare is relying on a correct radiance header. To be on the safe side,
you should always use the command option to provide the correct view option
to evalglare.
Also you should make sure, that you use a view type which really
corresponds to your lens. If your real lens is a hemispherical fish eye and
you provide -vta as view string, the angles and solid angles are
calculated wrong in evalglare and you get wrong results. So make sure that
you use -vta only if your lens is a angular fish eye.
And please don't use the -1 option in evalglare!!! This is a special
(undocumented) option to get fast results on images calculated without
ambient calculations. If you use it for normal images, the glare sources
might not detected correctly and you could get big differences. It is
working mostly properly in images with large black areas (-ab 0).
Since the -1 option is not robust for normal images, this option is
undocumented. There exist also other undocumented options since 2009 for
hdr treatment(e.g. pixel overflow correction, image fillup when ccd-array
is smaller than the projected image...), but these options are by purpose
undocumented because they should be used only in special cases and can
cause wrong results when not used properly.
If I look at your image, I guess your calibration is not correct. The sun
has a luminance of 2e10 cd/m2. In case of low transmittance glazing you
still have a luminance of Xe9 cd/m2, lets say at least 1e9cd/m2, which is
factor 200000 higher than you measured!!! And be aware you you might have
to deal with blooming effects when you have a pixel overflow (especially
when looking into the sun). Not sure about your camera setting, but if you
still have an overflow for the shortest exposure, you should think of
adding a neutral grey filter to reduce the overall transmittance to the ccd.
Finally I can't reproduce the 0 output of evalglare. I used your image and
used as well the 2500lux as input (even if the image is not cropped
correctly and the view string is wrong). See here:
*evalglare -i 2500 pmar_sin_03.hdr*
*Notice: Low brightness scene. Vertical illuminance less than 380 lux! dgp
might underestimate glare sources*
*dgp,dgi,ugr,vcp,cgi,Lveil: 0.311778 18.132195 21.670120 44.798004
27.925421 58.052605 *
But I always get an non-0 result, I never experienced this before. I tried
the linux ,the mac and also the windows version with your image - it didn't
happen. So which version are you using? Which operating system? (type
evalglare -v to find out)
@Alstan: Can you provide me another example where this happens as well?
Which version are you using? Which operating system?
A zero value should never appear, except your image is completely black.
Best,
Jan
Am 8/11/15 um 5:33 PM schrieb J. Alstan Jakubiec:
Hi Jasper,
This is one of the tricky aspects of doing glare analysis with your own
HDR images. A couple of pointers are below,
- You will need to crop your image to a square aspect about the image
center using the pcompos
<http://radsite.lbl.gov/radiance/man_html/pcompos.1.html> tool. There
was a helpful discussion on maintaining image exposure values while doing
this here
<http://www.radiance-online.org/pipermail/radiance-general/2011-March/007701.html>
.
- The -vv and -vh parameters are just best guesses according the HDR
generation software. Once you have cropped the image, you will want to open
the resulting HDR in a text editor and manually change the header 'VIEW'
field to include -vta -vv 180 -vh 180. You may also specify them via
the command line at this point, as you have done. I like to keep it
associated with the image.
- After that, unless I am forgetting something (others can chime in),
you are ready to run evalglare. I would run it with the -d flag, which
will report a lot of details. Most usefully, it reports illuminance as
derived from the image, which you can compare to your measured Ev value to
check the validity of the HDR. If your HDR is well-calibrated, not
inputting the measured illuminance value should be perfectly accurate.
- I suspect that inputting measured illuminance is somewhat broken in
the current version of evalglare as I have the same problem that you do.
One option is to use the -1 option to evalglare, which will return
only a single DGP value. It seems to avoid this error.
> evalglare -1 -i 2500 image.hdr
By the way, to avoid some of this cropping and exposure value pain, I use
an image-processing tool (like PIL for Python) these days that can maintain
EXIF data while cropping the source jpeg files. Though perhaps the cure is
worse than the disease in this case..
Best,
Alstan
On 8/11/2015 11:08 PM, Jasper Overduin wrote:
Dear all,
I have changed my lens to one with 180 circular view to do a contrast
analysis (hdrscope) and meanwhile the glare analysis in evalglare. If i use
the commands in evalglare getinfo i get the (HDR composed with photosphere
on a mac, calibrated with luminance pistol) i get a value for the lens -vv
and -vh which is not over 100, with a lens of 180. I can imagine that the
photo ratio and the lens are not the same and that causes this problem. But
when I enter the external measured Ev, the value the dgp goes somehow to
zero. The fact that the gdp is zero with a maximum luminance of 5600 cd/m2
and Ev of 2500 lux makes me a bit suspicious. How accurate is the result of
the dgp without external vertical lux? is it possible to use this value?
hdr files and printscreens of evalglare
<Dropbox - Error - Simplify your life;
Dropbox - Error - Simplify your life
Greetings Jasper
*Jasper Overduin*
MSc. Building Technology graduate student at Delft University of Technology
*S* Groenhoevelaan 3
*P* 2343 BP Oegstgeest
*T* +31 6 15 64 48 56 (NL)
*T* +56 9 51 11 76 48 (CL)
*E * <[email protected]>[email protected]
*Skype *jasper.overduin
On 1 May 2015 at 12:15, Jan Wienold <[email protected]> wrote:
Hi Jasper,
I briefly looked at your image - for sure you get a low DGP value if your
illuminance at camera (or eye) level is only about 300lux... It is not the
matter of the fish eye lens it is a matter of your lighting condition.
When I remember correctly, for the experiments I did for my PhD, the
people adjusted the blinds in a way, that they had 2500-3000 lux at the eye
level and they were less than 20% of them dissatisfied. So a value of 300
means one order of magnitude less light at the eye level and a much lower
adaptation level.
So I definitely understand the low DGP value in that case. The images
themselves look reasonable, so I don't think there is a problem in
calibration/processing so far (at least not for these low luminance
levels-it might be more tricky to calibrate for the high luminance values
when you get stray-light from the multiple lenses).
If all your images are like that it means you have a very low daylight
contribution at the place you measure. I'm not sure if DGP is then the
right way to measure glare in that case - as I wrote it is made more for
the daylight oriented workplace with higher levels and also to take into
account very high luminances (e.g. sun or specular reflections of the sun).
DGP might be modified in future, but these experiments are just starting.
Jan
Am 4/30/15 um 10:41 PM schrieb Jasper Overduin:
Thank you for the fast reply. We are still having some problems with the
outcome of Evalglare. With an external luxometre we have done some tests
now. The DGP is still very low or zero. It seems that in almost all the
case the DGP is low. In literature we read that values above 20% are
normal. What do you think? is the data much better if we use a full 180
degree lens?
.hdr file Dropbox - Error - Simplify your life
print screen cmd
<Dropbox - Error - Simplify your life;
Dropbox - Error - Simplify your life
test.pic Dropbox - Error - Simplify your life
Greetings Jasper
*Jasper Overduin*
MSc Building Technology graduate student at Delft University of
Technology
*S* Groenhoevelaan 3
*P* 2343 BP Oegstgeest
*T* +31 6 15 64 48 56 (NL)
*T* +56 9 51 11 76 48 (CL)
*E * <[email protected]>[email protected]
*Skype *jasper.overduin
On 30 April 2015 at 13:55, Jan Wienold < <[email protected]> >>> [email protected]> wrote:
Hi Jasper,
why are you using -vth -vh 140 -vv 80 when in your header of the HDR
image the view is specified as -vtv -vh 98.797409 -vv 75.402067 ?
Manipulating the lense type is really dangerous - in that case you
change from a perspective view to a hemispherical fish eye view, without
changing the image!!
If I apply evalglare for your image I get 0.17 as DGP (which is still
very low, but you have only 2000cd/m2 as maximum value, so this can be
expected). Be aware, that DGP accounts only for glare from a high amount of
daylight and/or spots of extreme luminances (>50000cd/m2), but not for
contrasted glare between task (e.g. Monitor) and immediate surroundings for
lower adaptation levels. This is subject of current research (also here at
EPFL) and there might be an extension of the DGP in future, depending on
the outcome of new experiments.
Back to the lens-type:
It is extremely important, that the right view type is given to
evalglare, otherwise ALL calculated values (it doesn't matter if this is
evalglare or findglare) are wrong. These errors could be huge, more than
100% for calculating the illuminance out of a 180 degree image.
If you manipulate an image by pcomb, in general the view is marked as
"invalid" in the header, because with that tool you could manipulate the
image in a way, that the original view is not valid any more. This is why
from evalglare version 1.0 on a check on the header was included, because
many people were creating wrong headers without knowing it and then
evalglare was calculating wrong values, when the header was invalid.
In addition for calculating the DGP it is important to have the
illuminance at camera level. evalglare calculates this value out of the
image. But if the image does not cover 180 degree, then the calculated
value for the illuminance is too low. For that reason, the -i option was
included, so you can provide the illuminance to evalglare (when you measure
it with an illuminance sensor).
So in your case, you should measure the illuminance just besides the
lens.
Then (in case this is the right lens description) you should use
evalglare -i LUXVALUE -vtv -vh 98.797409 -vv 75.402067 IMAGE_NAME
or better, if your task is always at the same place:
evalglare -i LUXVALUE -vtv -vh 98.797409 -vv 75.402067 -T 395 230 .6
-c CHECK_FILE_PICTURE IMAGE_NAME
good luck!
Jan
Am 4/30/15 um 6:04 PM schrieb Jasper Overduin:
Somehow cant use the command pfilt or change the pcomb, does this has
to do with the program Radiance? I have installed the version of windows
from the site, with evalglare v1.11windows . The problem is that I have
composed a .hdr (out of 7 jpg on a mac) and after using the command
c:/HDRI>evalglare -vth -vh 140 -vv 80 image.hdr all the dgp results are
really low, less than 5%. The problem can be in the .hdr (calibrated as
well) or is in the way evalglare is not working as it shoot on my computer.
*.hdr file* (post-it is calibration point 167,98)
<Dropbox - Error - Simplify your life;
Dropbox - Error - Simplify your life
*images* original
<Dropbox - Error - Simplify your life;
Dropbox - Error - Simplify your life
*command printscreen*
<Dropbox - Error - Simplify your life;
Dropbox - Error - Simplify your life
Need the help!
Greetings Jacobus
*Jasper Overduin*
MSc Building Technology graduate student at Delft University of
Technology
*S* Groenhoevelaan 3
*P* 2343 BP Oegstgeest
*T* +31 6 15 64 48 56 (NL)
*T* +56 9 51 11 76 48 (CL)
*E * <[email protected]>[email protected]
*Skype *jasper.overduin
_______________________________________________
Radiance-general mailing [email protected]://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
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
_______________________________________________
Radiance-general mailing [email protected]://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
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
_______________________________________________
Radiance-general mailing [email protected]://www.radiance-online.org/mailman/listinfo/radiance-general
_______________________________________________
Radiance-general mailing [email protected]://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
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
