| 11 |
|
][ |
| 12 |
|
.B \-f[afdc] |
| 13 |
|
][ |
| 14 |
+ |
.B "\-n nproc" |
| 15 |
+ |
][ |
| 16 |
|
.B "\-f file" |
| 17 |
|
][ |
| 18 |
|
.B "\-e expr" |
| 55 |
|
.I \-s |
| 56 |
|
options follow the last input matrix, output results will be transformed |
| 57 |
|
and/or scaled accordingly. |
| 58 |
< |
These operations are discussed in greater detail further on. |
| 58 |
> |
These operations are discussed in greater detail below. |
| 59 |
|
A single concatenation matrix may be applied after element operations |
| 60 |
|
using the |
| 61 |
|
.I \-m |
| 73 |
|
.fi |
| 74 |
|
.sp |
| 75 |
|
The number of components indicates that each matrix element is actually |
| 76 |
< |
composed of multiple elements, most commonly an RGB triple. |
| 76 |
> |
composed of multiple channels, most commonly an RGB triple. |
| 77 |
|
This is essentially dividing the matrix into planes, where each component |
| 78 |
|
participates in a separate calculation. |
| 79 |
|
If an appropriate header is not present, it may be added with a call to |
| 190 |
|
or |
| 191 |
|
.I \-f |
| 192 |
|
options are used to define a "co" variable or "co(p)" function, |
| 193 |
< |
this will be evaluated at each output |
| 194 |
< |
component for the current element. |
| 193 |
> |
which will be evaluated for each output |
| 194 |
> |
component from the current element. |
| 195 |
|
The "co" variable defines identical operations for all components, |
| 196 |
|
whereas "co(p)" may specify different operations for each component. |
| 197 |
|
The element position is defined |
| 252 |
|
.I \-w |
| 253 |
|
option turns off warnings about divide-by-zero and other non-fatal |
| 254 |
|
calculation errors. |
| 255 |
+ |
.PP |
| 256 |
+ |
The |
| 257 |
+ |
.I \-n |
| 258 |
+ |
option specifies how many execution processes to employ, |
| 259 |
+ |
which may improve performance on multi-core architectures, |
| 260 |
+ |
especially for matrix multiplication |
| 261 |
+ |
and complex operations on long input rows. |
| 262 |
|
.SH EXAMPLES |
| 263 |
|
To convert two hyperspectral inputs to RGB color space, |
| 264 |
|
average them together, and write them out as a RADIANCE picture: |
| 290 |
|
.I pcomb, |
| 291 |
|
whose capabilities somewhat overlap. |
| 292 |
|
The former loads each matrix into memory before operations, |
| 293 |
< |
and element components take 8 bytes apiece, adding up quickly. |
| 293 |
> |
and element components are stored as double-precision. |
| 294 |
|
Very large matrices therefore present a problem with that tool. |
| 295 |
|
Furthermore, |
| 296 |
|
.I rmtxop |
| 323 |
|
.I rcomb |
| 324 |
|
should be preferred over |
| 325 |
|
.I rmtxop |
| 326 |
< |
for any operations in can handle, which is everything except |
| 326 |
> |
for any operations it can handle, which is everything except |
| 327 |
|
multiple matrix concatenations and transpose |
| 328 |
< |
operations, which are handled more efficiently by |
| 329 |
< |
.I rcollate(1) |
| 330 |
< |
in any case. |
| 328 |
> |
operations. |
| 329 |
> |
The latter may be handled more efficiently by |
| 330 |
> |
.I rcollate(1). |
| 331 |
|
That said, there is no significant difference for |
| 332 |
< |
simple operations on smallish matrices, and note that only |
| 332 |
> |
simple operations on small matrices, and only |
| 333 |
|
.I rmtxop |
| 334 |
|
and |
| 335 |
|
.I dctimestep(1) |
| 336 |
< |
currently accept XML files as inputs. |
| 337 |
< |
Also, the resizing function of |
| 336 |
> |
accept XML files as inputs. |
| 337 |
> |
Also note that the resizing function of |
| 338 |
|
.I pcomb |
| 339 |
|
is not supported in |
| 340 |
|
.I rcomb, |
