Re: Message from Mark re: C++

["Ilya Razmanov" <ilyich@cacr.ioc.ac.ru>]

> Alfredo Luis Mateus wrote:
>
> > p.s. I think that the FFDG can grow to discuss any kind of plugin coding
> > techniques, the advantages of each one, code sharing, etc. So, please,
> > don't be shy or think that you have to be strictly "on the topic" here.

Oh well, "formally" this all will be off-topic. From another point, we
finally exceeded FF capabilities I think (hm, Alf, wasn't I saying this 2
years ago? Maybe 3 years?). Discussing FiFo vs FM and the like may be too
specific (e.g., it is of no interest for Mac users), but discussing general
image processing algorithms is of great importance. I feel like I need to
learn a lot.

First, I have to say some words about FM/FiFo vs C++. As far as  know, C is
rather expensive in case you'd like to be able to redistribute runtimes etc.
In a word, it is not too expensive if you develop "for your own" but it is
if you come to professional work (correct me if I'm wrong). Currently, FM
language (I'm not familiar with FiFo so I say for FM only) cannot compete
with full-blown C. But you don't need to buy an expensive compiler if you
have a rather simple ideas to develop - everything you need is within FM.
Besides, learning FM is very easy IMHO, especiall migrating from FF. At the
beginning, you simply use it as "FF without code length limit", then you
start to write your own loops etc, develop custom interface and so on. As
for me, currently I cannot afford all my time to learning complex C and SDK;
but I think I can start with FM and maybe this will lead to something
interesting. That's my opinion.

> 2) Further a links to pages with Image Processing stuff:
>
> http://www.mhri.edu.au/~pdb/colour/imageprocess/
>

Whoa, it contains some info on Fourier transform I was always interested -
thanks for the link!.. I think it may be of great use. The only drawback is
that FT usually is quite slow...

> For example a simple edge detection:
> Use something like that:  (it's known as "Laplacian kernel", I guess?)
>
>     -1 0 0
>      0 0 0
>      0 0 1
> then invert the image.

Interesting kernel; I think asymmetric kernels should always lead to some
emboss effect, right?

Some days ago, I released a couple of sample filters made with FM; one of
them performed blur/sharpen/edge functions. The general idea was: make blur;
calculate the difference between blurred and source image. This difference
is "edge" picture (you see, or a smooth picture, there's not much difference
between source and blurred. Only with contrast edges, we see noticeable
difference). My filter also run a "contrast autostretch" (i.e.
"Image/Equalize") after this. Then, we may calculate the "sharpened" picture
by adding the difference to the source image.

I think kernel like

111
1 -81
111

is equal to what my filter do on radius set to 1-pixel.

So, that's the general idea...

Yours,

Ilyich.
--------------------------------------------------------------------------
Ilya Razmanov (a.k.a. Ilyich the Toad), Institute of Organic Chemistry RAS
http://www.chat.ru/~bufo/ - Freeware Photoshop Filters and Design Showcase
"Stop him, Sam, he's gonna tell us a story!" - Max,
Sam and Max hit the road
--------------------------------------------------------------------------