It just occurred to me how nice it would be to have the ability for
antialiasing to start at a level above pixel-level. That is, at a
superpixel level.

Instead of taking a sample for each pixel as a basis, you could set it
to start taking samples for each 2x2 pixels. Or 4x4 or 8x8 etc. You
could have it stop at pixel level, or go further down in subpixel
levels, like in regular antialiasing.

Antialiasing with superpixels would be ideal for test renders. Now, a
800x600 image going from 4x4 level down to pixel level would take
exactly equally long to render as a 200x150 image going from pixel level
to level 2 regular antialising. However, the details are far more
visible in the big image than in the small one.

The reason: While an antialiased image have more information than an
image without antialiasing, there is still some information lost because
the samples are averaged together. Using superpixels however, no
information is lost at all (when it stops at pixel level). This gives
maximum value for your rendering time.

Of course details would get lost that are smaller than the superpixels,
but that's no different than details getting lost in regularly
antialiased images where the details are smaller than the pixels.

The point is that superpixel antialiasing would enable you to very
quickly render images where details would be clearly visible, while
areas of the image with less details would render very fast.

How would the superpixels look? Well, they could simply be squares of
pixels of equal color, but it would be an extra plus if there was an
option to interpolate them, using the same interpolation methods that
can be used with image_map interpolation. Then you might even in some
cases be able to use superpixel rendering for final renders.

What do you think?

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com **updated Jul 25**
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

In article <3f6eeb5a$1@news.povray.org>,
 "Rune" <run### [at] runevisioncom> wrote:

> Instead of taking a sample for each pixel as a basis, you could set it
> to start taking samples for each 2x2 pixels. Or 4x4 or 8x8 etc. You
> could have it stop at pixel level, or go further down in subpixel
> levels, like in regular antialiasing.

Sounds like an adaptive mosaiac preview...

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
> Sounds like an adaptive mosaiac preview...

Sort of, yes. The problems with the current mosaic preview are that it
is not adaptive, and that the mosaic samples are wasted in the end,
since the final pass goes all from scratch. Furthermore, mosaic previews
are of no use when you want to make a test *animation* render. Where
mosaic previews are based on the idea that you can abort the render when
you have seen enough details, the superpixel antialiasing render is
meant to finish rendering, and it only uses samples where there actually
*are* details. All in all a rather big difference...

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com **updated Jul 25**
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

On Mon, 22 Sep 2003 15:44:59 +0200, "Rune" <run### [at] runevisioncom> wrote:
> Sort of, yes. The problems with the current mosaic preview are that it
> is not adaptive, and that the mosaic samples are wasted in the end,
> since the final pass goes all from scratch.

What about rendering with lower image dimensions and double click in WinPOV on
title bar of render window ? Then you have antialiased boxes in enlarged
window ;-)

> Furthermore, mosaic previews
> are of no use when you want to make a test *animation* render.

Hmm, In this case I would render with lower resolution and order mpeg encoder
to rescale frames to desired dimensions to not waste space on drive for larger
images. At leas TMPG has rescaling of frames. Of course this could be always
done in mpeg player with rescaling window. Or perhaps I did not understood
your problem...

> the superpixel antialiasing render is
> meant to finish rendering, and it only uses samples where there actually
> *are* details

How do you imagine to "know" in renderer that pigment used on sky has less or
more details from applied turbilence ?

ABX

Post a reply to this message

> How do you imagine to "know" in renderer that pigment used on sky has less
or
> more details from applied turbilence ?

The same way antialiasing works. Shoot at the
four edges and find a great difference in color.

I for one first thought that someone was explaining
mosaic preview, then I saw that it was Rune who
wrote, then I read on.

I find the idea rather attractive, and I'd guess that
anyone able to look at the source-code and understand
antialiasing could tweak that to do the super-pixeling
Rune has proposed, though I'm not expert and could
be wrong there.

I always liked Mosaic-Previews, but Rune's idea
is even better. After all, you do several passes with
POV-Ray until you've set up camera, lighting etc,
during that time one could easily adjust the superpixeling
to the needs of that render, and later on, save time
by just copy-paste.

If there's someone out there capable of doing that in
a clean and efficient way, we might go rebel against
the POV-Team and have them introduce it into the
official version very quickly! ;-)
I rather like using the Official Version, and have only
used MegaPOV once to experiment a little with
isosurfaces and photons, when I knew that POV 3.5
would get them, just as background why I'd go rebel... :-)

