supersampling level vs speed ?

[kwez]

HI,
I keep reading that a higher supersampling factor will take more RAM,
but what about more time !?

If I understand correctly, the technique used is to create a larger image and 'collapse' it to correct size.

ie, 200x200 @ supersample level 2 => generated internal img is 400X400

so doesn't that mean that each successive level takes 4times longer ??

or does progressive rendering affect ths ?

thank you
Philippe

[OnoSendai]

It takes slightly longer due to cache effects, but not much longer.

[Kram1032]

- except (d'oh) you run out of ram and Indigo starts swapping... then, it'll highly affect render-times

[kwez]

coool,
isn't this magical ! ;-p

I won't mind using it if required then.
thx

[psor]

And just as a side note, if you save an untonemapped EXR, then you
can load this in your favorite application and will have the "full size"
image. Then you can resize and tonemap it with your tools. ;o))

e.g. res 800x600 | ss3

Code: Select all

PNG res: 800x600
EXR res: 800x600    (tonemapped)
EXR res: 2400x1800 (untonemapped)
IGI  res: 2400x1800 (will be resized through Violet/Indigo)

Have fun!

nb: If you guys wonder why I mention this, it can help to reduce
noise before resizing the image, especially if you do not have
that much RAM to render an huge image with ss3 ...




take care
psor

[lycium]

isn't this magical !

not really :P drawing 100,000 incoherent points to a big buffer won't take much longer than 100,000 points to a smaller buffer. the final image is the same resolution after the downsample, so you still get as many samples per final pixel both ways, which is what really determines the quality of the final image.

[kadajawi]

Hm... does it take just as long to render a image at 800x600 with ss2 as it takes to render a image at 1600x1200 with ss1?

Btw. if you have the igi, you can set the ss to 1, resume and render until it saves. You png should have the full resolution then.

[psor]

@kadajawi

I would say so, yes. And just enable to export an untonemapped EXR.
Then you'll have the "full" resolution image as an EXR file. ;o))



take care
psor

[Zom-B]

I would say so, yes. And just enable to export an untonemapped EXR.
Then you'll have the "full" resolution image as an EXR file. ;o))

Yes, but beware if you use env_maps... setting the gain for them to 10000 or even more is needed to get an untonemapped exr with actually something inside

[psor]

@ZomB

Good to know, thanx! But I do wonder, is really no data in the
EXR or is the exposure just so low that it seems black all over?



take care
psor

[Zom-B]

in some cases there realy is a little data inside, but you have to raise the "Belichtung" to the max to see some blocky artifacts with very low color information.
This is totally related to the env_map used!

My theory for this, is that Indigo works internally for example in 96bit mode (like C4D),
and saves the untonemapped.exr just by clamping it to 32bit.

Other lightsources are "normalized" internally, but env_maps aren't because there is no standard they follow in Brightness etc.
Indigo needs some kind of image based brightness detection to bring env_maps on the same level like other lightsources... but there is no such.
This job btw. could be done really nice using the GPU

[lycium]

My theory for this, is that Indigo works internally for example in 96bit mode (like C4D),
and saves the untonemapped.exr just by clamping it to 32bit.

exr has a compression method whereby the colours share an exponent, so you get all data in 32bit without clamping (however the result is lossy).

btw, indigo uses double precision internally because bidirectional path tracing needs it, so usually 896bits (14 doubles) are in use for the spectral colour representation if we go by the number of stratified wavelength clusters that was previously configurable in the ini file.

[psor]

"exr has a compression method whereby the colours share an exponent,
so you get all data in 32bit without clamping (however the result is lossy)."

Might be true that it's lossy if you compare it to Indigo's internal calculation,
but non the less, the most people will never use the advantages of the
OpenEXR format anyway. So the "lossy" is right, but for compositors and
artists in general 32bit per channel is enough for now.

------- SNIP --------

