Hi,

The attached code is my first attempt to convolve a pigment.. Don't expect
it to look good, please..

I think POV would benefit from having internal blurring routines.. There are
many routines to create procedural textures and we've also begun to
pigmentize objects and use pigments as functions.. Blurring would come in
handy.. I tried the other day with 255 averaged pigments but that's not good
enough.. It makes strange things sometimes, and in connection with
isosurfaces it better be more than 8-bit.

I searched on www.google.com to learn how to code gaussian blur, and I got
this far in SDL, this morning.. Unfortunately I never learned C, but I think
it would be easy to implement blur code there.. My routine is too slow to be
useful, though it might be possible to optimise, I don't know?  I also don't
know how to increase the amount of blur yet! Heeh, I thought it would work
with a bigger matrix, but that just seems to affect the blur quality.

But it might be that someone here will agree that POV would benefit from an
internal convolution matrix.


Regards,
Hugo

Post a reply to this message

Attachments:
Download 'Convolution-blur.pov.txt' (4 KB)

Hugo wrote:
> 
> Hi,
> 
> The attached code is my first attempt to convolve a pigment.. Don't expect
> it to look good, please..

First of all, please don't post binary attachments in this group, they
belong to povray.binaries.scene-files.  

> I think POV would benefit from having internal blurring routines.. There are
> many routines to create procedural textures and we've also begun to
> pigmentize objects and use pigments as functions.. Blurring would come in
> handy.. I tried the other day with 255 averaged pigments but that's not good
> enough.. It makes strange things sometimes, and in connection with
> isosurfaces it better be more than 8-bit.

This method will not allow using chekcer etc. in isosurface functions
anyway.  Even with high numbers of samples there will be steps (although
they can be invisible when you use it in a texture).

> I searched on www.google.com to learn how to code gaussian blur, and I got
> this far in SDL, this morning.. Unfortunately I never learned C, but I think
> it would be easy to implement blur code there.. My routine is too slow to be
> useful, though it might be possible to optimise, I don't know?  I also don't
> know how to increase the amount of blur yet! Heeh, I thought it would work
> with a bigger matrix, but that just seems to affect the blur quality.

As already said, you should have a look at previous work on this matter. 
The results of Chris Huff's most recent experiments can be found in:

Subject: Smoothly Blurred Patterns - blur2.jpeg (1/1)
Date: Mon, 05 Mar 2001 12:23:44 -0500
From: Chris Huff <chr### [at] maccom>
Newsgroups: povray.binaries.images

And my own in:

http://www.schunter.etc.tu-bs.de/~chris/povcyg/docu/docu_pattern01.html#BLUR

function patterns should allow to implement both methods in SDL.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

> First of all, please don't post binary attachments in this group, they
> belong to povray.binaries.scene-files.

Oh, I'm sorry.. I thought only pictures were banned due to size.. Well, I'll
remember.

> This method will not allow using chekcer etc. in isosurface functions
> anyway.  Even with high numbers of samples there will be steps (although
> they can be invisible when you use it in a texture).

I see.. I thought gaussian blur would be useful because it's so big in
effect, and fast in assembly code.

> As already said, you should have a look at previous work on this matter.

I did.. I remember the different approches to reflection blur.. They all
shot additional rays and was not meant for blurring a simple bitmap..
However I didn't notice Chris's blurred pattern-posts until now.. Thanks..
Maybe this will find it's way into the next Pov version.. Anyway I learned
today how to code a convolution matrix.. I'm just amazed it works SO slow in
SDL.. In machine code, it's real-time for a fullscreen picture.

Regards,
Hugo

Post a reply to this message

Hugo wrote:
> 
> > First of all, please don't post binary attachments in this group, they
> > belong to povray.binaries.scene-files.
> 
> Oh, I'm sorry.. I thought only pictures were banned due to size.. Well, I'll
> remember.

Put simply, a binary is any file that is not a plain text file. For our
newsgroup purposes, the following are examples of binary files:

- JPEGs, or other graphic file formats,

- HTML-encoded text (many people who follow our newsgroups use
  newsreaders that cannot automatically read HTML posts without
  launching an external Web browser. Please post plain text messages or,
  at least a combination of plain text and HTML),

- any executable file,

- any other file that is sent as an attachment to a posted message, even
    if it is readable text. This includes POV-Ray scene (.pov) files
    sent as message attachments.

