We Keep Coding

GPU rendering images with Python cv2 on Raspberry Pi

I am using the Raspberry Pi 2 to load large resolution images using opencv. I have sketch running, but without apparent "OpenGL" support as the opencv library states that it is not supported:
OpenCV Error: no OpenGL support (Library was built without openGL support)
I attempted to install pyOpenGL, but this had no effect. I am pretty new to graphics programming, so I'd take any suggestions on how to render to the GPU of the Raspberry Pi.

Ive stumbled across a Python friendly module that contains a GLSL API with quite a bit of examples :
http://pi3d.github.io/html/

You shouldn't need to deal with the gpu. Try following this blog, as it seems to have OpenCV install instructions. You might want to set INSTALL_PYTHON_EXAMPLES ON, but that is the only difference I could see.
Then you should be able to use it with python. If not, you may need to add it to your PATH.

wxPython GUI killed by enthought

I am writing a wxPython GUI. For certain functionality this requires that I use the Enthought distribution of python, but when I upgraded to Canopy it completely breaks my GUI. When I call up a certain window, everything freezes and I have to force quit. I don't get any kind of error message or traceback, just a freeze.
I am using the 64 bit Canopy, version 1.4.0.1938, and wxPython 2.9.2.4.
I am looking for either of two kinds of advice. 1. What is a good debugging protocol in this kind of situation? 2. How to get wxPython and Canopy to play nice?
I greatly appreciate any suggestions. I am happy to include any code that might be helpful, but I suspect that this is not particularly specific to my code.
edit:
I need the Enthought distribution specifically because my GUI builds on older code that uses some of the data analysis and plotting that EPD provides. This GUI actually incorporates and streamlines several older GUIs for analyzing paleomagnetic data.

This question is inaccurately titled and both your question and your own answer to it are inaccurate and incomplete. On the evidence, and from your comments on the Enthought knowledge base, your problem is twofold:
1) You want to use WXPython 2.8 in 64-bit Python on OSX. This is a fundamental technical impossibility because WxPython 2.8 uses Carbon OSX graphics, which is not supported for OSX 64-bit programs.
2) Failing that, you expect your program to run unmodified with WxPython 2.9 but apparently you have not taken any steps to migrate it to WxPython 2.9. See http://wxpython.org/migrationguide.php.

(Edited 5/6/2014)
My temporary solution was installing the 32 bit version of Canopy and then using the Package Manager to install an older version of wxPython (2.8.10.1). This worked temporarily, until I was able to get to the actual cause of the error.
https://support.enthought.com/entries/22601196-wxPython?page=1#post_22146884
The real problem did indeed turn out to be the version of wxPython.
The specific issue was calling ShowModal() instead of simply Show() for the main window of the GUI, which apparently worked in wxPython 2.8 but caused a freeze in 2.9. The code now thankfully works with 64 bit Canopy. Thanks to Jonathan March for pointing me in the right direction.

Python - Best GUI library for the job?

I've been using WxPython and I've tried Tk, but it seems that, while both are good and I'll likely use them for other projects, neither of those appear to be capable of accomplishing the things that I want for my current project (which is fine, they're good at what they do).
Basically what I'm looking for is something that will allow me to make rich graphical GUIs. My specific goal is a window that will draw bitmap buttons, resize the parent window automatically to fit them, and possibly animate the resize with a slide effect and have the buttons fade in. Also being able to have my own window border style instead of the inbuilt one is important to me.
This particular project will be Windows only, so non-portable libraries are fine in this case, though portable ones would be great too.
If I missed how this can be done in either WxPython or Tk, I'm all ears.

PySide: http://www.pyside.org/
The PySide project provides
LGPL-licensed Python bindings for the
Qt cross-platform application and UI
framework. PySide Qt bindings allow
both free open source and proprietary
software development and ultimately
aim to support all of the platforms as
Qt itself.
The Windows version of PySide is quite new and may be considered as a beta version. PySide is API compatible with PyQt.

How about PyQt?
http://www.riverbankcomputing.co.uk/software/pyqt/intro

