feature request - anti aliasing

[isosceles]

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

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.

[taurus]

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.

[Buddhi]

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.

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

[isosceles]

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.

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.

[David Makin]

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

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.

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.

[taurus]

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/. keeps the hope alive...

[David Makin]

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/. keeps the hope alive...

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.

<a href="http://www.youtube.com/v/-uJosDRUcsI&rel=1&fs=1&hd=1" target="_blank">http://www.youtube.com/v/-uJosDRUcsI&rel=1&fs=1&hd=1</a>

[David Makin]

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.

[isosceles]

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

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.

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

[taurus]

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

[isosceles]

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.

[Buddhi]

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.

[isosceles]

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.

[David Makin]

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://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

[isosceles]

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