Hi Axel, Sorry -- I missed the attachment in your previous method. I see that the spacing in the sync file is as it should be, so it must be the lock manager. You could try adding a 2-5 second wait (sleep 5) after each spawning of a new rpiece process. This gives the system time to do its thing before the next one opens the file.
I checked in the new version with warning. Best, -Greg > From: Axel Jacobs <[email protected]> > Date: January 21, 2012 10:12:19 AM PST > > Hi Greg, > > On 01/21/2012 05:55 PM, Gregory J. Ward wrote: > >> Yes, the resolution can go either up or down from what rpict would normally >> do. >> It should still stay within the original -x and -y bounds in any case. >> >> Regarding your duplicated and extraneous tiles, I can only suppose > > that your lock manager isn't behaving well. I looked over the code again, >> and I can't see any other way you would get duplicate pieces unless the >> lock manager wasn't providing exclusive access to the sync file as it should. >> This could also cause occasional problems reading the dimension limits > > (generating a piece that's out of range), though that's even harder > > for me to fathom. > > Hmm, seems to be one of those obscure LINUX-only bugs, that are so hard to > track down. > >> Are you running any of your rpiece commands with the -R option > > rather than -F? Using multiple rpiece commands with -R is the only > > time you should end up with duplicate pieces, which is why the man page > > advises against it. It also needs to be started when no other rpiece > > jobs are running. > > It's a straight-forward -F, as in the script that I sent you. I tend to not > use -R at all. > >> I'll check your changes in later this weekend. > > Two sync files attached. > > Thanks > > Axel ============ > From: Axel Jacobs <[email protected]> > Date: January 21, 2012 5:48:59 AM PST > To: "Gregory J. Ward" <[email protected]> > Subject: Re: [Radiance-dev] warning request: rpiece image resolution > > Hi Greg, > >> See if the attached does what you want, then: > > The new version of rpiece.c works well. I included the requested, > aspectratio-adjusted image dimensions as well (which would be nice to have in > the official version): > > if (!nowarn && (hr != hres*hmult) | (vr != vres*vmult)) > fprintf(stderr, "%s: warning - resolution changed from %dx%d to > %dx%d\n", > progname, hr, vr, hres*hmult, vres*vmult); > > and did a few test runs with a scene taken from one of the recipes in the > Cookbook. I am attaching this test scene with a BASH script that loops over a > number of request dims and compares the resulting image dimensions from an > rpict against rpiece. > > I was surprised to find that the rpiece dims can actually be larger than the > rpict dims, as shown below. This isn't a problem--I just didn't expect this > to happen: > > resolution: 300 > rpict: images/hdr/rpict.hdr: -Y 215 +X 300 > rpiece: warning - resolution changed from 300x215 to 300x216 > rpiece: warning - resolution changed from 300x215 to 300x216 > rpiece: warning - resolution changed from 300x215 to 300x216 > rpiece: warning - resolution changed from 300x215 to 300x216 > rpiece: images/hdr/300.hdr: -Y 216 +X 300 > ... > > man rpiece only mentions that the dims can be smaller: > "The overall picture dimensions will be xres by yres > (or smaller, depending on the -pa option and other view options)" > > I also came across a rather obscure behaviour that I have been observing for > quite some time, although I have not been able to a) reliably reproduce it, > and b) find out why this happens. When I run the script repeatedly, every now > and then, it will produce an rpiece warning about a piece being out of range. > > resolution: 302 > rpict: images/rpict.hdr: -Y 217 +X 302 > rpiece: warning - resolution changed from 302x217 to 300x216 > rpiece: warning - resolution changed from 302x217 to 300x216 > rpiece: warning - resolution changed from 302x217 to 300x216 > rpiece: requested piece (3,1) out of range > rpiece: warning - resolution changed from 302x217 to 300x216 > rpict: signal - Broken pipe > rpict: 9600 rays, 0.00% after 0.000u 0.000s 0.000r hours on dove.localdomain > rpiece: images/302.hdr: -Y 216 +X 300 > > With XDIV and YDIV both being set to 3, the (3,1) piece would indeed be out > of range. This warning crops up with about every fifth to tenth run of > rpiece. The image still finishes all right in such a case. I've observed this > on three different LINUX machines. > > The syncfiles from the last run are kept under temp/. I noticed that > occasionally, a particular piece is requested twice, as seen in this sync > file where this is the case wit the (2,1) piece: > > 3 3 > 0 0 > > 2 2 > 1 2 > 1 1 > 2 0 > 1 0 > 0 2 > 2 1 > 2 1 > 0 1 > 0 0 > > There appears to be no correlation between this happening and the > piece-out-of-range warning--either can occur without the other, I think. > > Thank you so much for the new warning. It's kind of an obvious little detail, > but the first time I ran into this resolution problem, it took me two hours > to work out what's going on. The second time, it still took half an hour for > me to fix it, because I had forgotten what the problem was the first time > 'round. This is much better now, although admittedly, there can be quite a > bit of noise when you run lots of parallel processes (the -w switch works > correctly and disables the new res warning). > > Cheers > > Axel > > > > [The attachment rpiece_warning_testscene.tar.gz has been manually removed] > _______________________________________________ Radiance-dev mailing list [email protected] http://www.radiance-online.org/mailman/listinfo/radiance-dev
