Mailman 3 September 2014 - scikit-image

Re: skimage and opencv
by Emmanuelle Gouillart 22 Sep '16

22 Sep '16

Hi FranÃ¯Â¿Â½ois, that's an excellent question, and not a troll :-). Opencv is a very powerful library, but it focuses primarily on computer vision (feature detection and extraction, classification, ...), as opposed to image processing in general (with other tasks such as denoising, segmentation, ...). The other big difference is that skimage builds on numpy ndarrays, and uses the full power of the numpy API (including of course the basic facilities for processing arrays as images that come with numpy), as well as some of scipy functions (you could have added scipy.ndimage to your list -- a few functions in skimage are wrappers around scipy.ndimage, that exist for the sake of completeneness). One important consequence is that algorithms working for 3-d or even n-d images can be easily implemented in 3-d/n-d in skimage, whereas opencv is restricted to 2-D images (as far as I know). Thanks to the use of numpy arrays, the API of skimage is also quite pleasant for a numpy user, more than the API of opencv. A related difference is that skimage is written in python and cython, whereas opencv is a C++ library. The two libraries attract a different crowd of developers, and a Python/Cython toolkit based on numpy arrays is easier to develop and maintain inside the Scientific Python ecosystem. I'm sure that other devs/users will have things to add to this discussion! Cheers, Emmanuelle On Thu, Dec 27, 2012 at 02:06:08PM -0800, FranÃ¯Â¿Â½ois wrote: > Hi users and devs, > It came to my knowledge that another python library (based on C++ and C > codes) for image processing exists too : opencv > I understand that numpy intregrates some basic features and we need some > advanced features but I have the feeling that skimages is redoundant with > opencv in some ways. > What's the position of skimage about that? (Don't read this question as a > troll but like a real question). > I mean that similar features exist in both. Would not be possible to > reuse/integrate opencv or merge? what's the reason for keeping them apart? > My observation is there is 4 libraries to manipulate images: > * PIL > * numpy > * skimages > * opencv > That's a lot. > Cheers,

3 2

scikits-image on PyPI
by Johannes Schönberger 28 Sep '14

28 Sep '14

Should we delete this old site here? Just to prevent accidental install of scikits-image, when people mistype it… https://pypi.python.org/pypi/scikits-image/0.7.1 Johannes Schönberger

2 2

ANN: scikit-video 0.1.2
by Alexander Izvorski 27 Sep '14

27 Sep '14

Hello, This is to announce an early version of scikit-video, a scikit for all your video needs :) Please excuse posting here, I think this may be of interest for anyone using scikit-image to work with video. Code: https://github.com/aizvorski/scikit-video Status: There is video reading and writing code, which is a drop-in replacement for opencv's VideoCapture and VideoWriter; some simple video player and transcoder examples using this; and a bunch of video quality metrics. Overall this is beta quality but usable. Motivation: This scikit is intended as a companion to scikit-image: the two are complementary and not competitive. What code is better in scikit-video than in scikit-image? Roughly, if the code *only* makes sense when applied to a sequence of images, then it may be better placed in scikit-video. An example of this would be temporal denoise. Other code which would make sense to have in here is code which is more often seen or used in a video context, even though it may in principle be used for both images or video. An example of this would be the SSIM quality metric. It is intended that scikit-image and scikit-video would "just work" together, for example you might read a video file using skvideo, use a skimage filter on each frame and write out the filtered frames to another file with skvideo. The video I/O part of this is perhaps even more useful now that skimage.io.video is not available in newer skimage releases. Roadmap: - Skeleton project from scikit-example - DONE - Video IO by wrapping ffmpeg/avconv - reading and writing DONE - Video metrics - have SSIM, VIF, PSNR (would like VQM, VQuad, polar edge coherence, ...) - Unit tests and CI - not yet :) (beyond this point are just possible future directions) - (?) TLD, CMT and other object tracking algorithms (wrap C, CUDA code) - (?) Pyramid motion estimation - (?) Details about a compressed video file: macroblock types, motion vectors, ... - (?) 3D denoise, guided filter denoise, etc - (?) Mini video player (there is already a playback example but without UI) - (?) Any existing off-the-shelf projects that would be good to merge into this I expect that if this gathers enough interest it will transition to a group-maintained project similar to skimage or sklearn. Your suggestions, ideas, and code are most welcome. Regards, Alex Izvorski

2 1

Re: How to Apply the Otsu Threshold Excluding Zero Values
by Stefan van der Walt 27 Sep '14

27 Sep '14

On 2014-09-26 08:03:24, vbubbly21(a)gmail.com wrote: > I want to use "skimage.filter.threshold_otsu(image, nbins=256)" module > excluding the 0 values of my image while computing the threshold. How about: skimage.filter.threshold_otsu(image[image != 0], nbins=256) Stéfan

2 1

Fwd: [Numpy-discussion] ANN: xray 0.3 released
by Stefan van der Walt 22 Sep '14

22 Sep '14

