> Basically, you have to compute the color of an area of texture, not just
> one point.
>
> 1: Use distance-based blurring on the texture. Beyond a certain
[....]
> techniques to compute the color. One possible way to do this would be to
> fire a pair of slightly different rays (or maybe 3 rays?) and calculate
> the angle between them. The only disadvantage this would have would be
> speed.

You know, you can always construct scenes (intentionally), that will breake
this algo ...

I would simply try to create _VERY_ small structures...
either I will produce still moires or your algo would be simply inaccurate
...

basically you wil always have problems, with scenes that produce
moire-patterns ...

Post a reply to this message

In article <3c756fc2@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>> No, it won't help.  Mipmapping just moves the problem to a preprocessing
>> stage and in general is nearly pointless for raytracing.
>
>   If it works in scanline rendering, it can work in the exact same way in
> raytracing.

I did not say it can't work, I said it is pointless.  How do you think the
mipmaps are created?  What kind of "more advanced" interpolation does a paint
program use/support that will increase quality compared to POV-Ray image map
interpolation and adaptive antialiasing?  The answer is that there is no such
interpolation 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

Thanks to the ones who submitted scenes.

There are first test results of my new implemenations compared to the old 
ones:

See http://www.povworld.org/povray/aatest.html . Note that the servers 
bandwith is quite limited.

- Micha

Post a reply to this message

In article <3c73fc36@news.povray.org>, Micha Riser <mri### [at] gmxnet> 
wrote:

> I am experimenting with new antialiasing methods for povray. Now I am 
> looking for scenes where the current methods do a poor job or need too many 
> samples/pixels to produce a nice result. If you have such a scene which is 
> not too large (<100kB) and does not take hours to render please send it to 
> me (mri### [at] gmxnet) or post it to p.*.sf. I will then test if my new 
> implementations do better than the old ones.

BTW, looking through the old Ray Tracing News archives, there's plenty 
of information about this...one interesting method was to make a hash 
value from the objects intersected and shadow rays. If the hash value 
changed from one pixel to another, either the set of objects hit 
changed, or the image passed into/out of shadow. Then the colors were 
compared, and the pixel was only antialiased if the hash changed and the 
color was different. No antialiasing the tail of a black cat on a 
moonless night, but only object/shadow edges were antialiased. Sharp 
edges in the texture were left alone...these guys apparently didn't use 
textures with sharp edges. ;-)
This technique could be adapted to POV as a way of specifying different 
antialiasing parameters for object edges and textures...if the hash 
value triggers it, use one setting, but if the color difference is 
greater than a threshold (and the hash values are the same), use a 
different setting. If it could be further controlled...certain textures 
or objects using no antialiasing...it could make things like starfields 
much easier.

This reminds me...are the colors clipped before or after antialiasing? 
It should be after...a "superbright" object (rgb > 1) should contribute 
more to a pixel than a dim (rgb 1) one.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

> In article <3c73fc36@news.povray.org>, Micha Riser <mri### [at] gmxnet>
> wrote:
> This reminds me...are the colors clipped before or after antialiasing?
> It should be after...a "superbright" object (rgb > 1) should contribute
> more to a pixel than a dim (rgb 1) one.

IMHO it would be a _MAJOR_ design-flaw, if it wouldn't be this way ...

Post a reply to this message

> See http://www.povworld.org/povray/aatest.html . Note that the servers
> bandwith is quite limited.

So what can we conclude ?

1. These Scenes _are_ hard nuts for AA
2. Your method _CAN_ improve the visual quality by taking not to much  
samples ... (under circumstances)
2'. But it can also be that it makes the result even worse ...
2". The result depends on the choosen AA-Method; There's no "Best-Of" ...
3. POV Raytracing works in a diskreet world where it's hard to simulate  
the continueity of the pure math ...
... leading to:
4. proving (of course, not a mathiematical proove) right, with my former  
statement, that every known AA-Algo can be broken with a scene ...

