I have been using SimpleCV for find blobs to be used with a self-driving robot. The problem is when I call the findBlobs command in SimpleCV. When I completely block the lens of the Kinect Camera, PyGame crashes giving me this error:
Fatal Python error: (pygame parachute) Segmentation Fault
Sometimes it works and other times it just crashes, even when the lens is unblocked. It will almost always crash when i run it for longer than about thirty seconds.
I have re-installed and fixed many problems in SimpleCV and tried re-installing Pygame and it doesn't seem to help at all. Also, I am using the X-Box kinect as my camera source. I'm using Ubuntu 11.04.
Here is my exact code:
from SimpleCV import *
from SimpleCV.Display import *
from time import sleep
k = Kinect()
dis = Display()
while 1:
depth = k.getDepth()
depth = depth.invert()
depth = depth.erode()
blobs = depth.findBlobs(threshval=127, minsize=10, maxsize=0)
if blobs:
blobs.draw()
depth.save(dis)
sleep(0)
Kat here, I wrote the SimpleCV blob library.
There were a couple issues with the blob library that we found after we shipped the 1.1 release. The two big ones were that the blob library would hit the python max recursion depth and bail out. The second one stems from the actual underlying OpenCV wrapper and causes the pygame error when there are no blobs are detected by the blob maker.
The solution right now is to use the version that is in the master branch of our github repo. The patched version will also be available in the new SimpleCV 1.2 release which is slated for later this month. If you want to manually fix the code I have pasted the fixed snippet below:
In BlobMaker.py around line 55
def extractFromBinary(self,binaryImg,colorImg, minsize = 5, maxsize = -1):
#fix recursion limit bug
sys.setrecursionlimit(1000000)
if (maxsize <= 0):
maxsize = colorImg.width * colorImg.height
retVal = []
#fix all black image bug
test = binaryImg.meanColor()
if( test[0]==0.00 and test[1]==0.00 and test[2]==0.00):
return FeatureSet(retVal)
seq = cv.FindContours( binaryImg._getGrayscaleBitmap(), self.mMemStorage, cv.CV_RETR_TREE, cv.CV_CHAIN_APPROX_SIMPLE)
retVal = self._extractFromBinary(seq,False,colorImg,minsize,maxsize)
del seq
return FeatureSet(retVal)
Anthony one of the SimpleCV developers here:
Can you try changing the last line:
sleep(0.01)
Just to see if there is some type of issue going on where it can't process fast enough. I recently upgraded to Ubuntu 11.04 and I think there are a couple of python bugs I need to squash that popped up since 10.10.
Also if you could post this to our issue queue I would appreciate it:
http://github.com/ingenuitas/SimpleCV/issues
Fatal Python error: (pygame parachute) Segmentation Fault
This means that some code crashed, and now you need to debug it to find the problem. I assume you are learning something; might as well learn how to debug ;-)
Sometimes it works and other times it just crashes, even when the lens is unblocked. It will almost always crash when i run it for longer than about thirty seconds.
These are classic symptoms of heap corruption, or a data race.
I have re-installed and fixed many problems in SimpleCV and tried re-installing Pygame and it doesn't seem to help.
Why did you think it would? Your problem does not at all look like an installation problem.
So here is what you do: the tool for debugging heap corruption problems on Linux is valgrind. Run it like this:
valgrind python your-code.py
Unfortunately, default Python installation is not Valgrind-friendly, and above command will likely produce a lot of "uninitialized memory read" errors. You'll want to suppress most of them using this suppression file.
It may be possible to concentrate on errors that contain non-Python parts (and SimpleCV in particular). You are looking for invalid {read,write} ... N bytes after block ....
If you find such an error, you can try to debug it further with GDB, or report it to SimpleCV developers and hope for the best.
If you don't find the error, you can build a Valgrind-friendly version of Python (instructions), and try again.
If above run is Valgrind-clean, then you may have a race rather than heap corruption. Repeat with ThreadSanitizer.
Just replace your blob threshold with "-1"; I had the same problem and this fixed it.
Related
I am debugging a Python (3.5) program with PyCharm (PyCharm Community Edition 2016.2.2 ; Build #PC-162.1812.1, built on August 16, 2016 ; JRE: 1.8.0_76-release-b216 x86 ; JVM: OpenJDK Server VM by JetBrains s.r.o) on Windows 10.
The problem: when stopped at some breakpoints, the Debugger window is stuck at "Collecting data", which eventually timeout. (with Unable to display frame variables)
The data to be displayed is neither special, nor particularly large. It is somehow available to PyCharm since a conditional break point on some values of the said data works fine (the program breaks) -- it looks like the process to gather it for display only (as opposed to operational purposes) fails.
When I step into a function around the place I have my breakpoint, its data is displayed correctly. When I go up the stack (to the calling function, the one I stepped down from and where I wanted initially to have the breakpoint) - I am stuck with the "Collecting data" timeout again.
There have been numerous issues raised with the same point since at least 2005. Some were fixed, some not. The fixes were usually updates to the latest version (which I have).
Is there a general direction I can go to in order to fix or work around this family of problems?
EDIT: a year later the problem is still there and there is still no reaction from the devs/support after the bug was raised.
EDIT April 2018: It looks like the problem is solved in the 2018.1 version, the following code which was hanging when setting a breakpoint on the print line now works (I can see the variables):
import threading
def worker():
a = 3
print('hello')
threading.Thread(target=worker).start()
I had the same issue with Pycharm 2018.2 when working on a complex Flask project with SocketIO.
When I put a debug breakpoint inside the code and pressed the debug button, it stopped at the breakpoint, but the variables didn't load. It was just infinitely collecting data. I enabled Gevent compatibility and it resolved the issue. Here is where you can find the setting:
In case you landed here because you are using PyTorch (or any other deep learning library) and try to debug in PyCharm (torch 1.31, PyCharm 2019.2 in my case) but it's super slow:
Enable Gevent compatible in the Python Debugger settings as linkliu mayuyu pointed out. The problem might be caused due to debugging large deep learning models (BERT transformer in my case), but I'm not entirely sure about this.
I'm adding this answer as it's end of 2019 and this doesn't seem to be fixed yet. Further I think this is affecting many engineers using deep learning, so I hope my answer-formatting triggers their stackoverflow algorithm :-)
Note (June 2020):
While adding the Gevent compatible allows you to debug PyTorch models, it will prevent you from debug your Flask application in PyCharm! My breakpoints were not working anymore and it took me a while to figure out that this flag is the reason for it. So make sure to enable it only on a per-project base.
I also had this issue when I was working on code using sympy and the Python module 'Lea' aiming to calculate probability distributions.
The action I took that resolved the timeout issue was to change the 'Variables Loading Policy' in the debug setting from the default 'Asynchronously' to 'Synchronously'.
I think that this is caused by some classes having a default method __str__() that is too verbose. Pycharm calls this method to display the local variables when it hits a breakpoint, and it gets stuck while loading the string.
A trick I use to overcome this is manually editing the class that is causing the error and substitute the __str__() method for something less verbose.
As an example, it happens for pytorch _TensorBase class (and all tensor classes extending it), and can be solved by editing the pytorch source torch/tensor.py, changing the __str__() method as:
def __str__(self):
# All strings are unicode in Python 3, while we have to encode unicode
# strings in Python2. If we can't, let python decide the best
# characters to replace unicode characters with.
return str() + ' Use .numpy() to print'
#if sys.version_info > (3,):
# return _tensor_str._str(self)
#else:
# if hasattr(sys.stdout, 'encoding'):
# return _tensor_str._str(self).encode(
# sys.stdout.encoding or 'UTF-8', 'replace')
# else:
# return _tensor_str._str(self).encode('UTF-8', 'replace')
Far from optimum, but comes in hand.
UPDATE: The error seems solved in the last PyCharm version (2018.1), at least for the case that was affecting me.
I met the same problem when I try to run some Deep Learning scripts written by PyTorch (PyCharm 2019.3).
I finally figured out that the problem is I set num_workers in DataLoader to a large value (in my case 20).
So, in the debug mode, I would suggest to set num_workers to 1.
For me, the solution was removing manual watches every-time before starting to debug. If there were any existing manual watches in the "variables" window then it would remain stuck in "Collecting data...".
Using Odoo or Other Large Python Server
None of the above solution worked for me despite I tried all.
It normally works but saldomly gives this annoying Collecting data... or sometimes Timed Out....
The solution is to restart Pycharm and set less breakpoints as possible. after that it starts to work again.
I don't know way is doing that (maybe too many breakpoint) but it worked.
I have been fooling around for about a month with python now and something is bothering me.
I use the python(x,y) toolkit, which comes with the neat Spyder IDE.
My question concerns the UMD (User module deleter) of Spyder.
I found this graphics module on the internet, which helps one to do some simple graphic stuff in a python script (as far as I understand).
It is not like i'm stuck, but when I execute the folowing code:
import pylab as p
import graphics as g
window = g.GraphWin("tryout", 600, 600)
window.close()
print p.sqrt(4)
The output is:
>>>runfile(r'C:\some\folders\tryout.py', wdir=r'C:\some\folders')
>>>UMD has deleted: graphics
>>>2.0
line 1 is obviously o.k. and so is line 3, but I don't get line 2.
Also, the provoked window flashes in and out of the screen, as it should.
Line 2 doesn't seem to do any harm, and i can perfectly rerun the file as many times as I wan't, but I want to know where it is comming from.
AFAIK UMD forces the interpreter to reload a module everytime a script is run.
Does the displayed message mean that 'it' has deleted the references to the module, because it isn't used anymore, or is it something else? Or does it mean something is wrong, and will it 'hurt' my code should I add more afterwards?
Note: first question, so please comment the crap out of it to help me improve my asking skills.
EDIT: i tried shifting around the test line print p.sqrt(4), and found out that it doesn't matter where I put it. If its the first line after importing the modules, it still raisses the message before showing sqrt(4)
Short Answer:
Perhaps deleted is not the best word in the message you mention. It should be reloaded, which is what UMD is really doing and because is way less confusing. I'll fill an issue for this in our issue tracker.
Long answer:
UMD reloads not only your script but also all the local modules it depends on. By local I mean modules outside your Python installation and over which you have writing permissions.
The idea is that next to your script, perhaps you have developed a library of auxiliary functions to go with it. So you most probably want to reload that library too, so that any changes to it are reflected at run time.
I know this is not your case, so if you want to remove that message, you can go to:
Tools > Preferences > Console > Advanced settings > User Module Deleter
and deactivate the option
Show reloaded modules list
Few days ago I went into searching for a good way to make a simple computer vision system. OpenCV library is something I need but it proved hard to learn with Python especially after OpenCV 2.4.3 update which have very slim Python related documentation. So I now understand that there was a bunch of changes in OpenCV, for exaxmple
import cv
is now
import cv2
And there is bunch of modules that is missing. I mean, yes there are examples of the new python-opencv syntax but it's very narrow and proven to be hard to understand.
For example:
Example in official documentation for Python code
cv2.cvtColor(src, code[, dst[, dstCn]])
I know what this code means and how to use it, at least I think i know. But writing source and color code does nothing just give me :
Traceback (most recent call last):
File "C:\FILEFOLDER\tut.py", line 11, in <module>
cv.cvtColor('proba.jpg', 'CV_RGB2GRAY')
TypeError: an integer is required
Or if i try to write code like variable:
Traceback (most recent call last):
File "C:\FILEFOLDER\tut.py", line 11, in <module>
cv.cvtColor('proba.jpg', CV_RGB2GRAY)
NameError: name 'CV_RGB2GRAY' is not defined
So is there any Python related reference document/tutorial/book/guide for newest OpenCV with the ground up explanations that does not confuse newbie like me with unwanted code examples for C++ or Java?
I think you are taking it in the reverse path.
Actually, with the new cv2 module, OpenCV has become far more simple compared to old cv interface. Not just simple, but very fast and highly productive, due to the Numpy support. Only thing is that, we should know how to use it appropriately.
Here, you should use the function as follows :
img = cv2.imread('pic.jpg')
gray = cv2.cvtColor(img,cv2.COLOR_BGR2GRAY)
I would like you to visit one SOF which shows some comparison between both the modules : What is different between all these OpenCV Python interfaces?
Another one SOF is here, which is a simple demonstration on how you can speed up the code with Numpy support : Performance comparison of OpenCV-Python interfaces, cv and cv2
You need not learn C++ or C to use OpenCV, although C++ is the official language. Still, Python-OpenCV has good support. Once you get a grip on how to use OpenCV, you will be able to convert C++ codes into Python yourself. Then you can learn OpenCV from C++ tutorials also. For example, I started learning OpenCV from "Learning OpenCV" by Gary Bradsky which is completely in C++. At that time, there was only cv interface.
As you mentioned in your comments, opencvpython.blogspot.com has some introductory tutorials. I started it focussing newbies in OpenCV.
Also, check this SOF for more tutorials : Books for OpenCV and Python?
To take it from another angle and allow you to run older code with new OpenCV installation versions...
First off the move from cv to cv2 has to do with the library using different data structures for a lot of functions. The easiest way to tell if a function has changed between cv2 and cv is that cv functions start with a capital. Reworked cv2 functions seem to always have the first letter in lowercase. So if you are using an old book or old examples, you can still use the legacy cv. cv is now simply embedded in cv2. Simply use the following at the top of your scripts
import cv2
import cv2.cv as cv #required for old code not to be changed
This allows you to simply run older code without changing it. I will demonstrate with your function call here. You had...
cv.cvtColor('proba.jpg', 'CV_RGB2GRAY')
The first thing I notice is that your function may be called wrong. (Given first letter of function is lower case it should start with cv2 not cv). Second is the 'code' you are passing the function. 'Codes' are members (coding noob here, forgive me if some of my vocab is inaccurate) of cv2 and cv but not always the same. You have 'CV_RGB2GRAY'. First off, no quotes. This is a cv 'code' not cv2. Also you are missing the 'cv.' in front. To demonstrate here is how I believe your function should be called for old cv version:
cv.CvtColor('proba.jpg', cv.CV_RGB2GRAY) #Assuming you used listed imports
cv2.cv.CvtColor('proba.jpg', cv2.cv.CV_RGB2GRAY) #Assuming you skipped second import
And now cv2...
cv2.cvtColor('proba.jpg', cv2.COLOR_RGB2GRAY)
There you go, I hope this helps. Remember that given python runs off of scripts you can type anything you are unsure of directly into command line. This does wonders for helping me build my understanding (I first used python 5 days ago). For example if you were wondering why it wanted an integer in your function, when you type
cv.CV_RGB2GRAY
directly into the python command line, it spits '7' (handy that it is an int) back at you. The cv2 version spits out '7L'. Just remember to use the WaitKey() function now and again in some form otherwise highgui may not have the required time to process some commands, in some situations. Well that wraps it up. Sorry if I covered some things that were already covered or referenced to. If I did feel free to delete it, admins.
Not sure what the above error means. I just installed ghmm on my mac and get this error every time I do a import ghmm. I do not get this message on my ghmm install on my linux machine and other than that all functions appear to be fine.
I wondering if anyone has seen this before and if there's anything I can do to get rid of this. The only thing I did different between the two installs was the autogen.sh file was refering to "libtoolize" which doesn't exist on my mac so I changed it to its replacement "glibtoolize" which allowed it to compile and install fine.
Any suggestions on what this error actually means(and hopefully how I can solve it) would be great.
(I couldn't find the answer on google but this program does not appear to be specific to ghmm)
I'm willing to be corrected on this, but at a guess I'd say this has nothing to do directly with ghmm or your compile tools. I think the error message you're seeing is coming from the BSD random number functions that OSX uses (they are documented here).
Assuming that ghmm is causing the warning (and not python), it might be possible to configure the build process to use plain old rand or some other PRNG. Alternatively, maybe you can find the right place to add a call to initstate() (see above doc link) to provide the state information it wants.
This bit from the man page probably points to your problem:
If initstate() is called with less than 8 bytes of state information, or if setstate() detects that the state information has been garbled, error messages are printed on the standard error output.
eaj is correct that initstate needs more than 8 bytes for state information. The best way to do this for ghmm is with either the --enable-gsl or --with-rng=bsd option for ./configure. --with-rng=bsd makes the type "ghmm_rng_state_t" 8 bytes instead of 1. See rng.h in the ghmm directory.
The ghmm web site says this about "libtoolize":
Mac OS X: 10.6 ships with a broken libtool which breaks the installation (and it also ships with Python 2.5, so you need an update for that). James Howard posted a solution on the mailing list: [Ghmm-list] Compiling in OS X 10.6
http://sourceforge.net/mailarchive/message.php?msg_id=25874107
HTH
I'm using Python 2.6 against OpenCV 2.0. I've started a file capture and pulled frames. I've displayed the image to make sure it's valid. When I call this routine, python crashes:
def SmoothImage(self,SmoothingMaskSize=3):
temp=cv.CreateImage(cv.GetSize(self._lpImage),self._lpImage.depth,self._lpImage.nChannels)
cv.Smooth(self._lpImage,temp)
self._lpImage=temp
I've also tried smoothing it in-place, using cv.Smooth(self._lpImage, self._lpImage)
I'm new to Python- am I missing something obvious?
Thanks!
The bindings that come with the OpenCV 2.0 installer are buggy; I had similar problem where some very simple operations triggered crashes. Compiling from the source should fix it.
If you don't need access to the object-oriented parts of OpenCV, you should take a look at ctypes-opencv, which is a better set of python bindings. It is lovingly hand-crafted, in contrast to the SWIG-generated bindings that come with OpenCV, and I have never found any bugs in it.
http://code.google.com/p/ctypes-opencv/
Can you isolate the problem by removing the class definition? I get this working:
planes = [cv.CreateImage(cv.GetSize(image), cv.IPL_DEPTH_32F, 1) for i in range(3)]
cv.Split(image, planes[0], planes[1], planes[2], None)
for plane in planes:
cv.Smooth(plane, plane, smoothtype=cv.CV_GAUSSIAN, param1=9, param2=0, param3=0, param4=0)