Features of OpenEXR
Starting in 1999, Industrial Light & Magic developed OpenEXR, a high-dynamic-range image file format
for use in digital visual effects production. In early 2003, after using and refining the file format for two
years, ILM released OpenEXR as an open-source C++ library. A unique combination of features makes
OpenEXR a good fit for high-quality image processing and storage applications:
• high dynamic range
Pixel data are stored as 16-bit or 32-bit floating-point numbers. With 16 bits, the representable
dynamic range is significantly higher than the range of most image capture devices: 109 or 30 fstops
without loss of precision, and an additional 10 f-stops at the low end with some loss of
precision. Most 8-bit file formats have around 7 to 10 stops.
• good color resolution
with 16-bit floating-point numbers, color resolution is 1024 steps per f-stop, as opposed to
somewhere around 20 to 70 steps per f-stop for most 8-bit file formats. Even after significant
processing (e.g., extensive color correction) images tend to show no noticeable color banding.
• compatible with graphics hardware
The 16-bit floating-point data format is fully compatible with the 16-bit frame-buffer data format
used in some new graphics hardware. Images can be transferred back and forth between an
OpenEXR file and a 16-bit floating-point frame buffer without losing data.
• lossless and lossy data compression
Most of the data compression methods currently implemented in OpenEXR are lossless; repeatedly
compressing and uncompressing an image does not change the image data. With the lossless
compression methods, photographic images with significant amounts of film grain tend to shrink to
somewhere between 35 and 55 percent of their uncompressed size. OpenEXR also supports lossy
compression, which tends to shrink image files more than lossless compression, but doesn't preserve
the image data exactly. New lossless and lossy compression schemes can be added in the future.
• arbitrary image channels
OpenEXR images can contain an arbitrary number and combination of image channels, for example
red, green, blue, and alpha; luminance and sub-sampled chroma channels; depth, surface normal
directions, or motion vectors.
• scan-line and tiled images, multiresolution images
Pixels in an OpenEXR file can be stored either as scan lines or as tiles. Tiled image files allow
random-access to rectangular sub-regions of an image. Multiple versions of a tiled image, each with
a different resolution, can be stored in a single multiresolution OpenEXR file.
Multiresolution images, often called "mipmaps" or "ripmaps", are commonly used as texture maps
in 3D rendering programs to accelerate filtering during texture lookup, or for operations like stereo
image matching. Tiled multiresultion images are also useful for implementing fast zooming and
panning in programs that interactively display very large images.
• ability to store additional data
Often it is necessary to annotate images with additional data; for example, color timing information,
process tracking data, or camera position and view direction. OpenEXR allows storing of an
arbitrary number of extra attributes, of arbitrary type, in an image file. Software that reads
OpenEXR files ignores attributes it does not understand.

------- SNAP --------

take care
psor

[Kram1032]

Hm... does it take just as long to render a image at 800x600 with ss2 as it takes to render a image at 1600x1200 with ss1?

Btw. if you have the igi, you can set the ss to 1, resume and render until it saves. You png should have the full resolution then.

I don't think so...

It makes subsamples, yes... But your pixel gets more or less the average colour of all subsamples made. So, with the same amount of samples on four pixels as four subsamples on one, the image looks the same (though, scaled down)
If you have less subsamples on the single pixel, that might still lead to quite the same appearance (as long as the difference isn't too big)...
So, it should take shorter to show the same thing.
Using SS isn't much slower than not using it (setting it to 1) The main speed difference is on the higher use of RAM, which might lead to swapping, when you don't have enough of it...

____
I somewhere read (it was quite some time ago, so I don't know if it's still the case or where I read it), that 32bit compression *always* is lossy, though, just slightly, where as halfprecession images (16bit per channel) can be saved entirely without loss...

Though, I've never seen a 16bit exr... hum...

[IanT]

btw, indigo uses double precision internally because bidirectional path tracing needs it

Does it?

Ian.