A question regarding generated tabulated BSDF

In topic “Is genBSDF applicable to generate BSDF for micro-prism film?”, I asked a question about how to generate BSDF compatible with radiance. Now I have an idea is following the workflow working from goniophotometer data. I want to generate a data set whose format is the same as goniophotometer data and then use pabopto2bsdf, bsdf2klems tools to generate tabulated BSDF. I downloaded a sample of goniophotometer data whose head is shown below:

* *
#pgII DSF data read from database by pab Ltd “mountain”
#see http://bsdf.pab.eu for pgII gonio-photometer and BSDF details
#mountain-version “pab mountain V3.2.2”
#database-host pgdb
#database-name pabpg
#measured_at “2018-12-04 12:41:38”
#data_read_from_db “2019-01-18 18:57:51”
#database_id 11216
#datapoints_in_db 247100
#database_reference_id 11079
#integrated_value 0.4 6.3
#sample_label “LCPED001”
#sample_name “solartran”
#lamp “halogen”
#beamshape “det,f=200,a=1”
#filterlamp “IRcutoff”
#filterdet “none”
#comment “Laser cut panels for Chantal Basurto.|Visible light, halogen, hot-mirror, focus on detector.|Half Klems, front and back.”
#mcomment “$Id: do_meas_batch.c,v 1.35 2017/08/30 14:27:44 apian Exp apian $daq serial[1]=“008” (channel minimum)|phirot2 place=1|optfile=BIMSOL_AutoRAutoT_High|userdata=$Header: /usr/local/pab_pg/etc/RCS/userdata.pgII-hslu,v 1.13 2017/03/29 13:03:56 pgadmin Exp pgadmin $|cxtcounter=yes|bl_armB=0|daq_ss=100|speedbend=(0,0)|pawait=150|minspacing=-1|lamp_cycles=76 poweron=63737 [h] last_change=5440 [min]”
#dbfilter “”
#column daq
#dump-host pgII-hslu
#incident_angle 110 67.5
#intheta 110
#inphi 67.5
#rear_integral 0.398
#incident_and_rear_integral 110 67.5 0.398
#mountain_minimum_angle 0.0014 [deg]
#datapoints_in_file 240660
#format: theta phi DSF
* *
As my understanding, the theta, phi, and data points in bold are used by pabopto2bsdf, and they should be revised case by case, but I am not quite sure whether other information is unused and it will not affect the resulted BSDF.

It should be possible to apply pabopto2bsdf with bsdf2ttree as you surmised. The header variables that are used are indicated in the pabopto2bsdf man page in ray/doc/man/man1/pabopto2bsdf.1 in the distribution. (I can send you a PDF, but I can only attach single-page JPEG’s in discourse.) It doesn’t look at the #datapoints_in_file or #incident_and_rear_integral settings, for instance, but it does care about #format:

Also, there are subtleties about what points you include in the data to succeed. In general, pabopto2bsdf will ingest anything, but it can fail if there aren’t enough measurements in the peak regions.

Cheers,
-Greg

Hi, Greg, thanks for your response, could you please send me the PDF to my email: zhaoyongqing1987@hnu.edu?

Hi,

I am pretty sure that you can skip most of the header lines. I would start with

#incident_angle <theta> <phi>
#intheta <theta>
#inphi <phi>
#format: theta phi DSF

followed by the data points. As a first test, you can set all of these to a constant value multiplied with the corresponding theta in the first column.

What is really important is to get the meaning of the angles theta and phi right, and to note that the last header line indicates that the third column shall be interpreted as DSF, not BSDF.

Best, Lars.

@Lars_Grobe @Greg_Ward
Thanks for your response!
I have generated goniophotometer data, but when I use pabopto2bsdf to convert it to sir file, it reported warnings:

pabopto2bsdf: Duplicate incident measurement ignored at (180.0,315.0)
pabopto2bsdf: Duplicate incident measurement ignored at (180.0,202.5)
pabopto2bsdf: Duplicate incident measurement ignored at (180.0,90.0)

