Hi Greg, I've sketched a collection of analysis tools that operate on Radiance output. Some of these tools should operate on Radiance output data whatever, regardless of source (e.g. rtrace, dctimestep) and provide sanity checks where possible. For argument's sake, assume I'm writing a C-based tool for calculating dot products with RGB triplets in a file with a variable number of records. A few approaches:
1.) Accept input data as-is. Collect/emit values with strtok_r, exiting on malformed/misaligned input. Because there's no way (?) to consistently distinguish records from fields without parsing the header (which may be missing), there's no safety net in the event the user accidentally provides wrongly typed data (say, an illuminance dat file vs irradiance values). 2.) Provide an "rcheck" command/function to perform record/field standardization up front. I currently approximate this by wrapping rcollate. This works well, as it isolates record parsing from the analysis logic. Data processing on RGB triplets (one per record) now can be treated consistently: while not EOF: rec = next_records(1) assert length(rec)==3 process_rec(rec) Unfortunately, this adds an additional scan of the input stream. 3.) Unify the field/record specification within Radiance itself in order to simplify the logic of analysis tools. Some of these sketched programs operate on a single record, while others collect n (12,24,60) records before processing. By munching tabs and spaces without discretion, it seems difficult to validate input format/record types during processing. For now I've opted for option (2), but figured I'd ask about alternative approaches. Many thanks — Devon Devon Sparks Consultant | Lighting Group Arup 560 Mission Street Seventh Floor San Francisco CA 94105 United States t +1 415 957 9445 d +1 415 946 0240 f +1 415 957 9096 From: Devon Sparks <devon.spa...@arup.com<mailto:devon.spa...@arup.com>> Date: Monday, April 7, 2014 5:26 PM To: "radiance-dev@radiance-online.org<mailto:radiance-dev@radiance-online.org>" <radiance-dev@radiance-online.org<mailto:radiance-dev@radiance-online.org>> Subject: Radiance ASCII format specification Does Radiance specify[1] a standard ASCII format for RGB output? I've observed two "defaults": * rtrace, rcalc - RGB fields separated by tabs. Sensor records separated by newlines. $ vwrays -vf myview.vf | head -n 1 | rtrace -ab 0 -h model.oct $ 0.000000e+00<TAB>0.000000e+00<TAB>0.000000e+00<TAB><CR> * dctimestep - RGB fields separated by spaces. Time-series records separated by tabs. Sensor records separated by newlines. $ gendaymtx -m 4 city.wea | dctimestep -n 8760 model.dc | head -n 1 $ 0.000000e+00<SP>0.000000e+00<SP>0.000000e+00<TAB>0.000000e+00<SP>0.000000e+00<SP>0.000000e+00<TAB>... Is there any reason to think that these two format specifications should be unified in the standard distribution (e.g. fields separated by spaces, time-based records separated by tabs, spatial records separated by newlines)? How many tools would be broken in the process? Thanks in advance — Devon [1] http://radsite.lbl.gov/radiance/refer/filefmts.pdf Devon Sparks Consultant | Lighting Group Arup 560 Mission Street Seventh Floor San Francisco CA 94105 United States t +1 415 957 9445 d +1 415 946 0240 f +1 415 957 9096 ____________________________________________________________ Electronic mail messages entering and leaving Arup business systems are scanned for acceptability of content and viruses
_______________________________________________ Radiance-dev mailing list Radiance-dev@radiance-online.org http://www.radiance-online.org/mailman/listinfo/radiance-dev