... at least if you consider the resolution to be independend ...


BUT: Good work ... I think we needed something like that ...

Post a reply to this message

Christopher James Huff wrote:

> BTW, looking through the old Ray Tracing News archives, there's plenty
> of information about this...one interesting method was to make a hash
> value from the objects intersected and shadow rays. If the hash value
> changed from one pixel to another, either the set of objects hit
> changed, or the image passed into/out of shadow. Then the colors were
> compared, and the pixel was only antialiased if the hash changed and the
> color was different. No antialiasing the tail of a black cat on a
> moonless night, but only object/shadow edges were antialiased. Sharp
> edges in the texture were left alone...these guys apparently didn't use
> textures with sharp edges. ;-)

I do not like the idea of antialiasing only at objects frontiers.. as 
textures are certainly one of the most important thing with POV-Ray.

> This technique could be adapted to POV as a way of specifying different
> antialiasing parameters for object edges and textures...if the hash
> value triggers it, use one setting, but if the color difference is
> greater than a threshold (and the hash values are the same), use a
> different setting. If it could be further controlled...certain textures
> or objects using no antialiasing...it could make things like starfields
> much easier.

I do not know the povray source good enough for adding object specific 
features :(.

> This reminds me...are the colors clipped before or after antialiasing?
> It should be after...a "superbright" object (rgb > 1) should contribute
> more to a pixel than a dim (rgb 1) one.

I will look this up.

- Micha

Post a reply to this message

Jan Walzer wrote:

>> See http://www.povworld.org/povray/aatest.html . Note that the servers
>> bandwith is quite limited.
> 
> So what can we conclude ?
> 
> 1. These Scenes _are_ hard nuts for AA

Sure.

> 2. Your method _CAN_ improve the visual quality by taking not to much
> samples ... (under circumstances)
> 2'. But it can also be that it makes the result even worse ...

Well, my method is based on method 2, that is also adaptive. If you compare 
it with the standart method 2, my new implementations do always equally or 
better. (sure one could contruct a scene where this is not the case)

> 2". The result depends on the choosen AA-Method; There's no "Best-Of" ...

I have been a bit surprised how god method 1 actually performed.. as it is 
really simple.

> 3. POV Raytracing works in a diskreet world where it's hard to simulate
> the continueity of the pure math ...
> ... leading to:
> 4. proving (of course, not a mathiematical proove) right, with my former
> statement, that every known AA-Algo can be broken with a scene ...
> 
> ... at least if you consider the resolution to be independend ...

This is certainly true.. but the worst case scenario is here certainly not 
allowed to be the criterion.

> 
> 
> BUT: Good work ... I think we needed something like that ...

Thanks.

Post a reply to this message

"Christopher James Huff" wrote:
> This reminds me...are the colors clipped before or
> after antialiasing?
> It should be after...a "superbright" object (rgb > 1)
> should contribute more to a pixel than a dim (rgb 1) one.

It is clipped before AA and there's a good reason.

Suppose you have a really bright sphere (the sun). All pixels that hit the
sun would be completely white no matter if the sun occupies a small or big
amount of the pixel, simply because the high brightness would dominate in
the average. The result would be that very bright objects would not look
antialiased at all no matter how high quality AA settings you used.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

I'll be looking at this more closely tommorow. What little I see is very
promising. Thanks for taking my proposal seriously Micha! This should be
perfect for the next MegaPOV. :-D

Post a reply to this message

In article <3c782d3c@news.povray.org>,
 "Rune" <run### [at] mobilixnetdk> wrote:

> It is clipped before AA and there's a good reason.
> 
> Suppose you have a really bright sphere (the sun). All pixels that hit the
> sun would be completely white no matter if the sun occupies a small or big
> amount of the pixel, simply because the high brightness would dominate in
> the average. The result would be that very bright objects would not look
> antialiased at all no matter how high quality AA settings you used.

Well, this explains why I never succeeded in getting stars to survive AA 
by increasing their brightness...that was the exact effect I expected 
and wanted. I can manually soften the sun's outline (media, or a dimmer 
sphere visible just around its edges), eliminating the problem there, 
but there doesn't seem to be any way to compensate for small 
(sub-pixel), very bright objects getting obliterated by the antialiasing.
Maybe a smarter algorithm would be possible...if there are other 
high-brightness pixels nearby, you are at the edge of a bright object, 
so clip and supersample, otherwise supersample then clip.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <8JP### [at] lzernet>, jan### [at] lzernet (Jan Walzer) wrote:

