[HDRI] Duplicated lines in HDRI header

[Belal Abboushi]

Hi all,

I am putting together a post processing cmd batch file to convert image to
hemispherical, resize, crop, mask, apply vignetting image, etc. The problem
I'm facing is that header of the resultant HDRI header contains some
duplicated lines, I am particularly concerned about view and exposure
lines, as you can see below:

#?RADIANCE
CAPDATE= 2017:09:30 22:49:12
GMT= 2017:10:01 05:49:12
9_1043com.hdr:
CAPDATE= 2017:09:30 22:49:10
GMT= 2017:10:01 05:49:10
maskc.hdr:
ra_bmp -r
9_1043cs.hdr:
CAPDATE= 2017:09:30 22:49:09
GMT= 2017:10:01 05:49:09
9_1043.hdr:
CAPDATE= 2017:09:30 22:49:08
GMT= 2017:10:01 05:49:08
9_1043.hdr:
CAMERA= Canon Canon PowerShot G15 version v.0
hdrgen created HDR image from 'IMG_8062.JPG' 'IMG_8061.JPG' 'IMG_8060.JPG'
'IMG_8059.JPG' 'IMG_8058.JPG' 'IMG_8057.JPG'
Removed lens flare
EXPOSURE=2.057471e-01
VIEW= -vtv -vh 49.053696 -vv 49.053696
CAPDATE= 2017:06:22 10:43:42
PRIMARIES= 0.6400 0.3300 0.3000 0.6000 0.1500 0.0600 0.3127 0.3290
pinterp -vf 9_1043.hdr -vth -x 1200 -y 1200 -ff 9_1043.hdr 1
VIEW= -vth -vp 0 0 0 -vd 0 1 0 -vu 0 0 1 -vh 49.0537 -vv 49.0537 -vo 0 -va
0 -vs 0 -vl 0
EXPOSURE=2.057471e-01
pcompos -x 1126 -y 1126 9_1043.hdr -55 -14
pfilt -1 -e 1.000 -x /1.4075 -y /1.4075
pcomb -e
ro=if(ri(1)-0.5,ri(2),0);go=if(gi(1)-0.5,gi(2),0);bo=if(bi(1)-0.5,bi(2),0)
maskc.hdr 9_1043cs.hdr
G15Vig.hdr:
ra_tiff -r
pcomb -e "ro=ri(1) / ri(2);go=gi(1) / gi(2);bo=bi(1) / bi(2)" -o
9_1043com.hdr G15Vig.hdr
FORMAT=32-bit_rle_rgbe
EXPOSURE=0.342682082

I am eager to hear your input on how to clean it up so it'd run in
Evalglare. Any suggestions are greatly appreciated!

Best,
Belal Abboushi


*Belal K. Abboushi*
Ph.D. Candidate | Department of Architecture
University of Oregon

[Gregory J. Ward]

The header lines from the inputs to pcomb and pcompos should be indented, which leads their being ignored during processing.

If your header is lacking the indentations, then something may be going wrong in your processing chain. Can you e-mail me your actual image so I may examine the header directly?

-Greg

