Is octave good to do image processing?

Hello All,

      I found octave to be good for signal processing applications.
      But is octave good for doing image processing too? The reason
      why I am asking this, is sometimes back I was using scilab for
      image processing applications. when I ventured more in depth
      I found it to be dead slow for processing large amounts of data,
      and specially if there were any for loops.

      Another question is Matlab's simulink is becoming popular for
      system level designs. Is there something like simulink existing
      on top of octave? If no then how much time and effort (man months)
      would it take to do it? and would it be worthwhile developing it?
      If so then in which language it should be developed? I am talking
      about various blocksets signal/image/comm toolboxes and blocksets.

      I found scilab's blockset to be very basic and painful. Also the
      language itself is painful. octave has a "filter" command widely 
      used. scilab does not have it. I had to write my own function which 
 
      was 20-25 lines. 

      Any suggestions/comments?

Regards
Bharat Pathak

Arithos Designs
www.Arithos.com

DSP Design consultancy and training company.

Yes, I am also really frustrated trying to find the right programming
language to do image, video and sound digital signal processing.  At
the moment I am trying out Freebasic. Ok, you can say what you like
there!
However it is easy to link in C libraries and you can do inline
assembly language to speed things up.  There is a definite limit to
the complexity of the programs you can write in basic thought.
There is no really good mid-level programming language for dsp work on
a pc.  Why are there so few choices?
The only other option I heard about is called LUSH but that uses a
dreadful lisp like programming language.

Thiophene <bitterlemon40@yahoo.ie> writes:

> Yes, I am also really frustrated trying to find the right programming
> language to do image, video and sound digital signal processing.  At
> the moment I am trying out Freebasic. Ok, you can say what you like
> there!
> However it is easy to link in C libraries and you can do inline
> assembly language to speed things up.  There is a definite limit to
> the complexity of the programs you can write in basic thought.
> There is no really good mid-level programming language for dsp work on
> a pc.  Why are there so few choices?
> The only other option I heard about is called LUSH but that uses a
> dreadful lisp like programming language.

Well, I have a few months experience with Lush and many years
experience with the Lisp-offspring Scheme.

Before I comment on Lush a question: why do you say ``dreadful lisp
like programming language''?  Do you want to say Lisp is dreadful?  If
so why?  What is your experience with Lisp?

No, I won't start a language war; not exen fight in one.  But it
amazes me again and again how persistent those myths on Lisp etc. are;
how people shy away from some of the most useful prgramming languages
ever because of FUD.

FYI: I have implemented non-trivial stuff in about 15 different
programming languages and took a good look at about 10 more.  My
favorite has become Scheme, which I use in combination with C for some
low-level building blocks.  And I started in the old days, with
FORTRAN IV on punch cards.  I am an experienced Unix programmer and
ten years ago I have been a Perl expert ...

When I was a Perl programmer, I thought about every half-an-hour
``there ought to be a better way to do this''; being a Scheme
programmer, I never think like that.  When I wrote a Perl Program (of
several thousand LOC) i enjoyed the beginning; in Scheme programming I
enjoy most extending and refinig a program.  Perhaps it is this what
people find annoying in Lisp: the trivial stuff is left to the
machine, the programmer is ``freed'' to look at the big picture, to
reason about underlying mathematical questions--- if he can.

Lisp syntax is fully parenthised polish notation, a synatx that is of
unsurpassed simplicity and power.  Lisp has no explicite types.  In
Lisp functions are ``first class'', i.e. you can create them at any
time you want, just like numbers in ``normal'' languages.  This all
are features that make Lisp and Scheme excellent for interactive use.

Bot Lisp and Scheme are _strong typed_.  I.e. it is impossible to,
say, add a number and a charcter, as e.g. C will happily do ...

Back to Lush: Lush is no Common Lisp.  Lush has dynamic binding.  Lush
is really two languages: a interpreted one and a compilable one
whith a major intersection of both.

Lush interfaces very well to C and at any time you can compile some
function (into binary) and load it into the running system; you can
afterwards modify it, compile, and reload.

Lush has been in use in the industry for signal and image processing
in the 80-ties and 90-ties.  Therefore it comes with datastructures
and interfaces to libraries that make it well suited for this area of
application: FFTW, GSL, ImageMagick, ...

Nevertheless I left Lush and recently started to build my own thing on
top of a Scheme system.  Though I plan to release under GPL, I have
nothing to offer at this time.

-- 
hw