> 4. proving (of course, not a mathiematical proove) right, with my former  
> statement, that every known AA-Algo can be broken with a scene ...

Just use an infinite number of samples per pixel. I don't have the CPU 
power to test this though, ask God. ;-)
Actually, that might not be enough, because you still have the grid of 
pixels...how about creating a neural net to detect the moire patterns 
and compensate for them?
Or just reduce the pixel size to near-microscopic. Then you won't even 
need antialiasing. ;-)
Really, I think resolutions are going to make a jump soon, so 
antialiasing won't be as big a requirement.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

"Christopher James Huff" wrote:
> Maybe a smarter algorithm would be possible...if
> there are other high-brightness pixels nearby,
> you are at the edge of a bright object, so clip
> and supersample, otherwise supersample then clip.

I have had similar considerations, but have not managed to get any further
than wondering what method could be used. I don't think it will be trivial,
and there'll always be cases where you get an opposite behavior of what you
want.

If a smart behavior isn't possible, I prefer the current one. The current
method works the same way as if you rendered the image at huge resolution
and then scaled it down.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Jan Walzer wrote:
> 
> > This reminds me...are the colors clipped before or after antialiasing?
> > It should be after...a "superbright" object (rgb > 1) should contribute
> > more to a pixel than a dim (rgb 1) one.
> 
> IMHO it would be a _MAJOR_ design-flaw, if it wouldn't be this way ...

In beta 11 ambient sphere of rgb 1 and rgb 100 produce the exact same
image when rendered with +am2 +a0.0 +j0.0. Also DOF produces
same image for both cases. The colors are clipped before aa
and DOF calculations :(


_____________
Kari Kivisalo

Post a reply to this message

Rune wrote:
>
> It is clipped before AA and there's a good reason.

It's not realistic.


_____________
Kari Kivisalo

Post a reply to this message

"Kari Kivisalo" wrote:
> Rune wrote:
> >
> > It is clipped before AA and there's a good reason.
>
> It's not realistic.

You can't talk about realistic. AA doesn't happen in nature... ;)

The current AA give the same result as if you rendered the image at a very
large resolution and then scaled it down. I think that's what AA is meant to
do. It gives smooth results. the way you'd like it to work, it wouldn't
always give smooth results, often things would look like they had not been
antialiased at all.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Rune wrote:
>
> You can't talk about realistic. AA doesn't happen in nature... ;)

Take a picture either with a film or ccd camera of a 10 candela source.
Compare that to picture of a 1000 candela source with same exposure.
You say they would look the same.

We are making _digital_ images. Even digital images of nature have
been subject to aa or lpf at some point. In real life the clipping
occurs at the image detector/film, not before. The aa/lpf operates
on the unclipped intensities. Would be hard to make it work the other
way around :)


_____________
Kari Kivisalo

Post a reply to this message

Wow. I'm impressed. Your new methods look very good. Can you conduct a few
tests on more complete scenes? It would also be nice if you could explain
how you acheived each one so some more discussion about them can be had.

Post a reply to this message

Tony[B] wrote:

> Wow. I'm impressed. Your new methods look very good. Can you conduct a few
> tests on more complete scenes? It would also be nice if you could explain
> how you acheived each one so some more discussion about them can be had.

If you have a particular scene that you want to have tested you can send it 
to me and I will test it. I still want to do some modifications to my 
implementations. Once I have finished that I will make a detailed 
explanation how they work.

