[Radiance-general] Errors with Vertically Tall HDR Images

[J. Alstan Jakubiec]

Dear Radiance friends,

(Sorry to post to the mailing list, but the Discourse server seems to be 
down.)

I have an issue when I am working with some rather tall HDR images 
(10,000 - 100,000 pixels tall). The application is that I am running 
annual discomfort calculations using Jan's gen_dgp_profile approach with 
many views on very large octrees. In this case, one call to rtrace with 
a big vwrays output file is better than 40+ to rpict where the octree 
needs to be loaded into memory each time. I tested this in a model with 
38 views and a 500 x 500 pixel output per view, resulting in a 500 x 
19,000 pixel image per timestep, which worked great! Now I am working 
with a model that has 56 views (a 500 x 28,000 pixel image), and I get 
systematic errors when passing the output to evalglare.

Here are the steps I am using:

  * I run vwrays 56 (or n) times: vwrays -ff -vta -vv 180 -vh 180 -vp
    ... -vd ... -x 500 -y 500 >> views.rays
  * rtrace -x 500 -y 28000 -ab 0 -lw 0.0000001 -st 0.15 -ffc !oconv ...
    < views.rays > image.hdr
  * I cut the output using pcompos, and pass it to evalglare: pcompos -x
    500 -y 500 image.hdr 0 *pixel_offset* | evalglare.exe -vta -vv 180
    -vh 180 ...
      o In this case pixel_offset is 0 for the last view, -500 for the
        second-to-last, etc.

I can extract images for every offset -500 through -27500 except for the 
0 offset. I get this error for the 0 offset (passing to ra_bmp in this 
case):

    image.hdr: read error (y==499)
    ra_bmp: error reading Radiance picture

I am not sure quite what to make of this and hope that someone here 
might have an idea. I uploaded an example image here: 
https://www.dropbox.com/s/7gub8i4row9qmsz/image.hdr?dl=0 Is the error 
with the render itself or with the size of the HDR?

Thank you,

Alstan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.radiance-online.org/pipermail/radiance-general/attachments/20180816/2a40eb5c/attachment.html>