Thanks, Devon. Definitely helps me to know some context.... Wrapping rcollate isn't a bad approach, since I wrote this program to be very efficient. It doesn't attempt to decode floating-point numbers (atof() is a very expensive call) and file i/o is streamlined as much as possible.
However, if there are specific changes you can suggest to specific Radiance tools that would make your life easier, I will look into it. I know some of the tools differ with regards to tabs and spaces between the final record and the newline, for example. This has caused me trouble when tried to use rcalc input formats, so I wouldn't working on that issue. As far as spaces versus tabs between RGB values, I can probably fix this as well for some tools, but generic programs like rcalc are not going to differentiate between fields in a record. Cheers, -Greg > From: Devon Sparks <devon.spa...@arup.com> > Subject: Re: [Radiance-dev] Radiance ASCII format specification > Date: April 8, 2014 10:56:10 AM PDT > > 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 > > From: Devon Sparks <devon.spa...@arup.com> > Date: Monday, April 7, 2014 5:26 PM > To: "radiance-dev@radiance-online.org" <radiance-dev@radiance-online.org> > 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
_______________________________________________ Radiance-dev mailing list Radiance-dev@radiance-online.org http://www.radiance-online.org/mailman/listinfo/radiance-dev
