Mailman 3 January 2013 - scikit-image

Re: skimage and opencv
by Emmanuelle Gouillart Sept. 22, 2016

Sept. 22, 2016

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

Re: Making algorithms at least 3D, preferably nD
by jeff witz April 26, 2013

April 26, 2013

Hello, I think you must all pay attention to standards if you want to act on nD images. For structured data files there is a library that hab been used for decade and which is very efficient, it's netcdf (http://www.unidata.ucar.edu/software/netcdf/), there is already tools in python to deal with it. This library allows one to deal with data in // which is important when one deals with big datas. The last version is based on hdf wich is the tools used on HPC. If your data are not stored in a standard format, the library ITK has provide a binding called SimpleITK that allows one to read every format ITK konws. It is important to take into account the fact that the operation on pixel depend on the grid spacing, as for exampe the finite difference gradient which is wrong when one chooses a step of one because the file as not been read correctly. As the 3D datas often comes from the measurement X-Ray Tomography, MRI, Echography, it is important to consider the device information. The format dicom as been made in this specific purpose there is a python binding called pydicom. I know that scikit team does'nt want to have to much dependances, but for nD case I think it is important to use existing libraries. Best regards Le vendredi 30 novembre 2012 05:45:49 UTC+1, Juan Nunez-Iglesias a écrit : > > Hey Guys, > > I mentioned this briefly at SciPy, but I would like to reiterate: a lot of > data is 3D images these days, and more and more data is being generated > that is multi-channel, 3D+t. Therefore, it would be awesome if scikit-image > started making more of an effort to support these. In the best case, the > dimension of the underlying array can be abstracted away — see here<https://github.com/jni/ray/blob/develop/ray/morpho.py#L328>for example, the functions juicy_center (which extracts the centre of an > array, along all dimensions), surfaces (grabs the "border" arrays along > each dimension), hollowed (zeroes-out the centre), and more. Otherwise, > writing a 3D function that gracefully degrades to 2D when one of the > dimensions is 1 is also possible. > > In general, the amount of additional effort to make code 3-, 4- or n- > dimensional is relatively low when you write the algorithm initially, > relative to refactoring a whole bunch of functions later. I'll try to > fiddle with whichever code I need, but in the meantime, what do you think > about adding a paragraph or a sentence about this issue in the scikit-image > contribute <http://scikit-image.org/docs/dev/contribute.html> section, so > that people at least have this in mind when they are thinking of writing > something new? > > Thanks, > > Juan. >

4 3

Re: Release plan for 0.8
by Schönberger Johannes Feb. 4, 2013

Feb. 4, 2013

I think we should push the release some days back to fix the majority of these issues. > https://github.com/scikit-image/scikit-image/issues/318 I'll take on this tomorrow. > https://github.com/scikit-image/scikit-image/issues/336 Made the necessary changes today as part of a new PR. > https://github.com/scikit-image/scikit-image/issues/341 I commented on this topic on github. > https://github.com/scikit-image/scikit-image/issues/418 (check relevance) Has been fixed before, so closed.

1 1

Re: Contribution: circles and hough transform
by François Feb. 3, 2013

Feb. 3, 2013

Le mercredi 9 janvier 2013 17:05:53 UTC+1, Stefan van der Walt a écrit : > > > Both patches would be very welcome! Let us know if you need any help > getting started. > > Thank. I discovered in master circle_perimeter(). This is actually the bresenham method. This PR is for Andres method. https://github.com/scikit-image/scikit-image/pull/410 Since bresenham in already in master, I'm working on the hough transform. :) François.

2 2

Re: Displaying video
by Almar Klein Jan. 31, 2013

Jan. 31, 2013

