From ralf.gommers at googlemail.com Mon Jan 2 02:22:42 2012 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 2 Jan 2012 08:22:42 +0100 Subject: Need an advice In-Reply-To: References: Message-ID: On Sat, Dec 31, 2011 at 6:51 AM, Tony Yu wrote: > > On Fri, Dec 30, 2011 at 5:48 PM, Ralf Gommers > wrote: > >> >> >> On Fri, Dec 30, 2011 at 8:05 PM, Tony Yu wrote: >> >>> >>> >>> On Fri, Dec 30, 2011 at 1:19 PM, Ralf Gommers < >>> ralf.gommers at googlemail.com> wrote: >>> >>>> >>>> >>>> On Fri, Dec 30, 2011 at 5:46 PM, Tony Yu wrote: >>>> >>>>> >>>>> >>>>> On Fri, Dec 30, 2011 at 8:20 AM, Nadav Horesh >>>> > wrote: >>>>> >>>>>> Remarks for the convolution subpackage: >>>>>> 1. The __init__.py should be probably changed to >>>>>> >>>>>> from ext import pyconvolve as convolve >>>>>> >>>>> >>>>> Agreed. Alternatively, the c-method could be renamed so that the >>>>> python method in ext can be named convolve. >>>>> >>>>>> >>>>>> 2. The test_convolution.py file is very instructive. It should be >>>>>> polished a bit. I think it would be worthwhile to add also >>>>>> scipy.signal.sepfir2d and cv2.sepFilter2D to the test. >>>>>> >>>>> >>>>>> 3. I found the convolve speed in par with cv.convolve2d (it can be >>>>>> slower or faster depending on the kernel) >>>>>> >>>>>> Nadav >>>>>> >>>>> >>>>> Thanks for testing the code. >>>>> >>>>> I've got the code compiling on my system now, so I was able to clean >>>>> up a few things. Could you update to what's currently on my >>>>> skimage-convolution branch to check that it builds on your system? If not, >>>>> what flags do you have to change/add to get it to compile? >>>>> >>>>> -Tony >>>>> >>>>> P.S. If any one else is building this on OS X: ppc compatible builds >>>>> is turned on by default (at least on my system). This should be turned off >>>>> before building. Add the following line to ~/.profile, or just run it right >>>>> before building: >>>>> >>>>> export ARCH_FLAGS="-arch i386 -arch x86_64" >>>>> >>>> >>>> Can you explain why is this necessary? >>>> >>>> In convolution/setup.py I also see you add "-ffast-math", which is a >>>> GCC-specific flag. It's better to remove it I think, it may give problems >>>> with other compilers. >>>> >>>> Ralf >>>> >>> >>> On my system at least, running gcc will, by default, add "-arch ppc" >>> along with i386 and x86_64. As far as I can tell, PPC doesn't support SSE, >>> which is used by this implementation. >>> >> >> That's true. I can't tell for sure, but it seems that this code is not >> optional. Meaning PPC is unsupported, and the ARCH_FLAGS need to be defined >> on OS X. I'm only a very occasional user now so it doesn't bother me too >> much, but isn't this a large penalty for the benefit you get? >> > > Well, I assume that we would be able to add a check to disable the build > on unsupported architectures. As far as, whether it's worth it: I don't > know. Is PPC very common? I'm only familiar with it in the context of old > Apple computers. From the Wikipedia page, > it seems like PPC is mainly used in servers now. > OS X on older PPC machines is still common enough, for example the laptop I build numpy/scipy binaries on has a PPC cpu. Also, even for many Intel based machines the Python defaults include PPC compilation, so this is going to trip people up. Therefore a fallback would be useful. Ralf As for the benefit: I think getting close to the performance of OpenCV is > pretty significant. (On my system, however, I don't quite see the > performance boost that Nadav sees: skimage: 0.034 secs, ndimage: 0.089 > secs, opencv: 0.018 secs, for the output of > 'test_convolution.py'---nevertheless, it's a significant improvement over > ndimage). And, in comparison, OpenCV can be incredibly difficult to build. > > There are probably other ways to get similar performance, but like I said, > I don't do any serious non-Python coding, so I have no idea what those > alternatives may be. Stefan and Pieter (the original author of this code) > have probably thought this through a bit more. > > -Tony > > >>> The flag is left over from the original implementation. Removing >>> "-ffast-math" works fine on my system. To be honest, I don't do much >>> non-Python coding so I don't know the implications of adding/removing the >>> flag. >>> >> >> It's very likely to give problems with unusual (or even Intel) compilers >> I think. >> >> Ralf >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nadavh.horesh at gmail.com Mon Jan 2 02:02:51 2012 From: nadavh.horesh at gmail.com (Nadav Horesh) Date: Mon, 2 Jan 2012 09:02:51 +0200 Subject: Need an advice In-Reply-To: References: Message-ID: Remarks after a test of the convolution from the recent git repository: 1. In the recent opencv (2.31a) there is no automatic conversion between numpy arrays to CV matrices. I attached a modification that makes the test run with both cv versions. 2. Shouldn't be a way to copy compilation flags from pythonx.x/config/Makefile? I think (not sure) that numpy does it. Nadav. 2011/12/31 Tony Yu > > On Fri, Dec 30, 2011 at 5:48 PM, Ralf Gommers > wrote: > >> >> >> On Fri, Dec 30, 2011 at 8:05 PM, Tony Yu wrote: >> >>> >>> >>> On Fri, Dec 30, 2011 at 1:19 PM, Ralf Gommers < >>> ralf.gommers at googlemail.com> wrote: >>> >>>> >>>> >>>> On Fri, Dec 30, 2011 at 5:46 PM, Tony Yu wrote: >>>> >>>>> >>>>> >>>>> On Fri, Dec 30, 2011 at 8:20 AM, Nadav Horesh >>>> > wrote: >>>>> >>>>>> Remarks for the convolution subpackage: >>>>>> 1. The __init__.py should be probably changed to >>>>>> >>>>>> from ext import pyconvolve as convolve >>>>>> >>>>> >>>>> Agreed. Alternatively, the c-method could be renamed so that the >>>>> python method in ext can be named convolve. >>>>> >>>>>> >>>>>> 2. The test_convolution.py file is very instructive. It should be >>>>>> polished a bit. I think it would be worthwhile to add also >>>>>> scipy.signal.sepfir2d and cv2.sepFilter2D to the test. >>>>>> >>>>> >>>>>> 3. I found the convolve speed in par with cv.convolve2d (it can be >>>>>> slower or faster depending on the kernel) >>>>>> >>>>>> Nadav >>>>>> >>>>> >>>>> Thanks for testing the code. >>>>> >>>>> I've got the code compiling on my system now, so I was able to clean >>>>> up a few things. Could you update to what's currently on my >>>>> skimage-convolution branch to check that it builds on your system? If not, >>>>> what flags do you have to change/add to get it to compile? >>>>> >>>>> -Tony >>>>> >>>>> P.S. If any one else is building this on OS X: ppc compatible builds >>>>> is turned on by default (at least on my system). This should be turned off >>>>> before building. Add the following line to ~/.profile, or just run it right >>>>> before building: >>>>> >>>>> export ARCH_FLAGS="-arch i386 -arch x86_64" >>>>> >>>> >>>> Can you explain why is this necessary? >>>> >>>> In convolution/setup.py I also see you add "-ffast-math", which is a >>>> GCC-specific flag. It's better to remove it I think, it may give problems >>>> with other compilers. >>>> >>>> Ralf >>>> >>> >>> On my system at least, running gcc will, by default, add "-arch ppc" >>> along with i386 and x86_64. As far as I can tell, PPC doesn't support SSE, >>> which is used by this implementation. >>> >> >> That's true. I can't tell for sure, but it seems that this code is not >> optional. Meaning PPC is unsupported, and the ARCH_FLAGS need to be defined >> on OS X. I'm only a very occasional user now so it doesn't bother me too >> much, but isn't this a large penalty for the benefit you get? >> > > Well, I assume that we would be able to add a check to disable the build > on unsupported architectures. As far as, whether it's worth it: I don't > know. Is PPC very common? I'm only familiar with it in the context of old > Apple computers. From the Wikipedia page, > it seems like PPC is mainly used in servers now. > > As for the benefit: I think getting close to the performance of OpenCV is > pretty significant. (On my system, however, I don't quite see the > performance boost that Nadav sees: skimage: 0.034 secs, ndimage: 0.089 > secs, opencv: 0.018 secs, for the output of > 'test_convolution.py'---nevertheless, it's a significant improvement over > ndimage). And, in comparison, OpenCV can be incredibly difficult to build. > > There are probably other ways to get similar performance, but like I said, > I don't do any serious non-Python coding, so I have no idea what those > alternatives may be. Stefan and Pieter (the original author of this code) > have probably thought this through a bit more. > > -Tony > > >>> The flag is left over from the original implementation. Removing >>> "-ffast-math" works fine on my system. To be honest, I don't do much >>> non-Python coding so I don't know the implications of adding/removing the >>> flag. >>> >> >> It's very likely to give problems with unusual (or even Intel) compilers >> I think. >> >> Ralf >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test_convolution1.py Type: text/x-python Size: 2395 bytes Desc: not available URL: From tsyu80 at gmail.com Thu Jan 5 23:59:21 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Thu, 5 Jan 2012 23:59:21 -0500 Subject: [scikits-image] Harris corner detection (#106) In-Reply-To: References: Message-ID: On Thu, Jan 5, 2012 at 12:50 PM, Varoquaux < reply+i-2636374-54829e76ead08234132b3dcaac8a1c3f1441e0cd-133031 at reply.github.com > wrote: > I fixed a few things, and added the parameter to set the deviation for the > gaussian blur. I also added @GaelVaroquaux as a contributor, as he helped > me debug the patch. > > I'll now work on the panorama stitching example. > > I just read through the PR for Harris corner detection. I made some inline comments on github, but I wanted to raise a question the list. It seems that everything in the `harris` function is essentially a peak detection algorithm. (Please correct me if I'm wrong or if the algorithm is specific to the Harris response.) It might be nice to make `_compute_harris_response` a public function (maybe renamed to `harris_response` or `harris`) and move the rest of `harris` to the detection subpackage as a peak detection function. We could really use a (or multiple) peak detection function(s) in skimage (e.g. with the hough transform or template matching). -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From yager.neil at gmail.com Mon Jan 9 03:49:48 2012 From: yager.neil at gmail.com (Neil Yager) Date: Mon, 9 Jan 2012 00:49:48 -0800 (PST) Subject: Harris corner detection (#106) In-Reply-To: References: Message-ID: <82ce9bbc-fc4a-49d7-bb99-fd3eec53cde7@m4g2000vbc.googlegroups.com> I think this is a great idea. Peak detection comes up all the time (e.g. peaks in Fourier space), and a general public function would be very useful. Neil On Jan 6, 4:59?am, Tony Yu wrote: > On Thu, Jan 5, 2012 at 12:50 PM, Varoquaux < > reply+i-2636374-54829e76ead08234132b3dcaac8a1c3f1441e0cd-133... at reply.github.com > > > wrote: > > I fixed a few things, and added the parameter to set the deviation for the > > gaussian blur. I also added @GaelVaroquaux as a contributor, as he helped > > me debug the patch. > > > I'll now work on the panorama stitching example. > > I just read through the PR for Harris corner > detection. > I made some inline comments on github, but I wanted to raise a question the > list. > > It seems that everything in the `harris` function is essentially a peak > detection algorithm. (Please correct me if I'm wrong or if the algorithm is > specific to the Harris response.) It might be nice to make > `_compute_harris_response` a public function (maybe renamed to > `harris_response` or `harris`) and move the rest of `harris` to the > detection subpackage as a peak detection function. We could really use a > (or multiple) peak detection function(s) in skimage (e.g. with the hough > transform or template matching). > > -Tony From stefan at sun.ac.za Mon Jan 9 12:21:17 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 9 Jan 2012 09:21:17 -0800 Subject: Harris corner detection (#106) In-Reply-To: References: <82ce9bbc-fc4a-49d7-bb99-fd3eec53cde7@m4g2000vbc.googlegroups.com> Message-ID: On Mon, Jan 9, 2012 at 8:05 AM, Tony Yu wrote: > You know what: I think I'm just going to merge your Harris detection pull > request as it is now, and then I'll start a new pull request with the peak > detection part factored out. I think that's the way to go. Peak detection would be very useful--it crops up all over the place. I was trying to recall who recently shared a review of peak detection algorithms with me, and I think it might have been you :) There are so many out there, almost all heuristics. Typically, there are two varieties: those that simply consider the input data (e.g., dividing the image into windows and choosing the maximum value in each), and those that in addition consider other peaks found (e.g., to avoid identifying very closely spaced peaks). The problem takes on an interesting twist when working with noisy data, where many points seem like peaks but aren't. Here, multi-level decompositions such as the Gaussian scale space or wavelets are often employed. Regards St?fan From nelle.varoquaux at gmail.com Mon Jan 9 04:36:27 2012 From: nelle.varoquaux at gmail.com (Nelle Varoquaux) Date: Mon, 9 Jan 2012 10:36:27 +0100 Subject: Harris corner detection (#106) In-Reply-To: <82ce9bbc-fc4a-49d7-bb99-fd3eec53cde7@m4g2000vbc.googlegroups.com> References: <82ce9bbc-fc4a-49d7-bb99-fd3eec53cde7@m4g2000vbc.googlegroups.com> Message-ID: I think it is a good idea to do a such a method: maybe in the util module ? On the other hand, the harris response by itself is totally useless, so I suggest to keep it in "one chunk". N On 9 January 2012 09:49, Neil Yager wrote: > I think this is a great idea. Peak detection comes up all the time > (e.g. peaks in Fourier space), and a general public function would be > very useful. > > Neil > > On Jan 6, 4:59 am, Tony Yu wrote: > > On Thu, Jan 5, 2012 at 12:50 PM, Varoquaux < > > > reply+i-2636374-54829e76ead08234132b3dcaac8a1c3f1441e0cd-133... at reply.github.com > > > > > wrote: > > > I fixed a few things, and added the parameter to set the deviation for > the > > > gaussian blur. I also added @GaelVaroquaux as a contributor, as he > helped > > > me debug the patch. > > > > > I'll now work on the panorama stitching example. > > > > I just read through the PR for Harris corner > > detection >. > > I made some inline comments on github, but I wanted to raise a question > the > > list. > > > > It seems that everything in the `harris` function is essentially a peak > > detection algorithm. (Please correct me if I'm wrong or if the algorithm > is > > specific to the Harris response.) It might be nice to make > > `_compute_harris_response` a public function (maybe renamed to > > `harris_response` or `harris`) and move the rest of `harris` to the > > detection subpackage as a peak detection function. We could really use a > > (or multiple) peak detection function(s) in skimage (e.g. with the hough > > transform or template matching). > > > > -Tony > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsyu80 at gmail.com Mon Jan 9 11:05:42 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Mon, 9 Jan 2012 11:05:42 -0500 Subject: Harris corner detection (#106) In-Reply-To: References: <82ce9bbc-fc4a-49d7-bb99-fd3eec53cde7@m4g2000vbc.googlegroups.com> Message-ID: On Mon, Jan 9, 2012 at 4:36 AM, Nelle Varoquaux wrote: > I think it is a good idea to do a such a method: maybe in the util module > ? On the other hand, the harris response by itself is totally useless, so I > suggest to keep it in "one chunk". > > N > Actually, I don't think this is much of a problem: if the peak detection part was factored out (maybe keeping it in the `feature` module instead of moving it to `util`), then you could just have the `harris` function call `_compute_harris_response` followed by a separate call to the peak detection function (possibly with different defaults that are tuned to the harris response array). I guess the question is whether this peak detection algorithm is generally useful, or if it's somehow specific to the harris response. From the looks of code, it seems the algorithm would be generally useful. You know what: I think I'm just going to merge your Harris detection pull request as it is now, and then I'll start a new pull request with the peak detection part factored out. -Tony > > > On 9 January 2012 09:49, Neil Yager wrote: > >> I think this is a great idea. Peak detection comes up all the time >> (e.g. peaks in Fourier space), and a general public function would be >> very useful. >> >> Neil >> >> On Jan 6, 4:59 am, Tony Yu wrote: >> > On Thu, Jan 5, 2012 at 12:50 PM, Varoquaux < >> > >> reply+i-2636374-54829e76ead08234132b3dcaac8a1c3f1441e0cd-133... at reply.github.com >> > >> > > wrote: >> > > I fixed a few things, and added the parameter to set the deviation >> for the >> > > gaussian blur. I also added @GaelVaroquaux as a contributor, as he >> helped >> > > me debug the patch. >> > >> > > I'll now work on the panorama stitching example. >> > >> > I just read through the PR for Harris corner >> > detection> >. >> > I made some inline comments on github, but I wanted to raise a question >> the >> > list. >> > >> > It seems that everything in the `harris` function is essentially a peak >> > detection algorithm. (Please correct me if I'm wrong or if the >> algorithm is >> > specific to the Harris response.) It might be nice to make >> > `_compute_harris_response` a public function (maybe renamed to >> > `harris_response` or `harris`) and move the rest of `harris` to the >> > detection subpackage as a peak detection function. We could really use a >> > (or multiple) peak detection function(s) in skimage (e.g. with the hough >> > transform or template matching). >> > >> > -Tony >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nelle.varoquaux at gmail.com Mon Jan 9 13:55:14 2012 From: nelle.varoquaux at gmail.com (Nelle Varoquaux) Date: Mon, 9 Jan 2012 19:55:14 +0100 Subject: Harris corner detection (#106) In-Reply-To: References: <82ce9bbc-fc4a-49d7-bb99-fd3eec53cde7@m4g2000vbc.googlegroups.com> Message-ID: 2012/1/9 St?fan van der Walt > On Mon, Jan 9, 2012 at 8:05 AM, Tony Yu wrote: > > You know what: I think I'm just going to merge your Harris detection pull > > request as it is now, and then I'll start a new pull request with the > peak > > detection part factored out. > > I think that's the way to go. Peak detection would be very useful--it > crops up all over the place. > I indeed thing peak detection would be very useful. I've used it recently to do segmentation, on handwriting dataset, and face detection, with probability score associated to a point. > > I was trying to recall who recently shared a review of peak detection > algorithms with me, and I think it might have been you :) There are > so many out there, almost all heuristics. Typically, there are two > varieties: those that simply consider the input data (e.g., dividing > the image into windows and choosing the maximum value in each), and > those that in addition consider other peaks found (e.g., to avoid > identifying very closely spaced peaks). The problem takes on an > interesting twist when working with noisy data, where many points seem > like peaks but aren't. Here, multi-level decompositions such as the > Gaussian scale space or wavelets are often employed. > > Regards > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsyu80 at gmail.com Mon Jan 9 23:34:53 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Mon, 9 Jan 2012 23:34:53 -0500 Subject: Harris corner detection (#106) In-Reply-To: References: <82ce9bbc-fc4a-49d7-bb99-fd3eec53cde7@m4g2000vbc.googlegroups.com> Message-ID: On Mon, Jan 9, 2012 at 1:55 PM, Nelle Varoquaux wrote: > > 2012/1/9 St?fan van der Walt > >> On Mon, Jan 9, 2012 at 8:05 AM, Tony Yu wrote: >> > You know what: I think I'm just going to merge your Harris detection >> pull >> > request as it is now, and then I'll start a new pull request with the >> peak >> > detection part factored out. >> >> I think that's the way to go. Peak detection would be very useful--it >> crops up all over the place. >> > > I indeed thing peak detection would be very useful. I've used it recently > to do segmentation, on handwriting dataset, and face detection, with > probability score associated to a point. > > >> >> I was trying to recall who recently shared a review of peak detection >> algorithms with me, and I think it might have been you :) > > Actually, if you're referring to the review paper [1] I mentioned in my PR for a grayscale reconstruction function, I'm inclined to say that that paper was on spot detection, as opposed to peak detection. I'm not sure if this is an accepted classification, but in my mind: peaks are *pixels* of high intensity, while spots are *regions* of high intensity. The spot detection algorithms described in [1] find regions of high intensity and then look for the centroids of those regions. This distinction between "spot" and "peak" may be artificial---I'm sort of making it up as I go along :) In any case, I've merged Nelle's corner detection PR, and I've created a new PR with peak detection factored out. There's a couple open questions, which I've added as comments on the PR. -Tony [1] Smal, et al., "Quantitative comparison of spot detection methods in fluorescence microscopy", IEEE Trans Med Imaging. (2010) > There are >> so many out there, almost all heuristics. Typically, there are two >> varieties: those that simply consider the input data (e.g., dividing >> the image into windows and choosing the maximum value in each), and >> those that in addition consider other peaks found (e.g., to avoid >> identifying very closely spaced peaks). The problem takes on an >> interesting twist when working with noisy data, where many points seem >> like peaks but aren't. Here, multi-level decompositions such as the >> Gaussian scale space or wavelets are often employed. >> >> Regards >> St?fan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Tue Jan 10 15:54:06 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 10 Jan 2012 12:54:06 -0800 Subject: Adding images to the repository for panorama stitching In-Reply-To: References: Message-ID: Hi Nelle On Tue, Jan 10, 2012 at 12:36 PM, Nelle Varoquaux wrote: > I was working on the panorama stitching example, and adding images to the > repository > (https://github.com/NelleV/scikits.image/commit/50ff69389bc3458eb1cfb263d14730f5c037e135). Out of curiosity, what methods are you implementing? I have some panorama stitching related code that may come in handy. > Talking with Ga?l about this, I realized it probably wasn't the best idea to > clutter the repository with images probably no one else will use. > In scikit-learn, data used for examples is downloaded from internet only > when used,, and stored in the user home folder. > > What do you think about implementing this for skimage ? We definitely don't want to clutter the git repo with too much data (we've been very careful in choosing the images in the data and testing modules). If we implement this, we should do it such that packaging systems like Debian can easily modify the data path (e.g., they may want to package python-skimage-data). Do the learn guys already have a caching system in place? Whatever solution we provide, a user should be able to download the files manually as well (otherwise, with Python's poor proxy support, people are going to run into problems). St?fan From nelle.varoquaux at gmail.com Tue Jan 10 15:36:46 2012 From: nelle.varoquaux at gmail.com (Nelle Varoquaux) Date: Tue, 10 Jan 2012 21:36:46 +0100 Subject: Adding images to the repository for panorama stitching Message-ID: Hi everyone, I was working on the panorama stitching example, and adding images to the repository ( https://github.com/NelleV/scikits.image/commit/50ff69389bc3458eb1cfb263d14730f5c037e135 ). Talking with Ga?l about this, I realized it probably wasn't the best idea to clutter the repository with images probably no one else will use. In scikit-learn, data used for examples is downloaded from internet only when used,, and stored in the user home folder. What do you think about implementing this for skimage ? Thanks, N -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Wed Jan 11 15:54:01 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 11 Jan 2012 12:54:01 -0800 Subject: Harris corner detection (#106) In-Reply-To: References: <82ce9bbc-fc4a-49d7-bb99-fd3eec53cde7@m4g2000vbc.googlegroups.com> Message-ID: On Mon, Jan 9, 2012 at 8:34 PM, Tony Yu wrote: > In any case, I've merged Nelle's corner detection PR, and I've created a new > PR with peak detection factored out. There's a couple open questions, which > I've added as comments on the PR. Thanks for taking care of that, Tony. I'll review the new PRs. Cheers St?fan From stefan at sun.ac.za Fri Jan 13 20:34:13 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 13 Jan 2012 17:34:13 -0800 Subject: Need an advice In-Reply-To: References: Message-ID: On Sun, Jan 1, 2012 at 11:02 PM, Nadav Horesh wrote: > Shouldn't be a way to copy compilation flags from pythonx.x/config/Makefile? > I think (not sure) that numpy does it. I've CCd David Cournapeau on this e-mail; I think he'll be able to recommend the best route forward (David, the full message is here: http://groups.google.com/group/scikits-image/browse_thread/thread/a2d4edb98c45d0cf ). One alternative is to simply try the compilation, first with the fast math flag, then without, and then have a conditional import in the code that loads whatever survives the compilation process (with ndimage's convolve as a backup). St?fan From cournape at gmail.com Wed Jan 25 14:54:44 2012 From: cournape at gmail.com (David) Date: Wed, 25 Jan 2012 11:54:44 -0800 (PST) Subject: Need an advice In-Reply-To: References: Message-ID: <1a2215f9-3bd3-47e7-bf83-9e90b81fd833@q8g2000yqa.googlegroups.com> On Jan 14, 1:34?am, St?fan van der Walt wrote: > On Sun, Jan 1, 2012 at 11:02 PM, Nadav Horesh wrote: > > Shouldn't be a way to copy compilation flags from pythonx.x/config/Makefile? > > I think (not sure) that numpy does it. > > I've CCd David Cournapeau on this e-mail; I think he'll be able to > recommend the best route forward > (David, the full message is here:http://groups.google.com/group/scikits-image/browse_thread/thread/a2d... > ). > > One alternative is to simply try the compilation, first with the fast > math flag, then without, and then have a conditional import in the > code that loads whatever survives the compilation process (with > ndimage's convolve as a backup). I would advise against using -ffast-math, which really should be called -funsafe-math. We removed it in scipy some time ago as it had the annoying property of giving completely borked results. David From siggin at gmail.com Wed Jan 25 20:01:19 2012 From: siggin at gmail.com (Sigmund) Date: Wed, 25 Jan 2012 17:01:19 -0800 (PST) Subject: io.plugins freeimage installation issue? Message-ID: Hallo! I'm using the freeimage plugin for reading uint8 and float32 Grey- scale TIFF files. The aim is some basic x-ray diffraction image processing. The development is done on MacOSX but some users are Win users. To make it short. The freeimage imread on Windows isn't working. Since it is working on the Mac and I had a hard time getting freeimage installed. I think I might have done something wrong during installation. The readme file from FreeImage didn't help much. So some questions: 1. Do I have to build the freeimage.dll or can I just use the compiled one? (didn't make it to compile) 2. Is just dropping the .dll in the _plugins Folder all I need to do? (thats basically all I did after trying 1. all day) I ended up with having a successful run of the test_freeimage.py and a ValueError for the TIFF files on the Windows machin. Error output: File "00PeakWIN.py", line 32, in img_for_dimentions = array(io.imread(bild, plugin="freeimage" ), dtype=int) File "C:\Python27\lib\site-packages\scikits_image-0.4.2-py2.7- win32.egg\skimage\io\_io.py", line 72, in imread img = call_plugin('imread', fname, plugin=plugin, **plugin_args) File "C:\Python27\lib\site-packages\scikits_image-0.4.2-py2.7- win32.egg\skimage\io\_plugins\plugin.py", line 88, in call return func(*args, **kwargs) File "C:\Python27\lib\site-packages\scikits_image-0.4.2-py2.7- win32.egg\skimage\io\_plugins\freeimage_plugin.py", line 512, in imread img = read(filename) File "C:\Python27\lib\site-packages\scikits_image-0.4.2-py2.7- win32.egg\skimage\io\_plugins\freeimage_plugin.py", line 282, in read bitmap = _read_bitmap(filename, flags) File "C:\Python27\lib\site-packages\scikits_image-0.4.2-py2.7- win32.egg\skimage\io\_plugins\freeimage_plugin.py", line 326, in _read_bitmap raise ValueError('Cannot determine type of file %s' % filename) ValueError: Cannot determine type of file E Thanks! Siggi From zachary.pincus at yale.edu Wed Jan 25 21:34:27 2012 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Wed, 25 Jan 2012 21:34:27 -0500 Subject: io.plugins freeimage installation issue? In-Reply-To: References: Message-ID: <7C561479-5617-4231-B625-7ABE3AA2C5CF@yale.edu> Hi Siggi, > 1. Do I have to build the freeimage.dll or can I just use the compiled > one? (didn't make it to compile) > 2. Is just dropping the .dll in the _plugins Folder all I need to do? > (thats basically all I did after trying 1. all day) Sorry for your frustrating day. Your idea for #2 is be correct -- just drop the pre-compiled DLL into _plugins. (Aside: I've opened a ticket on github regarding other locations that the code should look for the FreeImage DLL. There are obvious candidates on OS X/Linux, but I don't know if there's something akin to /usr/lib/ or whatnot on windows... We should obviously also beef up the documentation about where to get and put FreeImage.) > I ended up with having a successful run of the test_freeimage.py and a > ValueError for the TIFF files on the Windows machin. So test_freeimage.py works fine for you on Windows? That's good, and indicates (among other things) that the DLL is in the right place, and that FreeImage can open PNG files fine. Now, could you describe precisely the way that you're able to cause the below error? Also, the EXACT same code works fine on OS X but fails on windows? It would be great if you could pare down the failing code to provide a small, self-contained example that you could post, including code and the image you're trying to load? >From the below error, though, it looks like you're passing in a bad filename to imread -- the error is that you're trying to open a file named "E", and FreeImage can't tell what file type it is (this error also occurs if the file doesn't exist...) > Error output: > File "00PeakWIN.py", line 32, in > img_for_dimentions = array(io.imread(bild, plugin="freeimage" ), > dtype=int) > File "C:\Python27\lib\site-packages\scikits_image-0.4.2-py2.7- > win32.egg\skimage\io\_io.py", line 72, in imread > img = call_plugin('imread', fname, plugin=plugin, **plugin_args) > File "C:\Python27\lib\site-packages\scikits_image-0.4.2-py2.7- > win32.egg\skimage\io\_plugins\plugin.py", line 88, in call > return func(*args, **kwargs) > File "C:\Python27\lib\site-packages\scikits_image-0.4.2-py2.7- > win32.egg\skimage\io\_plugins\freeimage_plugin.py", line 512, in > imread > img = read(filename) > File "C:\Python27\lib\site-packages\scikits_image-0.4.2-py2.7- > win32.egg\skimage\io\_plugins\freeimage_plugin.py", line 282, in read > bitmap = _read_bitmap(filename, flags) > File "C:\Python27\lib\site-packages\scikits_image-0.4.2-py2.7- > win32.egg\skimage\io\_plugins\freeimage_plugin.py", line 326, in > _read_bitmap > raise ValueError('Cannot determine type of file %s' % filename) > ValueError: Cannot determine type of file E Zach From siggin at gmail.com Thu Jan 26 09:10:00 2012 From: siggin at gmail.com (Sigmund) Date: Thu, 26 Jan 2012 06:10:00 -0800 (PST) Subject: io.plugins freeimage installation issue? In-Reply-To: References: Message-ID: First, thank you for your answer! Since I'm not in my office today I tried to do the same at my BootCamp Win 7 64 Partition. Here I encountered a new problem. If I run the "test_freeimage.py" I get the error that the "OSError: Could not find libFreeImage in any of the following directories:"(full error output below). But I'm sure that it is in the right folder and that "python_freeimage.py" is looking in the right pace. How can that be? First idea was that "sys.platform" is returning "win64" instead of "win32" but it isn't. I also tried changing the case of the "FreeImage.dll" but didn't help. So as far I could check, everything is going right, but it is still not taking the FreeImage.dll. Running it on the BootCamp machine is not necessary for me but it might be of interest for you. I will get back to the first post tomorrow. By the way, it might be better and I think easy to change if the error "OSError: Could not find libFreeImage in any of the following directories:" is using the OS specific library name. Thats easier to understand for people like me that not relay know what they are doing. """ OSError: Could not find libFreeImage in any of the following directories: 'C:\Python27\lib\site-packages\scikits_image-0.4.2-py2.7- win-amd64.egg\skimage\io\_plugins', '/lib', '/usr/lib', '/usr/local/ lib', '/opt/local/lib', 'C:\Users\Siggi\lib' """ Siggi From cjgohlke at gmail.com Thu Jan 26 13:41:22 2012 From: cjgohlke at gmail.com (Christoph Gohlke) Date: Thu, 26 Jan 2012 10:41:22 -0800 Subject: io.plugins freeimage installation issue? In-Reply-To: References: Message-ID: <4F219E52.206@gmail.com> On 1/26/2012 6:10 AM, Sigmund wrote: > First, thank you for your answer! > > Since I'm not in my office today I tried to do the same at my BootCamp > Win 7 64 Partition. Here I encountered a new problem. > If I run the "test_freeimage.py" I get the error that the "OSError: > Could not find libFreeImage in any of the following directories:"(full > error output below). But I'm sure that it is in the right folder and > that "python_freeimage.py" is looking in the right pace. How can that > be? > First idea was that "sys.platform" is returning "win64" instead of > "win32" but it isn't. I also tried changing the case of the > "FreeImage.dll" but didn't help. So as far I could check, everything > is going right, but it is still not taking the FreeImage.dll. > > Running it on the BootCamp machine is not necessary for me but it > might be of interest for you. > > I will get back to the first post tomorrow. > > By the way, it might be better and I think easy to change if the error > "OSError: Could not find libFreeImage in any of the following > directories:" is using the OS specific library name. Thats easier to > understand for people like me that not relay know what they are doing. > > """ > OSError: Could not find libFreeImage in any of the following > directories: 'C:\Python27\lib\site-packages\scikits_image-0.4.2-py2.7- > win-amd64.egg\skimage\io\_plugins', '/lib', '/usr/lib', '/usr/local/ > lib', '/opt/local/lib', 'C:\Users\Siggi\lib' > """ > > > > Siggi > You are running a 64 bit version of Python. Please verify that the FreeImage.dll is also 64 bit. You may want to try scikits-image-0.4.2.win-amd64-py2.7.exe from , which includes a 64 bit FreeImage.dll. Christoph From tsyu80 at gmail.com Thu Jan 26 11:00:23 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Thu, 26 Jan 2012 11:00:23 -0500 Subject: Need an advice In-Reply-To: <1a2215f9-3bd3-47e7-bf83-9e90b81fd833@q8g2000yqa.googlegroups.com> References: <1a2215f9-3bd3-47e7-bf83-9e90b81fd833@q8g2000yqa.googlegroups.com> Message-ID: On Wed, Jan 25, 2012 at 2:54 PM, David wrote: > > > On Jan 14, 1:34 am, St?fan van der Walt wrote: > > On Sun, Jan 1, 2012 at 11:02 PM, Nadav Horesh > wrote: > > > Shouldn't be a way to copy compilation flags from > pythonx.x/config/Makefile? > > > I think (not sure) that numpy does it. > > > > I've CCd David Cournapeau on this e-mail; I think he'll be able to > > recommend the best route forward > > (David, the full message is here: > http://groups.google.com/group/scikits-image/browse_thread/thread/a2d... > > ). > > > > One alternative is to simply try the compilation, first with the fast > > math flag, then without, and then have a conditional import in the > > code that loads whatever survives the compilation process (with > > ndimage's convolve as a backup). > > I would advise against using -ffast-math, which really should be > called -funsafe-math. We removed it in scipy some time ago as it had > the annoying property of giving completely borked results. > > David Thanks for your help. Do you (or anyone else on the list) have any idea how to attempt compilation of a Cython file and gracefully exit if it's unsuccessful? (By graceful, I mean: continue compiling the rest of the package and don't produce *.so files for failed modules.) -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From siggin at gmail.com Thu Jan 26 14:18:15 2012 From: siggin at gmail.com (Sigmund) Date: Thu, 26 Jan 2012 11:18:15 -0800 (PST) Subject: io.plugins freeimage installation issue? In-Reply-To: References: <4F219E52.206@gmail.com> Message-ID: <63b00989-5803-48ec-beb7-fc17b22f3a14@o12g2000vbd.googlegroups.com> I first uninstalled the old version and than installed the new one. Still the same problem. >pythonw -u "readHASYLAB.py" Traceback (most recent call last): File "readHASYLAB.py", line 5, in io.use_plugin("freeimage", "imread" ) File "C:\Python27\lib\site-packages\skimage\io\_plugins\plugin.py", line 124, in use _load(name) File "C:\Python27\lib\site-packages\skimage\io\_plugins\plugin.py", line 180, in _load fromlist=[modname]) File "C:\Python27\lib\site-packages\skimage\io\_plugins \freeimage_plugin.py", line 99, in 'directories: \'%s\'' % '\', \''.join(lib_dirs)) OSError: Could not find libFreeImage in any of the following directories: 'C:\Python27\lib\site-packages\skimage\io\_plugins', '/ lib', '/usr/lib', '/usr/local/lib', '/opt/local/lib' >Exit code: 1 here is the command window response... C:\Users\Siggi>dir C:\Python27\lib\site-packages\skimage\io\_plugins Volume in Laufwerk C: hat keine Bezeichnung. Volumeseriennummer: CC91-F951 Verzeichnis von C:\Python27\lib\site-packages\skimage\io\_plugins 26.01.2012 20:05 . 26.01.2012 20:05 .. 24.10.2011 18:16 89 fits_plugin.ini 24.10.2011 18:16 4.488 fits_plugin.py 26.01.2012 20:05 4.241 fits_plugin.pyc 26.01.2012 20:05 4.241 fits_plugin.pyo 08.08.2011 08:25 3.417.600 FreeImage.dll 24.10.2011 18:16 92 freeimage_plugin.ini 24.10.2011 18:16 16.187 freeimage_plugin.py 26.01.2012 20:05 15.893 freeimage_plugin.pyc 26.01.2012 20:05 15.884 freeimage_plugin.pyo 24.10.2011 18:16 90 gdal_plugin.ini 24.10.2011 18:16 415 gdal_plugin.py 26.01.2012 20:05 721 gdal_plugin.pyc 26.01.2012 20:05 721 gdal_plugin.pyo 24.10.2011 18:16 91 gtk_plugin.ini 24.10.2011 18:16 1.709 gtk_plugin.py 26.01.2012 20:05 2.188 gtk_plugin.pyc 26.01.2012 20:05 2.188 gtk_plugin.pyo 24.10.2011 18:16 105 matplotlib_plugin.ini 24.10.2011 18:16 80 matplotlib_plugin.py 26.01.2012 20:05 443 matplotlib_plugin.pyc 26.01.2012 20:05 443 matplotlib_plugin.pyo 24.10.2011 18:16 91 null_plugin.ini 24.10.2011 18:16 348 null_plugin.py 26.01.2012 20:05 815 null_plugin.pyc 26.01.2012 20:05 815 null_plugin.pyo 24.10.2011 18:16 100 pil_plugin.ini 24.10.2011 18:16 2.886 pil_plugin.py 26.01.2012 20:05 3.423 pil_plugin.pyc 26.01.2012 20:05 3.371 pil_plugin.pyo 24.10.2011 18:16 5.727 plugin.py 26.01.2012 20:05 6.026 plugin.pyc 26.01.2012 20:05 6.026 plugin.pyo 24.10.2011 18:16 105 qt_plugin.ini 24.10.2011 18:16 5.091 qt_plugin.py 26.01.2012 20:05 5.471 qt_plugin.pyc 26.01.2012 20:05 5.471 qt_plugin.pyo 24.10.2011 18:16 11.991 q_color_mixer.py 26.01.2012 20:05 10.638 q_color_mixer.pyc 26.01.2012 20:05 10.638 q_color_mixer.pyo 24.10.2011 18:16 4.818 q_histogram.py 26.01.2012 20:05 5.159 q_histogram.pyc 26.01.2012 20:05 5.159 q_histogram.pyo 03.12.2011 14:28 8.041 scivi.py 26.01.2012 20:05 9.206 scivi.pyc 26.01.2012 20:05 9.206 scivi.pyo 24.10.2011 18:16 222 test_freeimage.py 26.01.2012 20:05 494 test_freeimage.pyc 26.01.2012 20:05 494 test_freeimage.pyo 24.10.2011 18:16 86 test_plugin.ini 24.10.2011 18:16 483 test_plugin.py 26.01.2012 20:05 1.204 test_plugin.pyc 26.01.2012 20:05 902 test_plugin.pyo 24.10.2011 18:16 13.238 util.py 26.01.2012 20:05 16.760 util.pyc 26.01.2012 20:05 16.680 util.pyo 05.12.2011 12:42 67.584 _colormixer.pyd 05.12.2011 12:42 44.032 _histograms.pyd 24.10.2011 18:16 21 __init__.py 26.01.2012 20:05 185 __init__.pyc 26.01.2012 20:05 185 __init__.pyo 60 Datei(en), 3.771.101 Bytes 2 Verzeichnis(se), 1.931.431.936 Bytes frei C:\Users\Siggi> An other good idea? From cjgohlke at gmail.com Thu Jan 26 14:45:34 2012 From: cjgohlke at gmail.com (Christoph Gohlke) Date: Thu, 26 Jan 2012 11:45:34 -0800 Subject: io.plugins freeimage installation issue? In-Reply-To: <63b00989-5803-48ec-beb7-fc17b22f3a14@o12g2000vbd.googlegroups.com> References: <4F219E52.206@gmail.com> <63b00989-5803-48ec-beb7-fc17b22f3a14@o12g2000vbd.googlegroups.com> Message-ID: <4F21AD5E.4040003@gmail.com> On 1/26/2012 11:18 AM, Sigmund wrote: > I first uninstalled the old version and than installed the new one. > Still the same problem. The 64 bit FreeImage.dll depends on the VC90 OpenMP runtime. I'm not sure Python installs the full VC90 redistributable package or just the CRT. The full installer, including OpenMP, can be obtained at . Christoph > > >> pythonw -u "readHASYLAB.py" > Traceback (most recent call last): > File "readHASYLAB.py", line 5, in > io.use_plugin("freeimage", "imread" ) > File "C:\Python27\lib\site-packages\skimage\io\_plugins\plugin.py", > line 124, in use > _load(name) > File "C:\Python27\lib\site-packages\skimage\io\_plugins\plugin.py", > line 180, in _load > fromlist=[modname]) > File "C:\Python27\lib\site-packages\skimage\io\_plugins > \freeimage_plugin.py", line 99, in > 'directories: \'%s\'' % '\', \''.join(lib_dirs)) > OSError: Could not find libFreeImage in any of the following > directories: 'C:\Python27\lib\site-packages\skimage\io\_plugins', '/ > lib', '/usr/lib', '/usr/local/lib', '/opt/local/lib' >> Exit code: 1 > here is the command window response... > > > C:\Users\Siggi>dir C:\Python27\lib\site-packages\skimage\io\_plugins > Volume in Laufwerk C: hat keine Bezeichnung. > Volumeseriennummer: CC91-F951 > > Verzeichnis von C:\Python27\lib\site-packages\skimage\io\_plugins > > 26.01.2012 20:05 . > 26.01.2012 20:05 .. > 24.10.2011 18:16 89 fits_plugin.ini > 24.10.2011 18:16 4.488 fits_plugin.py > 26.01.2012 20:05 4.241 fits_plugin.pyc > 26.01.2012 20:05 4.241 fits_plugin.pyo > 08.08.2011 08:25 3.417.600 FreeImage.dll > 24.10.2011 18:16 92 freeimage_plugin.ini > 24.10.2011 18:16 16.187 freeimage_plugin.py > 26.01.2012 20:05 15.893 freeimage_plugin.pyc > 26.01.2012 20:05 15.884 freeimage_plugin.pyo > 24.10.2011 18:16 90 gdal_plugin.ini > 24.10.2011 18:16 415 gdal_plugin.py > 26.01.2012 20:05 721 gdal_plugin.pyc > 26.01.2012 20:05 721 gdal_plugin.pyo > 24.10.2011 18:16 91 gtk_plugin.ini > 24.10.2011 18:16 1.709 gtk_plugin.py > 26.01.2012 20:05 2.188 gtk_plugin.pyc > 26.01.2012 20:05 2.188 gtk_plugin.pyo > 24.10.2011 18:16 105 matplotlib_plugin.ini > 24.10.2011 18:16 80 matplotlib_plugin.py > 26.01.2012 20:05 443 matplotlib_plugin.pyc > 26.01.2012 20:05 443 matplotlib_plugin.pyo > 24.10.2011 18:16 91 null_plugin.ini > 24.10.2011 18:16 348 null_plugin.py > 26.01.2012 20:05 815 null_plugin.pyc > 26.01.2012 20:05 815 null_plugin.pyo > 24.10.2011 18:16 100 pil_plugin.ini > 24.10.2011 18:16 2.886 pil_plugin.py > 26.01.2012 20:05 3.423 pil_plugin.pyc > 26.01.2012 20:05 3.371 pil_plugin.pyo > 24.10.2011 18:16 5.727 plugin.py > 26.01.2012 20:05 6.026 plugin.pyc > 26.01.2012 20:05 6.026 plugin.pyo > 24.10.2011 18:16 105 qt_plugin.ini > 24.10.2011 18:16 5.091 qt_plugin.py > 26.01.2012 20:05 5.471 qt_plugin.pyc > 26.01.2012 20:05 5.471 qt_plugin.pyo > 24.10.2011 18:16 11.991 q_color_mixer.py > 26.01.2012 20:05 10.638 q_color_mixer.pyc > 26.01.2012 20:05 10.638 q_color_mixer.pyo > 24.10.2011 18:16 4.818 q_histogram.py > 26.01.2012 20:05 5.159 q_histogram.pyc > 26.01.2012 20:05 5.159 q_histogram.pyo > 03.12.2011 14:28 8.041 scivi.py > 26.01.2012 20:05 9.206 scivi.pyc > 26.01.2012 20:05 9.206 scivi.pyo > 24.10.2011 18:16 222 test_freeimage.py > 26.01.2012 20:05 494 test_freeimage.pyc > 26.01.2012 20:05 494 test_freeimage.pyo > 24.10.2011 18:16 86 test_plugin.ini > 24.10.2011 18:16 483 test_plugin.py > 26.01.2012 20:05 1.204 test_plugin.pyc > 26.01.2012 20:05 902 test_plugin.pyo > 24.10.2011 18:16 13.238 util.py > 26.01.2012 20:05 16.760 util.pyc > 26.01.2012 20:05 16.680 util.pyo > 05.12.2011 12:42 67.584 _colormixer.pyd > 05.12.2011 12:42 44.032 _histograms.pyd > 24.10.2011 18:16 21 __init__.py > 26.01.2012 20:05 185 __init__.pyc > 26.01.2012 20:05 185 __init__.pyo > 60 Datei(en), 3.771.101 Bytes > 2 Verzeichnis(se), 1.931.431.936 Bytes frei > > C:\Users\Siggi> > > > > An other good idea? > From stefan at sun.ac.za Thu Jan 26 15:17:07 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 26 Jan 2012 12:17:07 -0800 Subject: io.plugins freeimage installation issue? In-Reply-To: References: <4F219E52.206@gmail.com> <63b00989-5803-48ec-beb7-fc17b22f3a14@o12g2000vbd.googlegroups.com> Message-ID: On Thu, Jan 26, 2012 at 11:57 AM, Zachary Pincus wrote: > Now, Christoph correctly pointed out that if you're using a 64-bit version of python, you need a 64-bit build of the FreeImage DLL. Unfortunately, the DLL provided by the FreeImage website is 32-bit only. Fortunately, Christoph provides 64-bit builds of scikits-image: > http://www.lfd.uci.edu/~gohlke/pythonlibs/#scikits-image These had been linked on the downloads webpage a while ago, but I forgot to rebuild. http://scikits-image.org/download.html Cheers St?fan From cjgohlke at gmail.com Thu Jan 26 15:41:55 2012 From: cjgohlke at gmail.com (Christoph Gohlke) Date: Thu, 26 Jan 2012 12:41:55 -0800 Subject: io.plugins freeimage installation issue? In-Reply-To: <88CB6B7D-62D0-4CD2-8006-651C649FB436@yale.edu> References: <4F219E52.206@gmail.com> <63b00989-5803-48ec-beb7-fc17b22f3a14@o12g2000vbd.googlegroups.com> <4F21AD5E.4040003@gmail.com> <88CB6B7D-62D0-4CD2-8006-651C649FB436@yale.edu> Message-ID: <4F21BA93.1040105@gmail.com> On 1/26/2012 12:00 PM, Zachary Pincus wrote: > On Jan 26, 2012, at 2:45 PM, Christoph Gohlke wrote: > >> On 1/26/2012 11:18 AM, Sigmund wrote: >>> I first uninstalled the old version and than installed the new one. >>> Still the same problem. >> The 64 bit FreeImage.dll depends on the VC90 OpenMP runtime. I'm not sure Python installs the full VC90 redistributable package or just the CRT. The full installer, including OpenMP, can be obtained at. >> >> Christoph > Oh ugh, what a pain! > > I will try to beef up the error-handling in freeimage_plugin so that it doesn't just say "no file found", but prints proper diagnostics for when it finds but cannot load a library. > > Sorry you're in the role of windows-bugfinder, Siggi! I don't have personal access to all the permutations of windows, so my testing on this has been obviously a bit spotty. > > Zach From zachary.pincus at yale.edu Thu Jan 26 13:12:05 2012 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Thu, 26 Jan 2012 13:12:05 -0500 Subject: io.plugins freeimage installation issue? In-Reply-To: References: Message-ID: > Since I'm not in my office today I tried to do the same at my BootCamp > Win 7 64 Partition. Here I encountered a new problem. > If I run the "test_freeimage.py" I get the error that the "OSError: > Could not find libFreeImage in any of the following directories:"(full > error output below). But I'm sure that it is in the right folder and > that "python_freeimage.py" is looking in the right pace. How can that > be? That is indeed odd. You're certain that FreeImage.dll is in: C:\Python27\lib\site-packages\scikits_image-0.4.2-py2.7-win-amd64.egg\skimage\io\_plugins Could you pop up a command window and paste the following in, just to double-check: dir C:\Python27\lib\site-packages\scikits_image-0.4.2-py2.7-win-amd64.egg\skimage\io\_plugins > By the way, it might be better and I think easy to change if the error > "OSError: Could not find libFreeImage in any of the following > directories:" is using the OS specific library name. Thats easier to > understand for people like me that not relay know what they are doing. > > """ > OSError: Could not find libFreeImage in any of the following > directories: 'C:\Python27\lib\site-packages\scikits_image-0.4.2-py2.7- > win-amd64.egg\skimage\io\_plugins', '/lib', '/usr/lib', '/usr/local/ > lib', '/opt/local/lib', 'C:\Users\Siggi\lib' > """ Definitely. All of the FreeImage loading stuff is still far too *NIX specific, in the search paths and also the errors. I'll try to fix that up. Zach From siggin at gmail.com Thu Jan 26 16:28:49 2012 From: siggin at gmail.com (Sigmund) Date: Thu, 26 Jan 2012 13:28:49 -0800 (PST) Subject: io.plugins freeimage installation issue? In-Reply-To: <4F21BA93.1040105@gmail.com> References: <4F219E52.206@gmail.com> <63b00989-5803-48ec-beb7-fc17b22f3a14@o12g2000vbd.googlegroups.com> <4F21AD5E.4040003@gmail.com> <88CB6B7D-62D0-4CD2-8006-651C649FB436@yale.edu> <4F21BA93.1040105@gmail.com> Message-ID: <7a107f89-24ab-40b7-a75e-9bb91182ed2e@t7g2000vbg.googlegroups.com> Thanks to you all it works now! -- with the version of "scikits-image-0.4.2.win-amd64-py2.7" from Christoph on: http://www.lfd.uci.edu/~gohlke/pythonlibs/#scikits-image -- and the " VC90 Open" runtime from http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=2092 it works! The initial problem is solve too. It' wasn't platform dependent. Just my fault. Thanks a lot guys! From zachary.pincus at yale.edu Thu Jan 26 13:51:33 2012 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Thu, 26 Jan 2012 13:51:33 -0500 Subject: io.plugins freeimage installation issue? In-Reply-To: <4F219E52.206@gmail.com> References: <4F219E52.206@gmail.com> Message-ID: > You are running a 64 bit version of Python. Please verify that the FreeImage.dll is also 64 bit. You may want to try scikits-image-0.4.2.win-amd64-py2.7.exe from , which includes a 64 bit FreeImage.dll. Good call, Christoph. I've verified that the FreeImage DLL available for download from the FreeImage site is 32-bit only. (Can one make "fat" 32/64-bit DLLs on Windows?) Siggi, probably the best option is to follow Christoph's advice and grab his packages. That's probably the easiest way to get you and your users to have a working scikits-image install. Zach From stefan at sun.ac.za Thu Jan 26 17:34:01 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 26 Jan 2012 14:34:01 -0800 Subject: io.plugins freeimage installation issue? In-Reply-To: <7a107f89-24ab-40b7-a75e-9bb91182ed2e@t7g2000vbg.googlegroups.com> References: <4F219E52.206@gmail.com> <63b00989-5803-48ec-beb7-fc17b22f3a14@o12g2000vbd.googlegroups.com> <4F21AD5E.4040003@gmail.com> <88CB6B7D-62D0-4CD2-8006-651C649FB436@yale.edu> <4F21BA93.1040105@gmail.com> <7a107f89-24ab-40b7-a75e-9bb91182ed2e@t7g2000vbg.googlegroups.com> Message-ID: On Thu, Jan 26, 2012 at 1:28 PM, Sigmund wrote: > Thanks to you all it works now! > > -- with the version of "scikits-image-0.4.2.win-amd64-py2.7" from > Christoph on: http://www.lfd.uci.edu/~gohlke/pythonlibs/#scikits-image > > -- and the " VC90 Open" runtime from > http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=2092 > > it works! Excellent! Just to verify: is the last runtime bundled with Chris's package or not? I'd like to update the installation instructions to help others following the same route. St?fan From zachary.pincus at yale.edu Thu Jan 26 14:57:25 2012 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Thu, 26 Jan 2012 14:57:25 -0500 Subject: io.plugins freeimage installation issue? In-Reply-To: <63b00989-5803-48ec-beb7-fc17b22f3a14@o12g2000vbd.googlegroups.com> References: <4F219E52.206@gmail.com> <63b00989-5803-48ec-beb7-fc17b22f3a14@o12g2000vbd.googlegroups.com> Message-ID: Hi Siggi, First, again sorry for all the trouble! Now, Christoph correctly pointed out that if you're using a 64-bit version of python, you need a 64-bit build of the FreeImage DLL. Unfortunately, the DLL provided by the FreeImage website is 32-bit only. Fortunately, Christoph provides 64-bit builds of scikits-image: http://www.lfd.uci.edu/~gohlke/pythonlibs/#scikits-image (It appears that you want scikits-image-0.4.2.win-amd64-py2.7.?exe .) Now, to clarify things: > I first uninstalled the old version and than installed the new one. What do you mean exactly by "the new one"? Is that a new scikits-image build (e.g. from Christoph?)? A new FreeImage DLL (from Christoph or another source)? First, you need to let us know whether your python 2.7 is 32- or 64-bit... you would have downloaded one or the other installer from Python.org. If you don't recall this, then start up python and type: import sys print sys.maxsize > 2**32 If the result is "True" then you have a 64-bit build of python and you will need to get Christoph's 64-bit scikits-image build, which contains a 64-bit FreeImage DLL. If "False", then you should either use Christoph's 32-bit build, or install your own scikits-image and use the 32-bit FreeImage DLL provided by the FreeImage site. Hope this is clear; if not please don't hesitate to ask me anything. Zach From siggin at gmail.com Thu Jan 26 17:59:04 2012 From: siggin at gmail.com (Sigmund) Date: Thu, 26 Jan 2012 14:59:04 -0800 (PST) Subject: io.plugins freeimage installation issue? In-Reply-To: References: <4F219E52.206@gmail.com> <63b00989-5803-48ec-beb7-fc17b22f3a14@o12g2000vbd.googlegroups.com> <4F21AD5E.4040003@gmail.com> <88CB6B7D-62D0-4CD2-8006-651C649FB436@yale.edu> <4F21BA93.1040105@gmail.com> <7a107f89-24ab-40b7-a75e-9bb91182ed2e@t7g2000vbg.googlegroups.com> Message-ID: >?Just to verify: is the last runtime bundled with Chris's > package or not? no its not. Without the separate download of the VC90 Open thing, it did not work. Siggi From zachary.pincus at yale.edu Thu Jan 26 15:00:26 2012 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Thu, 26 Jan 2012 15:00:26 -0500 Subject: io.plugins freeimage installation issue? In-Reply-To: <4F21AD5E.4040003@gmail.com> References: <4F219E52.206@gmail.com> <63b00989-5803-48ec-beb7-fc17b22f3a14@o12g2000vbd.googlegroups.com> <4F21AD5E.4040003@gmail.com> Message-ID: <88CB6B7D-62D0-4CD2-8006-651C649FB436@yale.edu> On Jan 26, 2012, at 2:45 PM, Christoph Gohlke wrote: > On 1/26/2012 11:18 AM, Sigmund wrote: >> I first uninstalled the old version and than installed the new one. >> Still the same problem. > > The 64 bit FreeImage.dll depends on the VC90 OpenMP runtime. I'm not sure Python installs the full VC90 redistributable package or just the CRT. The full installer, including OpenMP, can be obtained at . > > Christoph Oh ugh, what a pain! I will try to beef up the error-handling in freeimage_plugin so that it doesn't just say "no file found", but prints proper diagnostics for when it finds but cannot load a library. Sorry you're in the role of windows-bugfinder, Siggi! I don't have personal access to all the permutations of windows, so my testing on this has been obviously a bit spotty. Zach From cjgohlke at gmail.com Thu Jan 26 20:11:23 2012 From: cjgohlke at gmail.com (Christoph Gohlke) Date: Thu, 26 Jan 2012 17:11:23 -0800 Subject: io.plugins freeimage installation issue? In-Reply-To: References: <4F219E52.206@gmail.com> <63b00989-5803-48ec-beb7-fc17b22f3a14@o12g2000vbd.googlegroups.com> <4F21AD5E.4040003@gmail.com> <88CB6B7D-62D0-4CD2-8006-651C649FB436@yale.edu> <4F21BA93.1040105@gmail.com> <7a107f89-24ab-40b7-a75e-9bb91182ed2e@t7g2000vbg.googlegroups.com> Message-ID: <4F21F9BB.1080801@gmail.com> On 1/26/2012 2:59 PM, Sigmund wrote: >> Just to verify: is the last runtime bundled with Chris's >> package or not? > no its not. Without the separate download of the VC90 Open thing, it > did not work. > > > Siggi > Just wanted to confirm this: by default OpenMP is used by the LibRAW component of FreeImage, in 64 bit mode only. OpenMP DLLs are part of the VC90 runtime installer. The Python installer only includes the C, not the OpenMP, part of the whole VC90 runtime. I'll rebuild FreeImage without OpenMP support and upload new skimage installers that should be easier to distribute to systems without OpenMP runtime. Christoph From stefan at sun.ac.za Thu Jan 26 21:30:01 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 26 Jan 2012 18:30:01 -0800 Subject: io.plugins freeimage installation issue? In-Reply-To: <4F21F9BB.1080801@gmail.com> References: <4F219E52.206@gmail.com> <63b00989-5803-48ec-beb7-fc17b22f3a14@o12g2000vbd.googlegroups.com> <4F21AD5E.4040003@gmail.com> <88CB6B7D-62D0-4CD2-8006-651C649FB436@yale.edu> <4F21BA93.1040105@gmail.com> <7a107f89-24ab-40b7-a75e-9bb91182ed2e@t7g2000vbg.googlegroups.com> <4F21F9BB.1080801@gmail.com> Message-ID: On Thu, Jan 26, 2012 at 5:11 PM, Christoph Gohlke wrote: > I'll rebuild FreeImage without OpenMP support and upload new skimage > installers that should be easier to distribute to systems without OpenMP > runtime. Thanks, Christoph! I removed the instruction to download the runtime for the time being. St?fan From stefan at sun.ac.za Thu Jan 26 21:31:05 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 26 Jan 2012 18:31:05 -0800 Subject: Front page rotating gallery Message-ID: Hi all, The scikits-image frontpage has just gained a rotating gallery example, as well as a Google Plus button. Enjoy! http://scikits-image.org St?fan From stefan at sun.ac.za Thu Jan 26 23:13:07 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 26 Jan 2012 20:13:07 -0800 Subject: Front page rotating gallery In-Reply-To: References: Message-ID: On Thu, Jan 26, 2012 at 7:53 PM, Tony Yu wrote: > And I've been meaning to make some improvements to the website/docs: this is > good motivation. :) That'd be good--I've been meaning to fine-tune the layout of the website a bit, because the docs (especially) don't read very easily. There are so many beautiful sites from which we can draw inspiration. St?fan From tsyu80 at gmail.com Thu Jan 26 22:53:34 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Thu, 26 Jan 2012 22:53:34 -0500 Subject: Front page rotating gallery In-Reply-To: References: Message-ID: This is great Stefan! And I've been meaning to make some improvements to the website/docs: this is good motivation. :) -Tony 2012/1/26 St?fan van der Walt > Hi all, > > The scikits-image frontpage has just gained a rotating gallery > example, as well as a Google Plus button. Enjoy! > > http://scikits-image.org > > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emmanuelle.gouillart at nsup.org Fri Jan 27 01:46:44 2012 From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart) Date: Fri, 27 Jan 2012 07:46:44 +0100 Subject: Front page rotating gallery In-Reply-To: References: Message-ID: <20120127064644.GA23508@phare.normalesup.org> Pretty awesome, thank you St??????fan! Emmanuelle On Thu, Jan 26, 2012 at 06:31:05PM -0800, St??????fan van der Walt wrote: > Hi all, > The scikits-image frontpage has just gained a rotating gallery > example, as well as a Google Plus button. Enjoy! > http://scikits-image.org > St??????fan From stefan at sun.ac.za Fri Jan 27 19:23:58 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 27 Jan 2012 16:23:58 -0800 Subject: Cython Templating (fused types) Message-ID: Hi all, It's finally here! https://sage.math.washington.edu:8091/hudson/job/cython-docs/doclinks/1/src/userguide/fusedtypes.html [You need the git version of Cython to get this functionality] St?fan From nadavh.horesh at gmail.com Mon Jan 30 00:52:01 2012 From: nadavh.horesh at gmail.com (Nadav Horesh) Date: Mon, 30 Jan 2012 07:52:01 +0200 Subject: Cython Templating (fused types) In-Reply-To: References: Message-ID: C++ython? Nadav. 2012/1/28 St?fan van der Walt > Hi all, > > It's finally here! > > > https://sage.math.washington.edu:8091/hudson/job/cython-docs/doclinks/1/src/userguide/fusedtypes.html > > [You need the git version of Cython to get this functionality] > > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zachary.pincus at yale.edu Tue Jan 31 15:17:25 2012 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Tue, 31 Jan 2012 15:17:25 -0500 Subject: FreeImage manitenance Message-ID: Hi all, Apropos of the recent discussion about and troubles with diagnosing FreeImage library loading problems on 64-bit windows, I have tried to enhance the library-loading code: https://github.com/scikits-image/scikits-image/pull/117 And speaking of FreeImage and 64-bit-ness, https://github.com/scikits-image/scikits-image/pull/112 fixes some problems in 64-bit image loading, and also clarifies how to deal with 64-bit pointers and the ctypes interface. Finally, https://github.com/scikits-image/scikits-image/pull/113 builds on the changes in PR 112 to expose basic image metadata reading in a 64-bit-safe manner. Comments welcome. Zach