RE : [guidata/guiqwt] Re: pure python qwt
Pierre Raybaut
To be even more exact, the copies contain acceptable license terms/copyrights since v6.1.2a5 (available on PyPI until now) but v6.1.2a7 contains the very last license terms/copyrights (and is now available on PyPI).
However, more important than the license terms, please do remember that it’s an alpha release, so it’s still experimental and unfinished. So it’s too early to begin a big migration from PyQwt to python-qwt, *but* now is the time to begin testing it with your own code so that python-qwt may be ready even sooner in a beta state for more extensive tests.
De : Pierre Raybaut
Envoyé le :samedi 29 août 2015 23:13
À : guidata...@googlegroups.com
Objet :RE: [guidata/guiqwt] Re: pure python qwt
Uwe, I'm sure they will *not* be interested in more details 😊. And I'm sure that we will come to an agreement very soon: we are doing things so much more challenging every day.
And by the way, python-qwt v6.1.2a6, available on PyPI is at the same state as GitHub. So it doesn't have to be removed...! This is already the "official update" (it it does mean something: this is still an alpha release).
All old copies with the license issue/missing copyrights are not available for a while now.
De : Uwe Rathmann
Envoyé : 29/08/2015 17:57
À : guidata...@googlegroups.com
Objet : [guidata/guiqwt] Re: pure python qwt
On Mon, 24 Aug 2015 11:44:40 +0200, Carlos Pascual wrote:
> - do you consider qwt ready for use by 3rd parties?
Definitely not: all packages released so far are ignoring copyrights and
license implications !
If you are interested in more details see:
[1] https://github.com/PierreRaybaut/python-qwt/issues/11
[2] https://github.com/PierreRaybaut/python-qwt/issues/13
[3] https://github.com/PierreRaybaut/python-qwt/issues/14
[4] https://github.com/PierreRaybaut/python-qwt/issues/15
I'm happy to say that we made substantially progress, but I need more
time before I'm giving a final o.k. to it.
So please remove all copies ( including python-qwt 6.1.2a6 from https://
pypi.python.org/pypi/python-qwt ! ) and take care of not propagating it
even further. Instead use the current state from https://github.com/
PierreRaybaut/python-qwt or wait for an official update from Pierre.
According to the license:
The project - status today - is a mixture of MIT licensed and Qwt
licensed files - examples are under the PyQwt license. You have to find
out yourself, what this means for using it in your application.
Uwe
--
You received this message because you are subscribed to the Google Groups "guidata/guiqwt" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guidata_guiqw...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "guidata/guiqwt" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guidata_guiqw...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Carlos Pascual
Thanks a lot for your replies. I definitely am interested in the
licensing issues and relieved to see that there seems to be good
progress in solving them in spite of the difficult beginnings ;)
Errors done in "good-faith" may be annoying but should not matter in the
long term (specially among FOSS developers).
Now, assuming that the licensing issues will be overcome and once Pierre
catches his breath, I would still be interested in knowing about the
development model and performance (see my original questions).
Thanks again to both Uwe and Pierre for your replies and for sharing
your respective works.
Carlos
On Sat 29 August 2015 23:35:10 Pierre Raybaut wrote:
> To be even more exact, the copies contain acceptable license
> terms/copyrights since v6.1.2a5 (available on PyPI until now) but
> v6.1.2a7 contains the very last license terms/copyrights (and is now
> available on PyPI).
>
> However, more important than the license terms, please do remember
> that it’s an alpha release, so it’s still experimental and
> unfinished. So it’s too early to begin a big migration from PyQwt to
> python-qwt, *but* now is the time to begin testing it with your own
> code so that python-qwt may be ready even sooner in a beta state for
> more extensive tests.
>
>
> De : Pierre Raybaut
> Envoyé le :samedi 29 août 2015 23:13
> À : guidata...@googlegroups.com
> Objet :RE: [guidata/guiqwt] Re: pure python qwt
>
>
> Uwe, I'm sure they will *not* be interested in more details 😊. And
> I'm sure that we will come to an agreement very soon: we are doing
> things so much more challenging every day.
>
> And by the way, python-qwt v6.1.2a6, available on PyPI is at the same
> state as GitHub. So it doesn't have to be removed...! This is already
> the "official update" (it it does mean something: this is still an
> alpha release).
>
> All old copies with the license issue/missing copyrights are not
> available for a while now.
>
Carlos Pascual Izarra
Scientific Software Coordinator
Computing Division
ALBA Synchrotron [http://www.albasynchrotron.es]
Carretera BP 1413 de Cerdanyola-Sant Cugat, Km. 3.3
E-08290 Cerdanyola del Valles (Barcelona), Spain
E-mail: cpas...@cells.es
Phone: +34 93 592 4428
+----------------------------------------------------+
Uwe Rathmann
> development model
This project is a port of some subset of the Qwt C++ project ( 56000 vs
12000 lines of code ! )
From now on their might only be 2 options how to continue.
a) No own development and waiting for the next C++ version
b) Branching with the problem of becoming outdated
> performance
Almost all projects ( even the lamest duck ) claims to be "high
performant" and I wouldn't trust on any statement like this.
"Performance" always depends on the very specific use case, what usually
also includes application code. IMHO the only reasonable thing is trying
to understand what happens in which situation.
Let me give you 3 examples:
a) Line plots
With Qt5 the X11 paint engine is gone - instead the plot is rendered by
the raster paint engine before passing it to X11. Consequence is that
hardware acceleration is also gone with Qt5 ( I'm working on an OpenGL
canvas for Qwt 6.2, but unfortunately the Qt OpenGL paint engine doesn't
have that quality ).
Now it matters how important hardware acceleration is for you. For raster
graphics it isn't, for vector graphics ( f.e curves ) the difference is
significant.
But what means "significant": for a static plot of ~1000 points probably
not that much, for an application, that wants to replot in high refresh
rates a lot.
But at least one thing can be said in general: for line plots python-qwt
can't compete with a pyqt running the X11 paint engine - because of being
Qt5.
b) Raster data
Rendering an image that is displayed on screen is composed by requesting
values at any position from the application one by one. So f.e it is
possible to calculate those values on the fly when being requested
without having any memory footprint at all.
But of course you could also load gigs of values from disk into memory
and finding the value by interpolation algos.
So an answer about the Qwt memory footprint for displaying raster data as
image can't be given, as this all is decided in application code.
But as far as I can see python-qwt does not support displaying of raster
data at all at the moment.
c) Polygon clipping
Qt is known for doing clipping too late, with the consequence of having
potential performance issues. That's why Qwt does polygon clipping before
entering QPainter.
From the announcement it looks like python-qwt dropped the polygon
clipping. If this becomes a major performance issue depends on the
coordinates of the points and the current ranges of scales.
In situations, where the scale ranges are small compared to the bounding
rectangle of the curve a python-qwt application will probably show a
quite lousy performance in other situations you won't see any difference.
Uwe
Pierre Raybaut
Hi Carlos, Uwe and others,
Personally, I wouldn’t jump to conclusions at this stage of the “python-qwt” project.
So here is my unbiased view on the situation: I’m not attached to either “Qwt” or “python-qwt”; my only interest is to find the best solution for the future of our data processing software development.
Let’s start from the beginning. A lot of applications (here and there) are based on “guiqwt” which relies on PyQwt. PyQwt was the best choice in 2008 (when the “guidata” and “guiqwt” projects started) for plotting data efficiently. Since 2010, we know that there is a “PyQwt obsolescence” issue that we must solve in order to maintain our data processing software collection. In 2011, I started looking for an alternative to PyQwt. But then I was forced to step back from intensive software development at my work (I still am), so nothing happened except when I found some time to spare on this during my vacations (I started “python-qwt” at home during Christmas 2013).
I came rapidly to the conclusion that there were two solutions:
1. Write a pure Python version of Qwt – that’s “python-qwt” – which implements only the interesting part of the API (basically only the canvas and axes) ; “guiqwt” can already take care of image visualization very efficiently thanks to its C++ scaler engine.
2. Rely on an OpenGL-based solution (the best candidate seems to be “vispy”) and rewrite the intermediate layer of “guiqwt” which is currently interfaced with a Qwt-like API.
So, currently, with “python-qwt”, I’m exploring solution 1. which is clearly less performant than “PyQwt”. As Uwe pointed out, performance is a relative matter: the idea is to find out if the performance loss is acceptable for our applications. When executing “guiqwt” examples on a Core i5-2520M @ 2.50GHz, performance loss can be imperceptible (depending on the compiler used to build extensions ; there are still things to clear out of course). However, we still have to optimize “python-qwt” and evaluate it with our applications to really know if we are going to adopt this project for our future developments. I hope that we will be able to know if this is the solution before the end of the year.
If solution 1. does not fit our needs, we will switch to solution 2.
The plan is to be able to transform “guiqwt-2.3” into “guiqwt-2.4” (python-qwt) or to “guiplot” (vispy) before the end of 2016.
Independently from guidata/guiqwt, I think the “python-qwt” project may be of interest (even if we finally decide to switch to vispy for “guiqwt”). That’s why I wanted to make it public, so that people could benefit from this work and eventually use it to replace PyQwt in their own project if it fits their need.
Some answers @Uwe:
“This project is a port of some subset of the Qwt C++ project ( 56000 vs 12000 lines of code ! )”
Comparing the line of codes of a Python project with a C++ project has its limits (Python is leading to more compact code). A part from that, “python-qwt” does not implement the whole Qwt API, indeed. That’s because we don’t need it: “guiqwt” is providing the rest.
“Almost all projects ( even the lamest duck ) claims to be "high performant" and I wouldn't trust on any statement like this.”
Performance is a relative matter, I agree. We never stated that “guiqwt” was highly performant in absolute terms. We only wrote that it was more performant than “matplotlib”, which is undoubtedly true.
“a) Line plots” – “python-qwt can't compete with a pyqt running the X11 paint engine - because of being Qt5”
FYI, “python-qwt” is compatible with both Qt4 and Qt5. So, users can choose to use Qt4 if it's really necessary.
“b) Raster data”
“python-qwt does not support displaying of raster data at all at the moment”
As I wrote above, “python-qwt” does need to do support this feature because “guiqwt” is already supporting it and it proved to be a major asset (image visualization is very powerful within “guiqwt” thanks to the included C++ scaler engine – for example, an application of ours is showing and processing in real-time 20,000 x 20,000 pixel images: scaling, changing contrast, and applying any affine transform to the image in real-time – that is: we move a cursor to adjust a parameter and the image is refreshing real-time).
“c) Polygon clipping”
“From the announcement it looks like python-qwt dropped the polygon clipping […]In situations, where the scale ranges are small compared to the bounding rectangle of the curve a python-qwt application will probably show a quite lousy performance in other situations you won't see any difference.”
You’re perfectly right: this fits the warning you may read in “python-qwt” README. I think that polygon clipping is not necessary for our (internal) applications using “guiqwt”, so it doesn’t bother me but other users should indeed be aware of this limitation, in a very particular case. Maybe it could be implemented in the future, but right now I don’t see how to do it without a significant loss of performance.
Regarding the project future, Uwe is right to state that we have two options:
“a) No own development and waiting for the next C++ version
b) Branching with the problem of becoming outdated”
For now, I think that waiting for the next C++ version is not a good idea. Porting code from C++ to Python was not so easy and there is still a lot of work to do to optimize things. The next step could be to optimize code deeper than I did: you have to be smarter in Python than in C++ because milliseconds are easily lost if the algorithm is not efficient enough or if the data structure is too complicated and convulated. So the code base could evolve separately from its C++ counterpart.
Anyway, the Qwt API that we work with is so basic that I don’t imagine that the future evolutions would be hard to follow even if the code base has evolved since then.
So ==> option b).
Carlos, I hope that this message anwers you questions!
Cheers,
-Pierre
> From: Uwe.Ra...@tigertal.de
> Subject: [guidata/guiqwt] Re: pure python qwt
> Date: Mon, 31 Aug 2015 09:11:05 +0000
Carlos Pascual
My questions about performance are pretty well answered now.
Also Pierre's intentions for the future of python-qwt are much clearer
for us now.
Just one more question/clarification about the "Solution 2" scenario:
Suppose that we (in Taurus) decided to use only guiqwt for our plotting
(i.e. we stop importing PyQt4.Qwt in our code and import guiqwt only).
Now suppose that you come to the conclusion that python-qwt is not good
enough and you move to vispy. Would that mean that our widgets would
need to be adapted? or would the qwt->vispy transition be done inside
guiqwt maintaining API compatibility?
Cheers,
Carlos
Pierre Raybaut
> Now suppose that you come to the conclusion that python-qwt is not good
> enough and you move to vispy. Would that mean that our widgets would
> need to be adapted? or would the qwt->vispy transition be done inside
> guiqwt maintaining API compatibility?
Independantly from this migration, know that PyQt.Qwt5 is never imported in our applications: we are exclusively relying on guiqwt and you should do the same (it will help you migrate your widgets for both solutions: python-qwt or vispy).
Uwe Rathmann
> [ image processing ... ]
Comparing qwt and guiqwt here is somehow pointless as qwt doesn't have
any image processing at all. What Qwt has is a plot item that creates
images from 3D data ( z values -> color ).
The Qwt approach means, that algos are running on the data in application
code - not on images in libarary code, what has pros and cons. But when
the user has the most common use case of fast rendering with a low memory
footprint from 3D data only I would be surprised if guiqwt can do it
better.
There are also many details to take care of. F.e the coordinate system is
not necessarily equidistant due to the fact of rounding errors, when
drawing to a integer based coordinate system ( widgets ). When rendering
images you always need to take care of misalignments between other plot
items like points or grid lines.
But in the end it's like with, what I wrote about "performance": it
always depends and it is often difficult to compare. But even if we both
would try, we would fail as we both know enough about the other
implementation and which specific issues are solved there.
> python-qwt” does not implement the whole Qwt API, indeed ...
Dropping the slider/dials/wheels widgets and to focus on the classes of
the plot framework makes a reasonable subset, but when python-qwt not
even intends to cover a majority of the plot items I'm not sure if it is
a good idea to call it "python-qwt".
The README is wrong that explicitly states being a complete port beside
of 5 classes dealing with zooming. If you don't intend to have a port of
all the missing classes I suggest to make this clearer - you are creating
wrong expections otherwise.( See f.e https://ftp-master.debian.org/new/
python-qwt_6.1.2~a7-1~exp1.html )
> ... that’s because we don’t need it: “guiqwt” is providing the rest.
guiqwt focuses on specific use cases and adds extra value there, but the
reason, why so many classes have not been ported, is simply because guiqwt
doesn't need it.
It would be better to summarize, that you like to offer the plot widget,
the renderer to create PDF documents and a limited subset of plot items
( only 3 out of 16 ! ):
- QwtPlotCurve
- QwtPlotMarker
- QwtPlotHistogram
But featurewise this subset is on a level of what Qwt 2 offered - far
behind Qwt 5, what is currently supported by PyQwt.
ciao,
Uwe
Pierre Raybaut
guiqwt is focusing on visualization (adjusting the levels histogram, rotating or rescaling images are basic visualization features), not data processing like our internal software based on guiqwt. The image display engine of guiqwt is quite optimized: no memory copy at all is done on the displayed data, so unless doing memory mapping I don't see how to get a smaller memory footprint. Anyway, there was nothing like it in PyQwt5 at least. As for Qwt6, I can't tell because I don't know. Similarly, you should try it instead of blindly and systematically depreciating it.
Other plotting items are not supported just because we don't need them in guiqwt, that's all. I'm thrilled to learn that their were introduced in Qwt 3, 4 or 5, but, after all, you are posting on the guidata/guiqwt discussion group. 😊
I'll eventually clarify python-qwt README, in case someone is really interested in those other items. But please remember that a coding project is a living thing: maybe someone *constructive* will contribute by implementing those items.
Cheers,
Pierre
De : Uwe Rathmann
Envoyé : 31/08/2015 21:36
À : guidata...@googlegroups.com
Objet : [guidata/guiqwt] Re: pure python qwt
Uwe Rathmann
> Other plotting items are not supported just because we don't need them
> in guiqwt, that's all. I'm thrilled to learn that their were introduced
> in Qwt 3, 4 or 5, but, after all, you are posting on the guidata/guiqwt
> discussion group. 😊
and Carlos was interested in "how to get rid of our dependency on pyqwt5"
in *his* application.
I consider comparing features is somehow interesting in this context and
as I had checked the code already ...
There is also an aspect of your port, that might be interesting for
closed source applications: a GPL based element in the license stack is
gone.
But anyway, guess now I have given all I can contribute.
ciao,
Uwe
Carlos Pascual
C'mon guys!
I think that you both are actually giving pretty useful information in
this thread (do an exercise: re-read it just filtering out the uncalled
provocations and hostile remarks and you will see that it turns out to
be useful, informative and constructive) :)
With this I am just trying to say:
i) thanks Uwe and Pierre for your answers
ii) please do not let the anger ruin what could be a fruitful relation
for everybody. If python-qwt succeeds, Pierre can get contributors; Uwe
retains people from the python world around Qwt; and us -former PyQwt5
users- get an easier path of update.
Now, just to give you a hint of which aspects of this thread can be
interesting for some users such as me, here is an example on the kind of
decision that the Taurus community is facing:
a) re-writing all our plotting widgets from scratch (e.g. using
pyqtgraph, or vispy, or PyMca)
b) contribute to python-qwt so that our already-existing PyQwt5-based
widgets can use it (we would need to implement zooms and scales among
other things)
c) ditch our PyQwt5-based widgets and focus the effort on our also-
existing-but-less-mature guiqwt-based widgets (so that we do not care
about the missing parts in python-qwt because guiqwt provides them)
Option a) was the only one available to us two weeks ago. It is
expensive but it opens new interesting possibilities (mostly for 3D
visualization). Options b) and c) both seem to simplify the transition.
Their relative merits depend on how much work we need put on each one,
and on the level of support we can expect (by author and/or potential
community) and on the perceived long-term viability of python-qwt and
guiqwt compared to the alternatives in a).
I hope and wish that this post contributes to smooth things out a little
bit...
Cheers and thanks again...
Carlos
Pierre Raybaut
PythonQwt is making progress: it's stabilizing (documentation has been added). In the next few weeks, I'll try to test our most critical application in terms of performance (it allows manipulating images of 20 000 x 20 000 pixels: zooming in and out smoothly by moving the mouse with right-click button pressed, changing contrast in real-time using guiqwt's contrast panel, etc.). This will be the most important test and will eventually validate the approach of PythonQwt.
Regarding the choice between b) and c), it clearly depends on your code (taurus) and what will be missing exactly in PythonQwt. Our own strategy is to invest in guiqwt for the high-level features and leave the basic plotting features to PythonQwt (the base plot widget, the scales, the grid, and so on). In time, this strategy could allow us to switch to another plotting library more easily.
-Pierre