Projection adjustment

Rania_Labib1 · October 28, 2021, 12:09am

Hi There,

I’m trying to apply projection adjustment to my Photos using the following method

pcomb -f fisheye_corr.cal -o file.hdr
> getinfo -a “VIEW= -vta -vh 180 -vv 180”
> corrected_file.hdr

However, I get the following error:

getinfo -a “VIEW= -vta -vh 180 -vv 180” \

305.hdr
#?RADIANCE
CAPDATE= 2021:10:27 19:02:20
GMT= 2021:10:28 00:02:20
test.hdr:
CAMERA= Canon Canon EOS 5D Mark IV version v.0
hdrgen created HDR image from ‘IMG_0007_4.JPG’ ‘IMG_0006_4.JPG’ ‘IMG_0005_4.JPG’ ‘IMG_0004_4.JPG’ ‘IMG_0003_4.JPG’ ‘A2.JPG’ ‘A1.JPG’
EXPOSURE=1.190666e-02
VIEW= -vtv -vh 123.608200 -vv 123.608200
CAPDATE= 2021:10:26 19:06:12
PRIMARIES= 0.6400 0.3300 0.3000 0.6000 0.1500 0.0600 0.3127 0.3290
getinfo:
getinfo: bad picture size

I’m using Canon 5D Mark IV and Sigma 8mm fisheye lens. My photos are taken with an aspect ratio of 1:1 so that they are square-shaped. (example below)

Greg_Ward · October 28, 2021, 2:08am

Don’t you want:

I can’t tell from what you wrote whether the “>” characters are continuation for the previous line, or if they are actual redirect symbols for the shell. That’s why I put everything in one line, above.

Rania_Labib1 · October 28, 2021, 5:33pm

Hi Greg,

Thanks for your help. It worked, it turned out I accidentally replaced the “I” character with “>”. I have another question; now the image header has two lines that start with VIEW (please see below). Will two lines with different view types confuse Evalglare? Do I have to force Evalglare to read one of the lines, or even force it to use a specific using the command line (Evalglare -vta -vh 180 -vv 180 file.dhr).

Another question I have is when I took the file that was corrected by the fisheye_corr.cal file to HDRScope to calibrate it and then analyze it for glare, the DGP value was .02 which is impossible to believe. Before I corrected the projection, the DGP value was .39 which makes more sense to me and that is because I experienced some visual discomfort in the physical scene. (Note, the image I added t this post is one of a series of images of different EV, it’s NOT the final combined HDR image).

Any ideas what is happening here?

Image header:

corrected_file.hdr:
	#?RADIANCE
	CAPDATE= 2021:10:28 11:46:01
	GMT= 2021:10:28 16:46:01
	test.hdr:
		CAMERA= Canon Canon EOS 5D Mark IV version v.0
		hdrgen created HDR image from 'IMG_0007_4.JPG' 'IMG_0006_4.JPG' 'IMG_0005_4.JPG' 'IMG_0004_4.JPG' 'IMG_0003_4.JPG' 'A2.JPG' 'A1.JPG'
		EXPOSURE=1.190666e-02
		VIEW= -vtv -vh 123.608200 -vv 123.608200
		CAPDATE= 2021:10:26 19:06:12
		PRIMARIES= 0.6400 0.3300 0.3000 0.6000 0.1500 0.0600 0.3127 0.3290
	pcomb -f fisheye_corr.cal -o test.hdr
	VIEW= -vtv -vp 0 0 0 -vd 0 1 0 -vu 0 0 1 -vh 123.608 -vv 123.608 -vo 0 -va 0 -vs 0 -vl 0
	FORMAT=32-bit_rle_rgbe
	“VIEW=
	-vta
	-vh
	180
	-vv
	180”

Greg_Ward · October 28, 2021, 7:28pm

The view from the getinfo command is not working, probably because the double-quote is some other (special) character. You need to retype your command, making sure to use regular double-quotes around the view argument to “getinfo -a”. Don’t rely too much on cut-and-paste, especially from e-mail or browsers – they do all sorts of creative things to punctuation!

Regarding multiple views, I’m not sure what evalglare does or if it accepts them. The appropriate behavior is to treat VIEW options together as if they were concatenated on one line together, later options overriding earlier ones. I don’t know if evalglare does that or not – I think it may be more strict about it.

Rania_Labib1 · October 28, 2021, 7:59pm

Aha, it was the copy and paste problem. Thank you so much!
Although, glare anaylsis after correction is still odd. I’m not sure if the fisheye_corr.cal is the right file to correct the projection of my Sigma 8mm f/3.5 lens, which I think is equidistant.

Clotilde_Pierson · October 28, 2021, 8:12pm

Hi Rania,

From what I remember, the Sigma 8mm f/3.5 has an equisolid-angle projection type. You might want to look at the paper (open-access) I shared with you earlier in another post, as the method to apply such filter is described there.

