New `viewer` subpackage (was [Re: Imshow and Linescan - first version])

Tony Yu tsyu80 at gmail.com
Fri Mar 23 09:46:12 EDT 2012


2012/3/18 Stéfan van der Walt <stefan at sun.ac.za>

> Hey, Tony
>
> On Fri, Mar 16, 2012 at 6:49 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> > Possible Con
> > ------------------------
> > Someone mentioned a while back that it would be a good idea to keep
> skimage
> > focused on the basic toolset, and then a separate package could build
> off of
> > it.
> >
> > Counter-argument: This infrastructure (so far, at least) is fairly
> > lightweight, and I imagine the biggest area of growth would be the
> > plugins---most of which would just provide an interactive interface to
> > skimage functions.
>
> This is the way I see it too: one of skimage's most important
> contributions is to provide an easily-accessible Python platform for
> building image processing solutions.  This exactly means having good
> pipelines, good display, and all the tools needed to build a complete
> solution.  Some of the algorithms may be obtained from elsewhere
> (e.g., opencv)--but even so, building a solution using those packages
> is currently still a pain.  So, I see the construction of these basic
> tools and building blocks as a fundamental part of what we're trying
> to do.
>
> > Counter-argument: skimage would provide the simplest possible interface
> for
> > adding interactivity (taking advantage of Matplotlib tools for plotting
> > histograms, etc and its support for multiple gui toolkits). A separate
> > project would be ideal for gui-toolkit--specific viewers (which could
> > potentially be significantly fast) since it would likely take more code
> to
> > do some of these things (I could be wrong about this). Also, I assume
> more
> > people using skimage would know matplotlib over any specific backend.
>
> I think from the start we assumed that we'd be building tools on
> Matplotlib and Qt.  If something better comes along, we should
> consider it--of course--but in the meantime it still seems like a
> reasonable choice.  If the plugin infrastructure can be improved to
> make it easier to build external tools, I'm also all for that.
>
> > I'd like to come to some sort of consensus, if possible, so please---if
> you
> > *any* opinions on this---let your voice be heard.
>
> I guess my opinion is obvious, but for the record: I'd love to include
> this work directly as part of skimage.  But, if that's not to be, I
> still encourage it whole-heartedly!
>
> Stéfan
>

Since there weren't any objections, I added a new `viewer` subpackage in PR
165 <https://github.com/scikits-image/scikits-image/pull/165>.

Sorry for the big commit: the full commit history can be found in another
repo <https://github.com/tonysyu/skloupe>. The main parts are the viewer
base classes<https://github.com/tonysyu/scikits-image/blob/mpl-viewer/skimage/viewer/viewers/core.py>
and
the plugin base
class<https://github.com/tonysyu/scikits-image/blob/mpl-viewer/skimage/viewer/plugins/base.py>.
The rest of the code just demonstrates what this backbone allows. If
nothing else, you can play around with the
examples<https://github.com/tonysyu/scikits-image/tree/mpl-viewer/examples>
.

I plan on adding some sort of "How to write a custom Plugin" documentation,
but Guillaume didn't seem to have much trouble writing a ContrastSetter
plugin even without that :)

Cheers,
-Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120323/5bc338e8/attachment.html>


More information about the scikit-image mailing list