Finally, subprocesses were killed, maybe this is because there aren’t enough measurements in the peak regions as Greg pointed out.However I want to kown if these warnings will caused the failure and what will cause these warnings.

The warnings mean that two or more of your input files to pabopto2bsdf had the same #incident_angle specifications. I don’t know about your subprocesses being killed, but if you share your data, I can try running it on my end.

-Greg

Thank you, Greg! Below is my data link:
https://drive.google.com/file/d/1_ePlK8lcFwdldL6tknmktVgrPF_NvIxr/view?usp=sharing

Hi, Greg, I checked my data and found no duplicate incident data. According to the warnings, the repeat theta is 180 degrees, but It was strange that no data corresponding to incident theta of 180 degrees was measured in my dataset.
I shared my data at Google Drive: Sign-in

In addition, I failed to generate sir file fail using pabopto2bsdf. I didn’t know if it was because my data wasn’t correct.

Your google drive link doesn’t let me access the files. I sent a request, but haven’t heard back (unless I missed it in my burgeoning in-box).

The points are probably marked as duplicates because at theta=180°, you are at the pole and any phi will be in the same direction as any other phi. Same issue at theta=0°

-Greg

Hi, Greg, I have corected the link Google Drive: Sign-in

Either the RAR file is damaged or I don’t have the right software to unpack it.

Hi, Greg
I package the data as zip file, which shall be unpacked using explorer.

Thanks for your help!

OK, this download worked. I didn’t get the “duplicate incident measurement” error, but I can tell from looking at the measurements that the normalization is not as it should be. Are these BSDF measurements, or DSF measurements? The difference is that the latter is BSDF*cos(in_theta), which has closer correspondence to most goniophotometer measurements, but if your system has already converted to BSDF values, then the final line in your header should be:

#format: theta phi BSDF

rather than what you have. Even changing this specification in the header, I get integrated transmission values that are hundreds of times what they should be, indicating that something is amiss with the measurement process or data interpretation.

I don’t know whether this is calling pabopto2bsdf to stall or its interpolation subprocesses to fail, but I finally gave up waiting for it to finish after an hour or two on 4 processors, figuring something was wrong. It was at that point that I looked at a single incident file (btdf80_90.txt) that had an integrated transmission of 732, when the maximum should be 1.0. Changing the “DSF” to “BSDF”, it only went down to 699, so clearly something more is wrong.

Hope this helps!
-Greg

Thank you so much, Greg! Could you tell me how to calculate integrated transmission so that I can check my data?

I use the optional build pabopto2rad, which you can compile in ray/src/cv using:

cd ray/src/cv
rm bsdf*.o
rmake “OPT += -DDEBUG” pabopto2rad
mv pabopto2rad /my/bin/directory

The usage is simple:

pabopto2rad input.dat > output.rad

The -DDEBUG compilation has it print out extra information, such as the integrated total, to stderr.

Cheers,
-Greg

P.S. I am leaving for vacation starting tomorrow, and won’t have much access to the internet.

Here is a simple python script that might be helpful. You can use it to compute integration from pgII style data with Delaunay triangulation.
To get normal incidence hemispherical transmission, you can run:

python get_pgii_tdd.py -f your_directory -tin 0 -pin 0 -ha 90

If the data is in BSDF instead of DSF, use the -cos flag. You can also change -ha flag to ask for a specific cone angle instead of the entire hemisphere. The script read the header of each file in the directory to find the one with the specified incident angles.

OK! Thank you, Greg! Have a good holiday!

Hi, taoning

Thsnks for your reply!

I used to your python script to get normal incidence hemispherical transmission, but it always reported “Permission denied”.

It looks like command prompt doesn’t have permission to access those directory. Have you tried open the cmd as an administrator?

I opened cmd as administator, but the error still existed. I also found that if I input file path rather than directrory path, it ran successfully.