Dear all,
I am running self-compiled Radiance on Ubuntu. I’ve just noticed that in HEAD-20221121 (today), but also with HEAD-20220723, one of my scripts now fails on dctimestep with
a ‘fatal - unspecified matrix size’ error. The problem seems to lie with a missing NROWS= line in the header of the dc matrix (I am reading the pts from stdin).
However, this has always been the case. I dug out an older version (HEAD-20210912), in which dctimestep works, even without NROWS= in the DC header.
Have there been any recent code changes affecting how matrices are parsed? Is dctimestep more picky now? I believe that dctimestep used to impose a hard limit of 32k rows when it could not find an NROWS= header line, but could otherwise deal with the missing header line.
Many thanks
Axel
Hi Axel,
I did make some adjustments to dctimestep behavior to make it more consistent with the other tools that read and write matrices and vectors. It retains the ability to size an incoming vector length, but only in the case of an ASCII (RGB) matrix with NO header, but you must also specify the “-n 1” option on the command line.
Let me know if that doesn’t work for you.
Cheers,
-Greg
Hi Greg,
thank you so much for your swift reply.
I stripped the entire header from the DC matrix, and ran dctimestep with the -n 1 option, but to no avail. The updated man page for dctimestop advises that -n 1 is to be used if the sky matric lacks NCOLS. In my case, it is the DC matrix that appears to be the culprit, not the sky matrix.
So it looks as if there is no easy way out. Unless, of course, I use getinfo -a to inject the missing NROWS line into the CD matrix header, which isn’t too difficult, but I haven’t tried it. Do you reckon this is the way forward? I believe this approach would be backward-compatible, which is very important to us.
Thank you
Axel
Hi Axel,
Yes, you can either use:
your_generator | getinfo -a NROWS=%d | dctimestep …
with %d replaced by your row count, or:
your_generator | rcollate -ir %d | dctimestep …
which should have the same effect.
Cheers,
-Greg
I’m sorry I misunderstood your first question. You are correct that dctimestep can’t manage if the number of rows isn’t given in the DC matrix.
Hi Greg,
thanks for your reply. I probably should have mentioned that I’m using dctimestep in the ‘first invocation’ with the optional sky matrix, according to the man page:
“Dctimestep has two invocation forms. In the first form, dctimestep is given a daylight coefficient specification and an optional sky vector or matrix, which may be read from the standard input if unspecified.”
I tried to get dctimestep to read the DC matrix from stdin using a hyphen, but triggered a usage error:
nrows=$( cat PTS |wc -l )
cat DC.mtx |getinfo -a NROWS=$nrows |dctimestep - SKY.mtx >test.mtx
Usage: dctimestep [-n nsteps][-o ospec][-x xr][-y yr][-i{f|d|h}][-o{f|d|c}] DCspec [skyf]
or: dctimestep [-n nsteps][-o ospec][-x xr][-y yr][-i{f|d|h}][-o{f|d|c}] Vspec Tbsdf Dmat.dat [skyf]
Equally, dctimestep will only take the sky matrix, but not the dc matrix from stdin, which of course is consistent with the man page:
cat DC.mtx |getinfo -a NROWS=$nrows |dctimestep SKY.mtx >test.mtx
fatal - unexpected column count in header
This tells me that I need to fix the DC.mtx before writing it to file (I’m doing this in a separate step), but not on-the-fly when calling dctimestep. This is not a big deal for us, as we can modify all our scripts that call dctimestep. However, I do fear that other scripts will break, too. Some of which might be less well supported than our own software.
I think it would be very helpful if this new behaviour of dctimestep could be mentioned in the man page (maybe even with an example). I bet it’ll throw quite a few people off their tracks.
Cheers
Axel
Basically, the ‘-’ input from stdin is not supported by dctimestep, and that is where you are running into problems. As stated in the man page, you can leave off the sky matrix and read it from the standard input, without a header if the -n $cols option is specified on the command line, and with an expected header, otherwise.
If you can suggest rewording of the man page to make this clearer, I am happy to amend it.
There is a way to get dctimestep to accept the DC matrix missing the number of rows. You could use:
dctimestep “!getinfo -a NROWS=$nrows < DC.mtx” SKY.mtx > test.mtx
Since any of the matrices may be produced by a command, just use getinfo as your command that also adds the number of rows. (You may have to escape the ‘!’ character with a backslash if you are using the C-shell.)
Cheers,
-Greg
Hello Greg
I agree with Axel as the new behavior of dctimestep broke my scripts for the 3-phase operation. Fortunately I found this thread explaining the change.
This change may break scripts using dctimestep with matrices not having the NROWS in the matrix header.
A note in the manpage to the effect as of:
CRITICAL CHANGES:
- Radiance 5.4, dctimestep now requires NROWS specification in the DCspec matrix. The NROWS can be added to the matrix header using …
- …
Regards
Terrance
Hmm. I didn’t realize people were relying on dctimestep’s original ability to handle matrices that were missing NROWS in the header. In general, these are not valid matrix files, and rmtxop for example will not accept them.
My problem in making the original change, which enabled an alternate method for specifying the matrix size in a resolution string, is that I couldn’t figure out the logic to do this and still support matrices with no resolution string and only NCOLS specified in their headers.
I spent some more time on the problem this morning, and I think I have worked out the proper logic. So, rather than documenting this shortcoming in the man page, I fixed the problem and checked in a new version of dctimestep that supports matrices with incomplete size specifications as before.
I hope this is satisfactory. You’ll need to either download the latest src/util folder from CVS and compile it yourself, or wait for an update to the distribution on github. Specifically, I updated the cmatrix.c module.
Cheers,
-Greg
P.S. Updated installers hot off the compiler here.