Date: September 30, 2017 11:49:06 PM PDT
Hi all,
#?RADIANCE
CAPDATE= 2017:09:30 22:49:12
GMT= 2017:10:01 05:49:12
CAPDATE= 2017:09:30 22:49:10
GMT= 2017:10:01 05:49:10
ra_bmp -r
CAPDATE= 2017:09:30 22:49:09
GMT= 2017:10:01 05:49:09
CAPDATE= 2017:09:30 22:49:08
GMT= 2017:10:01 05:49:08
CAMERA= Canon Canon PowerShot G15 version v.0
hdrgen created HDR image from 'IMG_8062.JPG' 'IMG_8061.JPG' 'IMG_8060.JPG' 'IMG_8059.JPG' 'IMG_8058.JPG' 'IMG_8057.JPG'
Removed lens flare
EXPOSURE=2.057471e-01
VIEW= -vtv -vh 49.053696 -vv 49.053696
CAPDATE= 2017:06:22 10:43:42
PRIMARIES= 0.6400 0.3300 0.3000 0.6000 0.1500 0.0600 0.3127 0.3290
pinterp -vf 9_1043.hdr -vth -x 1200 -y 1200 -ff 9_1043.hdr 1
VIEW= -vth -vp 0 0 0 -vd 0 1 0 -vu 0 0 1 -vh 49.0537 -vv 49.0537 -vo 0 -va 0 -vs 0 -vl 0
EXPOSURE=2.057471e-01
pcompos -x 1126 -y 1126 9_1043.hdr -55 -14
pfilt -1 -e 1.000 -x /1.4075 -y /1.4075
pcomb -e ro=if(ri(1)-0.5,ri(2),0);go=if(gi(1)-0.5,gi(2),0);bo=if(bi(1)-0.5,bi(2),0) maskc.hdr 9_1043cs.hdr
ra_tiff -r
pcomb -e "ro=ri(1) / ri(2);go=gi(1) / gi(2);bo=bi(1) / bi(2)" -o 9_1043com.hdr G15Vig.hdr
FORMAT=32-bit_rle_rgbe
EXPOSURE=0.342682082
I am eager to hear your input on how to clean it up so it'd run in Evalglare. Any suggestions are greatly appreciated!
Best,
Belal Abboushi
Belal K. Abboushi
Ph.D. Candidate | Department of Architecture
University of Oregon
_______________________________________________
HDRI mailing list
https://www.radiance-online.org/mailman/listinfo/hdri

[Gregory J. Ward]

Hi Belal,

I am not familiar with hdrscope, but you might inform the author that it's not a good idea to remove the tabs when reporting the header, since they are very important to the interpretation of the image.

Since all of the views are indented in your header, you will at minimum need to add back a valid VIEW= line to the header, using the getinfo "-a" option we discussed earlier, e.g.:

getinfo -a "VIEW= -vta -vh 180 -vv 180" < processed.hdr > final.hdr

Best,
-Greg

Date: October 1, 2017 10:57:25 AM PDT
Hi Greg,
The header does contain indentations. The header I posted to forum is copied from hdrscope. Attached is the header file (directly from radiance) and the Image.
Thank you very much for helping,
--
Best,
Belal
Date: October 1, 2017 10:36:27 AM PDT
The header lines from the inputs to pcomb and pcompos should be indented, which leads their being ignored during processing.
If your header is lacking the indentations, then something may be going wrong in your processing chain. Can you e-mail me your actual image so I may examine the header directly?
-Greg

Date: September 30, 2017 11:49:06 PM PDT
Hi all,
#?RADIANCE
CAPDATE= 2017:09:30 22:49:12
GMT= 2017:10:01 05:49:12
CAPDATE= 2017:09:30 22:49:10
GMT= 2017:10:01 05:49:10
ra_bmp -r
CAPDATE= 2017:09:30 22:49:09
...
EXPOSURE=0.342682082
I am eager to hear your input on how to clean it up so it'd run in Evalglare. Any suggestions are greatly appreciated!
Best,
Belal Abboushi

[Belal Abboushi]

Hi Greg,
Thanks for looking into this. I added the view line but I still get the
same error message from evalglare, which is:

error: header contains invalid exposure entry!!!!
Check exposure and correct header setting~
Stopping.

I tried to manually (using hdrscope) delete the two indented exposure lines
(which leaves one) and evalglare seems to run fine.
Any suggestions are greatly appreciated.

Thank you,
Belal

[Gregory J. Ward]

Ah. I guess evalglare expects an exposure line in the file as reassurance it wasn't produced by Photoshop or some other program that doesn't concern itself with absolute calibration. In that case, try changing the final process to:

getinfo -a "VIEW= -vta -vh 180 -vv 180" "EXPOSURE=1.0" < processed.hdr > final.hdr

Hopefully, evalglare will be satisfied with that (and it will be correct).

Cheers,
-Greg

Date: October 1, 2017 2:55:15 PM PDT
Hi Greg,
error: header contains invalid exposure entry!!!!
Check exposure and correct header setting~
Stopping.
I tried to manually (using hdrscope) delete the two indented exposure lines (which leaves one) and evalglare seems to run fine.
Any suggestions are greatly appreciated.
Thank you,
Belal

