Hi Belal,
actually evalglare just evaluates, if the exposure is "valid" - as soon
as it is marked as "invalid" (e.g. by the use of pcomb, pcompos) it
stops. It is good to see that the new safety feature in evalglare works
properly and prevents making mistakes in the header treatment ;-).
Actually evalglare can handle multiple ("valid") exposure entries, e.g.
of you apply several time pfilt...
As Clotilde mentioned, just avoid the exposure completely and try to get
the exposure values "in-cooperated" into pixel values (ra_xyz or pcomb
-o ). Actually there is no need to add it at the end again with value 1,
but it does not hurt.
And other remarks:
- why are you masking the image? If you do this to set the values
outside 180 to zero, then it is not necessary. Evalglare automatically
sets the values outside the field of 180°x180° to zero. It is an
additional effort for you to create the right mask, the mask might
change between apertures and applying it does not change anything, when
you apply evalglare afterwards. If you just use evalglare, it is useless
to apply masking to remove areas outside 180°.
- why are you mapping it to vth? Although evalglare can handle -vth
views, I recommend using -vta. The reason is, that due to definition
reasons, I have to set the outer pixels (at 180°) to zero, as soon as
one corner of the pixel is outside of the 180 (problems occur, when the
center of a pixel is "inside", but one corner "outside"). So you loose
one "row" (well actually it is a circle) of pixels.This does not apply
to -vta.
- if I see your view string, I'm not sure this is correct, are you
having only around 50° view angle? No fish-eye? (in your header :-vh
49.0537 -vv 49.0537). If you don't have a fish-eye, why are you mapping
it to fish-eye? evalglare could handle also -vtv (of course cannot
calculate a correct illuminance, when the FOV is not at least 180.
- if you have a fish-eye, please check the projection method of your
lens. Many of the lenses are equal-solid-angle and have to be re-mapped
before they can be used in any radiance-based tools, which need the
correct angles (e.g. evalglare, findglare..).
Jan
On 02.10.17 08:20, Belal Abboushi wrote:
Hi Greg,
Unfortunately that didn't satisfy evalglare. My hunch is that
evalglare reads indented EXPOSURE lines and then doesn't know which
exposure line to pick. Is there a way to erase the 2 old exposure
lines in post processing? I'm trying to avoid having to manually edit
header for each HDRI individually.
Thank you for helping,
Belal
_______________________________________________
HDRI mailing list
[email protected]
https://www.radiance-online.org/mailman/listinfo/hdri
--
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
_______________________________________________
HDRI mailing list
[email protected]
https://www.radiance-online.org/mailman/listinfo/hdri
