Hi all,
What wisdom do people have about generating absurdely (IMHO) large images (for example 22,000 x 22,000 at 3 times over sample, eg running at 76,000 x 76,000). The best thing that I can think of is to render the images as a seriese of sub views (tiles) with appropriate shift and lifts so the final image can be composed from the sub pieces. If the tiles are all pfilted (using the same exposure settings) to their final size prior to composing the final image will there be problems at the tile edges?
Thanks for any input/guidance,
-Jack de Valpine
Ack, that is pretty bad!
22,000x22,000 at 3X or 66,000x66,000
Jack de Valpine wrote:
···
Hi all,
What wisdom do people have about generating absurdely (IMHO) large images (for example 22,000 x 22,000 at 3 times over sample, eg running at 76,000 x 76,000). The best thing that I can think of is to render the images as a seriese of sub views (tiles) with appropriate shift and lifts so the final image can be composed from the sub pieces. If the tiles are all pfilted (using the same exposure settings) to their final size prior to composing the final image will there be problems at the tile edges?
Thanks for any input/guidance,
-Jack de Valpine
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
--
# John E. de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
Hi Jack,
Is there any reason you can't just render your large image straight off? It will come out uncompressed, as the RLE algorithm in Radiance doesn't work for scanlines longer than 32K, but otherwise everything should work. Are you getting some error along the way? I just ran a test with pcompos, creating a 50K by 50K image. It took 9 GBytes of disk space and took a few minutes to write out, but seemed OK otherwise.
Compositing tiles after filtering them separately will result in visible lines at the tile boundaries in some cases.
-Greg
···
From: Jack de Valpine <[email protected]>
Date: January 20, 2005 10:57:03 AM PST
Hi all,
What wisdom do people have about generating absurdely (IMHO) large images (for example 22,000 x 22,000 at 3 times over sample, eg running at 76,000 x 76,000). The best thing that I can think of is to render the images as a seriese of sub views (tiles) with appropriate shift and lifts so the final image can be composed from the sub pieces. If the tiles are all pfilted (using the same exposure settings) to their final size prior to composing the final image will there be problems at the tile edges?
Thanks for any input/guidance,
-Jack de Valpine
Jack,
I have only done images up to 28800x28800 (3 GB file), and always by using rpiece or the method that you suggest. Unfortunately, I have always done pfilt on the whole image, so I have no experience with pfilting beforehand.
I can imagine that you could cobble together a script that would read data from the adjacent images and attach a thin border around each piece, allowing you to pfilt first. Then you could trim the extra border off and assemble the full image later.
You've probably thought of this, though.
Mark
···
On Thu, 20 Jan 2005, Jack de Valpine wrote:
Hi all,
What wisdom do people have about generating absurdely (IMHO) large images (for example 22,000 x 22,000 at 3 times over sample, eg running at 76,000 x 76,000). The best thing that I can think of is to render the images as a seriese of sub views (tiles) with appropriate shift and lifts so the final image can be composed from the sub pieces. If the tiles are all pfilted (using the same exposure settings) to their final size prior to composing the final image will there be problems at the tile edges?
Thanks for any input/guidance,
-Jack de Valpine
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
Hey Greg,
I could probably do the large image straight off. But since I have never tried it, I am trying to consider contingencies.
So alternatively, tiles could be generated seperately, pcomposed together and then filtered down to avoid tile boundaries.
-Jack
Greg Ward wrote:
···
Hi Jack,
Is there any reason you can't just render your large image straight off? It will come out uncompressed, as the RLE algorithm in Radiance doesn't work for scanlines longer than 32K, but otherwise everything should work. Are you getting some error along the way? I just ran a test with pcompos, creating a 50K by 50K image. It took 9 GBytes of disk space and took a few minutes to write out, but seemed OK otherwise.
Compositing tiles after filtering them separately will result in visible lines at the tile boundaries in some cases.
-Greg
From: Jack de Valpine <[email protected]>
Date: January 20, 2005 10:57:03 AM PST
Hi all,
What wisdom do people have about generating absurdely (IMHO) large images (for example 22,000 x 22,000 at 3 times over sample, eg running at 76,000 x 76,000). The best thing that I can think of is to render the images as a seriese of sub views (tiles) with appropriate shift and lifts so the final image can be composed from the sub pieces. If the tiles are all pfilted (using the same exposure settings) to their final size prior to composing the final image will there be problems at the tile edges?
Thanks for any input/guidance,
-Jack de Valpine
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
--
# John E. de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
Hey Mark,
Thanks for the follow-up. I figured you might have some insight. I too had thought of putting together a script as well to "trim" the borders.
Have you run your large images renderings distributed over multiple machines? How has this worked for you?
-Jack
Mark Stock wrote:
···
Jack,
I have only done images up to 28800x28800 (3 GB file), and always by using rpiece or the method that you suggest. Unfortunately, I have always done pfilt on the whole image, so I have no experience with pfilting beforehand.
I can imagine that you could cobble together a script that would read data from the adjacent images and attach a thin border around each piece, allowing you to pfilt first. Then you could trim the extra border off and assemble the full image later.
You've probably thought of this, though.
Mark
On Thu, 20 Jan 2005, Jack de Valpine wrote:
Hi all,
What wisdom do people have about generating absurdely (IMHO) large images (for example 22,000 x 22,000 at 3 times over sample, eg running at 76,000 x 76,000). The best thing that I can think of is to render the images as a seriese of sub views (tiles) with appropriate shift and lifts so the final image can be composed from the sub pieces. If the tiles are all pfilted (using the same exposure settings) to their final size prior to composing the final image will there be problems at the tile edges?
Thanks for any input/guidance,
-Jack de Valpine
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
--
# John E. de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
Jack,
I usually break them up into 5-10 subimages, each one the entire width, but a fraction of the height. I typically have 2 to 10 machines that I can render on (depending on whether work needs the 8-proc Opteron cluster). I'll write the rpict commands by hand, and "nohup ... -t 600 ... &" each command. Keep in mind that I don't use a global ambient cache. I do the "-aa 0 -ab [low] -ad [low] -as 0" trick to prevent the RAM requirements from getting too high (and to avoid having to deal with NFS).
Then I just use rsync/scp to put the completed portions on one machine, and pfilt there. pfilt uses only a very little bit of memory, but it can be slow on massive images, especially with -r and decent downsampling. Compared to the rendering, though, I'll sit around and wait for the pfilt.
M
···
On Thu, 20 Jan 2005, Jack de Valpine wrote:
Hey Mark,
Thanks for the follow-up. I figured you might have some insight. I too had thought of putting together a script as well to "trim" the borders.
Have you run your large images renderings distributed over multiple machines? How has this worked for you?
-Jack
Mark Stock wrote:
Jack,
I have only done images up to 28800x28800 (3 GB file), and always by using rpiece or the method that you suggest. Unfortunately, I have always done pfilt on the whole image, so I have no experience with pfilting beforehand.
I can imagine that you could cobble together a script that would read data from the adjacent images and attach a thin border around each piece, allowing you to pfilt first. Then you could trim the extra border off and assemble the full image later.
You've probably thought of this, though.
Mark
On Thu, 20 Jan 2005, Jack de Valpine wrote:
Hi all,
What wisdom do people have about generating absurdely (IMHO) large images (for example 22,000 x 22,000 at 3 times over sample, eg running at 76,000 x 76,000). The best thing that I can think of is to render the images as a seriese of sub views (tiles) with appropriate shift and lifts so the final image can be composed from the sub pieces. If the tiles are all pfilted (using the same exposure settings) to their final size prior to composing the final image will there be problems at the tile edges?
Thanks for any input/guidance,
-Jack de Valpine
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
--
# John E. de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general