[Scilab-users] What is the future of Scilab?

[Alasdair McAndrew]

The poor quality of image processing toolboxes is what turned me off Scilab
to GNU Octave, which has a very good imaging toolbox.  Or Python, which
with its various imaging libraries and scientific/numeric libraries is now
a serious competitor for matrix-oriented software like
Matlab/Scilab/Octave.  I've written two image processing textbooks, and at
no time has Scilab ever been a serious contender for their software.

On Wed, Feb 17, 2016 at 7:20 PM, <amonmayr at laas.fr> wrote:

> Le 02/17/2016 01:23 AM, AlvaroOsvaldo a écrit :
>
> I am worried, in previous versions of scilab, I implemented a medium
> project for scientific computing with scilab at that time had many memory
> leaks and had been a nightmare. With the new updates that was fixed and
> this much better.  But now I am implementing another project involving
> massive image processing. And the three atoms for this, one does not work,
> one does not load images but the manual says they can do, and other charges
> but leak the computer's memory and it took me longer skirting the problem
> than implementing the solution. And worse, because this the system is much
> slower than it should. This atom memory failure it has been known, however,
> despite it make impraticable to use the atom for medium and large projects,
> makes three years that no one gets the bug.
> forge.scilab.org/index.php/p/IPD/issues/992/ There are high expectations
> with Scilab 6 and I believe we will have a much better platform. But for
> what you know, in the meantime we will run out of many atoms, and this
> greatly reduces the possibility of working in scilab. What is the future of
> Scilab? For now, the impression I have is that the atoms are abandoned and
> without the atoms the usefulness of scilab is reduced a lot.
>
>
> Hi,
>
> I think there are two issues here:
>
> 1) The sad state of image processing toolbox with Scilab. It's terrrible.
> Image processing with Scilab is a nightmare. Every other language I use is
> far better than Scilab in this area (even extremely young language like
> Julia offers a better experience. The 3 toolboxes are either broken,
> unmaintained or difficult (or impossible) to install. And the experience is
> even worse under Linux (IPD for example requires a very old version of
> opencv to be manually installed under Linux which is a daunting task for
> most user and which introduces many compatibility issues with other
> softwares relying on opencv).
>
> 2) The lack of information on the life (or lack of life) for a given atoms
> module. I know some information is available on the atoms website, but I've
> always found it difficult to determine whether the package was long dead or
> under active development. There are some long dead modules that are still
> listed alongside with actively maintained ones and that show excellent
> rating. It's a bit confusing.
>
> Concerning the first issue, image processing with scilab, I think a basic
> core image support should be part of scilab.
>
> Antoine
>
>
>
>
> ------------------------------
> View this message in context: What is the future of Scilab?
> <http://mailinglists.scilab.org/What-is-the-future-of-Scilab-tp4033471.html>
> Sent from the Scilab users - Mailing Lists Archives mailing list archive
> <http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html>
> at Nabble.com.
>
>
> _______________________________________________
> users mailing listusers at lists.scilab.orghttp://lists.scilab.org/mailman/listinfo/users
>
>
>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
>
>


-- 
[image: http://www.facebook.com/alasdairmcandrew] [image:
https://twitter.com/amca01] <https://twitter.com/amca01>
<https://www.linkedin.com/in/alasdair-mcandrew-108178a>
<https://plus.google.com/+AlasdairMcAndrew/posts>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20160217/7cf20393/attachment.htm>