Additionnally, for the large difference you get in evalglare before and after applying the projection filter, this might be related to the exposure information in the header. I think the pcomb command nullify this exposure value by adding a tab in front of it in the header. So evalglare cannot find this exposure value and interpret it as 1. To avoid such issue, you would need to include your exposure value in your pixels by using the ra_xyze -r -o command for instance. This is also explained in detail in the paper I mentioned before (and I attached the link again here in case: https://www.tandfonline.com/doi/full/10.1080/15502724.2019.1684319 )

Clotilde

Greg_Ward · October 28, 2021, 8:42pm

The -o option to pcomb should undo the exposure, so that the output is absolutely calibrated (i.e., “EXPOSURE=1”). I think you need to look elsewhere for the problem.

-Greg

Jan_Wienold · October 28, 2021, 9:35pm

Hi Greg,
The core problem is that pcomb -o corrects the exposure. Without -o it does not. In both cases the header looks exactly the same for the exposure entry. Pcompos also makes the exposure invalid. In any case the entry remains in the header, always with the invalid marker. Since people are using all these commands and multiple times plus manual header manipulation it is impossible for evalglare to find out what is the correct way to treat the “invalid” exposure entry. For that reason I included in the 2.0 version a safety check stopping evalglare automatically if an invalid exposure entry is detected. Many, many people had that problem and unfortunately also papers were published having this header issue with the exposure.
Unfortunately people are still using older versions of evalglare, also in this case here.
The best option would be to remove this “invalid making of the exposure” by tools like pcomb and pcompos, that would really avoid many headaches (and avoid papers using screwed images) …
Users who use these tools differently where the exposure really gets indeed invalid typically know what they are doing and could deal a valid exposure entry… at least that is my opinion.
I know I tried to convince you already before to change this invalid marking, but maybe this time is successful
Regarding view string reading - this works in evalglare in the same manner than in other radiance tools - so the last one is taken. It just needs to be correctly written in the header, what is probably not the case here.

Cheers
Jan

Jan_Wienold · October 28, 2021, 9:55pm

Hi Rania,
As I can see from the header, following topics arise here:

You use an outdated evalglare version, that is at least 6 years old - otherwise evalglare would stop with this header… So make sure you have at least the 2.08 version installed. Maybe also HDRscope is shipping an outdated version. You can check the version by typing evalglare -v .
you need to get rid of the exposure entry as Clotilde mentioned and described in the tutorial, using the ra_xyze -r -o command directly after hdrgen.
you need to measure the real angle of the fisheye - we had measured for the same type of lens 183.5 degree- which should be then used in the -vv and -vh option. And I also confirm that this lens has a equidsolidangle projection, that needs to be corrected.
make sure the view string is correctly set , which is not the case here, as Greg mentioned.
As quality check I would not use a DGP value as measure (it is not always that obvious as in this case), but compare the calculated Ev with the measured one of a luxmeter and accept it only when the difference is less than X %. X is maybe 10-20%, the smaller the better…

Cheers
Jan

Greg_Ward · October 29, 2021, 5:48am

The latest version of pcompos does pass on the exposure if given a single input or multiple inputs with the same exposure multiplier. So, that at least is fixed in the HEAD version.

Unfortunately, it is impossible to pass on the correct exposure with pcomb, since this is a general-purpose program for manipulating pixel values, and there is no way for the program to figure out when the input exposure should be passed to the output and when it should not.

None of the other Radiance tools attempt to interpret any header lines that are indented, as this is the standard way of saying such lines are related to the indicated inputs, not to the output. It’s always been a dangerous toolkit to work with if you don’t know exactly what each tool is doing.

The best way to make these things more foolproof is to write scripts that perform common tasks, and this is what I would recommend for common image preparation steps for evalglare. Perhaps it is time we write a Perl script to handle these operations.

The VIEW= lines need to be interpreted in sequence, so the header:

VIEW= -vtv -vh 90 -vv 70
VIEW= -vta -vv 180

Is equivalent to:

VIEW= -vta -vh 90 -vv 180

In other words, it’s not the same as just taking the last VIEW= line. Is this what evalglare is doing?

Cheers,
-Greg

Rania_Labib1 · October 29, 2021, 6:37pm

Hi Clotilde,

The ra_xyze mentioned in the paper solved my problem! thank you!

As for the Sigma 8mm f/3.5 according to this thesis- page 200, I thought my lens has Equidistant projection. But I see that many people on this forum confirmed that it has an Equisolid projection.

Rania_Labib1 · October 29, 2021, 6:48pm

Hi Jan,

Your list helped me a lot. I was using evalglare through HDRscope (probably an outdated version) and that’s why it didn’t stop with the faulty header. Once I used the Evalglare installed on my linux machine, which is version 2.10, Evlaglare couldn’t continue with that header. The ra_xyze that Coltide menioned earlier solved the problem, additionally DGP values look very reasonable based on observations in the physical scene. it’s worth mentioning that I didn’t correct the view in the header, but I forced evalglare to override the view type/angles using the command line. I will do a quality check using a luminance or illuminance meter later to check the validity of the images corrected by the fisheye_corr.cal file.