 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I posted a patch adding bicubic interpolation to image_maps
to .binaries.programming.
A few things to discuss:
1) It is enabled with "interpolation 3"
In image.h this is/was mapped to CUBIC_SPLINE, but wasn't implemented
until now. Now the question is: is bicubic interpolation the same as
cubic spline interpolation? Should interpolation 3 be used for
bicubic, or should it be leaved reserved for some other interpolation?
2) cubic interpolation can possibly return values outside the
[0..1] range.
Do these values need to be clipped? IMHO not for values >1 (colors >1
are allowed anyway), but what about <0?
Do I have to worry about this, or are the values already clipped
somewhere else where needed?
3) Currently the matrix with determines the coefficients for the
cubic interpolation function is hardcoded. Would it make sense
to let the user specifiy a different one?
for example like this:
image_map
{
sys "somepic"
interpolation 3
matrix <-0.5, 1.5, -1.5, 0.5,
1.0, -2.5, 2.0, -0.5,
-0.5, 0.0, 0.5, 0.0,
0.0, 1.0, 0.0, 0.0>
}
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3ee67833$1@news.povray.org>,
Lutz-Peter Hooge <lpv### [at] gmx de> wrote:
> 1) It is enabled with "interpolation 3"
> In image.h this is/was mapped to CUBIC_SPLINE, but wasn't implemented
> until now. Now the question is: is bicubic interpolation the same as
> cubic spline interpolation? Should interpolation 3 be used for
> bicubic, or should it be leaved reserved for some other interpolation?
I'd just use type 3 for bicubic. If something else was originally
planned, it was so long ago that it makes no difference, and it fits in
with existing ones nicely. (similarly, light sources used to have a
"track" keyword, but it never did anything)
Another nice patch would be to allow keywords to be used instead of
numeric identifiers.
> 2) cubic interpolation can possibly return values outside the
> [0..1] range.
> Do these values need to be clipped? IMHO not for values >1 (colors >1
> are allowed anyway), but what about <0?
> Do I have to worry about this, or are the values already clipped
> somewhere else where needed?
I would leave them unclipped. Code that needs clipped values will clip
them itself, intermediate values that go out of the usual range are fine.
> 3) Currently the matrix with determines the coefficients for the
> cubic interpolation function is hardcoded. Would it make sense
> to let the user specifiy a different one?
>
> for example like this:
> image_map
> {
> sys "somepic"
> interpolation 3
> matrix <-0.5, 1.5, -1.5, 0.5,
> 1.0, -2.5, 2.0, -0.5,
> -0.5, 0.0, 0.5, 0.0,
> 0.0, 1.0, 0.0, 0.0>
> }
Are those coefficients random? I can't figure out any order to them.
Maybe this would have some use, but can't think of any. Any special
effects this makes possible?
--
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 <cja### [at] earthlinknet> wrote:
> I'd just use type 3 for bicubic. If something else was originally
> planned, it was so long ago that it makes no difference, and it fits in
> with existing ones nicely.
Then IMHO CUBIC_SPLINE should be renamed to BICUBIC.
(Or BILINEAR to LINEAR_SPLINE)
> I would leave them unclipped. Code that needs clipped values will clip
> them itself, intermediate values that go out of the usual range are fine.
Ok.
> Are those coefficients random?
No, they are those used in the patch.
You get them by putting constraints to the cubic function,
then solving for the cofficients.
The constraints I used where:
-the interpolation should go through the original points
-the derivative at the edges of each segment is the
arithmetic mean of the two derivatives that linear interpolation
would have left and right of that point
(sounds complicated, is simple).
You geht the cubic interpolation function out of the matrix M and
the four sample points like this (^t means: transposed):
(x^3,x^2,x,1) * (M * (f1,f2,f3,f4)^t)
> Maybe this would have some use, but can't think of any. Any special
> effects this makes possible?
At least it should be possible to replicate linear and quadratic
interpolation with it.
But I think it is also possible to modify the matrix to get a sharper
image (with the tradeoff of getting more grid artifacts)
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3ee693b7$1@news.povray.org>,
Lutz-Peter Hooge <lpv### [at] gmxde> wrote:
> > I'd just use type 3 for bicubic. If something else was originally
> > planned, it was so long ago that it makes no difference, and it fits in
> > with existing ones nicely.
>
> Then IMHO CUBIC_SPLINE should be renamed to BICUBIC.
> (Or BILINEAR to LINEAR_SPLINE)
Well, it's not used anywhere, so might as well.
> > Are those coefficients random?
>
> No, they are those used in the patch.
>
> You get them by putting constraints to the cubic function,
> then solving for the cofficients.
Hmm...I was looking at it as something similar to a convolution matrix,
and expected something symmetrical. I'll have to look at the code to
figure out what the pattern is.
> > Maybe this would have some use, but can't think of any. Any special
> > effects this makes possible?
>
> At least it should be possible to replicate linear and quadratic
> interpolation with it.
But a direct implementation would be faster, right?
> But I think it is also possible to modify the matrix to get a sharper
> image (with the tradeoff of getting more grid artifacts)
That may be useful, but I personally think if the image is low-res
enough for that to be an issue, a higher resolution image is the best
solution. You could use a more computationally intensive algorithm to
resize it outside of POV and use one of the cheap ones for rendering.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lutz-Peter Hooge wrote:
> I posted a patch adding bicubic interpolation to image_maps
> to .binaries.programming.
The matrix stated in the description (from image.cpp)
>* DESCRIPTION
>* calculates the interpolation between f[1] and f[2] at position x
>* using the cubic function given by:
>*
>* ( [-0.5 1.5 -2.5 0.5 ] [f[0]] )
>* [x^3, x^2, x, 1] * ( [ 1.0 -2.5 2.0 -0.5 ] * [f[1]] )
>* ( [-0.5 0.0 0.5 0.0 ] [f[2]] )
>* ( [ 0.0 1.0 0.0 0.0 ] [f[3]] )
>*
does not correspond to the code
>static DBL interp_cubic(DBL f[4], DBL x)
>{
> DBL val;
> val=(-0.5*f[0] + 1.5*f[1] - 1.5*f[2] + 0.5*f[3])*x*x*x
> +( 1.0*f[0] - 2.5*f[1] + 2.0*f[2] - 0.5*f[3])*x*x
> +(-0.5*f[0] + 0.5*f[1] )*x
> +( 1.0*f[1] );
> return(val);
>}
>
It seems that the code implements the other matrix:
( [-0.5 1.5 -1.5 0.5 ] [f[0]] )
[x^3, x^2, x, 1] * ( [ 1.0 -2.5 2.0 -0.5 ] * [f[1]] )
( [-0.5 0.5 0.0 0.0 ] [f[2]] )
( [ 0.0 1.0 0.0 0.0 ] [f[3]] )
Is it just a typing mistake or ?
>A few things to discuss:
>
>3) Currently the matrix with determines the coefficients for the
>cubic interpolation function is hardcoded. Would it make sense
>to let the user specifiy a different one?
It would be more convenient to have a choice, of course with some
default matrix hardcoded.
Gleb
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 11 Jun 2003 02:30:49 +0200, Lutz-Peter Hooge <lpv### [at] gmxde> wrote:
> In image.h this is/was mapped to CUBIC_SPLINE
This is something I would prefer changed. I recently patched a lot of splines
and other features and it made difficulties to include files image.h, splines.h,
lathe.h, prism.h, sphsweep.h and iirc some others at the same time. I would
prefered enumerated characteristics in frame.h and consistent usage of keywords
in parser instead of numerical values. But making a patch for it is imo useless
because numerical values have to be supported for compatibility with 3.5 and
this would decomposite writing/reading/comparing sources.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
While we are at it, how about implementing some kind of trilinear and
tricubic mapping?
Naturally the only problem to solve is what mipmap to use for reflected
and refracted rays (for direct camera rays it is trivial, as the formula
to choose the mipmap is the same as with scanline rendering). Perhaps the
total length of the rays traced so far for the current pixel could be a
good heuristic...
For those who don't know what trilinear/tricubic mapping is, here's an
explanation:
Bilinear/bicubic mapping helps smoothing pixelation when image map
samples are needed from between the image map pixels. This is done by
interpolating between the 4/16 pixels around the point we want the color
from.
However, this works ok only when the image map pixels are larger than
the rendered image pixels. When the image map pixels are smaller,
bilinear/bicubic mapping doesn't help: You get moire artifacts.
Mipmapping is a technique to avoid these moire artifacts.
It's idea is that smaller versions of the original image map are calculated
by averaging pixels (the first mipmap is 1/4 of the size of the original, the
second mipmap is 1/4 of the size of the first mipmap and so on). When a
sample of the image map is needed, it's taken from the largest mipmap which
pixels are larger or equal to the rendered image pixels (there's a simple
formula to calculate this). Bilinear/bicubic interpolation is used normally
on this mipmap (or the original image if its pixels are large enough). This
gets completely rid of the moire effects.
But mipmapping alone is not enough. If you use mipmapping only, you will
get clearly visible lines in the texture where there's a change in mipmap.
This can be even worse than the moire effects.
To solve this, we don't take just one mipmap, but we also take the next
mipmap smaller than the chosen one, take the sample from it as well, and
then interpolate between these two samples (linear interpolation is sufficient
in this case). The "distance" between mipmaps can be calculated with the
same formula as the one mentioned above to choose which mipmap to use.
This is called trilinear or tricubic mapping (depending on whether we are
using bilinear or bicubic sampling) and results in a completely smooth
texturing with no moire effects nor pixelation.
(However, to be frank, the paragraph above is untrue: If you look at the
textured surface from a very small angle, you can still get moire effects,
but this is caused by a slightly different reason. There's a solution for
this problem as well: anisotropic filtering. However, this filtering may
be quite complicated to implement (I don't really know how it works). OTOH
this artifact is seldom a real problem.)
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11 Jun 2003 06:15:33 -0400, Warp <war### [at] tagpovrayorg> wrote:
> While we are at it, how about implementing some kind of trilinear and
> tricubic mapping?
Isn't this already available in
http://staff.aist.go.jp/r-suzuki/e/povray/iso/df_body.htm
? Do you mean some different applications ?
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
gk <g_k### [at] mail333com> wrote:
> >* DESCRIPTION
> >* calculates the interpolation between f[1] and f[2] at position x
> >* using the cubic function given by:
> >*
> >* ( [-0.5 1.5 -2.5 0.5 ] [f[0]] )
^^^
Typo. Should read -1.5.
> > DBL val;
> > val=(-0.5*f[0] + 1.5*f[1] - 1.5*f[2] + 0.5*f[3])*x*x*x
> > +( 1.0*f[0] - 2.5*f[1] + 2.0*f[2] - 0.5*f[3])*x*x
> > +(-0.5*f[0] + 0.5*f[1] )*x
^^^^
Aargh. :-/
Another Typo. Should be f[2]. Indentation is correct here.
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> to choose the mipmap is the same as with scanline rendering). Perhaps the
> total length of the rays traced so far for the current pixel could be a
> good heuristic...
I don't think so. It would be correct for a reflection on a plane, but
totally wrong for a reflection on a small sphere.
To make it correct the 'width' of the ray would be needed, and to
calculate (an approximation of) this, the curvature of the reflective/
refractive surface at the intersection point would be needed.
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3ee6c543@news.povray.org> , gk <g_k### [at] mail333com> wrote:
>Date: Wed, 11 Jun 2003 12:59:06 -0600
>From: gk <g_k### [at] mail333com>
Hi,
Please correct your system clock and/or timezone. It is ahead of the rest
of the world.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lutz-Peter Hooge wrote:
> 1) It is enabled with "interpolation 3"
> In image.h this is/was mapped to CUBIC_SPLINE, but wasn't implemented
>
What about introducing string names as alternatives to the numeric
values? Then one could prevent ambiguities and make the scene file more
readable. The numeric values can still be accepted, too.
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ABX <abx### [at] abxartpl> wrote:
> Isn't this already available in
> http://staff.aist.go.jp/r-suzuki/e/povray/iso/df_body.htm
No, that's df3 interpolation. I talk about image map interpolation.
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Mipmapping is a technique to avoid these moire artifacts.
NO NO NO! Not mip mapping in POVRay! Mip mapping ruins the image. Whenever I
play any of the Quake-based games, I turn it off. I think things look a lot
better without it. I'd rather have the shimmering, than the blurriness.
Now, how about including Trilinear/Tricubic interpolation for use with voxel
objects?
Rohan _e_ii
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <cja### [at] earthlinknet> wrote:
> But a direct implementation would be faster, right?
Of course.
> > But I think it is also possible to modify the matrix to get a sharper
> > image (with the tradeoff of getting more grid artifacts)
I experimented a bit with it. At least blur and sharpen is possible.
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rohan Bernett <rox### [at] yahoocom> wrote:
> NO NO NO! Not mip mapping in POVRay! Mip mapping ruins the image.
Strange claim.
Trilinear filtering is closer to the photographic phenomenon than the
plain bilinear filtering. In other words, it's more photorealistic.
In the real world, when you scan a photograph (or take a photo with a
high-quality digital camera), one pixel will be the average of all the
colors inside the pyramid which goes through that pixel towards the scene.
This is exactly what trilinear filtering simulates: It averages all the
texture pixels which fall into this pyramid to get the pixel color.
That is, if 40 of the texture pixels are inside that singe image pixel,
the average of all those 40 pixels is calculated there (as would happen
with a photograph).
In regular bilinear filtering this does not happen. Instead of taking
into account all the 40 texture pixels, it takes 4. All the other 36
texture pixels are simply ignored.
You can imagine that if the texture has very fine details, this causes
really bad moire effects.
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3ee7479b$1@news.povray.org>,
Lutz-Peter Hooge <lpv### [at] gmxde> wrote:
> I don't think so. It would be correct for a reflection on a plane, but
> totally wrong for a reflection on a small sphere.
> To make it correct the 'width' of the ray would be needed, and to
> calculate (an approximation of) this, the curvature of the reflective/
> refractive surface at the intersection point would be needed.
You need to track the ray footprint, it's called differential ray
tracing. If I remember right, Ron Parker was talking about this a few
years ago, but never got it added to POV.
http://graphics.stanford.edu/papers/trd/
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.3ee7f5f8d02fbf4518ccf4f70@news.povray.org>,
"Rohan Bernett" <rox### [at] yahoocom> wrote:
> > Mipmapping is a technique to avoid these moire artifacts.
>
> NO NO NO! Not mip mapping in POVRay! Mip mapping ruins the image. Whenever I
> play any of the Quake-based games, I turn it off. I think things look a lot
> better without it. I'd rather have the shimmering, than the blurriness.
Mip-mapping is simply a way to more cheaply do supersampling. Small
details can not be represented by the pixels, so the details in each
pixel are blended together. The final image has more information, not
less, and is a more realistic representation of what the eye or a camera
would see. You might as well be ranting against the use of antialiasing.
--
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:
> Mip-mapping is simply a way to more cheaply do supersampling. Small
> details can not be represented by the pixels, so the details in each
> pixel are blended together. The final image has more information, not
> less, and is a more realistic representation of what the eye or a camera
> would see. You might as well be ranting against the use of antialiasing.
Both AA and MM have their advantages and drawbacks. Many a time I have
lamented the severe AA settings I had to use to get rid of strait edge
stair stepping only to see my textures and other geometry related details
suffer as a result.
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>Both AA and MM have their advantages and drawbacks. Many a time I have
>lamented the severe AA settings I had to use to get rid of strait edge
>stair stepping only to see my textures and other geometry related details
>suffer as a result.
Hear Hear!
Rohan _e_ii
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The next version of my patch is available:
-interpolation matrix support
-some small modifications to pvengine.c and windows/config.h
so it can be compiled with MingW.
<http://www.lutz-peter.hoogi.de/extern/lppov_usr.zip>
Win32 executable (MingW) and sample scenes
<http://www.lutz-peter.hoogi.de/extern/lppov_diff.zip>
Just the changed files needed to apply the patch to megapov 1.0
<http://www.lutz-peter.hoogi.de/extern/lppov_src.zip>
Full source code (minus support libs) including makefiles for
MingW (windows and windows console) and BCC 5.5
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