Post a reply to this message

"Kari Kivisalo" wrote:
> We are making _digital_ images. Even digital images of
> nature have been subject to aa or lpf at some point.

Photos are not subject to antialiasing I think. They are subject to focal
blur and probably other types of blurring that I don't know about. (Is that
what lpf mean?) But blurring has nothing to do with antialiasing. Blurring
(in nature) is resolution independent and covers many pixels, while
antialiasing is highly resolution dependent and has to do with individual
pixels.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

OK. Cool. I'll see if I can find anything. I didn't have any specific one in
mind, I was just wondering how different a given scene would look.

Post a reply to this message

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

> You can't talk about realistic. AA doesn't happen in nature... ;)

But it is intended to calculate a specific thing (the color over the 
entire pixel), and clipping makes that less accurate. And it apparently 
also happens with focal blur...not good!
I'd gladly take having unantialiased edges on superbright objects to 
have them work properly in other cases...I can work around the first 
problem by adding information to the scene, I can't work around the 
second (currently existing) problem. :-(
It also seems unintuitive to me: you have a bunch of small stars, and 
antialiasing wipes them out because they don't cover whole pixels. You 
make them brighter to compensate...nothing happens?!?
And with focal blur, the problem is worse...you simply will get a less 
realistic image.
Maybe some flag to limit the max value of a sample...radiosity uses 
similar tricks.


> The current AA give the same result as if you rendered the image at a 
> very large resolution and then scaled it down.

Not really...you could render to a format with a larger dynamic range, 
like RGBE, and process with tools that can handle it. ;-)

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <3c782656@news.povray.org>, Micha Riser <mri### [at] gmxnet> 
wrote:

> I do not like the idea of antialiasing only at objects frontiers.. as 
> textures are certainly one of the most important thing with POV-Ray.

I wasn't suggesting that this be done. I was talking about a way of 
specifying different parameters for edge and texture AA.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

"Christopher James Huff" wrote:
> Rune wrote:
> > You can't talk about realistic.
> > AA doesn't happen in nature... ;)
>
> But it is intended to calculate a specific thing
> (the color over the entire pixel), and clipping
> makes that less accurate.

No, it's a definition issue. The current definition of AA in POV-Ray is that
it is intended to calculate the average clipped color over the entire pixel
and it does that 100% accurately according to the definition.

If you want to change the definition, that can be discussed, but the current
behavior is not flawed or inaccurate in any way as it does exactly what it's
intended to do.

> And it apparently also happens with focal blur...not good!

I agree there. Focal blur is a completely different issue, and it should
take the unclipped colors as input. (And then we could get cool lens effects
without "cheating"!)

BTW, as I see AA and focal blur as two separate things, I think it should be
possible to use both at the same time (though it would be slow). I have
never understood why it's not possible.

> I'd gladly take having unantialiased edges on superbright
> objects to have them work properly in other cases...

But I wouldn't. I want my AA to smooth edges without exception. That's what
AA is for. To average colors is not the goal, it's just a mean to reach the
goal. The goal is smooth edges.

> It also seems unintuitive to me: you have a bunch of
> small stars, and antialiasing wipes them out because
> they don't cover whole pixels. You make them brighter
> to compensate...nothing happens?!?

Exactly what would happen if you rendered the image at a large resolution
and then scaled it down. You get smooth results. If your very bright stars
covered several pixels each, they would be completely jaggy using your
method. To me that's not intuitive when I have turned on AA to get smooth
results.

> And with focal blur, the problem is worse...you simply will
> get a less realistic image.

I agree.

> Maybe some flag to limit the max value of a sample...

You mean that the user should be able to change the value that samples are
clipped to, which is currently one? I wouldn't mind as long as the current
behavior keeps being the default.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Rune <run### [at] mobilixnetdk> wrote:
> BTW, as I see AA and focal blur as two separate things, I think it should be
> possible to use both at the same time (though it would be slow). I have
> never understood why it's not possible.

  It's probably possible, but thought to be unnecessary.
  (However, it might give a better result if the focal blur is giving a
grainy result no matter what variance values you are giving.)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