Regards,
Tim

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: no_lights (@) digitaltwilight.de

> > Sort of, yes. The problems with the current mosaic preview are that it
> > is not adaptive, and that the mosaic samples are wasted in the end,
> > since the final pass goes all from scratch.
>
> What about rendering with lower image dimensions and double click in
WinPOV on
> title bar of render window ? Then you have antialiased boxes in enlarged
> window ;-)
>
> > Furthermore, mosaic previews
> > are of no use when you want to make a test *animation* render.
>
> Hmm, In this case I would render with lower resolution and order mpeg
encoder
> to rescale frames to desired dimensions to not waste space on drive for
larger
> images. At leas TMPG has rescaling of frames. Of course this could be
always
> done in mpeg player with rescaling window. Or perhaps I did not understood
> your problem...
>
> > the superpixel antialiasing render is
> > meant to finish rendering, and it only uses samples where there actually
> > *are* details
>
> How do you imagine to "know" in renderer that pigment used on sky has less
or
> more details from applied turbilence ?
>
> ABX


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.520 / Virus Database: 318 - Release Date: 18.09.2003

Post a reply to this message

In article <3f6f0780$1@news.povray.org> , "Tim Nikias v2.0" <no_lights (@)
digitaltwilight.de> wrote:

> The same way antialiasing works. Shoot at the
> four edges and find a great difference in color.

No, this won't work.  Also you don't notice most of the time, anti-aliasing
does nothing when it comes to finding small details.  All it does is smooth
out sharply separated details that were already "known" (visible).  On
occasion this will find other small details while looking for the clear
separation of the already known details, but this is not more than a
side-effect of the anti-aliasing process.

However, his does not imply the desired effect - rendering a scene with
increasing detail, isn't possible.  It is just more difficult to obtain.
Using other information, like the vista buffer information, can be used to
track at least all the boundable objects.  However, using this information
isn't as simple as an anti-alising-like algorithm.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> No, this won't work.  Also you don't notice
> most of the time, anti-aliasing does nothing
> when it comes to finding small details.  All
> it does is smooth out sharply separated
> details that were already "known" (visible).

I already mentioned that details smaller than the specified superpixel
size would not be detected. Isn't that what you're talking about? If you
choose to render with 8x8 superpixels, then a 6 pixels wide sphere
easily could get lost. However, the border of a 100 pixels wide sphere
would be completely sharp - wouldn't it?

So certainly, the feature would not work well for some scenes with very
small details, but for many scenes I think it would work brilliantly,
especially if you keep the superpixels reasonable small, like 4x4 or 2x2
(which would still give a huge speed-up).

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com **updated Jul 25**
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

> What do you think?

You've got my support!  I remember using StrataVision 3D back in the day and
it had support for this.  When I first started using POV-Ray, I was
surprised how much longer it took to render a simple scene with a flat
background.  Superpixel antialiasing is visibly blocky, but interpolated
and done with a low threshold would be seamless enough for most renders. 
95% of the renders I do are only tests anyway and once you run it through a
codec like divx, it's only going to make it (more) blocky.  But I'm just
rambling.  Makes sense to me.

 - Ricky

Post a reply to this message

In article <3f6f3cb6@news.povray.org> , Ricky Reusser 
<ple### [at] emailcom>  wrote:

> once you run it through a
> codec like divx, it's only going to make it (more) blocky.

You should note one tiny little bit of information that is good to know, and
applies to all lossy image and image sequence compression algorithms: The
"better" the source material, the better the compression result.

"better" in this context means that anti-aliased image sequences will
compress better, as will blurred ones when you are using DCT-based codecs.
All common codecs that achieve good compression (from JPEG to DV to
MEPG-1,2,4, and all derived ones like divx) are DCT-based.  Even H.264 (aka
MPEG-4 Part 10 or MEPG-4 AVC) uses a DCT-like transformation.  The trick is
that a smooth image results in more effective quantisation and hence better
compression.

If you get "blocky" results, this means your compression settings are simply
to high and too many coefficients are lost during the quantisation process.
In particular when compressing not anti-aliased computer-generated
animations you get compression quality problems ... as do you when feeding
the compressor a noisy captured video sequence.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

ABX wrote:
> 

If it's just for a preview rendering of an animation rendering at a
small size is my tactic too. Then I preview the frame sequence at the
desired size if necessary (I use Bumper for that (*spam alert*) which
has some other handy options) . 

Remco

Post a reply to this message