On Sat, 3 Jun 2006, Sivakatirswami <[EMAIL PROTECTED]> wrote:
You people all amaze me... are there no limits? (smile)
Question (duh type): are these filters limited to image data that is
an exact square? (implied by "3X3" "7X7")
Or, would a "filter" that supports 7 X 7 also handle an image that
was, for example, 345 pixels wide and 500 pixels tall? I assume the
answer is yes, but wanted to check.
The answer is indeed yes. The size of of the filter matrix is totally
unrelated to the size of the image to be processed. In Chipp Walter's
original scripts the height and the width of the image are among the
parameters that are assembled before the matrix formula (with a DLL or
completely scripted) is being applied. In my adapted versions I use an
image size of 640 X 480 pixels, but they could easily be changed to work
for other sizes.
The matrix-filter size defines the number of pixels involved in
computing the color value of the center pixel. With a 3 X 3 matrix, the
color values of the eight pixels surrounding the center pixel - along
with a so-called "division" factor and optionally a "bias" factor - are
processed by means of a specific formula to arrive at the new value for
the center pixel. This process is repeated for each image pixel.
Similarly, a 7 X 7 matrix would use 48 surrounding pixels to compute a
filtered value of the center pixel. The greater the matrix, the more
variable effects in changing an image with a filter are possible.
Border and corner pixels pose a special problem as they have less
neighbouring pixels. With a 3X3 filter a border pixel possesses 5, and a
corner pixel only 3 adjacent pixels, meaning the processing formula has
to take this into account and find a workaround.
Chipp's no-external formula produces a "black" 1-pixel border in this
context, his DLL formula produces a "white" 2-pixel border, Derek Bump's
DLL a black 2-pixel border. Photoshop and PaintShop Pro, for that
matter, do not produce such border effects after filter use, as they use
a more sophisticated equation when border pixels are involved.
it would be interesting if this whole thing could run without a GUI
on a web server as a faceless processor.... that could have major
implications for web apps where users upload source images, the rev
processor goes to work and the CGI incorporates downsized images back
to some web pages or image repository directory ... I would
certainly put this to use almost immediately. Quality is the big
issue for some potential uses, not for others.
(snip)
Sivakatirswami
My guess is that once a satifactory and versatile solution for filter
use inside Rev is in place, this could also be used with a CGI. I assume
there are a sufficient number of web-experienced Revolution users that
could then recommend and implement CGI versions.
Best regards,
Wilhelm Sanke
<http://www.sanke.org/MetaMedia>
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
