 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi, there!
I wonder how large a povray rendered image can be?
While 1280x1024 fits on an A4-page nicely at 150 dpi, what about renders at
higher resolutions? What are the limits?
What is the largest image you have rendered and how long did it take?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
TC wrote:
> What is the largest image you have rendered and how long did it take?
I've rendered stuff for Zazzle at silly resolutions. (It takes a *long*
time with a 32-bit CPU.)
Let me go check... Yeah, that was 8,000 x 6,000 pixels.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
TC schrieb:
>
> I wonder how large a povray rendered image can be?
>
> While 1280x1024 fits on an A4-page nicely at 150 dpi, what about renders at
> higher resolutions? What are the limits?
Sky's the limit!
Ah well, main memory actually is.
I did a 20,000x10,000 pixels render recently. On my 6-GB 64-bit XP
machine POV-Ray went unstable, but my 6-GB 64-bit Linux machine did the job.
Note that the output buffer needs 4 bytes per pixel and color channel
(invariably buffering the data in 32-bit floating point format before
converting to whatever the output file format holds), for a total of 12
or 16 bytes per pixel (can't tell off the top of my head whether space
for an alpha channel is always reserved or not), so the aforementioned
resolution needs some 2 GB of output buffer alone.
> What is the largest image you have rendered and how long did it take?
Rendering times are too strongly influenced by the scene to make any
absolute statement here that would help you.
The 20,000x10,000 render, for instance, did take no more than 7 minutes;
but it was only a montage step to merge two other renders - something
that would take just a few seconds at "sane" resolutions.
As a rule-of-thumb, expect a render with twice the resolution (i.e. four
times the pixels) to simply take about four times as long; or, more
generally, multiplying the resolution by N will multiply your rendering
times by N^2. Maybe a bit lower I'd guess, as some caching mechanisms
may become more effective (provided you keep the overall level of detail
unchanged), but probably not much. Radiosity may actually bog down the
render more at higher resolution if you set always_sample to on (which
is generally a bad idea but happens to be the default).
(BTW, why did you post this in povray.off-topic?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> Sky's the limit!
Note that many image formats have a limit of 65536x65536 pixels. (I don't
know if PNG has such a limit.)
As for POV-Ray itself, I bet the limit is 2147483648x2147483648 pixels
(or maybe even 4294967296x4294967296 pixels).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Note that many image formats have a limit of 65536x65536 pixels. (I don't
> know if PNG has such a limit.)
According to the official PNG specification [which I just happen to have
on my work PC], the size of the image is specified by the IHDR chunk.
The maximum value for the width and height in pixels is explicitly
specified to be 2^31 - 1 (even though the fields are 4-byte unsigned
integers). It is plausible that some programs might incorrectly support
2^32 - 1 though.
> As for POV-Ray itself, I bet the limit is 2147483648x2147483648 pixels
> (or maybe even 4294967296x4294967296 pixels).
Any theories on how many GB of RAM would be required to render that?
(Assuming you turn off the display preview - apparently some people
don't know you can do this...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Any theories on how many GB of RAM would be required to render that?
> (Assuming you turn off the display preview - apparently some people
> don't know you can do this...)
In theory, POV-Ray needs to store (width*2) pixels. libpng may need to store
a bunch more rows at once while compressing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Any theories on how many GB of RAM would be required to render that?
>> (Assuming you turn off the display preview - apparently some people
>> don't know you can do this...)
>
> In theory, POV-Ray needs to store (width*2) pixels. libpng may need to store
> a bunch more rows at once while compressing.
libpng only needs the current and previous row to run the pixel filter.
I have no idea what the DEFLATE compressor needs. (Other than a complete
redesign...) All assuming you're not going to generate interlaced PNG,
that is.
I note that to store (2^31 - 1) x (2^31 - 1) pixels, where each pixel
requires exactly 4 bytes, requires about 18 exabytes of storage. (!!)
http://www.wolframalpha.com/input/?i=(2^31+-+1)^2+*+4+bytes
Note: 1 exabyte = 1,000 petabytes = 1,000,000 terabytes (or thereabouts).
Nobody has anything approaching that amount of disk space, never mind RAM.
Also, if POV-Ray achieves a million pixels per second (highly unlikely),
that gives us...
http://www.wolframalpha.com/input/?i=(2^31+-+1)^2+%2F+1000000+*+1+second
...almost 150 millennia. So it seems pretty moot to me. :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> libpng only needs the current and previous row to run the pixel filter.
> I have no idea what the DEFLATE compressor needs. (Other than a complete
> redesign...) All assuming you're not going to generate interlaced PNG,
> that is.
Well, with antialiasing off, it should be possible (in theory) to produce an
interlaced PNG with O(1) memory too. You'd have to modify POV-Ray to
compute the pixels in the same order they're stored in the PNG file.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp schrieb:
> As for POV-Ray itself, I bet the limit is 2147483648x2147483648 pixels
> (or maybe even 4294967296x4294967296 pixels).
On contemporary x64 machines, the limit will be much smaller - some 4e6
x 4e6 pixels; more than that, and you'll crash through the 256 TeraByte
address limit (contrary to legend, contemporary x64 processors only
support 48-bit addresses, despite the architecture being designed for
future extensibility to full-fledged 64-bit addresses).
Windows will not allow more than some 7e5 x 7e5 pixels (8 TB), while
Linux will not go beyond some 3e6 x 3e6 pixels (128 TB) due to
per-process address space limits.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez schrieb:
> In theory, POV-Ray needs to store (width*2) pixels. libpng may need to store
> a bunch more rows at once while compressing.
Hum... yes, for POV-Ray 3.6 this is true. I was thinking of POV-Ray 3.7
only.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