For the sake of newsgroup organization we ask that you post binary
attachments to the appropriate groups, such as:

- images to "povray.binaries.images",

- animations to "povray.binaries.animations",

- program utilities to "povray.binaries.utilities", and

- any attached scene files, whether text or binaries, to
     "povray.binaries.scene.files".

Simple POV-Ray (.pov) scene files, text include files, and text macros
may be 'cut and pasted' into the body of your message and posted in the
group "povray.text.scene.files". Please be reasonable and don't paste a
10mb mesh include file into the body of a message :) If your scene
source needs to be this large then you might consider providing a .url
so that people may download it from a remote location.

If you post an image to a binary group and then decide to provide the
scene source (due to overwhelming demand), post the source in the
appropriate binary (for attachments) or text (when your source is typed
or pasted into the body of your message) group and make a reference to
your posted image in the subject line.

Please consider converting 24-bit bitmap images, such as targas and
Windows .bmp, to JPEG (.jpg) file format which uses a compression
algorithm to reduce the file size considerably. This conserves space on
the news.povray.org server for everyone.

Animations can be of various popular file formats such as Windows .avi,
.fli, MPEG, or Apple QuickTime, but one should consider that some
animation formats may not be viewable on all platforms and therefore may
not reach as wide of an audience. Again, using an available compression
scheme with your animation program will benefit all who use this server
by conserving disk space.

  Thank you all for your consideration and happy raytracing!
-- 
Alan

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
: If you post an image to a binary group and then decide to provide the
: scene source (due to overwhelming demand), post the source in the
: appropriate binary (for attachments) or text (when your source is typed
: or pasted into the body of your message) group and make a reference to
: your posted image in the subject line.

  I don't understand why the scene source can't be posted in the same group
(and the same thread) as the original image. (I have don't that several times
and nobody has complained; I think nobody has any reason to do so...)

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

Post a reply to this message

On 7 Dec 2001 11:18:20 -0500, Warp wrote:
> Ken <tyl### [at] pacbellnet> wrote:
>: If you post an image to a binary group and then decide to provide the
>: scene source (due to overwhelming demand), post the source in the
>: appropriate binary (for attachments) or text (when your source is typed
>: or pasted into the body of your message) group and make a reference to
>: your posted image in the subject line.
> 
>   I don't understand why the scene source can't be posted in the same group
> (and the same thread) as the original image. (I have don't that several times
> and nobody has complained; I think nobody has any reason to do so...)

Well, it depends on what the source is.  If it's a general-purpose technique
that just happens to be represented by the image, it makes a lot more sense
to put it in a scene-files group.  But that's just my opinion.

-- 
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg

Post a reply to this message

>   I don't understand why the scene source can't be posted in the same
group
> (and the same thread) as the original image. (I have don't that several
times
> and nobody has complained; I think nobody has any reason to do so...)

Searching for scene files is easier to do in the related groups because they
contain much less messages (<3000) than binaries.images (>36000). I don't
"read" the scene file groups but I sure use them as a library of tips and
tricks.

G.

--

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

On Fri, 7 Dec 2001 17:40:24 +0100, Gilles Tran wrote:

>>   I don't understand why the scene source can't be posted in the same
> group
>> (and the same thread) as the original image. (I have don't that several
> times
>> and nobody has complained; I think nobody has any reason to do so...)
> 
> Searching for scene files is easier to do in the related groups because they
> contain much less messages (<3000) than binaries.images (>36000). I don't
> "read" the scene file groups but I sure use them as a library of tips and
> tricks.

You should "read" them.  Some of my best tricks haven't been posted anywhere
else.

--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}

Post a reply to this message

> You should "read" them.  Some of my best tricks haven't been posted
anywhere
> else.

Be sure I know :) That was my point in fact : I can browse the scene-file
groups once in a while because I know the good stuff there can be found
easily just by looking at the headers (which are usually self-explanatory).
Finding a snippet of code posted 3 months ago in a p.b.i thread is a little
more difficult, even when one knows it's there.

G.

--

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

Warp wrote:

>   I don't understand why the scene source can't be posted in the same group
> (and the same thread) as the original image. (I have don't that several times
> and nobody has complained; I think nobody has any reason to do so...)

I think Gilles summed it up well. Besides, Alan says so, that's why.

-- 
Ken Tyler

Post a reply to this message