Pending release of 0.3

[SirVer]

On 5 Nov., 15:27, Chris Colbert <sccolb... at gmail.com> wrote:
> On Thu, Nov 5, 2009 at 3:16 PM, SirVer <sir... at gmx.de> wrote:
>
> > Hi,
>
> > On 4 Nov., 15:04, Stéfan van der Walt <ste... at sun.ac.za> wrote:
> >> 2009/11/4 SirVer <sir... at gmx.de>:
>
> >> > Stefan, concerning my GUI branch:
> >> > I played around with pyqt and QImages and they just couldn't deliver
> >> > what I needed: Speed.
>
> >> I'd like to see some benchmarks that support this, because it should
> >> be the cost of 2 python calls + whatever time the GUI uses.  QImage is
> >> fast when loading directly from a numpy array.  I'm not sure, with the
> >> copying that you have to do into a texture, that OpenGL can do any
> >> better.
> > I did some benchmarks, but unfortunately I do not have the code
> > around. I created QImages and painted them directly in PyQt. It was
> > reasonable fast, but I couldn't reach the performance I have with a
> > QGLWidget which delivers easily 300fps or 60fps in 12 different
> > windows. I'd rather not hack this again since this issue is somewhat
> > settled for me and I'd prefer spending my coding time on other itches
> > I have.
>
> > I still think that PyQt is a much bigger dependency then PyOpenGL -
> > and even so: both are optional and only needed when GUI stuff in real
> > time should be performed.
>
> I think you're not really grasping the idea of "plugin"
Well, I understood the principle of plugin quite well; BUT the plugin
architecture does not allow real time display of images right now. It
won't be possible to implement it that way.
AND there are users who will need this and might need it in image
processing tasks. The question here is just if and if yes how to
implement this.

If my code and my attempts are not to be included in scikit.image, so
be it. I will continue to use it anyway; i just think they are useful
and WANT to contribute them to the public.

>
>
>
> > Cheers,
> > Holger
>
> >> Regards
> >> Stéfan