>> Jan Walzer wrote:
>> IMHO it would be a _MAJOR_ design-flaw, if it wouldn't be this way ...

> In beta 11 ambient sphere of rgb 1 and rgb 100 produce the exact same
> image when rendered with +am2 +a0.0 +j0.0. Also DOF produces
> same image for both cases. The colors are clipped before aa
> and DOF calculations :(

/me doesn't like this ...

Post a reply to this message

"Warp" wrote:
>   It's probably possible, but thought to be unnecessary.

Yet it's a known fact that things very close to the focal point are jaggy.

And thinking about it, just like normally, the AA would only kick in where
necessary, so using normal AA settings together with focal blur would
probably only activate the AA on small amounts of the pixels, thus meaning
that it wouldn't even be much slower. (It's logical, I just didn't realize
it before.) I think it should be allowed. This is a feature request!

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Jan Walzer <jan### [at] lzernet> wrote:
>> In beta 11 ambient sphere of rgb 1 and rgb 100 produce the exact same
>> image when rendered with +am2 +a0.0 +j0.0. Also DOF produces
>> same image for both cases. The colors are clipped before aa
>> and DOF calculations :(

> /me doesn't like this ...

  So you prefer to have a white sphere which doesn't look antialiased at all?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Rune wrote:
>
> Photos are not subject to antialiasing I think.

Digital (sampled) photos are. To sample correctly a signal
the sampling frequency must be at least twice the maximum
signal frequency. The signal must be Low Pass Filtered before
sampling or the high frequncy components will be aliased or
mirrored around 0.5*sampling frequency and appear as low
frequency interference in the sampled signal. The term aliasing
comes from this. High frequency components appear as low
frequency components.

> But blurring has nothing to do with antialiasing.

In ccd cameras the obvious choice for LPF would be to defocus
the lens. This blurring limits the spatial frequency and
prevents aliasing. So blurring _is_ antialiasing and operates
on the unclipped signal. The blurred signal is then sampled and
clipped at the detector.


_____________
Kari Kivisalo

Post a reply to this message

In article <3c7924be@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   So you prefer to have a white sphere which doesn't look antialiased at all?

Yes.
Well, not precisely...a plain rgb 1 sphere with normal levels of 
lighting will render fine. But an object twice as bright should 
influence a pixel twice as much. You can work around a rgb 10 sphere not 
looking antialiased, you can't work around the values being clipped.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> In article <3c78cad6$1@news.povray.org>,
>  "Rune" <run### [at] mobilixnetdk> wrote:
>
> > You can't talk about realistic. AA doesn't happen in nature... ;)
>
> It also seems unintuitive to me: you have a bunch of small stars, and
> antialiasing wipes them out because they don't cover whole pixels.


No matter how many "superbright" stars you have, you will have many ~more~
dark sky samples.  The answer is not to make the stars brighter, but to make
them bigger.  Have them cover at least a pixel.

If you really wanted to, you could make each star between 1/2 - 3 pixels on
a 640x480 screen, and use media-filled spheres instead of plain white dots,
to give a nice glowing effect that wouldn't look bad on higher resolutions
:)

...Chambers


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.323 / Virus Database: 180 - Release Date: 2/8/2002

Post a reply to this message

