warning request: rpiece image resolution

Dear list,

I appreciate the irony: with the 'no light sources' warning removed
from rpict, I would like to request a new warning, this time for
rpiece.

vwrays and rpict calculate the overall image dimensions from the -v*
parameters and the -x and -y image dimensions. When rpict is run
through rpiece, the image is split up into tiles, each of which is
rendered in a separate thread. The tiles are then pcomposed into the
final image. The width of the final image is xdim = tilex * xdiv,
where tilex is computed by rpiece. Since tilex needs to be an int, it
is actually calculated as floor(xdim / xdiv). If the requested xdim is
not divisible by xdiv, xdim of an image generated by rpiece will be
smaller than xdim of an image with exactly the same -v*, -x and -y
generated by rpict. Same goes for the height of of the image...

I have stumbled across this a few times now. Admittedly, I tend to use
rpictmt from http://www.bakharev.org/index.php?option=com_content&task=view&id=23&Itemid=38,
which is a convenient wrapper around rpiece, although it makes no
difference to the problem at hand.

So my feature request is actually a warning request: Could rpiece
output a warning like:
"warning: requested image size of xdim x ydim reduced to xdim1 x
ydim1" to stderr.
It would be even cooler if the last tile within a row had its tilex
adjusted so that the final image comes out exacly like an rpict one
(ditto for tiley for all tiles within the last row), but this is
probably more difficult to implement, otherwise I guess you would have
done it already.

Many thanks

Axel

Hi Axel,

Because I use the -S option to rpict when rpiece calls it, I can't change the output resolution of the tiles -- they all have to match up exactly.

I thought about adding a warning, but I'm muddled as to when to warn the user and when not to. Oftentimes, a particular view demands that one or the other image side be reduced to fit the desired pixel aspect ratio (1.0 for square pixels by default). I don't think the user wants to be warned about this standard rpict-like behavior. You only want to know when the dimensions produced by rpiece will differ from those that would have been produced by calling rpict directly, right?

-Greg

···

From: Axel Jacobs <[email protected]>
Date: January 19, 2012 7:06:52 AM PST

Dear list,

I appreciate the irony: with the 'no light sources' warning removed
from rpict, I would like to request a new warning, this time for
rpiece.

vwrays and rpict calculate the overall image dimensions from the -v*
parameters and the -x and -y image dimensions. When rpict is run
through rpiece, the image is split up into tiles, each of which is
rendered in a separate thread. The tiles are then pcomposed into the
final image. The width of the final image is xdim = tilex * xdiv,
where tilex is computed by rpiece. Since tilex needs to be an int, it
is actually calculated as floor(xdim / xdiv). If the requested xdim is
not divisible by xdiv, xdim of an image generated by rpiece will be
smaller than xdim of an image with exactly the same -v*, -x and -y
generated by rpict. Same goes for the height of of the image...

I have stumbled across this a few times now. Admittedly, I tend to use
rpictmt from http://www.bakharev.org/index.php?option=com_content&task=view&id=23&Itemid=38,
which is a convenient wrapper around rpiece, although it makes no
difference to the problem at hand.

So my feature request is actually a warning request: Could rpiece
output a warning like:
"warning: requested image size of xdim x ydim reduced to xdim1 x
ydim1" to stderr.
It would be even cooler if the last tile within a row had its tilex
adjusted so that the final image comes out exacly like an rpict one
(ditto for tiley for all tiles within the last row), but this is
probably more difficult to implement, otherwise I guess you would have
done it already.

Many thanks

Axel

Hello, Greg,

> Because I use the -S option to rpict when rpiece calls it, I can't
> change the output resolution of the tiles -- they all have to match
> up exactly.

Oh, I see...

> I thought about adding a warning, but I'm muddled as to when to warn
> the user and when not to. Oftentimes, a particular view demands that
> one or the other image side be reduced to fit the desired pixel
> aspect ratio (1.0 for square pixels by default). I don't think the
> user wants to be warned about this standard rpict-like behavior. You
> only want to know when the dimensions produced by rpiece will differ
> from those that would have been produced by calling rpict directly,
> right?

Yes, only if and when the rpiece image would have different dimensions to the rpict image. I don't want to know when rpiece/vwray do their normal job. I didn't bring this up in my original post, because the aspect ratio adjustment of -x or -y happens all the time. Ideally, the warning should output those adjusted image dimensions, not the raw -x -y request. Does that make sense?

-Greg

>> From: Axel Jacobs <jacobs.axel at gmail.com>
> Date: January 19, 2012 7:06:52 AM PST
>>
>> Dear list,
>>
>> I appreciate the irony: with the 'no light sources' warning removed
>> from rpict, I would like to request a new warning, this time for
>> rpiece.
>>
>> vwrays and rpict calculate the overall image dimensions from the -v*
>> parameters and the -x and -y image dimensions. When rpict is run
>> through rpiece, the image is split up into tiles, each of which is
>> rendered in a separate thread. The tiles are then pcomposed into the
>> final image. The width of the final image is xdim = tilex * xdiv,
>> where tilex is computed by rpiece. Since tilex needs to be an int, it
>> is actually calculated as floor(xdim / xdiv). If the requested xdim >> is
>> not divisible by xdiv, xdim of an image generated by rpiece will be
>> smaller than xdim of an image with exactly the same -v*, -x and -y
>> generated by rpict. Same goes for the height of of the image...
>>
>> I have stumbled across this a few times now. Admittedly, I tend to
>> use
>> rpictmt from http://www.bakharev.org/index.php?option=com_content&task=view&id=23&Itemid=38,

···

which is a convenient wrapper around rpiece, although it makes no

>> difference to the problem at hand.
>>
>> So my feature request is actually a warning request: Could rpiece
>> output a warning like:
>> "warning: requested image size of xdim x ydim reduced to xdim1 x
>> ydim1" to stderr.
>> It would be even cooler if the last tile within a row had its tilex
>> adjusted so that the final image comes out exacly like an rpict one
>> (ditto for tiley for all tiles within the last row), but this is
>> probably more difficult to implement, otherwise I guess you would
>> have done it already.

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]