You could do it with OpenGl, although it wouldn't be straightforward. You can also do it in visvis (which uses OpenGl). Here's some untested code that would do this: import visvis as vv vv.clf() # Clear figure (or create a new figure) tex = vv.imshow(first_frame) while video_not_ended: tex.SetData(next_frame) time.sleep(1.0/framerate) vv.processEvents() - Almar On 30 January 2013 22:07, Colin Lea <colincsl(a)gmail.com> wrote: > For a long time now I've kept OpenCV in my vision stack primarily for > displaying videos. I'm trying to get rid of it as a dependence for use on a > secure remote server which I don't have unfettered access to. > > So I'm wondering, how do other people display videos? I see that PyGame is > another option. Does anyone use that? By displaying videos essentially I > just mean showing streams of images (not necessary from a video file). > > If nobody else has a solution other than to use OpenCV, would it be of > interest to implement something (either using PyGame or otherwise) for > skimage? > > > -- > 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/groups/opt_out. > > >

1 0

removing small connected components
by Juan Nunez-Iglesias Jan. 30, 2013

Jan. 30, 2013

Hi guys, For my own segmentation package, I wrote a small function to remove small connected components in an ndarray. You can see it here: https://github.com/janelia-flyem/gala/blob/master/gala/morpho.py#L72 I've been looking at things that could be moved from there to skimage and I thought that was a prime candidate (I think you actually do the same thing in one of the examples, but without making it into a function). Any interest in a PR? There's other nd operations in there: morphological reconstruction, h-minima, regional (aka local) minima, and impose minima. Let me know if you would like any of these for inclusion in skimage... Thanks, Juan.

1 0

Re: Policy for import of submodules
by Stéfan van der Walt Jan. 29, 2013

Jan. 29, 2013

On Wed, Jan 30, 2013 at 1:37 PM, Juan Nunez-Iglesias <jni.soma(a)gmail.com> wrote: > Ok so I'm hearing consensus about what you guys want to do, which is great. > For future reference though, is the intent that second-level packages do > import everything underneath? Currently there don't appear to be more than > two levels, but will that always be true? Yes, we don't want to stack anything more deeply than that. It really is just a means of ensuring that you can import a selected portion of scikit-image without waiting too long, or without loading unnecessary dependencies (e.g., importing the io module will also import gstreamer if available). Also, in the most severe case where one sub-module can't import, you can at least continue working with the rest. Stéfan

1 0

Re: Policy for import of submodules
by Juan Nunez-Iglesias Jan. 29, 2013

Jan. 29, 2013

Ok so I'm hearing consensus about what you guys want to do, which is great. For future reference though, is the intent that second-level packages *do* import everything underneath? Currently there don't appear to be more than two levels, but will that always be true? On Wed, Jan 30, 2013 at 5:13 PM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: > On Wed, Jan 30, 2013 at 11:42 AM, Tony Yu <tsyu80(a)gmail.com> wrote: > >> So my question is, is this behaviour by design, or should there be > nothing > >> at all in the top-level, or should everything be imported? > > > > I tend to agree that it should be one or the other (with the exception of > > the standard metadata at the top-level). > > As Tony mentioned, it's by design from the lessons learnt in NumPy, > aimed at limiting the import time of the library. Because > ``img_as_float``, ``test`` etc. are used so often, we put them in the > root namespace. We have: > > skimage.data_dir skimage.img_as_int skimage.test > skimage.get_log skimage.img_as_ubyte skimage.test_verbose > skimage.img_as_bool skimage.img_as_uint skimage.util > skimage.img_as_float skimage.pkg_dir skimage.version > > Of these, I would keep at least skimage.version, skimage.test, > skimage.test_verbose and skimage.get_log, because they provide > overarching functionality. > > 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/groups/opt_out. > > >

1 0

Re: Policy for import of submodules
by Stéfan van der Walt Jan. 29, 2013

Jan. 29, 2013

On Wed, Jan 30, 2013 at 11:42 AM, Tony Yu <tsyu80(a)gmail.com> wrote: >> So my question is, is this behaviour by design, or should there be nothing >> at all in the top-level, or should everything be imported? > > I tend to agree that it should be one or the other (with the exception of > the standard metadata at the top-level). As Tony mentioned, it's by design from the lessons learnt in NumPy, aimed at limiting the import time of the library. Because ``img_as_float``, ``test`` etc. are used so often, we put them in the root namespace. We have: skimage.data_dir skimage.img_as_int skimage.test skimage.get_log skimage.img_as_ubyte skimage.test_verbose skimage.img_as_bool skimage.img_as_uint skimage.util skimage.img_as_float skimage.pkg_dir skimage.version Of these, I would keep at least skimage.version, skimage.test, skimage.test_verbose and skimage.get_log, because they provide overarching functionality. Stéfan