> Jan Walzer <jan### [at] lzernet> wrote:
>>> In beta 11 ambient sphere of rgb 1 and rgb 100 produce the exact same
>>> image when rendered with +am2 +a0.0 +j0.0. Also DOF produces
>>> same image for both cases. The colors are clipped before aa
>>> and DOF calculations :(

>> /me doesn't like this ...

>   So you prefer to have a white sphere which doesn't look antialiased at
> all?

Yep ...
But IIRC it will get AA'ed if samples are taken long enough ...
I, for myself, also use normally +J1 ... (OK ... this should be sqrt(2))

... so I assume there would be a way, to make it "soft" if one wants to  
...

Post a reply to this message

> Exactly what would happen if you rendered the image at a large  
resolution
> and then scaled it down. You get smooth results. If your very bright stars
> covered several pixels each, they would be completely jaggy using your
> method. To me that's not intuitive when I have turned on AA to get smooth
> results.


I assume, you can get this result with P3.5, if you:

1) Scale the brightness of all lights/textures to fit into [0,1]
2) Render the image with an n-times higher resolution, using 16Bit
3) Rescale the image to the size, you want ...
4) make the brighness-adjustment of 1) reverse ...

this should avoid the "unwanted" clipping ...
And I think, this is what should happen, when using bright pigments ...

Post a reply to this message

"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> In article <3c7924be@news.povray.org>, Warp <war### [at] tagpovrayorg>
> wrote:
>
> >   So you prefer to have a white sphere which doesn't look antialiased at
all?
>
> Yes.
> Well, not precisely...a plain rgb 1 sphere with normal levels of
> lighting will render fine. But an object twice as bright should
> influence a pixel twice as much. You can work around a rgb 10 sphere not
> looking antialiased, you can't work around the values being clipped.

Having superbright objects influence their surroundings more than others
would mean, I believe, that ultrabright (>100?) objects would influence
larger and larger areas of the screen, which is not possible with the
current method.

Hmm, talking about color, how's this for an idea (warning: this is
tangential to the thread): store all image data as 64bit integers, with the
range 0-1 fitting in 24 or 32 bits.  Then, adjust the overall brightness of
the scene based on the brightest object?

...Chambers


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.323 / Virus Database: 180 - Release Date: 2/8/2002

Post a reply to this message

> If you really wanted to, you could make each star between 1/2 - 3 pixels  
on
> a 640x480 screen, and use media-filled spheres instead of plain white dots,
> to give a nice glowing effect that wouldn't look bad on higher resolutions

that _IS_ cheating ...
... just to have the AA work the way you want ...

Post a reply to this message

In article <3c7931d6@news.povray.org>,
 "Ben Chambers" <bdc### [at] yahoocom> wrote:

> Having superbright objects influence their surroundings more than others
> would mean, I believe, that ultrabright (>100?) objects would influence
> larger and larger areas of the screen, which is not possible with the
> current method.

Not at all. It will only influence a pixel which covers the object.


> Hmm, talking about color, how's this for an idea (warning: this is
> tangential to the thread): store all image data as 64bit integers, with the
> range 0-1 fitting in 24 or 32 bits.  Then, adjust the overall brightness of
> the scene based on the brightest object?

The brightness is already stored as single-precision floats, I don't see 
where this would help. And scaling the colors so the brightest object is 
rgb 1 won't work very well...it is too linear, and you will end up with 
some objects being white and everything else being nearly black. And 
antialiasing will still wipe out small details.
The clipping will eventually need to be done, because monitors have a 
finite dynamic range, but it shouldn't be done before antialiasing in my 
opinion. Really, there should be a way to output more accurate colors to 
the final image file, there are a few formats designed for this.
A smarter antialiasing scheme should be possible, which would soften 
jagged edges but leave points and small details alone.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <3c792f95@news.povray.org>,
 "Ben Chambers" <bdc### [at] yahoocom> wrote:

> No matter how many "superbright" stars you have, you will have many ~more~
> dark sky samples.  The answer is not to make the stars brighter, but to make
> them bigger.  Have them cover at least a pixel.

That just doesn't look good at ordinary resolutions. The result only 
slightly resembles stars. If the values were unclipped, you could make 
sure that the stars were sub-pixel at all but extremely high 
resolutions, but crank up their brightness.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote:
> Not at all. It will only influence a pixel which covers the object.

  This depends on whether we want a "mathematically correct" image or
