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