Welcome to Fractal Forums

I'm have started to perform some huge renders and the render times are getting outrageous. Especially since I am hiding the aliasing by rendering the image double the size and then scaling down by 50%. I would like to request adding an anti aliasing feature. Thoughts? Options?

Original (960x720):
https://picasaweb.google.com/lh/photo/mb1ZwMSghZGM63iOjgrzDavgzFmHVER8BXOSyqa-pbg?feat=directlink
(https://lh4.googleusercontent.com/-b4ODbmK4rRI/TuOHqyLtekI/AAAAAAAAAQA/SW2stUnvjFY/s960/image00000.jpg)



GIMP-> scale 3x -> oilify 6pxl -> unsharpen mask 3.0 -> scale back to original size:
https://picasaweb.google.com/lh/photo/jXGlUzypFWXXVwWxrbA3sKvgzFmHVER8BXOSyqa-pbg?feat=directlink
(https://lh5.googleusercontent.com/-b3EudQTyKzk/TuOID9d-M5I/AAAAAAAAAQM/lgLX76PXC8U/s960/image00000x.jpg)

[I don't know why these images are appearing much larger than they should.]

Many knobs to turn in GIMP, so this might be improved.  Also GIMP can handle multiple images for animations (tutorials on GIMP site).

Anti-aliasing is a never-ending story. It's very difficult to create efficient AA algorithm which will filter only fractal edges (but what means edge when there is no polygons). I have some ideas but for implement this I have to redesign rendering algorithm.
Now only way to have anti-aliasing is render image in double (or triple) resolution.

I once did a 2D monochrome anti-aliasing algorithm that involved a bunch of L and T shapes.  It pattern matched the shapes and replaced them with angles.  When applied to bitmap fonts it was almost tolerable.  Without imaging at a higher resolution, all antialiasing algorithms are just going to introduce more noise to the image, and the quality seems to go down.

Mandelbulber's detail parameter seems pretty nice - I've only just begun playing with it.  Very curious how it was implemented.

I have no idea how easy or hard it would be to implement something like this but it seems to perform pretty well...
http://dl.dropbox.com/u/50613830/wavelet_rasterization.pdf
Check it out. A wavelet-based analytic antialiasing algorithm.
It's only box-filtered but therefore with essentially infinite sampling depth for being analytic.
Also they mentioned, extending to orthogonal wavelets would be trivial, so maybe there are better choices that are still simple enough.
:)
Though the algorithm directly has to work on the polygon, it seems.
Voxel-based rendering techniques might be improved by that too...

Yes I figured it was a very difficult request. Thanks for your thoughts.

Currently, I've been rendering at double the resolution. Then I add .2 Gaussian blur to remove the digital grain look.

I've also been testing out this plugin. It works quite well.
http://powerretouche.com/Antialias_plugin_tutorial.htm (http://powerretouche.com/Antialias_plugin_tutorial.htm)

Another feature request. Would it be possible to add tile rendering support? Even if just renders out the tiles individually and I have stitch them manually (or with a script). I am performing some huge renders and I am running out of RAM.

If you are only interested in anti-alising sharp edges, some of screen space techniques used in the gaming industry might help, for instance MLAA: http://www.geeks3d.com/20101023/tips-what-is-the-morphological-anti-aliasing-mlaa/

In the raytracer I wrote for Structure Synth, I experimented with detecting large changes in the z-buffer and large changes in the normals, and supersampled only at these boundaries. But it ended up as a mess, because other types of alias were still present: shadow boundaries alias, ambient occlusion, textures, etc...

And fractals are terribly complicated with lots of details - so there is probably no free lunch.

How big images do you want to render and how much RAM you have (and which operating system you have)? When I know requirements I will think about some solution. But even if I implement render-to-disk option it will have some limitations. There will not work SSAO and DOF.

I've got 8GB RAM and sometimes I've wondered if I could use an image on the order of 12,000 x 10,000 pixels but it seems to crash larger than 3k^2 or so.  The application would be primitive animations that just scan over the larger 2D generated image.

i made images 8k x 5k on a 32bit system. when you're right the 64bit version would be useless...  :hmh:

Yes - running Vista 64-bit with the 64-bit version of Mandelbulber 1.08.  I just verified simple mandelbulb render larger than 4k x 5k - with Task Manager reporting app using 1.5GB.  Then tried 7k x 5k, same image crashed.

Um... let me double check that before I complete embarrass myself.   :embarrass:

Okay - I was running the 32-bit version... sorry.  64-bit does fine.

On system like this there should be possible to render up to 20000x20000 (I render 15000x15000 with 4GB RAM). To achieve such big resolution Mandelbulber has to be started in "low mem" mode. To do this on Windows just start the program from Start menu by "Mandelbulber 64-bit - Low memory" or from console (on Windows or Linux) with parameter "-lowmem". Then the program will start in limited mode, with no possibility to make any post-rendering tuning of images. Final image will look exactly the same like in normal mode.

I am currently rendering 23040x12960. About 6GB of RAM used.

8GB RAM. Windows 7 64-bit. Mandelbulber 64-bit low memory mode.

My plan is to create truely huge renders for high-quality large-format canvas prints. So I must render twice the size to remove the aliasing and also achieve a more detailed final result. So I would like to render even bigger... Possibly 40k or 80k. Hence the need for tile rendering.

I am fine with the limitations of render-to-disk. I always use real AO. For shots that use DOF, I would just use the normal rendering mode.

Could the tile render have the option to select the amount of X-tiles and Y-tiles? In other words, the user drives the division of the grid.

I am not an expert but I remember a thread were someone (was it Dave Makin?) said it was pointless to do anti-aliasing for large size prints.

Thanks! Good to know. I am going to be doing some print tests soon. If that is the case, then it will be even easier to do huge prints.

---

I have one worry about tile rendering in Mandelbulber. Sometimes a 3px lighter color border can show up on renders. Here are a few examples.
http://www.mandelbulber.com/gallery/hirez/Mini_bulboxes_by_KrzysztofMarczak.jpg
http://www.mandelbulber.com/gallery/hirez/infinity__s_end_by_hyakugojuuichi-d3g36fr.jpg

So to combat this, perhaps implementing an overlap border option would work. Either driven by user input in pixels or a checkbox that adds a 5px border.

you're rendering only with regular ao? i encounter these light borders only with ssao.

one thing about the really big ones. most print services are printing only with  150 dpi above about 50cm. so 23040 px lead to almost 4 m (over 4,2 yard) length. so it seems better to ask your service provider first.

This border is only visible when Screen Space Ambient Occlusion effect is enabled. Near the image edge there is not enough z-buffer data to calculate proper shading. Disabling SSAO effect is also recommended while rendering images for full dome (equirectangular projection).

Ah so that explains why I don't always see the border artifacts! Good to know. Thanks.

Hmm I understand. The SSAO effect is not recommended for equirectangular projection because the border-artifact would be visible; therefore when the equirectangular projection is converted to fisheye, you would see the border-artifact.

It's pointless if you're sticking to 300dpi+ but if you're reducing the dpi for the larger formats then I'd add proportionate anti-aliasing e.g. 2*2 to 3*3 if using 150 to 300 dpi, 3*3 to 4*4 if down to 100dpi and I wouldn't recommend less than 100dpi even for billboard-size - so in that case tiling or lots of ram and full 64-bit access would be required ;)

With respect to DoF with fractals I still think there's mileage in the option I started to investigate but haven't had time to finish - that (implemented fully) would use several "solid depth thresholds" based on the true one for the real surface and the current distance from viewpoint to get multiple solid surface colours for each ray and then combine them to give pseudo-DoF. Obviously this method would work fine with muliti-threading/parallelism of the GPU type.

thanks, david. i think you answered a question i asked here http://www.fractalforums.com/3d-fractal-generation/dof-a-single-threaded-task-by-fate/msg38888/ (http://www.fractalforums.com/3d-fractal-generation/dof-a-single-threaded-task-by-fate/msg38888/). keeps the hope alive... :pray:

Here's my (very limited) investigation into the idea - you should note that this doesn't actually "mix" results from different distance thresholds, nor does it mix background with values from the fractal at thresholds less than the true "solid" threshold which of course would be necessary for the effect to work.

http://www.youtube.com/watch?v=-uJosDRUcsI (http://www.youtube.com/watch?v=-uJosDRUcsI)

Just to add that using multiple samples at different distance thresholds could also be used to simulate a translucent shell around the main solid object.

Thanks for sharing your experience David. Much appreciated.

I definitely want to print at 300dpi. In my experience, whatever you can see on screen will then show up at the press. There is a bit edge-jagginess that is fixed when I reduce down to 11520x6480.

Would you mind clarifying your thoughts when printing at 300dpi?

I did a bit more research into Giclee canvas printing.
http://www.allpconline.com/giclee_dpi.htm

interesting article. matches my observations so far.
my summary: measuring the quality of prints in dpi is quite like measuring the quality of an orchestra (or a recording) in sone...  :laugh:

Just had another idea for the tile render option. Could it check for any tiles already rendered and skip them if found? Just like how the animation feature can skip. This would obviously assume that none of the params or image size has changed. This isn't completely necessary, but would be quite helpful. I've had many instances where I had to stop the render and wish I could resume the render from where it left off.

You will have this in next program release. Tile rendering is almost done. Now I'm during testing it on 32000x32000 image. There will be also possibility to resume rendering from last rendered tile.
During rendering image is saved into temporary binary files and after end of rendering all tiles are compiled to PNG-16 bit image file. Compiling of image doesn't use RAM.

Very exciting! Thank you. I look forward to testing it.

:) I guess I should have been more specific, I actually meant 300ppi *not* dpi, but with most printers (I mean the hardware) the print will always be done at the native dpi of the printer anyway - for instance the *dot* resolution of my Epson is 360 but it's true dpi is 1440 so on that I always use source images of at least 360 ppi - sometimes with extra AA but mostly resized down from original images @8000*6000 - the printer is A4 so for a 4*3 image I use a final source at 3840*2880.
The relevant phrase from the page you referenced is "We print giclee at the native resolution of our printers, which is 180 and 360 PPI."
In other words ideally find out the *dot* resolution of the target printer (of whatever type) and your final ready to print source image should be set at that ppi - and that dpi in the image info as well.
e.g. I believe Durst Lambda's (although continuous tone) have an equivalent dot resolution of 400dpi so if having prints done on those I would want my final source image to be at 400 ppi (i.e. 8000*6000 pixels for a 20" by 15" print) and set at 400dpi in the image info.
With respect to seeing "jaggies" on the monitor there are 2 caveats here 1. Make sure you're viewing at the final print size i.e. so one inch of monitor distance would be one inch on the final print and 2. Because of the way most printers work nowadays there is a degree of smoothing/blurring between adjacent "dots" inherent in the printing process - there is *no* equivalent to this on your monitor display (unless using a plasma??) so a certain level of "jag" on the monitor can be overlooked as it will end up being smoothed out on the print.

With respect to AA if you create an image with a simple series of black lines (1 pixel width) without AA and print that at 300dpi I'd be interested to know if you can see the jaggies on the print without using a magnifying glass ;)

Here's a macro photo of part of a varnished canvas giclee that's from a source that was simply rendered @300ppi without AA and as you can see there aren't any jaggies apparent even where they normally would appear (the height of the photo on the canvas is around 1 inch).

(http://nocache-nocookies.digitalgott.com/gallery/9/141_18_12_11_2_07_51.jpeg)

http://www.fractalforums.com/index.php?action=gallery;sa=view;id=9603 (http://www.fractalforums.com/index.php?action=gallery;sa=view;id=9603)

Note there is considerably exaggeration of the canvas texture as I used a very bright LED headtorch to shed enough light on the subject ;)

Wow thanks so much for sharing such details. Very enlightening. I am going to do more research and then read over this again. Thanks!

For RCPage and anyone else interested, here's the full canvas with the rectangle that the macro shows outlined in red....

Title: "A Green View".

(http://nocache-nocookies.digitalgott.com/gallery/9/141_19_12_11_2_24_20.jpeg)

http://www.fractalforums.com/index.php?action=gallery;sa=view;id=9618 (http://www.fractalforums.com/index.php?action=gallery;sa=view;id=9618)

Mandelbulber passed test of rendering image in resolution 32000x32000

Downscaled image to 8000x8000 is here (unfortunately DeviantArt has image resolution limitation): http://krzysztofmarczak.deviantart.com/#/d4jo300

Some interesting numbers:
- RAM used: only 250 MB (it's not a joke)
- rendering time: about 20 hours (256 tiles in resolution 2000x2000)
- image file size (PNG 16-bit): 2,5 GB
- image saving (compiling) time: 15 minutes (PNG16 compression is very slow)

Tile rendering mode can't be used with post-effects like depth of field and screen space ambient occlusion