if we want to simulate photography.
  In photography a really bright object will "bleed" in the image, and its
influence can extend considerably outside its real boundaries.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Jan Walzer <jan### [at] lzernet> wrote:
> Yep ...
> But IIRC it will get AA'ed if samples are taken long enough ...

  I don't think so.
  If the border of the bright object takes one half of the current pixel,
about a half of the samples will hit the object. If the object contributes
10 times more than the other half of the pixel, it will dominate the color
of the pixel with a factor of 10:1 (which means that the other half of
the pixel can diminish the color of the pixel only by 1/10, even though
its area is 1/2 of the pixel).

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp wrote:

>   I don't think so.
>   If the border of the bright object takes one half of the current pixel,
> about a half of the samples will hit the object. If the object contributes
> 10 times more than the other half of the pixel, it will dominate the color
> of the pixel with a factor of 10:1 (which means that the other half of
> the pixel can diminish the color of the pixel only by 1/10, even though
> its area is 1/2 of the pixel).

It will give a solution (nearly)equal to

http://news.povray.org/8JTVb%2BOd4xB%40lzer.net

which is IMO the way AA should work ...
at least I would like to hava a switch, controlling this behaviour ...
You can also use the Jitter to select the set of points, which contribute  
to the pixel ... set it to sqrt(2) and you should have a fairly good AA- 
effect ... (if only I could hack a POV-Patch ...)

Remember: Clipping means loosing information ... We should throw away this
information only if we have finished processing the image ...
Don't argue with: "AA also means loosing Information" ...

true, but AA is what we want ...
But we (at least me) don't really want clipping... we just use it, because  
of the limits of our graphics-hardware and fileformats ...

I wished my monitor could present pixels in a color of <1024,1024,1024>,  
when <255,255,255> is normal white ...

Is there any way to convince you ?

BTW: if the behaviour would have any chance of beeing changed, consider,  
for the sake of consistency, to do this as well for negative values, not  
only for positves ...
so a 50%-AA combination of <10,1,0> and <0,-10,0> would give <1,0,0> after  
clipping and not <0.5,0.5,0>

Post a reply to this message

In article <3c7941af@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   This depends on whether we want a "mathematically correct" image or
> if we want to simulate photography.
>   In photography a really bright object will "bleed" in the image, and its
> influence can extend considerably outside its real boundaries.

That's not what antialiasing is for...it is to counteract aliasing.

Such a glow effect would still be useful, and would pretty much have to 
be built-in unless POV is patched to output a high dynamic range format. 
One possibility is to make it part of a post-processing stage, similar 
in purpose to the MegaPOV patch but more flexible. (if such a 
post_process stage is available, it would be simple to add a filter to 
soften the edges of bright objects...people would probably just use the 
glow filter though)
(MegaPOV has a glow filter, but I don't think it does the exact same 
thing)

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

"Christopher James Huff" wrote:
> That's not what antialiasing is for...it is to counteract aliasing.

But what if you have a pattern with two colors - black and an extremely
bright white - and the pattern is aliased... What will your version of
antialiasing do about it? Nothing!

Let's repeat the message: We have antialiasing to counteract aliasing. That
is what it should do.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

"Jan Walzer" <jan### [at] lzernet> wrote in message news:8JT### [at] lzernet...
> > If you really wanted to, you could make each star between 1/2 - 3 pixels
> on
> > a 640x480 screen, and use media-filled spheres instead of plain white
dots,
> > to give a nice glowing effect that wouldn't look bad on higher
resolutions
>
> that _IS_ cheating ...
> ... just to have the AA work the way you want ...

But wouldn't it be cool to have several thousand media filled spheres added
to your scene? :)

...Chambers


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.323 / Virus Database: 180 - Release Date: 2/8/2002

Post a reply to this message

In article <3c79887d@news.povray.org>, run### [at] mobilixnetdk 
says...

> But what if you have a pattern with two colors - black and an extremely
> bright white - and the pattern is aliased... What will your version of
> antialiasing do about it? Nothing!