For those of you who do a lot of N-d processing: On 2014-09-22 05:44:37, Stephan Hoyer <shoyer(a)gmail.com> wrote: > I'm pleased to announce the v0.3 release for xray, N-D labeled arrays and > datasets in Python. > > xray is an open source project and Python package that aims to bring > the labeled data power of pandas to the physical sciences, by > providing N-dimensional variants of the core pandas data structures, Series > and DataFrame: the xray DataArray and Dataset. > > Our goal is to provide a pandas-like and pandas-compatible toolkit > for analytics on multi-dimensional arrays, rather than the tabular data for > which pandas excels. Our approach adopts the Common Data Model for > self-describing scientific data in widespread use in the Earth sciences > (e.g., > netCDF and OPeNDAP): xray.Dataset is an in-memory representation of > a netCDF file. > > Documentation: http://xray.readthedocs.org > Code: http://github.com/xray/xray > Mailing list: xray-dev(a)googlegroups.com > > Comments, feedback and contributions are all very welcome! > > Cheers, > Stephan

1 0

New core developer: Steven Silvester
by Stefan van der Walt 17 Sep '14

17 Sep '14

Hi everyone I am happy to announce that Steven Silvester has joined the scikit-image core team. Welcome, Steven, we look forward to many productive collaborations and taking the project to new heights together! Stéfan

2 1

Re: String formatting style
by Michael Aye 17 Sep '14

17 Sep '14

On Wednesday, September 3, 2014 2:57:56 AM UTC-7, Stefan van der Walt wrote: > > On Wed, Sep 3, 2014 at 1:20 AM, Michael Aye <kmicha...(a)gmail.com > <javascript:>> wrote: > > It's part of the Python tutorial for many years and common standard I'd > say. > > It's basic use might be cumbersome at first, but its power is great. > > > > Things like "My name is {0[name]}".format(dict(name='Fred')) > > With great power comes great responsibility! I find the above very > close to unreadable. > > Compare to: > > "My name is %s" % name > > This one is an unfair comparison as you have removed the dictionary part (for template codings). In this simplest case it just can be "My name is {}".format(name) and that is arguable better readable, especially considering the cluttered %s" % part in the old syntax. In this simplest case I much prefer not to have all these modulo operators flying around. When including dictionary access for run-time templates, obviously it get's more complicated. How does the old syntax deal with 2 or more dictionaries? Here it would just be another number: "Our names are {0[name]} and {1[name]}".format(dict(name="Fred"), dict(name="Susan")) Obviously, in real code, one would never define the dictionaries inside the format() but they would be determined elsewhere in the code, so in reality this would more look like: "Our names are {0[name]} and {1[name]} and we live at {0[address]} and {1[address]} respectively".format(d0, d1) Michael or > > "My name is %(name)s" % {'name': 'Fred'} > > Stéfan >

1 1

Re: Matplotlib style sheets
by Johannes Schönberger 13 Sep '14

13 Sep '14

Nice. Now we only have to settle for a style… :-) I like this one here: http://matplotlib.org/examples/style_sheets/plot_bmh.html Johannes Schönberger On Sep 13, 2014, at 9:43 AM, Stéfan van der Walt <stefan(a)sun.ac.za> wrote: > Hi all > > A heads up about a new feature in Matplotlib 1.4, style sheets: > > http://matplotlib.org/users/style_sheets.html > http://matplotlib.org/gallery.html#style_sheets > > I imagine this will be very useful for the examples gallery and documentation. > > Regards > Stéfan > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/d/optout.

1 0

Matplotlib style sheets
by Stéfan van der Walt 13 Sep '14

13 Sep '14

Hi all A heads up about a new feature in Matplotlib 1.4, style sheets: http://matplotlib.org/users/style_sheets.html http://matplotlib.org/gallery.html#style_sheets I imagine this will be very useful for the examples gallery and documentation. Regards Stéfan

1 0

Re: String formatting style
by Josh Warner 12 Sep '14

12 Sep '14

The main reason I’ve preferred the .format method in a couple of recent PRs and my own work is completely separate from readability. I feel the % operator is inappropriately overloaded when used both as the proper ‘modulo’ operator as well as a common shortcut to control string formatting. It always felt odd to me, like Python’s C roots were showing. It’s true, .format is not always more readable. However, I’ve found this is more of an adjustment than objectively true. The only danger is that explicit numbers must be used for all inserted brackets instead of empty brackets to retain Python 2.6 compatibility. I don’t really mind either way, just food for thought. Josh On Wednesday, September 3, 2014 5:57:56 AM UTC-4, Stefan van der Walt wrote: On Wed, Sep 3, 2014 at 1:20 AM, Michael Aye <k...aye(a)gmail.com> wrote: > > It's part of the Python tutorial for many years and common standard I'd > say. > > It's basic use might be cumbersome at first, but its power is great. > > > > Things like "My name is {0[name]}".format(dict(name='Fred')) > > With great power comes great responsibility! I find the above very > close to unreadable. > > Compare to: > > "My name is %s" % name > > or > > "My name is %(name)s" % {'name': 'Fred'} > > Stéfan >

1 0