Trouble with idle from python 2.4.2 on SUSE linux 9.3
I've just installed python 2.4.2 from source - it works fine from the command line. But when I attempt to start idle, I am told: ** IDLE can't import Tkinter. Your Python may not be configured for Tk. ** I have tcl 8.4 and tk 8.4 on my system; can anybody provide me with some advice? Sorry if this is a FAQ; I've spent some time searching the net for helpful clues, and I am a python ultra-newbie. Thanks, Alasdair -- http://mail.python.org/mailman/listinfo/python-list
Re: Trouble with idle from python 2.4.2 on SUSE linux 9.3
Thanks - that did the trick! I wonder why it's not mentioned in the README, or (so far as I can tell) anywhere else? -Alasdair -- http://mail.python.org/mailman/listinfo/python-list
Arbitrary precision integer arithmetic: ceiling?
I need to apply the ceiling function to arbitrary sized (long) integers. However, division automatically returns the type of its operands, so that, for example: math.ceil(7/4) returns 1. I can use float, as in: math.ceil(7/float(4)), except that for very large integers float causes an unacceptable loss of precision. What is the best way of finding a ceiling of a quotient of arbitrary sized integers? Thanks, Alasdair -- http://mail.python.org/mailman/listinfo/python-list
Re: Arbitrary precision integer arithmetic: ceiling?
Thanks, all - you've been most helpful. By the way, what does // do? I haven't yet run down its definition in the manual. -A. -- http://mail.python.org/mailman/listinfo/python-list
Resize RGB image?
I can resize a 2d image "im" with a command something like: r,c = shape(im) im2 = resize(im,(r//2,c//2)) However, resize doesn't seem to work with an RGB image: r,c,n = shape(im) # returns, say 500 600 3 I then need to take each band separately, resize it, and put them all back together with dstack: imr = im[:,:,0] img = im[:,:,1] imb = im[:,:,2] imr2 = resize(imr,(r//2,c//2)) img2 = resize(img,(r//2,c//2)) imb2 = resize(imb,(r//2,c//2)) im2 = dstack((imr2,img2,imb2)) This works fine, but seems a little clumsy. Of course this could be done in one command: im2 = dstack([resize(im[:,:,i],(r//2,c//2)) for i in range(3)]) What I want to know is: is there a version of resize which can be applied directly to multi-band images, without having to apply to each band separately? Thanks, Alasdair -- http://mail.python.org/mailman/listinfo/python-list
Re: Resize RGB image?
Thank you for your speedy response! And yes, I was too hasty in firing off a
request without the necessary details.
And in fact the resize from the PIL Image module does work:
f = Image.open('bird-of-paradise-flower-1.jpg')
r,c = f.size
f2 = f.resize((r//2,c//2))
f2.show()
shape(f) # returns(768, 1024, 3)
shape(f2) # returns (384, 512, 3)
I think I was confused about all the different "resize" methods floating about.
Clearly I had been using the wrong one! But if f is defined - as I've just
done - as an Image image, then it will use the correct resize method.
I'll crawl back under my rock now.
-Alasdair
--
http://mail.python.org/mailman/listinfo/python-list
Imaging libraries in active development?
I'm investigating Python for image processing (having used Matlab, then Octave for some years). And I'm spoiled for choice: PIL and its fork pillow, scipy.ndimage, scikits-image, mahotas, the Python interface to openCV... However, PIL doesn't seem to be in active development. What I want to know is - what are the current "standard" libraries for image processing in Python which are in active development? I have quite a few image processing student notes which I'm thinking of converting to Python, but I'd like to use the most up-to-date library. Thanks, Alasdair -- http://mail.python.org/mailman/listinfo/python-list
Re: Imaging libraries in active development?
I take your point that not being actively developed doesn't necessarily mean that the software is bad - but in general healthy software is continuously updated and expanded to meet the needs of its users, or to take advantage of new algorithms or hardware. And in its current form PIL has a number of limitations: it doesn't allow linear filters of arbitrary size or shape, or non-linear filters (such as median filter) of arbitrary size. There doesn't seem to be built in support for standard imaging filters: Gaussian, Laplacian, LoG, edge detection, unsharp masking and so on. It doesn't seem to have support for color space conversions (RGB, YIQ, HSV etc). There don't seem to be standard edge detection routines (Laplacian of Gaussian, Canny, etc). And so on. Now maybe some of these can be found in other Python libraries, but I can't imagine I'm the only person who would ever want them in an imaging library. Other libraries (scipy.ndimage, scikits-image) do go a long way to addressing my concerns. Anyway, I was curious to know why PIL is lacking so much of what I would consider fairly fundamental imaging facilities, and why development seems to have stalled since 2009. On Thursday, 29 November 2012 05:14:30 UTC+11, Michael Torrie wrote: > On 11/28/2012 05:30 AM, Alasdair McAndrew wrote: > > > I'm investigating Python for image processing (having used Matlab, > > > then Octave for some years). And I'm spoiled for choice: PIL and its > > > fork pillow, scipy.ndimage, scikits-image, mahotas, the Python > > > interface to openCV... > > > > > > However, PIL doesn't seem to be in active development. What I want > > > to know is - what are the current "standard" libraries for image > > > processing in Python which are in active development? > > > > > > I have quite a few image processing student notes which I'm thinking > > > of converting to Python, but I'd like to use the most up-to-date > > > library. > > > > I'm curious. What features do you need that pil doesn't have? Other > > than updating pil to fix bugs, support new image types or new versions > > of Python, what kind of active development do you think it needs to > > have? Maybe pil has all the features the original author wanted and is > > pretty stable. To judge a package on how fast it's changing seems a bit > > odd to me. Obviously you want to know that bugs can get fixed of > > course. Perhaps none have been reported recently. -- http://mail.python.org/mailman/listinfo/python-list
Re: Imaging libraries in active development?
Thanks for the heads-up about OpenCV. I have in fact briefly looked at OpenCV (well, the documentation), and it does seem remarkably complete. And what it doesn't provide, such as image transforms (FFT, DCT etc), are offered elsewhere by other Python libraries. Probably the combinations of OpenCV, Scipy.ndimage and scikits-image would cover pretty much all of my needs. Thanks, Alasdair > Hey Alasdair, > > > > I believe OpenCV might do the trick for you: > > - it contains everything you seem to need (+ much much more); > > - it is efficient; > > - it is cross-platform; > > - it has a usable python interface since version 2.4; > > - it is not going away any time soon and is constantly improved; > > - it has an active user base. > > > > But (there is always a but), it also has some issues: > > - (the main one for me) documentation is often incomplete or even > > sometimes cryptic: the website (http://docs.opencv.org/) is great, but, > > IIRC, the docstrings are automatically generated from the C++ prototypes > > using Boost.Python; some trial & error is often necessary to find out > > what the parameters of a function should be; > > - it may be overkill if you just want to do some basic image processing > > (maybe scikits-image is a better choice there?). > > > > Hope this helps, > > > > Adrien > > > > Le 29/11/2012 07:53, Alasdair McAndrew a écrit : > > > I take your point that not being actively developed doesn't necessarily > > mean that the software is bad - but in general healthy software is > > continuously updated and expanded to meet the needs of its users, or to > > take advantage of new algorithms or hardware. > > > > > > And in its current form PIL has a number of limitations: it doesn't allow > > linear filters of arbitrary size or shape, or non-linear filters (such as > > median filter) of arbitrary size. There doesn't seem to be built in support > > for standard imaging filters: Gaussian, Laplacian, LoG, edge detection, > > unsharp masking and so on. It doesn't seem to have support for color space > > conversions (RGB, YIQ, HSV etc). There don't seem to be standard edge > > detection routines (Laplacian of Gaussian, Canny, etc). And so on. Now > > maybe some of these can be found in other Python libraries, but I can't > > imagine I'm the only person who would ever want them in an imaging library. > > Other libraries (scipy.ndimage, scikits-image) do go a long way to > > addressing my concerns. > > > > > > Anyway, I was curious to know why PIL is lacking so much of what I would > > consider fairly fundamental imaging facilities, and why development seems > > to have stalled since 2009. > > > > > > On Thursday, 29 November 2012 05:14:30 UTC+11, Michael Torrie wrote: > > >> On 11/28/2012 05:30 AM, Alasdair McAndrew wrote: > > >> > > >>> I'm investigating Python for image processing (having used Matlab, > > >>> then Octave for some years). And I'm spoiled for choice: PIL and its > > >>> fork pillow, scipy.ndimage, scikits-image, mahotas, the Python > > >>> interface to openCV... > > >>> However, PIL doesn't seem to be in active development. What I want > > >>> to know is - what are the current "standard" libraries for image > > >>> processing in Python which are in active development? > > >>> I have quite a few image processing student notes which I'm thinking > > >>> of converting to Python, but I'd like to use the most up-to-date > > >>> library. > > >> > > >> > > >> I'm curious. What features do you need that pil doesn't have? Other > > >> > > >> than updating pil to fix bugs, support new image types or new versions > > >> > > >> of Python, what kind of active development do you think it needs to > > >> > > >> have? Maybe pil has all the features the original author wanted and is > > >> > > >> pretty stable. To judge a package on how fast it's changing seems a bit > > >> > > >> odd to me. Obviously you want to know that bugs can get fixed of > > >> > > >> course. Perhaps none have been reported recently. -- http://mail.python.org/mailman/listinfo/python-list