++++++++++

Date: October 1, 2017 2:36:03 PM PDT
Hi Belal,
I am not familiar with hdrscope, but you might inform the author that it's not a good idea to remove the tabs when reporting the header, since they are very important to the interpretation of the image.
getinfo -a "VIEW= -vta -vh 180 -vv 180" < processed.hdr > final.hdr
Best,
-Greg

Date: October 1, 2017 10:57:25 AM PDT
Hi Greg,
The header does contain indentations. The header I posted to forum is copied from hdrscope. Attached is the header file (directly from radiance) and the Image.
Thank you very much for helping,
--
Best,
Belal

[Belal Abboushi]

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

[Clotilde Pierson]

Hi Belal,

You could use the ra_xyze command to insert the exposure into the pixels value right after creating the HDR image.

ra_xyze –r –o input.hdr > output.hdr

This way, the exposure line is removed from the header in Radiance and you can do manipulations on your HDR image with pcomb/pcompos.

At the end, you can insert back the exposure line in the header with a value of 1 using getinfo –a as Greg mentioned.

Best,

Clotilde


From: Belal Abboushi [mailto:***@gmail.com]
Sent: lundi 2 octobre 2017 08:21
To: Gregory J. Ward <***@gmail.com>
Cc: High Dynamic Range Imaging <***@radiance-online.org>
Subject: Re: [HDRI] Duplicated lines in HDRI header

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

[Jan Wienold]

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

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
https://www.radiance-online.org/mailman/listinfo/hdri

[Belal Abboushi]

Hi,
Thank you Clotilde and Jan. The ra_xyze command solved the problem. I am
actually using a fish eye lens (the -vh 49.0537 -vv 49.0537 was in the
original image created by hdrgen) but I am passing view info in the
evalglare line). I have few follow up questions to make sure I understand
what you mentioned regarding view type.

1. Assuming I have an angular projection, I converted that to hemispherical
projection using pinterp, and used that for Ev calculations and absolute
calibration, and then for evalglare. My question is: Is a
hemispherical projection a requirement for calculating vertical illuminance
in Radiance? If yes, should I convert back to angular after calculating Ev?

2. Is there a way to tell if projection is Angular or hemispherical by
looking at images? I am using a low-cost Opteka 0.2x fish eye.. there's no
mention by manufacturer on projection type.

Thank you for your help,
Belal

[Jan Wienold]

Hi Belal,

Post by Belal Abboushi
Hi,
Thank you Clotilde and Jan. The ra_xyze command solved the problem. I
am actually using a fish eye lens (the -vh 49.0537 -vv 49.0537 was in
the original image created by hdrgen) but I am passing view info in
the evalglare line). I have few follow up questions to make sure I
understand what you mentioned regarding view type.
1. Assuming I have an angular projection, I converted that to
hemispherical projection using pinterp, and used that for Ev
calculations and absolute calibration, and then for evalglare. My
question is: Is a hemispherical projection a requirement for
calculating vertical illuminance in Radiance? If yes, should I convert
back to angular after calculating Ev

I dont understand, why you need a vth. with every re-projection you add
an additional error to your measurement. in that case it is not
necessary. evalglare can use vta for all calculations, also for the
vertical illuminance. (command: evalglare -V image).

Post by Belal Abboushi
2. Is there a way to tell if projection is Angular or hemispherical by
looking at images? I am using a low-cost Opteka 0.2x fish eye..
there's no mention by manufacturer on projection type.

then you should measure it. make marks every 5 or 10 degree on a target
(e.g. a corner of a room), covering the total field of view. If you have
an angular lens, then the pixel distance between the marks is the same.
If not, then it is at least not an angular projection. Actually a
hemispherical lens is rather rare on the market. More common is
equid-solid-angle.

Jan

Post by Belal Abboushi
Thank you for your help,
Belal
_______________________________________________
HDRI mailing list
https://www.radiance-online.org/mailman/listinfo/hdri