Heinrich Wolf <hwmuell@willis-werkstaette.de> writes:
> [language war deleted...]

Heinrich,

I've just dabbled for a grand total of perhaps a week in lisp over the
last few years, mainly in dealing with XEmacs, and one of the things
that scares me the most away from using it instead of something like C
is its (apparent) weak typing. How would you justify it against a 
moderately typed language like C?
-- 
%  Randy Yates                  % "Remember the good old 1980's, when 
%% Fuquay-Varina, NC            %  things were so uncomplicated?"
%%% 919-577-9882                % 'Ticket To The Moon' 
%%%% <yates@ieee.org>           % *Time*, Electric Light Orchestra
http://www.digitalsignallabs.com

Fair enough, I have not had too much experience of using Lisp.  I do
feel however it is one of those languages that have occurred because
it made life very, very easy for the person who wrote the first
compiler - ie. get the programmer to do most of the work - ie. lazy
compiler writer. Anyway I like my maths straight.
The 3 main problems I have are:
1) accessing video and sound data without writing a mass of supporting
code.
2) modern languages and compilers are completely cache unaware. They
do not support in any way optimal use of the L1 and L2 caches.
3) they do not provide unordered loops and other statements to
transparently make use of the power of multi-core processors, from 2
core x86's to 128 core Nvidia CUDA processors.

example:
ordered loop:

for i=1 to 10
print i
next

would print 1,2,3,4,5,6,7,8,9,10

unorder loop:

all i=1 to 10
print i
next

might print 1,5,6,2,3,7,8,9,4,10
because it spread the work across 2 cores.

bharat pathak wrote:
> Hello All,
> 
>       I found octave to be good for signal processing applications.
>       But is octave good for doing image processing too? The reason
>       why I am asking this, is sometimes back I was using scilab for
>       image processing applications. when I ventured more in depth
>       I found it to be dead slow for processing large amounts of data,
>       and specially if there were any for loops.
> 
>       Another question is Matlab's simulink is becoming popular for
>       system level designs. Is there something like simulink existing
>       on top of octave? If no then how much time and effort (man months)
>       would it take to do it? and would it be worthwhile developing it?
>       If so then in which language it should be developed? I am talking
>       about various blocksets signal/image/comm toolboxes and blocksets.
> 
>       I found scilab's blockset to be very basic and painful. Also the
>       language itself is painful. octave has a "filter" command widely 
>       used. scilab does not have it. I had to write my own function which 
>  
>       was 20-25 lines. 
> 
>       Any suggestions/comments?
> 
> Regards
> Bharat Pathak
> 
> Arithos Designs
> www.Arithos.com
> 
> DSP Design consultancy and training company.
> 
> 
I have used octave for some image processing.  For moderate processing 
it is fine, but it has not matched MatLab for its efficiency.  Any 
interpreted language will remain sub-par for large amounts of data. 
Octave has MEX support (exactly like MatLab).  That is necessary for 
optimizing any heavy processing.  Granted it's basically programming in 
C, but you can quickly check results and display output with octave.  It 
testing quick ideas faster than doing it all in C.

I have not used simulink much, but I would be interested if octave 
support anything similar.  However I think MatLab has a huge advantage 
since much of the simulink development was done with other corporate 
partners.

Cheers,
J. Elms

Randy Yates <yates@ieee.org> writes:

> Heinrich Wolf <hwmuell@willis-werkstaette.de> writes:
>> [language war deleted...]

I appreciate this! :-)

>
> Heinrich,
>
> I've just dabbled for a grand total of perhaps a week in lisp over the
> last few years, mainly in dealing with XEmacs, and one of the things
> that scares me the most away from using it instead of something like C
> is its (apparent) weak typing. How would you justify it against a 
> moderately typed language like C?

It is not clear to me to what exactly you are refering.  Could you
give an example?

I have written my own (X)Emacs mode and extended some other ELisp
stuff, a few thousand LOC total.  I don't like ELisp much, but I am
not aware of an editor with a similar powerful extension language,
therefore I stay with Emacs.  Elisp is a rather dated Lisp and has
also dynamic _binding_ just as Lush; something that seems to be an
disadvantage in complex programs.

But ELisp has (strong?) dynamic typing.  This means that the operators
do checks of their arguments amd reject the operation when the types
do not match.  This is done at runtime and can be done as (most) data
are ``boxed''; this means that they are implemented by a ``structure''
that contains a type tag.

