Logo by Pauldelbrot - Contribute your own Logo!

END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

it was a great time but no longer maintainable by c.Kleinhuis contact him for any data retrieval,
thanks and see you perhaps in 10 years again

this forum will stay online for reference
News: Visit the official fractalforums.com Youtube Channel
 
*
Welcome, Guest. Please login or register. August 11, 2020, 09:13:11 PM


Login with username, password and session length


The All New FractalForums is now in Public Beta Testing! Visit FractalForums.org and check it out!


Pages: [1]   Go Down
  Print  
Share this topic on DiggShare this topic on FacebookShare this topic on GoogleShare this topic on RedditShare this topic on StumbleUponShare this topic on Twitter
Author Topic: Anti-aliasing Technique... // 4 Jesse...  (Read 4793 times)
0 Members and 1 Guest are viewing this topic.
Raydianze
Guest
« on: May 16, 2011, 11:11:11 AM »

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!
Logged
David Makin
Global Moderator
Fractal Senior
******
Posts: 2286



Makin' Magic Fractals
WWW
« Reply #1 on: May 16, 2011, 12:29:58 PM »

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 wink
« Last Edit: May 16, 2011, 12:32:26 PM by David Makin » Logged

The meaning and purpose of life is to give life purpose and meaning.

http://www.fractalgallery.co.uk/
"Makin' Magic Music" on Jango
Raydianze
Guest
« Reply #2 on: May 16, 2011, 07:29:08 PM »

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...
Logged
lycium
Fractal Supremo
*****
Posts: 1158



WWW
« Reply #3 on: May 16, 2011, 08:56:51 PM »

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.
Logged

Syntopia
Fractal Molossus
**
Posts: 681



syntopiadk
WWW
« Reply #4 on: May 16, 2011, 09:33:34 PM »

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.

Logged
lycium
Fractal Supremo
*****
Posts: 1158



WWW
« Reply #5 on: May 16, 2011, 09:43:27 PM »

I happen to write physically-based renderers for a living (Indigo Renderer) so this is pretty much my bread and butter wink 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
Logged

Raydianze
Guest
« Reply #6 on: May 16, 2011, 10:13:15 PM »

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)
Logged
Jesse
Download Section
Fractal Schemer
*
Posts: 1013


« Reply #7 on: May 16, 2011, 10:52:10 PM »

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  Azn
« Last Edit: May 16, 2011, 11:12:34 PM by Jesse » Logged
David Makin
Global Moderator
Fractal Senior
******
Posts: 2286



Makin' Magic Fractals
WWW
« Reply #8 on: May 17, 2011, 03:39:49 AM »

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  Azn

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).
Logged

The meaning and purpose of life is to give life purpose and meaning.

http://www.fractalgallery.co.uk/
"Makin' Magic Music" on Jango
KRAFTWERK
Global Moderator
Fractal Senior
******
Posts: 1439


Virtual Surreality


WWW
« Reply #9 on: May 17, 2011, 12:05:09 PM »

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

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)
Logged

Xenodimensional
Navigator
*****
Posts: 71


Nothing cannot be


beau.deeley
WWW
« Reply #10 on: July 06, 2011, 04:44:00 AM »

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?
Logged

causality ignores the persecutory illusions of free will
Jesse
Download Section
Fractal Schemer
*
Posts: 1013


« Reply #11 on: July 06, 2011, 10:16:40 PM »

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  cheesy
Logged
Pages: [1]   Go Down
  Print  
 
Jump to:  


Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM
Page created in 0.181 seconds with 28 queries. (Pretty URLs adds 0.013s, 2q)