Posted by bharat pathak April 29, 2008
Wow!!

   Looks like the search ends here.

   Jim, will there be any speed or memory limitations now that
   opencv is integrated with octave? will i be ale to do reasonable
   amount of image processing?

   Second question what is difference between .oct and .mex 
   which one is prefferd and why?

   Thanks once again for all the help.

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 >
Posted by April 29, 2008
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
Posted by bharat pathak April 28, 2008
>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
Posted by Heinrich Wolf April 28, 2008
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
Posted by Heinrich Wolf April 28, 2008
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
Posted by April 28, 2008
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
Posted by Thiophene April 28, 2008
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.




Posted by Randy Yates April 28, 2008
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
Posted by Heinrich Wolf April 27, 2008
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
Posted by Thiophene April 27, 2008
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.