OTOH in C you have no runtime checks (of course, C is a racing car where
everything has been left out for sake of speed, even the breaks ...) 
but you have Compilers that are supposed to do compiletime checks.
Well, you know how easy it is to cast pointers and what interesting
effects this may introduce ....

This combination of compile-time checks and easy ways to ``fool'' the
compiler is called static (compile-time) and weak (foolable) typing.

[But to be fair: a compiler like modern GCC and a reasoonable to
slightly pedantic coding style will help you a lot.]

Common Lisp and Scheme have dynamic typing--- type checks at
runtime--- and ``no'' ways to fool the system with wrong-type
arguments, which is called strong typing.

-- 
hw

Thiophene <bitterlemon40@yahoo.ie> writes:

> Fair enough, I have not had too much experience of using Lisp.  I do
> feel however it is one of those languages that have occurred because
> it made life very, very easy for the person who wrote the first
> compiler - ie. get the programmer to do most of the work - ie. lazy
> compiler writer. Anyway I like my maths straight.

This may have been true 50 or so years ago to some extent.  AFAIK Lisp
was originally introduced as a notation by some AI guys to specify
programs to their assembler programmers.  Soon someone discovered that
it is not too difficult to write an interpreter for this notation ...

But in any case I consider it untrue that a Lisp program is more
difficult than a C or C++ program for a given general task.  If you
doubt this, I suggest to take a look at SICP (Structure and
Interpretation of Computer Programs by Abelson and Sussman) and show
me how their stuff could be easier implemented in another language.
They have a website:

    http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/

> The 3 main problems I have are:
> 1) accessing video and sound data without writing a mass of supporting
> code.
> 2) modern languages and compilers are completely cache unaware. They
> do not support in any way optimal use of the L1 and L2 caches.
> 3) they do not provide unordered loops and other statements to
> transparently make use of the power of multi-core processors, from 2
> core x86's to 128 core Nvidia CUDA processors.
> ....

Well, we were speaking originally about frontends for DSP, not about
compilers that allow you to exploit the full power of your hardware.

You know what languages hardware drivers are written in by the
manufacturers, the community of Lisp programmers is probably a few
orders of magnitude smaller than that of C programmers, no really big
firms pushing Lisp technology forwards--- so what could one expect?

(Scheme compilers mostly allow to produce binaries with about the
speed of C++ programs.  But there are cases where C programs are
outperformed.  Similar with Common Lisp AFAIK.)

-- 
hw

>I have used octave for some image processing.  For moderate processing 
>it is fine, but it has not matched MatLab for its efficiency.  Any 
>interpreted language will remain sub-par for large amounts of data. 
>Octave has MEX support (exactly like MatLab).  That is necessary for 
>optimizing any heavy processing.  Granted it's basically programming in 
>C, but you can quickly check results and display output with octave.  It

>testing quick ideas faster than doing it all in C.

Hi Elms,

   Thanks for your response. OpenCV is image processing library written
   in C (backed by intel). So my question is can this be integerated
   with octave to speed up things for image processing? If so how should
   one integrate the same?

   mex route or oct route or something else. 

Regards
Bharat

bharat pathak wrote:
>> I have used octave for some image processing.  For moderate processing 
>> it is fine, but it has not matched MatLab for its efficiency.  Any 
>> interpreted language will remain sub-par for large amounts of data. 
>> Octave has MEX support (exactly like MatLab).  That is necessary for 
>> optimizing any heavy processing.  Granted it's basically programming in 
>> C, but you can quickly check results and display output with octave.  It
> 
>> testing quick ideas faster than doing it all in C.
> 
> Hi Elms,
> 
>    Thanks for your response. OpenCV is image processing library written
>    in C (backed by intel). So my question is can this be integerated
>    with octave to speed up things for image processing? If so how should
>    one integrate the same?
> 
>    mex route or oct route or something else. 
> 
> Regards
> Bharat
I think others would be more likely to contribute to MEX.  And 
truthfully I am not aware of why one might pick oct over mex.

However, it looks like you may be in luck:
"3/27/08: These bindings have been integrated into OpenCV. Latest 
sources are now available only from OpenCV CVS."
~ http://octave-swig.sourceforge.net/octave-opencv.html

I am going to find some time to look into this myself. I think you'll 
have to get the source to get the bindings (maybe only available from 
the CVS repository). It might be buggy, but it's a start.

I also found a different link, but it looks older and limited.
http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=12200&objectType=File

Cheers,
J. Elms