Dear all, Just notice that the warning on the page is still there( http://scikits-image.org/docs/0.7.0/coverage_table.html). There are still more red than green :) I am not sure whether it is a good idea to update this page and set priorities on what to expect in the near future for this package i.e. next release? My personal feeling is maybe a table of what is still missing for this package will benefit those contributors which in turn will benefit the package itself. I myself love open source and try to make some contributions(if any) for those great packages that are related to my work(computer vision mostly) but sometimes just get confused what piece of codes will benefit others and could be included into the packages. IMHO, issue on github could be a guideline and is important, but seem not to be enough. Maybe a big picture at the website just as the coverage_table is equally important.(Or maybe there are some such pages I just missed). Best, Wei
I'm not a core developer, so anyone feel free to correct any inaccuracies in this post. - I think most of the subsection "Image Types and Type Conversions" is now handled by various utility functions in `skimage.util` (like `img_as_float`). - There are now some registration tools available in skimage. I see many other areas that are either included, or appear to be blind attempts to translate Matlab functions directly. I could easily write an `imsubtract`, for example, but that functionality exists for any base 2D ndarray! Should function-for-function feature parity, even where this is not particularly useful, be a goal? That's what I get from this table. A separate but related issue is reinventing the wheel. NiBabel can read/write most medical image formats, including Analyze 7.5, nifti, and DICOM. Other well-known packages do 2d static visualization very well, load R files, etc. I don't have an answer for this without either reinventing many wheels, bringing over code from other projects (with attendant licensing issues and updating with their codebase, concern for backward compatibility), or adding dependencies to many other packages. As a reformed Matlab user, I personally prefer the general Python way which is *not* "everything and the kitchen sink" in one massive package, but more pick-and-choose from a diverse toolkit for the problem(s) at hand. But that's just me. On Monday, October 1, 2012 8:08:45 AM UTC-5, Wei LI @kuantkid wrote:
Dear all,
Just notice that the warning on the page is still there( http://scikits-image.org/docs/0.7.0/coverage_table.html). There are still more red than green :) I am not sure whether it is a good idea to update this page and set priorities on what to expect in the near future for this package i.e. next release?
My personal feeling is maybe a table of what is still missing for this package will benefit those contributors which in turn will benefit the package itself. I myself love open source and try to make some contributions(if any) for those great packages that are related to my work(computer vision mostly) but sometimes just get confused what piece of codes will benefit others and could be included into the packages. IMHO, issue on github could be a guideline and is important, but seem not to be enough. Maybe a big picture at the website just as the coverage_table is equally important.(Or maybe there are some such pages I just missed).
Best, Wei
Hi everyone, On Mon, Oct 1, 2012 at 4:15 PM, Josh Warner <silvertrumpet999@gmail.com> wrote:
Should function-for-function feature parity, even where this is not particularly useful, be a goal? That's what I get from this table.
[...]
As a reformed Matlab user, I personally prefer the general Python way which is not "everything and the kitchen sink" in one massive package, but more pick-and-choose from a diverse toolkit for the problem(s) at hand. But that's just me.
Thanks for your thoughts, Josh, I agree with the points you make. In my recent talk at EuroSciPy, I mentioned that the MATLAB compatibility table was probably a mistake on my part. At that time, I was trying to find a way forward with skimage that would help us to grow, and providing an easy route of transitioning for users from other platforms seemed like a worthwhile goal. Looking back, especially at my experience with Octave, I realize that trying to imitate another package squashes much innovation and does not lead to well-designed or Pythonic solutions. In the mean time, the core team has grown, with a very active role being played by excellent coders such as Tony, Johannes, Andreas, and others, so I feel much less pressured to continue along that path. I think the compatibility table could still be useful as a list of "pointers", but unless someone updates it soon, we should think about removing it. That role can also be played by the user guide (unfortunately, one of our weak points, which I'd love to address). Stéfan
participants (3)
-
Josh Warner
-
Stéfan van der Walt
-
Wei LI @kuantkid