1 0

Re: Policy for import of submodules
by Tony Yu Jan. 29, 2013

Jan. 29, 2013

On Tue, Jan 29, 2013 at 10:05 PM, Juan Nunez-Iglesias <jni.soma(a)gmail.com>wrote: > Hi, > > Does scikit-image have a specific policy for how imports should work? For > example, as far as I know, numpy currently imports everything into the np > namespace with: > > import numpy as np > > > However, the following raises an error, even though the import statement > works fine: > > import skimage as skim > coins = skim.data.coins() > > giving the error: > > --------------------------------------------------------------------------- > AttributeError Traceback (most recent call last) > <ipython-input-3-0ce27ef61295> in <module>() > ----> 1 coins = skim.data.coins() > > AttributeError: 'module' object has no attribute 'data' > > > But some things *are* in the top-level namespace. The following works > fine: > > import skimage as skimfrom skimage import data > coins = data.coins() > coins = skim.img_as_float(coins) > > > So my question is, is this behaviour by design, or should there be nothing > at all in the top-level, or should everything be imported? > > I tend to agree that it should be one or the other (with the exception of the standard metadata at the top-level). The argument against importing everything is that it can lead to slow import times (see, numpy for example<http://numpy-discussion.10968.n7.nabble.com/quot-import-numpy-quot-is-slow-…>), even when you're only using a small subset of the package. While this time may not be too severe now, the hope is that scikit-image will grow ever-more functionality, which would slow import times. I'm in favor of moving the functionality out of the top level. I think the only thing that would need to be moved out would be the converters in `skimage.util.dtype`. There should be a shorter path to access those functions, though. Side note: I'm not a huge fan of `util` (I would have thought `utils`), but that's a minor point. And of course, if others agree, this would need to be phased in over time---probably with a couple of releases raising deprecation warnings when trying to access those functions at the top level. Also, this would wait until after the release of 0.8. -Tony

1 0

Policy for import of submodules
by Juan Nunez-Iglesias Jan. 29, 2013

Jan. 29, 2013

Hi, Does scikit-image have a specific policy for how imports should work? For example, as far as I know, numpy currently imports everything into the np namespace with: import numpy as np However, the following raises an error, even though the import statement works fine: import skimage as skim coins = skim.data.coins() giving the error: --------------------------------------------------------------------------- AttributeError Traceback (most recent call last) <ipython-input-3-0ce27ef61295> in <module>() ----> 1 coins = skim.data.coins() AttributeError: 'module' object has no attribute 'data' But some things *are* in the top-level namespace. The following works fine: import skimage as skimfrom skimage import data coins = data.coins() coins = skim.img_as_float(coins) So my question is, is this behaviour by design, or should there be nothing at all in the top-level, or should everything be imported?

1 0

Re: canvastools subpackage for scikit-image viewer
by Tony Yu Jan. 24, 2013

Jan. 24, 2013

On Thu, Dec 27, 2012 at 11:56 PM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: > Hi Tony > > On Wed, Dec 26, 2012 at 10:41 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > > I just added another tool: A canvas painter. It's a bit less responsive > than > > I'd like, but I think it's as fast as it'll get (it's limited by > > matplotlib's blitting support for images). Check out the watershed demo > in > > the `viewer_examples/plugins` folder, which uses the paint tool to > generate > > markers for watershed segmentation. > > Finally, a path to that FFT filter painter I've had in mind! This is > very exciting. > > By the way, it took me a while to figure out to press "enter" to run > the segmentation, so how about printing some instructions to the > terminal? > > Thanks again, > Stéfan > > Sorry for the really late reply on this. Actually, the demo should have printed instructions to the terminal in that version. In any case, getting the user to press enter wasn't great for usability. I just changed this demo<https://github.com/tonysyu/scikit-image/commit/230fefa748db13af928e5cf69989…> so that you press a button to display the watershed segmentation. -T

1 0

Re: Release plan for 0.8
by Schönberger Johannes Jan. 21, 2013

Jan. 21, 2013

Hi, some bugs have been fixed so far, thanks to everyone. This mail serves as a reminder for everyone who encountered any remaining problems with the current development version, since I plan to push out 0.8 in two days. Regards, Johannes

2 1

Release plan for 0.8
by Johannes Schönberger Jan. 16, 2013

Jan. 16, 2013

Hi everybody, a lot of features have been added since we released version 0.7 about 4 months ago. I therefore suggest to make a feature freeze for the next week until January 23rd and only merge bugfixes in this time frame. Are there any changes you want to see in 0.8? It would be great if we could test the current development version on all common system environments to ensure we don't release a broken version. For me it works on OSX 10.8, Python 2.7 and Ubuntu 12.10 32bit, Python 2.7. Regards, Johannes

6 5

Re: When will 0.8 official be released?
by Johannes Schönberger Jan. 14, 2013

Jan. 14, 2013

Hi Tony, OK, I'll give it a try! There is one small PR (https://github.com/scikit-image/scikit-image/pull/413) I would like to merge before I would set the timeline. I will get in touch with you if I encounter any problems. Regards, Johannes 2013/1/15 Tony Yu <tsyu80(a)gmail.com>: > On Wed, Jan 9, 2013 at 8:08 PM, Steven Silvester > <steven.silvester(a)gmail.com> wrote: >> >> Johannes, >> >> RELEASE.txt looks pretty well laid out. Perhaps you could cut a "release >> candidate", and wait until next month for the final release and the Debian >> version. >> >> Let me know if I can be of service. I maintain a PyPi package. >> >> >> Regards, >> Steve > > > > Sorry, I meant to respond sooner, but I've been busy. I think it's a great > idea to get an early start on the release. > > In particular, there's some grace period where we should announce a pending > release. Any bug fixes or *small* enhancements that people want to get in > before the release should be added at this time (~week). Then, there should > be another week or so for testing. (I don't think we've done release > branches in the past, but it might be a good idea.) > > So, to summarize, Johannes: I think it'd be great if you could get the ball > rolling by setting the timeline. You may want to take a look at my email > preparing for the 0.7 release. > > Also, as Steve suggests, RELEASE.txt is pretty thorough. The previous > release was the first release not handled by Stéfan, and I more or less > followed that document for the release. (Well, I probably also sent numerous > emails to Stéfan, too.) So if you're up for it, Johannes, it might be a good > idea to give it a go. (And any improvements you can make to RELEASE.txt > would be great.) > > Just a reminder: We may want to revisit the docs version linked on the > website after this release. > > Cheers, > -Tony > > -- > >

1 0

Re: When will 0.8 official be released?
by Steven Silvester Jan. 14, 2013

Jan. 14, 2013

Johannes, RELEASE.txt looks pretty well laid out. Perhaps you could cut a "release candidate", and wait until next month for the final release and the Debian version. Let me know if I can be of service. I maintain a PyPi package. Regards, Steve

2 1

Re: Master branch fails tests?
by Johannes Schönberger Jan. 10, 2013

Jan. 10, 2013

I think this is only necessary if new have been added or removed. Am Donnerstag, 10. Januar 2013 schrieb Juan Nunez-Iglesias : > That did the trick! Any guidelines on when I should do a full working tree > cleanup? Every build? > > On Thu, Jan 10, 2013 at 9:12 PM, Stéfan van der Walt <stefan(a)sun.ac.za<javascript:_e({}, 'cvml', 'stefan(a)sun.ac.za');> > > wrote: > >> Hi Juan >> >> On Thu, Jan 10, 2013 at 11:46 AM, Juan Nunez-Iglesias >> <jni.soma(a)gmail.com <javascript:_e({}, 'cvml', 'jni.soma(a)gmail.com');>> >> wrote: >> > Am I doing something wrong? I can't get master to work on OSX; 6 tests >> fail >> > with the following import error: >> >> Could you try: >> >> git checkout master >> git reset --hard origin/master >> git clean -xdf >> make >> >> And then try again? The tests run fine over here. >> >> Thanks! >> Stéfan >> >> -- >> >> >> > -- > > >

1 0

Re: Master branch fails tests?
by Juan Nunez-Iglesias Jan. 10, 2013

Jan. 10, 2013

That did the trick! Any guidelines on when I should do a full working tree cleanup? Every build? On Thu, Jan 10, 2013 at 9:12 PM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: > Hi Juan > > On Thu, Jan 10, 2013 at 11:46 AM, Juan Nunez-Iglesias > <jni.soma(a)gmail.com> wrote: > > Am I doing something wrong? I can't get master to work on OSX; 6 tests > fail > > with the following import error: > > Could you try: > > git checkout master > git reset --hard origin/master > git clean -xdf > make > > And then try again? The tests run fine over here. > > Thanks! > Stéfan > > -- > > >

1 0

Re: Master branch fails tests?
by Stéfan van der Walt Jan. 10, 2013

Jan. 10, 2013

Hi Juan On Thu, Jan 10, 2013 at 11:46 AM, Juan Nunez-Iglesias <jni.soma(a)gmail.com> wrote: > Am I doing something wrong? I can't get master to work on OSX; 6 tests fail > with the following import error: Could you try: git checkout master git reset --hard origin/master git clean -xdf make And then try again? The tests run fine over here. Thanks! Stéfan

1 0

Master branch fails tests?
by Juan Nunez-Iglesias Jan. 9, 2013

Jan. 9, 2013

Hi everyone, Am I doing something wrong? I can't get master to work on OSX; 6 tests fail with the following import error: ====================================================================== ERROR: Failure: ImportError (cannot import name denoise_tv_chambolle) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/loader.py", line 390, in loadTestsFromName addr.filename, addr.module) File "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/importer.py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/importer.py", line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/Volumes/Projects/skimage/skimage/feature/__init__.py", line 4, in <module> from .peak import peak_local_max File "/Volumes/Projects/skimage/skimage/feature/peak.py", line 3, in <module> from ..filter import rank_order File "/Volumes/Projects/skimage/skimage/filter/__init__.py", line 6, in <module> from ._denoise import denoise_tv_chambolle, tv_denoise ImportError: cannot import name denoise_tv_chambolle This is after running make all. If I do `git co ec3f3`, i.e. before implementation of `tv_denoise`, it runs fine. nuneziglesiasj@jni-lscc-mbp Thu Jan 10 15:45 ~/projects/skimage ((no branch))$ make test nosetests skimage Exception AttributeError: "'UmfpackContext' object has no attribute '_symbolic'" in <bound method UmfpackContext.__del__ of <scipy.sparse.linalg.dsolve.umfpack.umfpack.UmfpackContext object at 0x108caddd0>> ignored ...........................................................................................................................................................................................................................................................SSSSS.....SSSS.....................S......................SSS.....................................................S....................................................................................................................................................................................................... ---------------------------------------------------------------------- Ran 565 tests in 22.690s OK (SKIP=14) Any ideas?

1 0

Re: "No definition found"
by Juan Nunez-Iglesias Jan. 9, 2013

Jan. 9, 2013

Hmm. Well IPython seems to work fine with unicode docstrings in when you specify the encoding, in Python files at least... def foo(x): """Añadir 1 al número deseado.""" return x + 1 gives In [1]: import foo File "foo.py", line 2 SyntaxError: Non-ASCII character '\xc3' in file foo.py on line 2, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details but placing the line `# coding=utf-8` at the start of the file gives: In [2]: import foo In [3]: %pdoc foo.foo Class Docstring: Añadir 1 al número deseado. Calling Docstring: x.__call__(...) <==> x(...) So maybe it's a Cython thing? Science is tricky... ;) On Tue, Jan 8, 2013 at 2:14 AM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: > On Sun, Jan 6, 2013 at 10:35 PM, Juan Nunez-Iglesias <jni.soma(a)gmail.com> > wrote: > >> Not sure--but this also shows that IPython does not handle unicode > >> characters in a docstring correctly! > > > > Huh? Are you jumping to conclusions or did you test this? > > I patched the Cython docstring to remove all unicode > characters--everything then worked fine. > > Stéfan > > -- > > >

1 0

Re: When will 0.8 official be released?
by Johannes Schönberger Jan. 9, 2013

Jan. 9, 2013

I could do it in the coming weeks, but I have never done it before. Is there any step by step guide? To be honest I'd rather wait to avoid an invalid release... Am Mittwoch, 9. Januar 2013 schrieb Tony Yu : > > > On Tue, Jan 8, 2013 at 6:14 AM, Stéfan van der Walt <stefan(a)sun.ac.za<javascript:_e({}, 'cvml', 'stefan(a)sun.ac.za');> > > wrote: > >> Hi Isaac >> >> On Mon, Jan 7, 2013 at 8:14 AM, Isaac Gerg <isaac.gerg(a)gergltd.com<javascript:_e({}, 'cvml', 'isaac.gerg(a)gergltd.com');>> >> wrote: >> > I need the entropy function in the 0.8 version of scikit-image. I was >> > wondering when this version will be officially released so that C >> Gohlke may >> > provide a 64 bit package to support python 3.2. >> >> I am currently travelling, and was planning on doing a release >> beginning February when I got back. However, there's no reason I >> should be the bottleneck, so if any of the other team members feel up >> to cutting the release earlier I'd encourage them to do so. Tony, >> Andreas? >> >> Stéfan >> >> > I agree that version 0.8 is due. Unfortunately, I just moved half-way > across the country, and I'm getting ready to start a new job, so I don't > think I'll have much time to work on this release (at least, not in the > next couple of weeks). I'll probably have a little more free time starting > in February. > > Cheers, > -Tony > > -- > > >

1 0

Re: When will 0.8 official be released?
by Tony Yu Jan. 9, 2013

Jan. 9, 2013

On Tue, Jan 8, 2013 at 6:14 AM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: > Hi Isaac > > On Mon, Jan 7, 2013 at 8:14 AM, Isaac Gerg <isaac.gerg(a)gergltd.com> wrote: > > I need the entropy function in the 0.8 version of scikit-image. I was > > wondering when this version will be officially released so that C Gohlke > may > > provide a 64 bit package to support python 3.2. > > I am currently travelling, and was planning on doing a release > beginning February when I got back. However, there's no reason I > should be the bottleneck, so if any of the other team members feel up > to cutting the release earlier I'd encourage them to do so. Tony, > Andreas? > > Stéfan > > I agree that version 0.8 is due. Unfortunately, I just moved half-way across the country, and I'm getting ready to start a new job, so I don't think I'll have much time to work on this release (at least, not in the next couple of weeks). I'll probably have a little more free time starting in February. Cheers, -Tony

1 0

Contribution: circles and hough transform
by François Jan. 9, 2013

Jan. 9, 2013

Hi, On my spare time, I work on a code to implement a hough transform to detect circles. This is not implemented yet in skimage. Is Skimage interested in this implementation? (I don't want to spend much more time to polish the code if there is no need) If the answer is positive, it can be done in two steps: * add a method to draw circles. The current "circle" method is for disks. We need circles (very easy to write). This is already done, but in pure python. I saw that drawing methods are implemented in cython. I have never used cython before, but it must be easy (I guess). I implemented two methods (Bresenham or midpoint circle and Andres), both are useful I think. * write the hough algorithm for circle. Done for a Quick and dirty usage, but it's not suitable yet for integration (not safe). I would prefer to send one patch per step. Even if I already tackled bugs in some projects, I never done this kind of contribution before ;) François.

3 2

Re: skimage and opencv
by Isaac Gerg Jan. 9, 2013

Jan. 9, 2013

Does openCV have Python 3 bindings? Isaac On Thursday, December 27, 2012 5:06:08 PM UTC-5, 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, > > -- > François Boulogne.http://www.sciunto.org > > >

2 1