I am using aBSDF type materials to model roller shades using 5pm for annual glare risk assessment based on DGP.
I ran the same set of input files on Windows and Linux twice, but the maximum luminance values from Radiance-Linux ( Radiance 5.4a (2023-01-29)) are much higher than those from Radiance-Windows ( Radiance 5.4a (2023-01-13)), particularly when the sun is at the edge of the façade.
For example, at 10 am on March 6th, in Chicago:
Maxmum luminance in cds hdr image
Maxmum luminance (blurred 5pm)
DGP (blurred 5pm)
Although Linux Radiance detects a glare source to be above 1.98E+08, it looks like a single pixel and I could not manually locate the glare source using “hdrscope”. When I tried to select the glare source from both cds hdr images, the glare sources were around 3.78E+06 in both images.
Could be possible that the PE algorithm on Radiance-Linux and Radiance-Windows are slightly different?
Is it sensible to replace the luminance value of a single-pixel glare source for the scenarios when the sun is at the edge of the façade, or add a narrow black mask along the edge of the facade on the original cds hdr image? If so, I wonder how to replace luminance values in parts of a hdr image.
This is less likely a difference between Linux and Windows versions of Radiance and more likely random sampling variations that might be corrected by rendering higher-resolution images so that you don’t have just one or two samples for the sun.
If this is happening right at the edge of your window, small numerical differences in the calculation might also be at play. I hesitate to guess where these might be happening, but you could check the solar times/angles or make sure you use the -pj 0 option to vwrays and the same data types in Windows and Linux when passing ray vectors from vwrays to rfluxmtx or rcontrib.
in more general terms, you cannot expect that an image feature is accurately represented by one pixel (analogies to the Nyquist theorem may be drawn). To have a reliable result, you should aim for at least three samples (e.g. pixels) per dimension (x,y) on the smallest feature you want to account for (e.g. that would still make a difference in your study). 800px almost fullfills that for a 180° fisheye when the full sun disk is visible (e.g. 800px/180deg. = 4.4px/deg. gives 2.2px on a 0.5deg. sun disk), but not when partially occluded.