Just sharing my opinion: Kivy.
Innovative open-source library. Supports both 2.x and 3.x versions of Python.
Kivy - Open source Python library for rapid development of applications
that make use of innovative user interfaces, such as multi-touch apps.
Kivy is based on OpenGL ES 2 and includes native multi-touch for each platform and Android/iOS. It’s an event-driven framework based around a main loop, and is thus also suitable for game development.

Try Pyglet. Its a library for python that makes using OpenGL very easy. You can draw pretty good 2d interfaces using Quads.

I can't tell you what is best because that is subjective but I can give you another option: PyGTK
PyGTK lets you to easily create programs with a graphical user interface using the Python programming language. The underlying GTK+ library provides all kind of visual elements and utilities for it and, if needed, you can develop full featured applications for the GNOME Desktop.
PyGTK applications are truly multiplatform and they're able to run, unmodified, on Linux, Windows, MacOS X and other platforms.

CPython vs. Jython vs. IronPython for cross-platform GUI development [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm thinking of making some kind of experimental IDE for digital hardware design. So I can't decide witch platform to choose.
I'm going to have text-editor with syntax highlighting, some vector graphics and lots of tabbed windows.
My goals:
1. to make GUI using as less custom components as possible.
2. to make it as cross-platform as possible
(I know already that CPython and Jython are cross-platform-friendly, but what about IronPython+Mono?)
So - the question is about GUI - what should I choose?

IronPython with Mono is cross platform - to whatever platforms supported by Mono, and for the feature set supported by Mono (which pretty much means Windows Forms is supported fairly well). Other options for GUI toolkits are available, however, which may provide better "cross platform" capabilities, or at least a better feel on non-Windows platforms.
CPython will depend on the GUI suite you choose. Personally, I've found CPython with PyQt to be the most usable, cross platform GUI option from Python. It's very powerful, feature-rich, and works quite well.
Jython will work, but I personally don't like the GUI options as much (this is a 100% personal preference, however).

I'd say that if cross-platform is a goal, forget IronPython. A lot of people hate the dependency hell it causes so it'll be too much work to get it up in running in some OSes/distributions. Jython will suffer this also, albeit to a lesser degree.

Well, Mono does not come with the base of most Linux distributions. It's not a terribly lightweight dependency either, and I think Java is considerably more likely for people to already have. Would you plan on using "Winforms" with Mono? If so, and you don't have experience with Winforms, read about what others have to say :-) The other .NET GUI toolkit is WPF, which unfortunately Mono has no plans to implement.
Jython would be better too, because you can use SWT, which renders native widgets and provides lots of layout possibilities easily. Or you can use Jython with Swing, or whatever else -- even AWT if you love ugliness.
I really like wxPython (which you can use with CPython, which is on most distros by default), because it renders good-looking native widgets in OSX, Windows and Linux (I've only seen the Gnome widgets in person). wxPython is by far the easiest to use GUI toolkit I've used -- even programatically (i.e. layout without Glade or similar). I've also used SWT, which I found quite nice, and Swing, which I personally don't really like the looks of, and Winforms, which was a nightmare to try to do even simple layouts with.
Here's a quick comparison of the existence of the interpreter/language runtime by OS
CPython
Windows - Probably not installed, and you'd have to make a non-python installer install it with your software :-P
Linux - Probably installed (Ubuntu, Gentoo and RedHat all have system tools that are written in Python and run on CPython)
Mac - Preinstalled on OSX
Jython
Windows - Probably installed at some point in my experience, though it doesn't come with
Linux - Probably installed, but more importantly nobody would hate you for depending on it like Mono
Mac - Preinstalled on OSX ("Mac OS X Leopard comes with J2SE 5.0 preinstalled, based on JDK 1.5.0_13_b05" -- Apple's site)
IronPython
Windows - Will probably run fine because I bet most people have at the very least .NET 2.0 if they have a recent version of Windows
Linux - Probably not installed -- the only application with which I've used Mono on Linux was Rasterbator, which worked well but I felt weird putting .NET on Linux
Mac - See above
I would choose a GUI toolkit first, since that will very much impact the user experience and overall difficulty (I would choose wxPython but SWT would be a close second) then consider the above as well maybe as a tiebreaker.

I faced this same question roughly a year ago. After looking at all the alternatives, I ended up with CPython and PyQt. IMO, Qt/PyQt is by far the best choice amongst all of the Python GUI toolkits. After hitting many bugs in wxPython I switched to PyQt and never looked back. Qt/PyQt are much more solid than the wx toolkits in my experience.
I use the exact same code base and build stand alone executables with PyInstaller for Windows and Py2App for the Mac (PyInstaller can be used for Linux as well). Because these builders embed the Python interpreter and all of the dependencies, it takes a lot of the hassle away. The only rub is that you'll need both a Windows and Mac to do the builds. Getting all of the configurations correct can be a pain too, but it's possible and time worth investing.

Take a look at comparable GUI's written in python/jython/ironpython. Look for programs that you like and find out what they use. I guess most if not all will be written in cpython + gtk or cpython + qt. I think all gui toolkits in python are cross platform.

Java is the most portable platform. Jython is written in 100% pure Java. 'Nuff said.
BTW I just switched a CPython/GTK project to Jython (trying to remove as much unmanaged code as possible), the only problem is that Jython is at 2.5 still, which kind of sucks when you're used to 2.6/2.7/3 :)

There are plenty of answers already, but I'd like to add one important thing - regardless of which library you learn, most of the principles will be the same when you move to another library.
I don't know about Qt, but for most graphics programs (in PyGTK or Tkinter) the best thing to do, as far as editing goes, is to use a PIL image (or something similar) to draw on and then draw that image on your canvas widget, otherwise you can lose pixel data if your window gets covered.

You may use Python 2.7 or 3.1 (CPython) with ttk (in Standart Library in 2.7, 3.1), ttk support themes (looks nice and very simple coding)
(1-st screen is text-editor with tabs and syntax highlighting) ttk screenshots

OpenGL in Python with Snow Leopard?

I'm interested in playing around with OpenGL in Python. I've used OpenGL in C++ and Objective-C, but I don't have much experience in Python. I'm wondering if there's a good tutorial that works in Snow Leopard. I'd prefer to stay in 64-bit mode if possible, since I've heard 32-bit programs require loading a lot of extra 32-bit libraries.
I've already tried a PyOpenGL/wxPython tutorial. When I ran the code, it crashed with this message:
ImportError: /System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/_core_.so: no appropriate 64-bit architecture (see "man python" for running in 32-bit mode)
It looks like there's a bug in wxPython that prevents it from working on a 64-bit system.
I also looked at Pyglet, but they have a similar issue. They provide a work-around (setting Python to 32-bit mode), but it doesn't look like they're going to fix it.
Finally, I looked at PyGLUT, but I think it's only for Windows.
Are there any other libraries that would let me access OpenGL and draw on the screen? Again, I'd prefer to stay in 64-bit mode, but if nothing works, I'll switch to 32-bit and try wxPython or Pyglet again.
Edit: I've also tried PyGame. It depends on SDL which is broken in SL. I thought about trying to use Cocoa through PyObjc, but the Xcode Python application templates have been removed.

I've used PyOpenGL 3.0.0 quite successfully on Snow Leopard. It uses ctypes, so it should be making 64-bit calls if those libraries are available (and Snow Leopard's Python includes a 64-bit version). I haven't used the wxPython stuff with PyOpenGL so that's where you might be running into problems, but PyOpenGL also includes GLUT, which both run fine.

There's probably no good reason to avoid 32-bit mode. Unless your Python programs need to larger address space, of course.

You could try pygame. Pygame is a python wrapper around SDL. According to their website they have Max OS X binaries. Here is a simple example of using pygame with OpenGL. Once you are able to create the window and handle events most OpenGL programming is just like it would be in C or C++, but with some added python goodness. For OpenGL a great tutorial is NeHe.

Also when programing with OpenGL in python remember that Python datastructures can be rather slow when it comes to requirements for 3D graphics. PyGL developers for example recommend using ctypes for operations that concern graphics, since that way you can get enough performance for some complicated geometry with bareable FPS.