If somebody wants such a bright object in his scene, he'll need some kind 
glowing effect (wich will hide the aliasing) around it or it won't look 
right anyway.

Lutz-Peter

Post a reply to this message

"Lutz-Peter Hooge" wrote:
> If somebody wants such a bright object in his scene,
> he'll need some kind glowing effect

No he don't. I have made scenes with very bright object where I wanted
antialiasing but no glowing. I don't need glowing just because you say so.

> or it won't look right anyway.

You don't define what looks right or wrong. When bright objects glow it's
actually caused by focal blurring or something similar, but I have scenes
where I don't want such a glow. Things shouldn't glow unless I tell them to.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

On Sun, 24 Feb 2002 17:54:40 +0100, Rune wrote:
> "Warp" wrote:
>>   It's probably possible, but thought to be unnecessary.
> 
> Yet it's a known fact that things very close to the focal point are jaggy.
> 
> And thinking about it, just like normally, the AA would only kick in where
> necessary, so using normal AA settings together with focal blur would
> probably only activate the AA on small amounts of the pixels, thus meaning
> that it wouldn't even be much slower. (It's logical, I just didn't realize
> it before.) I think it should be allowed. This is a feature request!

I think it's not allowed because the render loop for focal blur is a different
loop than the one for AA.  That's mostly historical, but it'd be hard to 
change.

-- 
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker

Post a reply to this message

What focal blur work with animation? I haven't checked the povray source
code, but maybe it doesn't "remember" what rays it casted during the
tracing. If would put the exact data about what rays it's casted in a
buffer-like thing, with that buffer it should be possible to do
antialiasing. Same thing with animations. Saving that buffer to disk and
reusing it for the next frame should be able to prevent any jittering.

But maybe I'm completely wrong. I didn't try focal blur with animations that
much and I haven't checked povray's source code.

--
Apache
http://geitenkaas.dns2go.com/experiments/
apa### [at] yahoocom

Post a reply to this message

["Apache" <apa### [at] yahoocom>]
| What focal blur work with animation? I haven't checked the povray source
| code, but maybe it doesn't "remember" what rays it casted during the
| tracing. If would put the exact data about what rays it's casted in a
| buffer-like thing, with that buffer it should be possible to do
| antialiasing. Same thing with animations. Saving that buffer to disk and
| reusing it for the next frame should be able to prevent any jittering.

Err. Jittering is optional. Simply don't use it in animation.

-- 
It's a dark day for mad science.

Post a reply to this message

I'm not talking about the jittering possibility available with +j, but about
the loose pixels that are visible when using focal blur. Don't those focal
blur pixels show a jitter-like behaviour when animating? If they do,
increasing the amount of focal blur samples will fix it anyways (needs more
processing time though).

Regards.
--
Apache
http://geitenkaas.dns2go.com/experiments/
apa### [at] yahoocom

Post a reply to this message

In article <3c863416$1@news.povray.org>,
 "Apache" <apa### [at] yahoocom> wrote:

> What focal blur work with animation? I haven't checked the povray source
> code, but maybe it doesn't "remember" what rays it casted during the
> tracing. If would put the exact data about what rays it's casted in a
> buffer-like thing, with that buffer it should be possible to do
> antialiasing. Same thing with animations. Saving that buffer to disk and
> reusing it for the next frame should be able to prevent any jittering.

This can't be done, because not only would it require a huge amount of 
memory, focal blur is adaptive. Since the scene being blurred changes, 
the blur samples need to change as well. You could just remove the 
adaptive capability, but that would be very slow. It should be possible 
to generate a list of random jitter vectors and use those for all pixels 
in every frame...the number of samples might vary, but most of the 
samples will be the same. This would give smoother results, actually, 
since the samples won't vary as much from pixel to pixel, though it 
might produce visible artifacts.
For now, you are pretty much stuck with using high enough settings that 
the grainyness isn't a problem.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message