Anti-aliasing Technique... // 4 Jesse...

[Raydianze]

Hi Jesse....
after reading up all the issues around max. file sizes... issues around 32/64 bit...
I have an idea on how one could possibly improve the anti-aliasing situation whereby this would
allow for much much larger printable output files...
((I was a software programmer for well over 15 years))

OK... right now... the max file size I can generate is 12750x8500 ....
of course - this is not anti-aliased... and depending on the type of image... a size-reduction to
create anti-aliasing is on the order of 1:2 or even 1:3 and in some worst case 1:4...
this significantly reduced possible print sizes!!!

NOW -- if we could have an output size of 12750x8500 fully anti-aliased by selecting quality level
of 1:2, 1:3, 1:4 .... WELL - WOW... super super big prints possible...
and then -- it would not be an issue of dealing with a 64 bit version for mega-file sizes...

SO --- here's what my brain has been thinking through...
How about --
*** An internal anti-aliasing buffer...
whereby -- depending on quality of anti-aliasing (user selected)...
instead of writing line-by-line of the image -- to the view window... it first is saved in an internal
buffer... of Xxx number of lines...
and then ... when X-number of lines have accumulated ... one does the anti-aliasing on what's in
the buffer... and then write out the cleaned up output line....

In short... that's the logic behind it...
Might not be all that difficult to implement -- if you think through the logic of it all...
and the coding might happen quickly...

Sure would love to see super-size super-clean printable images coming into existence!
Given... Epson now has printers that can print 64 inches wide!
so a 12750x8500 Anti-aliased image -- could be produced super-clean at 96x64 inches!
that would be WOW!

[David Makin]

A better alternative is the option of conditional super-sampling done using an algorithm like the one that Frederik uses for disk renders in Ultra Fractal.
This is more complex in programming terms but only computes extra pixels where necessary (as dictated by the user AA options) so is pretty much optimum in performance terms.
Possible method:
1. Render at given siize as normal.
2. Now scan pixels/pixel diffs to decide where over-sampling is required based on the desired AA settings and perform extra pixel calculations as necessary - storing extra data in small buffer with location info. Note that this could be recursive such that if the user has specified a max. of 4*4 oversampling with a threshold limit of x then where the limit is not met you perform 2*2 first then if the limit is still not met you go to 3*3 and so on, ending at the user specified max such as 4*4.
3. Use extra pixels to apply AA to the standard render (in 1).

Of course if the user specifies a threshold limit of zero then you need to use Ray's method in any case

[Raydianze]

David! thanks for participating in this thread!
Ultra-fractal does an excellent job with the anti-aliasing....
I hope we can help Jesse work out - think through - how to conquer this issue
with the least amount of effort...

[lycium]

Sorry to be contrary, but I must disagree:

1. UF does a pretty bad job of AA - try comparing it to other commercial products.
2. The adaptive AA technique David suggested has a number of inherent problems, especially when used to render fractals.


Adaptive AA is great in theory, however there are a number of tricky issues to be addressed in a practical implementation; using a statistical estimate of how many additional samples to use, especially as a binary none/more decision, simply results in a different kind of noise which is easily visible in smooth transitions.

[Syntopia]

Just a quick comment. I'm currently reading the excellent 'Physically Based Rendering' by Pharr and Humphreys, and one thing that surprised me, is that anti-aliasing is complicated stuff - they have a whole chapter dedicated to sampling and reconstruction only.

A few points: rendering images at large sizes and downsampling is not the best way to anti-alias. This corresponds to uniform sampling and better results may be obtained by using stratified sampling or other sampling strategies. Another point is that simply averaging (box filtering) subsamples to produce a final pixel is the worst possible reconstruction strategy: instead more advanced filters such as Mitchell and Sinc should be used.

Unfortunately these stragies are somewhat difficult to implement on a GPU, since ideally one sample should contribute to more than one pixel in the final image. These means that rendering is not embarrassingly parallel anymore - a CPU implementation should be doable though: for a nice example see the Sunflow raytracer (Open Source) which implements many filtering and sampling techniques.

[lycium]

I happen to write physically-based renderers for a living (Indigo Renderer) so this is pretty much my bread and butter Some of what you've written isn't entirely accurate, but I've already spammed quite a lot on the subject of antialiasing on this forum and others so I won't rehash it here.

The coverage in PBRT is indeed very good and is even available for free online (I've linked it before on this forum in a different thread): http://graphics.stanford.edu/~mmp/chapters/pbrt_chapter7.pdf

[Raydianze]

So? for simplicity sakes...
would my first stated idea -- be perhaps the easiest for Jesse to implement -
with reasonable anti-aliasing...
the buffering technique is really nothing more than what is being down by down-sizing the
image as is being down by 1:2 or 1:3 scaling...
(I'm not sure if Jesse has implemented some sort of aliasing algorithm in the down-scaling.
I suspect so)

[Jesse]

I did a thresholded lanczos8 filtering on downscaled image saving, thresholded based on the data.
This is a good compromise between effort and result, but needs surrounding pixels... what leads to
the conclusion that i do a unscaled saving if i implement tiled renderings.
Hmm... have to do other things first, but its a note on the list  

[David Makin]

I did a thresholded lanczos8 filtering on downscaled image saving, thresholded based on the data.
This is a good compromise between effort and result, but needs surrounding pixels... what leads to
the conclusion that i do a unscaled saving if i implement tiled renderings.
Hmm... have to do other things first, but its a note on the list  

I'd have thought that the tiling issue is simply overcome by adding a gutter of appropriate size to all tiles that is discarded when pieced together (that's what I was contemplating for doing tiling on the GPU).

[KRAFTWERK]

I am with you Jesse, go for the tiling!
 
That way you could do as big renders as you like: http://mandelwerk.com/ 

In my world a 12750 x 8500 pixel render is in best case good enough for "only" 42 x 28 inches prints on a good printer. (at 300 dpi)

[Xenodimensional]

I have been printing my renders at 1200mmx900mm (35x47 inches) from 8000x6000 pixel files. The resultant images are gobsmacking in scale and detail. I have to look at them from less than 40cm (15 inches) to see any 'noise' artifacts...

I think large format fractaling starts to tread into billboard territory, a 5 metre picture need not have zillions of pixels if it is intended to be viewed from a few metres back, having said that I'm sure we'd all like to see a 5 metre fractal at full resolution...

Now here's the bit where I probably make a complete goose of myself... is it not possible to have the gpu do antialiasing ala Vue 9.5?

[Jesse]

Now here's the bit where I probably make a complete goose of myself... is it not possible to have the gpu do antialiasing ala Vue 9.5?

No, but tiling is on the way