Just want to get some potential ideas on what is happening here.
So I have taken some HDR images using a calibrated camera by following Pierson’s tutorial . All images are taken at the a fixed location facing window so the sky/sun is in the field of view, and these all captured by an automatic script. I set up an external illuminance meter so that I can compare against the calculated Ev from the HDR images. However, this is what I have gotten so far. About half of the images match the metered lux within an acceptable range, while the other half seemed to be off by a ratio (the illuminance calculation from the hdr tends to over predict ).
I have tried to explore what factors can distinguish these two clusters, including time of day, max luminace, if or not sun is in the FOV, etc but nothing really explains what happens here. I am a bit lost here since I was wondering if what should I be looking for to identify the culprits? Should I get rid of the erroneous images or is there any way to salvage (e.g. should I apply correction factor so that the Ev can match? should I just input the Ev value and carry on evalglare analysis )?
Below is the comparisons between the metered Ev values (horizon axis) and the calculated Ev values (vertical axis)
Hello Greg thanks for your response. I actually looked at those images and it does not look like there is a particular pattern-----only that the bad images appeared to be a bit brighter/overexposed albeit all images were captured using the same script. Not sure why though. I thought it has something to do with pixel overflowing but whether or not sun is in the field of view is not a distinguishing factor here.
Ev sensor and the camera are 1" apart, so external obstruction can certainly be a possible cause but should it be off by a different ratio? I would think it would be a gaussian noise or something non-linear, no?
Can you post two HDR pictures, somewhere? Close in time but one from one trendline and the other from the other trendline? Also, let us know what the measured illuminances were corresponding to each.
I would also recommend you post two matching single exposures (same shutter speed, say the shortest exposure with some valid (not black) pixels) that are from the sequences used to make these two HDR pictures. Post the originals so we can look at all the metadata, just in case something changed.
Sorry for delayed reply as the server that contains my data was down. Thanks for you reply. I uploaded two sets of sample HDR images and can be accessed here. The last four-digit number represents the external Ev measurement (averaged over a few minutes to smooth out).
I think it has something to do with color. As you can see, the two HDRs in each of the set have very distinct RGB distributions. Not sure what caused it and maybe it was the RPi camera that randomly distorted colour profile? Unfortunately, I did not save the LDR images since they were deleted immediately upon compiling the HDR to save space.
May I please know what you think? Do you have any hypothesis of what caused it? Is there any way to fix this (e.g correcting the color distribution)?
Are you having hdrgen rederive the camera response each time, or are you using a “-r static.rsp” input file with the same data for every run? If you are using hdrgen without a -r option, this could well be the cause of your inconsistent results.
Unfortunately, it’s really difficult to back any of this out if you didn’t save your original capture files.
Oh, good that you keep the response file consistent. However, you should leave off the “-f” and “-g” options, as these may also cause inconsistent behavior and should not be used in your situation. While the “-f” option for flare removal may be appropriate in some sense, it doesn’t get applied every time and could be the cause of your issue. The “-g” option is probably harmless, but also entirely unnecessary when the camera position is fixed. See the hdrgen man page I posted here, taking care to note the default mode of each option, which is a “switch” in that it flips the feature on or off.
While I’m on the subject, there seems to be an unnecessary pcomb command in your operations that removes the outside of the circle. You then run the fisheye_corr.cal operation, which does this for you.
Besides what Greg mentioned about the “-f” and “-g” options, I was wondering whether you had fixed your camera parameters while taking the jpg pictures? E.g., did you make sure the white balance stayed the same between different series of pictures?
