From dfarmernv at gmail.com Thu May 12 11:53:38 2011 From: dfarmernv at gmail.com (Dan Farmer) Date: Thu, 12 May 2011 08:53:38 -0700 (PDT) Subject: Cython on windows (again?) Message-ID: <28938579.1373.1305215618059.JavaMail.geo-discussion-forums@prok25> Hi Guys, So the semester is over and I'm starting to gear back up (sorry for dropping off the map for bit :( ). Since my last work on the project I got a new computer so I'm now working in Windows using EPD 7. I checked everything out last night and updated, but when I tried to build in place I get the traceback below. EPD 7 does come with cython 0.14.1 Any ideas to help me get up and running again? Thanks, Dan cython -o C:\source\scikits.image\scikits\image\opencv\opencv_backend.c.new C:\source\scikits.image\scikits\image\opencv\opencv_backend.pyx Cython compilation of opencv_backend.pyx failed. Falling back on pre-generated file. python.exe : C:\Python27\python.exe: can't open file 'C:\Python27\Scripts\cython.py': [Errno 2] No such file or directory Traceback (most recent call last): File "setup.py", line 97, in cmdclass={'build_py': build_py}, File "C:\Python27\lib\site-packages\numpy\distutils\core.py", line 152, in setup config = configuration() File "setup.py", line 44, in configuration config.add_subpackage(DISTNAME) File "C:\Python27\lib\site-packages\numpy\distutils\misc_util.py", line 972, in add_subpackage caller_level = 2) File "C:\Python27\lib\site-packages\numpy\distutils\misc_util.py", line 941, in get_subpackage caller_level = caller_level + 1) File "C:\Python27\lib\site-packages\numpy\distutils\misc_util.py", line 878, in _get_configuration_from_s etup_py config = setup_module.configuration(*args) File "scikits\image\setup.py", line 8, in configuration config.add_subpackage('opencv') File "C:\Python27\lib\site-packages\numpy\distutils\misc_util.py", line 972, in add_subpackage caller_level = 2) File "C:\Python27\lib\site-packages\numpy\distutils\misc_util.py", line 941, in get_subpackage caller_level = caller_level + 1) File "C:\Python27\lib\site-packages\numpy\distutils\misc_util.py", line 878, in _get_configuration_from_setup_py config = setup_module.configuration(*args) File "scikits\image\opencv\setup.py", line 20, in configuration cython(cython_files, working_path=base_path) File "C:\source\scikits.image\scikits\image\_build.py", line 51, in cython os.remove(c_file_new) WindowsError: [Error 2] The system cannot find the file specified: 'C:\\source\\scikits.image\\scikits\\ima ge\\opencv\\opencv_backend.c.new' -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfarmernv at gmail.com Mon May 16 00:37:08 2011 From: dfarmernv at gmail.com (Dan Farmer) Date: Sun, 15 May 2011 21:37:08 -0700 Subject: Cython on windows (again?) In-Reply-To: <28938579.1373.1305215618059.JavaMail.geo-discussion-forums@prok25> References: <28938579.1373.1305215618059.JavaMail.geo-discussion-forums@prok25> Message-ID: So I was able to resolve this. In EPD the cython.py file is located in site-packages, but cython.exe evidently expects it to be in Scripts. So I moved cython.py to c:\Python27\Scripts and it worked (incidentally, I compared this to python x,y and it defaults to putting cython.py in Scripts, so scikits.image builds out of the box with python x,y on windows). I don't know distutils well enough to say if something should change on the scikits.image side or if Enthought just needs to tweak their setup. Unfortunately that's not the end of the issues, but I'll send a separate email for future Google searchers. Thanks, Dan On Thu, May 12, 2011 at 8:53 AM, Dan Farmer wrote: > Hi Guys, > So the semester is over and I'm starting to gear back up (sorry for dropping > off the map for bit :( ). Since my last work on the project I got a new > computer so I'm now working in Windows using EPD 7. I checked everything out > last night and updated, but when I tried to build in place I get the > traceback below. EPD 7 does come with cython 0.14.1 > Any ideas to help me get up and running again? > Thanks, > Dan > cython -o C:\source\scikits.image\scikits\image\opencv\opencv_backend.c.new > C:\source\scikits.image\scikits\image\opencv\opencv_backend.pyx > Cython compilation of opencv_backend.pyx failed. Falling back on > pre-generated file. > python.exe : C:\Python27\python.exe: can't open file > 'C:\Python27\Scripts\cython.py': [Errno 2] No such file or directory > > Traceback (most recent call last): > ? File "setup.py", line 97, in > ? ? cmdclass={'build_py': build_py}, > ? File "C:\Python27\lib\site-packages\numpy\distutils\core.py", line 152, in > setup > ? ? config = configuration() > ? File "setup.py", line 44, in configuration > ? ? config.add_subpackage(DISTNAME) > ? File "C:\Python27\lib\site-packages\numpy\distutils\misc_util.py", line > 972, in add_subpackage > ? ? caller_level = 2) > ? File "C:\Python27\lib\site-packages\numpy\distutils\misc_util.py", line > 941, in get_subpackage > ? ? caller_level = caller_level + 1) > ? File "C:\Python27\lib\site-packages\numpy\distutils\misc_util.py", line > 878, in _get_configuration_from_s > etup_py > ? ? config = setup_module.configuration(*args) > ? File "scikits\image\setup.py", line 8, in configuration > ? ? config.add_subpackage('opencv') > ? File "C:\Python27\lib\site-packages\numpy\distutils\misc_util.py", line > 972, in add_subpackage > ? ? caller_level = 2) > ? File "C:\Python27\lib\site-packages\numpy\distutils\misc_util.py", line > 941, in get_subpackage > ? ? caller_level = caller_level + 1) > ? File "C:\Python27\lib\site-packages\numpy\distutils\misc_util.py", line > 878, in _get_configuration_from_setup_py > ? ? config = setup_module.configuration(*args) > ? File "scikits\image\opencv\setup.py", line 20, in configuration > ? ? cython(cython_files, working_path=base_path) > ? File "C:\source\scikits.image\scikits\image\_build.py", line 51, in cython > ? ? os.remove(c_file_new) > WindowsError: [Error 2] The system cannot find the file specified: > 'C:\\source\\scikits.image\\scikits\\ima > ge\\opencv\\opencv_backend.c.new' From dfarmernv at gmail.com Mon May 16 01:24:32 2011 From: dfarmernv at gmail.com (Dan Farmer) Date: Sun, 15 May 2011 22:24:32 -0700 Subject: FreeImage_GetPitch not found (on Win7 x64) Message-ID: I see there has been some recent activity on Windows issues in the last few days, but I didn't see anything exactly related to this issue, so I opened ticket: https://github.com/stefanv/scikits.image/issues/22 (I only mention this because I don't know if anyone besides Stefan gets notified when an issue is created). The traceback and other details are in the issue on github. I tried manually loading FreeImage.dll using ctypes in an ipython session and had the same issue, checking FreeImage's header file shows that the function should be there though. Anyone have any ideas on what else I can try? Thanks, Dan From zachary.pincus at yale.edu Mon May 16 08:08:08 2011 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Mon, 16 May 2011 08:08:08 -0400 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: Message-ID: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> Hi Dan, > I see there has been some recent activity on Windows issues in the > last few days, but I didn't see anything exactly related to this > issue, so I opened ticket: > https://github.com/stefanv/scikits.image/issues/22 (I only mention > this because I don't know if anyone besides Stefan gets notified when > an issue is created). The traceback and other details are in the issue > on github. > > I tried manually loading FreeImage.dll using ctypes in an ipython > session and had the same issue, checking FreeImage's header file shows > that the function should be there though. Anyone have any ideas on > what else I can try? I suspect it's not just FreeImage_GetPitch that isn't visible, but all FreeImage_ API calls. (You could check this easily enough though...) I think GetPitch is just the first one that gets looked up. My guess is that the library on Win7 has different name mangling than is expected. I think that in general the library gets loaded as a "cdll" instead of a "windll" on windows, which appears to work with my limited testing on a XP 32-bit virtual machine. Perhaps try loading the library as a windll via ctypes and then see if any of the symbols are visible. Or you could dump the dll's symbol table and see what's there... (MinGW has some tools for this -- pexports I think? I bet there are MS tools for the same as part of VC++ but I have no idea.) Sorry to not be more direct help, Zach From dfarmernv at gmail.com Mon May 16 23:58:32 2011 From: dfarmernv at gmail.com (Dan Farmer) Date: Mon, 16 May 2011 20:58:32 -0700 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> References: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> Message-ID: On Mon, May 16, 2011 at 5:08 AM, Zachary Pincus wrote: > Hi Dan, > >> I see there has been some recent activity on Windows issues in the >> last few days, but I didn't see anything exactly related to this >> issue, so I opened ticket: >> https://github.com/stefanv/scikits.image/issues/22 (I only mention >> this because I don't know if anyone besides Stefan gets notified when >> an issue is created). The traceback and other details are in the issue >> on github. >> >> I tried manually loading FreeImage.dll using ctypes in an ipython >> session and had the same issue, checking FreeImage's header file shows >> that the function should be there though. Anyone have any ideas on >> what else I can try? > > I suspect it's not just FreeImage_GetPitch that isn't visible, but all FreeImage_ API calls. (You could check this easily enough though...) I think GetPitch is just the first one that gets looked up. > > My guess is that the library on Win7 has different name mangling than is expected. I think that in general the library gets loaded as a "cdll" instead of a "windll" on windows, which appears to work with my limited testing on a XP 32-bit virtual machine. Perhaps try loading the library as a windll via ctypes and then see if any of the symbols are visible. > > Or you could dump the dll's symbol table and see what's there... (MinGW has some tools for this -- pexports I think? I bet there are MS tools for the same as part of VC++ but I have no idea.) > > Sorry to not be more direct help, > Zach Hi Zach, Loading the library with WinDLL worked (unfortunately in the freeimage plugin code it looks like that's handled by numpy.ctypeslib.load_library which apparently doesn't support anything other than cdll). I read up on ctypes and saw that you can also call functions by ordinal. So loading FreeImage.dll using the cdll calling convention and accessing via ordinal worked fine as well. So I'm not sure what your preferred fix would be, I guess just changing the load code to handle cdll versus windll is more clear than mapping functions to ordinals. -Dan From zachary.pincus at yale.edu Tue May 17 08:25:23 2011 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Tue, 17 May 2011 08:25:23 -0400 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> Message-ID: Hi, An additional difficulty is that on some versions of windows with some versions of the FreeImage library, the cdll calling convention is the one to use (I seem to recall, from my limited testing). So I suppose the fix will have to be to load the library one way and test if the functions can be found, and if not, load it the other way. Ugh. Plus the problem with numpy.ctypeslib.load_library. Getting this fixed plus the 64-bit crash bug I tracked down earlier (https://github.com/zachrahan/scikits.image/tree/FreeImage64 ) will hopefully make FreeImage a viable option for image IO for more folks. Zach On May 17, 2011, at 8:07 AM, St?fan van der Walt wrote: > Hi Dan > > On Tue, May 17, 2011 at 5:58 AM, Dan Farmer wrote: >> So I'm not sure what your preferred fix would be, I guess just >> changing the load code to handle cdll versus windll is more clear than >> mapping functions to ordinals. > > It sounds like we should submit a patch to numpy, but then also use an > updated version in scikits.image in the meanwhile. It'd be great if > you could have a further look. > > Thanks! > St?fan From dfarmernv at gmail.com Tue May 17 12:08:31 2011 From: dfarmernv at gmail.com (Dan Farmer) Date: Tue, 17 May 2011 09:08:31 -0700 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> Message-ID: Ok, I'll see if I can get the windll thing coded up. In terms of "git-fu" should I base those changes on your branch you listed or wait for that to be merged? I don't want to create a merging mess by having branches of branches, but maybe I'm underestimating git. -Dan On Tue, May 17, 2011 at 5:25 AM, Zachary Pincus wrote: > Hi, > > An additional difficulty is that on some versions of windows with some versions of the FreeImage library, the cdll calling convention is the one to use (I seem to recall, from my limited testing). So I suppose the fix will have to be to load the library one way and test if the functions can be found, and if not, load it the other way. Ugh. > > Plus the problem with numpy.ctypeslib.load_library. > > Getting this fixed plus the 64-bit crash bug I tracked down earlier (https://github.com/zachrahan/scikits.image/tree/FreeImage64 ) will hopefully make FreeImage a viable option for image IO for more folks. > > Zach > > > > On May 17, 2011, at 8:07 AM, St?fan van der Walt wrote: > >> Hi Dan >> >> On Tue, May 17, 2011 at 5:58 AM, Dan Farmer wrote: >>> So I'm not sure what your preferred fix would be, I guess just >>> changing the load code to handle cdll versus windll is more clear than >>> mapping functions to ordinals. >> >> It sounds like we should submit a patch to numpy, but then also use an >> updated version in scikits.image in the meanwhile. ?It'd be great if >> you could have a further look. >> >> Thanks! >> St?fan > > From stefan at sun.ac.za Tue May 17 05:44:52 2011 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 17 May 2011 11:44:52 +0200 Subject: PyOpenCL computing backend Message-ID: Hi all, As you may know, we now have a GSoC student working on a new backend engine for scikits.image: http://pythonimaging.blogspot.com/2011/04/gsoc2011.html One of these will be a PyOpenCL-backend, which I hope will be able to leverage this PyOpenCL-subproject: https://github.com/inducer/compyte Cheers St?fan From zachary.pincus at yale.edu Tue May 17 12:44:58 2011 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Tue, 17 May 2011 12:44:58 -0400 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> Message-ID: <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> Cool -- thanks, Dan. Probably best to just branch off of Stefan's master, and then send him a pull request for your new branch. My FreeImage64 branch didn't touch any of the library-loading machinery at all (you could look at its diff), so any changes you make would merge cleanly with mine. Zach On May 17, 2011, at 12:08 PM, Dan Farmer wrote: > Ok, I'll see if I can get the windll thing coded up. In terms of > "git-fu" should I base those changes on your branch you listed or wait > for that to be merged? I don't want to create a merging mess by having > branches of branches, but maybe I'm underestimating git. > > -Dan > > On Tue, May 17, 2011 at 5:25 AM, Zachary Pincus wrote: >> Hi, >> >> An additional difficulty is that on some versions of windows with some versions of the FreeImage library, the cdll calling convention is the one to use (I seem to recall, from my limited testing). So I suppose the fix will have to be to load the library one way and test if the functions can be found, and if not, load it the other way. Ugh. >> >> Plus the problem with numpy.ctypeslib.load_library. >> >> Getting this fixed plus the 64-bit crash bug I tracked down earlier (https://github.com/zachrahan/scikits.image/tree/FreeImage64 ) will hopefully make FreeImage a viable option for image IO for more folks. >> >> Zach >> >> >> >> On May 17, 2011, at 8:07 AM, St?fan van der Walt wrote: >> >>> Hi Dan >>> >>> On Tue, May 17, 2011 at 5:58 AM, Dan Farmer wrote: >>>> So I'm not sure what your preferred fix would be, I guess just >>>> changing the load code to handle cdll versus windll is more clear than >>>> mapping functions to ordinals. >>> >>> It sounds like we should submit a patch to numpy, but then also use an >>> updated version in scikits.image in the meanwhile. It'd be great if >>> you could have a further look. >>> >>> Thanks! >>> St?fan >> >> From james.bergstra at gmail.com Tue May 17 13:28:07 2011 From: james.bergstra at gmail.com (James Bergstra) Date: Tue, 17 May 2011 13:28:07 -0400 Subject: PyOpenCL computing backend In-Reply-To: References: Message-ID: Exciting work. Can I draw your attention to related ongoing work with Andreas Klochner and Frederic Bastien on the 'gpundarray' also slated for compyte? The goal is essentially to provide a c-based datatype to supersede PyOpenCL's and PyCUDA's GpuArray. This datatype would be used as the gpu-side container by PyCUDA, PyOpenCL, Theano, and hopefully other projects too. It will extend the existing GpuArray by supporting strided memory layouts like numpy's ndarray. For ongoing design discussions - feel free to join the list: http://lists.tiker.net/listinfo/gpundarray James Bergstra On Tue, May 17, 2011 at 11:52 AM, Ralf Gommers wrote: > > > 2011/5/17 St?fan van der Walt > >> Hi all, >> >> As you may know, we now have a GSoC student working on a new backend >> engine for scikits.image: >> > > Sounds great! Perhaps Pieter's blog can be added to Planet Scipy for some > more exposure? > > Cheers, > Ralf > > >> http://pythonimaging.blogspot.com/2011/04/gsoc2011.html >> >> One of these will be a PyOpenCL-backend, which I hope will be able to >> leverage this PyOpenCL-subproject: >> >> https://github.com/inducer/compyte >> >> Cheers >> St?fan >> > > -- http://www-etud.iro.umontreal.ca/~bergstrj -------------- next part -------------- An HTML attachment was scrubbed... URL: From sccolbert at gmail.com Tue May 17 13:45:53 2011 From: sccolbert at gmail.com (Chris Colbert) Date: Tue, 17 May 2011 13:45:53 -0400 Subject: Scikits.image convore forum Message-ID: I've created a Convore forum for scikits.image https://convore.com/scikitsimage/ Just request membership and I'll approve you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jturner at gemini.edu Tue May 17 13:57:06 2011 From: jturner at gemini.edu (James Turner) Date: Tue, 17 May 2011 13:57:06 -0400 Subject: Scikits.image convore forum In-Reply-To: References: Message-ID: <4DD2B6F2.4080700@gemini.edu> > I've created a Convore forum for scikits.image > > https://convore.com/scikitsimage/ > > Just request membership and I'll approve you. Is this in addition to the mailing list or instead of it? I see it looks like an IRC-type thing so I'm guessing the former. Cheers, James. From sccolbert at gmail.com Tue May 17 14:00:37 2011 From: sccolbert at gmail.com (Chris Colbert) Date: Tue, 17 May 2011 14:00:37 -0400 Subject: Scikits.image convore forum In-Reply-To: <4DD2B6F2.4080700@gemini.edu> References: <4DD2B6F2.4080700@gemini.edu> Message-ID: On Tue, May 17, 2011 at 1:57 PM, James Turner wrote: > I've created a Convore forum for scikits.image >> >> https://convore.com/scikitsimage/ >> >> Just request membership and I'll approve you. >> > > Is this in addition to the mailing list or instead of it? I see it > looks like an IRC-type thing so I'm guessing the former. > > Cheers, > > James. > This will be in addition to the mailing list. Mostly for people that enjoy a more rapid discussion environment like IRC or chat (even though conversations are persisted). After using it now internally at Enthought for a while, I find it a really good medium for discussions during and surrounding development. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Tue May 17 08:07:07 2011 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 17 May 2011 14:07:07 +0200 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> Message-ID: Hi Dan On Tue, May 17, 2011 at 5:58 AM, Dan Farmer wrote: > So I'm not sure what your preferred fix would be, I guess just > changing the load code to handle cdll versus windll is more clear than > mapping functions to ordinals. It sounds like we should submit a patch to numpy, but then also use an updated version in scikits.image in the meanwhile. It'd be great if you could have a further look. Thanks! St?fan From ralf.gommers at googlemail.com Tue May 17 11:52:24 2011 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Tue, 17 May 2011 17:52:24 +0200 Subject: PyOpenCL computing backend In-Reply-To: References: Message-ID: 2011/5/17 St?fan van der Walt > Hi all, > > As you may know, we now have a GSoC student working on a new backend > engine for scikits.image: > Sounds great! Perhaps Pieter's blog can be added to Planet Scipy for some more exposure? Cheers, Ralf > http://pythonimaging.blogspot.com/2011/04/gsoc2011.html > > One of these will be a PyOpenCL-backend, which I hope will be able to > leverage this PyOpenCL-subproject: > > https://github.com/inducer/compyte > > Cheers > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Tue May 17 13:34:23 2011 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 17 May 2011 19:34:23 +0200 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> References: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> Message-ID: On Tue, May 17, 2011 at 6:44 PM, Zachary Pincus wrote: > Probably best to just branch off of Stefan's master, and then send him a pull request for your new branch. My FreeImage64 branch didn't touch any of the library-loading machinery at all (you could look at its diff), so any changes you make would merge cleanly with mine. Zach's changes are now all merged into my branch. Thanks, Zach! Cheers St?fan From dfarmernv at gmail.com Wed May 18 01:13:51 2011 From: dfarmernv at gmail.com (Dan Farmer) Date: Tue, 17 May 2011 22:13:51 -0700 Subject: PyOpenCL computing backend In-Reply-To: References: Message-ID: Just as a relevant resource for other people trying to get OpenCL savvy in a hurry, I've been watching a series of talks that Andreas Klockner gave in Jan. 2011. There are 4 one hour sessions: Lecture 1 - http://www.youtube.com/watch?v=X9mflbX1NL8 (Intro stuff) Lecture 2 - http://www.youtube.com/watch?v=MqvfCE_bKOg (PyOpenCL) Lecture 3 - http://www.youtube.com/watch?v=TAvKmV7CuUw (Code generation) Lecture 4 - http://www.youtube.com/watch?v=SsuJ0LvZW1Q (Multi-GPU, PyCUDA) Hope it helps someone :) -Dan 2011/5/17 James Bergstra : > Exciting work. ?Can I draw your attention to related ongoing work with > Andreas Klochner and Frederic Bastien on the 'gpundarray' also slated for > compyte? > The goal is essentially to provide a c-based datatype > to?supersede?PyOpenCL's and PyCUDA's GpuArray. This datatype would be used > as the gpu-side container by PyCUDA, PyOpenCL, Theano, and hopefully other > projects too. It will extend the existing GpuArray by supporting strided > memory layouts like numpy's ndarray. > For ongoing design discussions - feel free to join the list: > http://lists.tiker.net/listinfo/gpundarray > James Bergstra > On Tue, May 17, 2011 at 11:52 AM, Ralf Gommers > wrote: >> >> >> 2011/5/17 St?fan van der Walt >>> >>> Hi all, >>> >>> As you may know, we now have a GSoC student working on a new backend >>> engine for scikits.image: >> >> Sounds great! Perhaps Pieter's blog can be added to Planet Scipy for some >> more exposure? >> >> Cheers, >> Ralf >> >>> >>> http://pythonimaging.blogspot.com/2011/04/gsoc2011.html >>> >>> One of these will be a PyOpenCL-backend, which I hope will be able to >>> leverage this PyOpenCL-subproject: >>> >>> https://github.com/inducer/compyte >>> >>> Cheers >>> St?fan >> > > > > -- > http://www-etud.iro.umontreal.ca/~bergstrj > From holtzhau at gmail.com Wed May 18 05:16:50 2011 From: holtzhau at gmail.com (Pieter Holtzhausen) Date: Wed, 18 May 2011 11:16:50 +0200 Subject: PyOpenCL computing backend In-Reply-To: References: Message-ID: Hello group, My name is Pieter and I'll be working on improving this scikit as part of the GSOC project. Our work will mostly involve the backend and the implementation of various algorithms, but there may be lee way for additional improvements to make this scikit even more useful. Looking forward to contribute! Regards Pieter 2011/5/17 St?fan van der Walt : > Hi all, > > As you may know, we now have a GSoC student working on a new backend > engine for scikits.image: > > http://pythonimaging.blogspot.com/2011/04/gsoc2011.html > > One of these will be a PyOpenCL-backend, which I hope will be able to > leverage this PyOpenCL-subproject: > > https://github.com/inducer/compyte > > Cheers > St?fan > From dfarmernv at gmail.com Thu May 19 03:07:10 2011 From: dfarmernv at gmail.com (Dan Farmer) Date: Thu, 19 May 2011 00:07:10 -0700 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> Message-ID: So I made the change/minor fork for ctypeslib.load_library and it worked great for me. I had a few thoughts though. 1. The idea about pushing back to Numpy sounds great, but I wonder how to test it well enough? I imagine this is the type of thing that is used a lot and could break a lot of code if the behavior changes (e.g., people have already worked around it in some other manner, etc.) -- this one is minor from the scikits perspective, I just haven't really thought about how to change something in such a mature library before. 2. The "auto-detect" idea that Zach mentioned sounds good (try to import and call a function and if it fails try to load using the other calling convention and try again), but again thinking about Stefan's upstream comment that requires that load_library has some knowledge about the library being loaded (e.g., it needs a candidate test function to try to call). Anyway just thinking out loud, I'll push the branch in the morning (late here) and we can see if some other windows users can try it out to make sure it works on other systems. Thanks, Dan 2011/5/17 St?fan van der Walt : > On Tue, May 17, 2011 at 6:44 PM, Zachary Pincus wrote: >> Probably best to just branch off of Stefan's master, and then send him a pull request for your new branch. My FreeImage64 branch didn't touch any of the library-loading machinery at all (you could look at its diff), so any changes you make would merge cleanly with mine. > > Zach's changes are now all merged into my branch. ?Thanks, Zach! > > Cheers > St?fan > From jeanpatrick.pommier at gmail.com Thu May 19 10:19:43 2011 From: jeanpatrick.pommier at gmail.com (jip) Date: Thu, 19 May 2011 07:19:43 -0700 (PDT) Subject: multispectral imaging: rgb image Message-ID: <5609603.1070.1305814783392.JavaMail.geo-discussion-forums@yqmi17> Dear all, Is there something available in scikits-image to produce a rgb image from a 4 or more channels multispectralimage? Thanks Jean-Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Thu May 19 11:10:35 2011 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 19 May 2011 17:10:35 +0200 Subject: multispectral imaging: rgb image In-Reply-To: <5609603.1070.1305814783392.JavaMail.geo-discussion-forums@yqmi17> References: <5609603.1070.1305814783392.JavaMail.geo-discussion-forums@yqmi17> Message-ID: Hi Jean-Patrick On Thu, May 19, 2011 at 4:19 PM, jip wrote: > Is there something available in scikits-image to produce a rgb image from a > 4 or more channels multispectral image? We don't have any specific false-colour mappings implemented; these are typically problem dependent. It should be trivial to make such a mapping, though. See if you can find more information on the specific one used in your example, then we can give you a hand. Regards St?fan From dfarmernv at gmail.com Fri May 20 03:10:54 2011 From: dfarmernv at gmail.com (Dan Farmer) Date: Fri, 20 May 2011 00:10:54 -0700 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> Message-ID: Sorry for the delay, I pushed this branch https://github.com/dfarmer/scikits.image/compare/master...dfarmer-windll I've tested it on my system (Win7 x64 EPD 7), but obviously it needs regression testing in linux (working on my vm, turns out Ubuntu 10.04 doesn't have any of the requirements for scikits.image at the correct versions) and should probably be tested on Windows XP. So if anyone has a chance to test it that'd be cool, otherwise I'll at least try to run it on ubuntu in the next day or two. Thanks, Dan On Thu, May 19, 2011 at 12:07 AM, Dan Farmer wrote: > So I made the change/minor fork for ctypeslib.load_library and it > worked great for me. I had a few thoughts though. > > 1. The idea about pushing back to Numpy sounds great, but I wonder how > to test it well enough? I imagine this is the type of thing that is > used a lot and could break a lot of code if the behavior changes > (e.g., people have already worked around it in some other manner, > etc.) -- this one is minor from the scikits perspective, I just > haven't really thought about how to change something in such a mature > library before. > > 2. The "auto-detect" idea that Zach mentioned sounds good (try to > import and call a function and if it fails try to load using the other > calling convention and try again), but again thinking about Stefan's > upstream comment that requires that load_library has some knowledge > about the library being loaded (e.g., it needs a candidate test > function to try to call). > > Anyway just thinking out loud, I'll push the branch in the morning > (late here) and we can see if some other windows users can try it out > to make sure it works on other systems. > > Thanks, > Dan > > 2011/5/17 St?fan van der Walt : >> On Tue, May 17, 2011 at 6:44 PM, Zachary Pincus wrote: >>> Probably best to just branch off of Stefan's master, and then send him a pull request for your new branch. My FreeImage64 branch didn't touch any of the library-loading machinery at all (you could look at its diff), so any changes you make would merge cleanly with mine. >> >> Zach's changes are now all merged into my branch. ?Thanks, Zach! >> >> Cheers >> St?fan >> > From jeanpatrick.pommier at gmail.com Fri May 20 15:46:53 2011 From: jeanpatrick.pommier at gmail.com (jip) Date: Fri, 20 May 2011 12:46:53 -0700 (PDT) Subject: =?UTF-8?Q?Re=C2=A0:_Re:_multispectral_imaging:_rgb_image?= In-Reply-To: Message-ID: <29484348.2814.1305920813291.JavaMail.geo-discussion-forums@yqaf40> Hi St?fan, The following script try to produce a rgb image from a five channels image (with the grey images from my blog, converted to png:FarRed, Red, Gold, Green, Aqua(blue)). It fails with error: red=c3_r.reshape(c3,shape) TypeError: only length-1 arrays can be converted to Python scalars The other issue is how to choose the coef of the matrix m such that the colors are "well separated". In the HSV space, I suppose it is possible to choose the coef such that the colors are separated by 2pi/5 in the hue component,starting with FarRed=0?. *import numpy as np import readmagick import os user=os.path.expanduser("~") workdir=os.path.join(user,"Applications","ImagesTest","MFISH") blue="Aqua.tif" green="Green.tif" gold="Gold.tif" red="Red.tif" frd="FarRed.tif" complete_path=os.path.join(workdir,blue) i1=readmagick.readimg(complete_path) # complete_path=os.path.join(workdir,green) i2=readmagick.readimg(complete_path) # complete_path=os.path.join(workdir,gold) i3=readmagick.readimg(complete_path) # complete_path=os.path.join(workdir,red) i4=readmagick.readimg(complete_path) # complete_path=os.path.join(workdir,frd) i5=readmagick.readimg(complete_path) # shape=i5.shape print shape b=i1.flatten() g=i2.flatten() y=i3.flatten() r=i4.flatten() f=i5.flatten() #make a 2D array #each line is a pixel, column=channel channel5=np.vstack((f,r,y,g,b)) c5=channel5.T print c5.shape #try some coef m=np.array([[0.0, 0.02, 0.80], [0.0, 0.03, 0.10], [0.10, 0.05, 0.05], [0.10, 0.80, 0.04], [0.80, 0.10, 0.01]]) print m.shape #produce a flat rgb image c3=np.dot(c5,m) print "c3:",c3.shape c3_r=c3[:,0] print "c3_r:",c3_r.shape,c3_r.dtype c3_g=c3[:,1] c3_b=c3[:,2] print c3_r.shape red=c3_r.reshape(c3,shape)#should be a red image green=c3_g.reshape(c3,shape) blue=c3_b.reshape(c3,shape) import pylab pylab.imshow(red) pylab.show* Best regards Jean-Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfarmernv at gmail.com Fri May 20 19:15:33 2011 From: dfarmernv at gmail.com (Dan Farmer) Date: Fri, 20 May 2011 16:15:33 -0700 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> Message-ID: I tested it on Linux and found that I had an indentation error. After a series of embarrassingly stupid commits (sorry :( ) it now works for me on Win7 x64 and Ubuntu 10.04 32bit. Thanks, Dan On Fri, May 20, 2011 at 12:10 AM, Dan Farmer wrote: > Sorry for the delay, I pushed this branch > > https://github.com/dfarmer/scikits.image/compare/master...dfarmer-windll > > I've tested it on my system (Win7 x64 EPD 7), but obviously it needs > regression testing in linux (working on my vm, turns out Ubuntu 10.04 > doesn't have any of the requirements for scikits.image at the correct > versions) and should probably be tested on Windows XP. So if anyone > has a chance to test it that'd be cool, otherwise I'll at least try to > run it on ubuntu in the next day or two. > > Thanks, > Dan > > On Thu, May 19, 2011 at 12:07 AM, Dan Farmer wrote: >> So I made the change/minor fork for ctypeslib.load_library and it >> worked great for me. I had a few thoughts though. >> >> 1. The idea about pushing back to Numpy sounds great, but I wonder how >> to test it well enough? I imagine this is the type of thing that is >> used a lot and could break a lot of code if the behavior changes >> (e.g., people have already worked around it in some other manner, >> etc.) -- this one is minor from the scikits perspective, I just >> haven't really thought about how to change something in such a mature >> library before. >> >> 2. The "auto-detect" idea that Zach mentioned sounds good (try to >> import and call a function and if it fails try to load using the other >> calling convention and try again), but again thinking about Stefan's >> upstream comment that requires that load_library has some knowledge >> about the library being loaded (e.g., it needs a candidate test >> function to try to call). >> >> Anyway just thinking out loud, I'll push the branch in the morning >> (late here) and we can see if some other windows users can try it out >> to make sure it works on other systems. >> >> Thanks, >> Dan >> >> 2011/5/17 St?fan van der Walt : >>> On Tue, May 17, 2011 at 6:44 PM, Zachary Pincus wrote: >>>> Probably best to just branch off of Stefan's master, and then send him a pull request for your new branch. My FreeImage64 branch didn't touch any of the library-loading machinery at all (you could look at its diff), so any changes you make would merge cleanly with mine. >>> >>> Zach's changes are now all merged into my branch. ?Thanks, Zach! >>> >>> Cheers >>> St?fan >>> >> > From zachary.pincus at yale.edu Fri May 20 17:16:38 2011 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Fri, 20 May 2011 17:16:38 -0400 Subject: =?iso-8859-1?Q?Re=3A_Re=A0=3A_Re=3A_multispectral_imaging=3A_rgb?= =?iso-8859-1?Q?_image?= In-Reply-To: <29484348.2814.1305920813291.JavaMail.geo-discussion-forums@yqaf40> References: <29484348.2814.1305920813291.JavaMail.geo-discussion-forums@yqaf40> Message-ID: > red=c3_r.reshape(c3,shape) > TypeError: only length-1 arrays can be converted to Python scalars I assume you want red = c3_r.reshape(c3.shape) ? The method signature for the reshape method of numpy.ndarray is: ndarray.reshape(shape, order='C') From zachary.pincus at yale.edu Sun May 22 09:19:08 2011 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Sun, 22 May 2011 09:19:08 -0400 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> Message-ID: Hi Dan, I've been meaning to test this on my XP image, but I know that the previous version (which opened the library as cdll) worked properly on XP. So I wonder if there aren't different versions of the FreeImage dll that were compiled differently? This may complicate matters! I'll test this when I get a chance... Zach On May 20, 2011, at 7:15 PM, Dan Farmer wrote: > I tested it on Linux and found that I had an indentation error. After > a series of embarrassingly stupid commits (sorry :( ) it now works for > me on Win7 x64 and Ubuntu 10.04 32bit. > > Thanks, > Dan > > On Fri, May 20, 2011 at 12:10 AM, Dan Farmer wrote: >> Sorry for the delay, I pushed this branch >> >> https://github.com/dfarmer/scikits.image/compare/master...dfarmer-windll >> >> I've tested it on my system (Win7 x64 EPD 7), but obviously it needs >> regression testing in linux (working on my vm, turns out Ubuntu 10.04 >> doesn't have any of the requirements for scikits.image at the correct >> versions) and should probably be tested on Windows XP. So if anyone >> has a chance to test it that'd be cool, otherwise I'll at least try to >> run it on ubuntu in the next day or two. >> >> Thanks, >> Dan >> >> On Thu, May 19, 2011 at 12:07 AM, Dan Farmer wrote: >>> So I made the change/minor fork for ctypeslib.load_library and it >>> worked great for me. I had a few thoughts though. >>> >>> 1. The idea about pushing back to Numpy sounds great, but I wonder how >>> to test it well enough? I imagine this is the type of thing that is >>> used a lot and could break a lot of code if the behavior changes >>> (e.g., people have already worked around it in some other manner, >>> etc.) -- this one is minor from the scikits perspective, I just >>> haven't really thought about how to change something in such a mature >>> library before. >>> >>> 2. The "auto-detect" idea that Zach mentioned sounds good (try to >>> import and call a function and if it fails try to load using the other >>> calling convention and try again), but again thinking about Stefan's >>> upstream comment that requires that load_library has some knowledge >>> about the library being loaded (e.g., it needs a candidate test >>> function to try to call). >>> >>> Anyway just thinking out loud, I'll push the branch in the morning >>> (late here) and we can see if some other windows users can try it out >>> to make sure it works on other systems. >>> >>> Thanks, >>> Dan >>> >>> 2011/5/17 St?fan van der Walt : >>>> On Tue, May 17, 2011 at 6:44 PM, Zachary Pincus wrote: >>>>> Probably best to just branch off of Stefan's master, and then send him a pull request for your new branch. My FreeImage64 branch didn't touch any of the library-loading machinery at all (you could look at its diff), so any changes you make would merge cleanly with mine. >>>> >>>> Zach's changes are now all merged into my branch. Thanks, Zach! >>>> >>>> Cheers >>>> St?fan >>>> >>> >> From jeanpatrick.pommier at gmail.com Sun May 22 16:05:24 2011 From: jeanpatrick.pommier at gmail.com (jip) Date: Sun, 22 May 2011 13:05:24 -0700 (PDT) Subject: =?ISO-8859-1?Q?Re=3A_Re=A0=3A_Re=3A_multispectral_imaging=3A_rgb_image?= In-Reply-To: References: <29484348.2814.1305920813291.JavaMail.geo-discussion-forums@yqaf40> Message-ID: Hi c3_r is a 1D vector of size: (333465,) I have shape=(517, 645) Now if I do: print "New Red 1D vecteur:",c3_r.shape print "original widthXheight=",shape[1]*shape[0] #Reconstitute original image size #should be a red image of size =shape red=c3_r.reshape(shape) print red.shape, red.dtype I have the right original size. Thank you Jean-Patrick On 20 mai, 23:16, Zachary Pincus wrote: > > red=c3_r.reshape(c3,shape) > > TypeError: only length-1 arrays can be converted to Python scalars > > I assume you want red = c3_r.reshape(c3.shape) ? > > The method signature for the reshape method of numpy.ndarray is: > ndarray.reshape(shape, order='C') From zachary.pincus at yale.edu Mon May 23 08:12:08 2011 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Mon, 23 May 2011 08:12:08 -0400 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> Message-ID: <4B864BA4-15FE-4B3B-A6C9-EF65F0CB13AD@yale.edu> > Strange that it worked at all then. Does anybody know the difference > between cdll and windll? It's to do with how the symbols are declared in the library, and how the arguments are pushed to the stack (or something similar). Not all dlls on windows seem to be compiled with the windll calling convention, though I don't know why or in what circumstances you see that. Anyway, I'll test further when I get a chance (sorry, very busy here). From dfarmernv at gmail.com Mon May 23 11:16:38 2011 From: dfarmernv at gmail.com (Dan Farmer) Date: Mon, 23 May 2011 08:16:38 -0700 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: <4B864BA4-15FE-4B3B-A6C9-EF65F0CB13AD@yale.edu> References: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> <4B864BA4-15FE-4B3B-A6C9-EF65F0CB13AD@yale.edu> Message-ID: Zach's essentially got it. It has to do with the different x86 calling conventions that are available. Most compilers use cdecl, but Microsoft's compilers sometimes use something called stdcall (which, looking at the symbols from FreeImage.dll, appears to be the case there). So ctypes.cdll loads a dll using cdecl convention and ctypes.windll loads a dll using stdcall. The unfortunate thing is that you're not guaranteed to always get stdcall dlls on windows and cdecl everywhere else. MSVC++ can compile cdecl exe's also, it's just a flag. Since this particular code is for the freeimage bindings though my hope is that if it passes the "download the latest freeimage binary, unzip and run" test then maybe we can call it good? -Dan On Mon, May 23, 2011 at 5:12 AM, Zachary Pincus wrote: >> Strange that it worked at all then. ?Does anybody know the difference >> between cdll and windll? > > It's to do with how the symbols are declared in the library, and how the arguments are pushed to the stack (or something similar). Not all dlls on windows seem to be compiled with the windll calling convention, though I don't know why or in what circumstances you see that. > > Anyway, I'll test further when I get a chance (sorry, very busy here). From jeanpatrick.pommier at gmail.com Mon May 23 13:46:12 2011 From: jeanpatrick.pommier at gmail.com (jip) Date: Mon, 23 May 2011 10:46:12 -0700 (PDT) Subject: =?UTF-8?Q?Re=C2=A0:_Re:_Re=C2=A0:_Re:_multispectral_imaging:_rgb_image?= In-Reply-To: Message-ID: <21262528.4973.1306172772250.JavaMail.geo-discussion-forums@yqlq3> Hi I have written a simpler script without linear algebra . Jean-Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From zachary.pincus at yale.edu Mon May 23 11:33:37 2011 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Mon, 23 May 2011 11:33:37 -0400 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> <4B864BA4-15FE-4B3B-A6C9-EF65F0CB13AD@yale.edu> Message-ID: <47A84913-6B0A-43D6-8536-E17FB748159B@yale.edu> Dan, if you could check that the relevant binaries (x64 and i386) of the latest version of FreeImage available online are stdcall, then that fix should be good. Otherwise (or perhaps in any case) we could add a "sniff_function" parameter to load_library, which would be the name of a symbol to look for in the library, and if not present, try to open the library with the other convention. Something like: if sys.platform == 'win32': windll = ctypes.windll(libpath) if sniff_function is not None and not hasattr(dll, sniff_function): cdll = ctypes.cdll(libpath) if hasattr(cdll, sniff_function): return cdll else: raise AttributeError("Could not find function %s in %s"%(sniff_function, libpath)) return windll On May 23, 2011, at 11:16 AM, Dan Farmer wrote: > Zach's essentially got it. It has to do with the different x86 calling > conventions that are available. Most compilers use cdecl, but > Microsoft's compilers sometimes use something called stdcall (which, > looking at the symbols from FreeImage.dll, appears to be the case > there). So ctypes.cdll loads a dll using cdecl convention and > ctypes.windll loads a dll using stdcall. > > The unfortunate thing is that you're not guaranteed to always get > stdcall dlls on windows and cdecl everywhere else. MSVC++ can compile > cdecl exe's also, it's just a flag. Since this particular code is for > the freeimage bindings though my hope is that if it passes the > "download the latest freeimage binary, unzip and run" test then maybe > we can call it good? > > -Dan > > On Mon, May 23, 2011 at 5:12 AM, Zachary Pincus wrote: >>> Strange that it worked at all then. Does anybody know the difference >>> between cdll and windll? >> >> It's to do with how the symbols are declared in the library, and how the arguments are pushed to the stack (or something similar). Not all dlls on windows seem to be compiled with the windll calling convention, though I don't know why or in what circumstances you see that. >> >> Anyway, I'll test further when I get a chance (sorry, very busy here). From stefan at sun.ac.za Mon May 23 07:00:19 2011 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 23 May 2011 13:00:19 +0200 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> Message-ID: On Sun, May 22, 2011 at 3:19 PM, Zachary Pincus wrote: > I've been meaning to test this on my XP image, but I know that the previous version (which opened the library as cdll) worked properly on XP. So I wonder if there aren't different versions of the FreeImage dll that were compiled differently? This may complicate matters! Strange that it worked at all then. Does anybody know the difference between cdll and windll? Regards St?fan From zachary.pincus at yale.edu Mon May 23 20:21:57 2011 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Mon, 23 May 2011 20:21:57 -0400 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: <47A84913-6B0A-43D6-8536-E17FB748159B@yale.edu> References: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> <4B864BA4-15FE-4B3B-A6C9-EF65F0CB13AD@yale.edu> <47A84913-6B0A-43D6-8536-E17FB748159B@yale.edu> Message-ID: <5EA2F707-E2EC-4976-BD97-9D4CED278F27@yale.edu> Dan, your patch works fine on XP. I was in error in thinking that some other version of FreeImage.dll was compiled as cdecl. (Long story...) Zach On May 23, 2011, at 11:33 AM, Zachary Pincus wrote: > Dan, if you could check that the relevant binaries (x64 and i386) of the latest version of FreeImage available online are stdcall, then that fix should be good. > > Otherwise (or perhaps in any case) we could add a "sniff_function" parameter to load_library, which would be the name of a symbol to look for in the library, and if not present, try to open the library with the other convention. Something like: > > if sys.platform == 'win32': > windll = ctypes.windll(libpath) > if sniff_function is not None and not hasattr(dll, sniff_function): > cdll = ctypes.cdll(libpath) > if hasattr(cdll, sniff_function): > return cdll > else: > raise AttributeError("Could not find function %s in %s"%(sniff_function, libpath)) > return windll > > > On May 23, 2011, at 11:16 AM, Dan Farmer wrote: > >> Zach's essentially got it. It has to do with the different x86 calling >> conventions that are available. Most compilers use cdecl, but >> Microsoft's compilers sometimes use something called stdcall (which, >> looking at the symbols from FreeImage.dll, appears to be the case >> there). So ctypes.cdll loads a dll using cdecl convention and >> ctypes.windll loads a dll using stdcall. >> >> The unfortunate thing is that you're not guaranteed to always get >> stdcall dlls on windows and cdecl everywhere else. MSVC++ can compile >> cdecl exe's also, it's just a flag. Since this particular code is for >> the freeimage bindings though my hope is that if it passes the >> "download the latest freeimage binary, unzip and run" test then maybe >> we can call it good? >> >> -Dan >> >> On Mon, May 23, 2011 at 5:12 AM, Zachary Pincus wrote: >>>> Strange that it worked at all then. Does anybody know the difference >>>> between cdll and windll? >>> >>> It's to do with how the symbols are declared in the library, and how the arguments are pushed to the stack (or something similar). Not all dlls on windows seem to be compiled with the windll calling convention, though I don't know why or in what circumstances you see that. >>> >>> Anyway, I'll test further when I get a chance (sorry, very busy here). From jeanpatrick.pommier at gmail.com Tue May 24 04:35:21 2011 From: jeanpatrick.pommier at gmail.com (jip) Date: Tue, 24 May 2011 01:35:21 -0700 (PDT) Subject: =?UTF-8?Q?Re=C2=A0:_Re:_Re_:_Re:_Re_:_Re:_mu?= =?UTF-8?Q?ltispectral_imaging:_rgb_image?= In-Reply-To: Message-ID: <5446898.5797.1306226121080.JavaMail.geo-discussion-forums@yqmi17> Hi St?fan, Thank you so much! I have things to learn with your script. You use a dictionary for the bands, isn't it? That may help me to write a class where the number of fluorochromes can vary. When Running the script, I get: *Traceback (most recent call last): File "/home/claire/Applications/ProjetPython/mfish/mfish.py", line 20, in bands.append(sio.imread(band)) File "/usr/local/lib/python2.6/dist-packages/scikits.image-0.3dev-py2.6-linux-i686.egg/scikits/image/io/io.py", line 72, in imread return func(*args, **kwargs) File "/usr/local/lib/python2.6/dist-packages/scikits.image-0.3dev-py2.6-linux-i686.egg/scikits/image/io/_plugins/pil_plugin.py", line 16, in imread im = Image.open(fname) File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 1952, in open fp = __builtin__.open(fp, "rb") IOError: [Errno 2] No such file or directory: 'Aqua.tif' img = call_plugin('imread', fname, plugin=plugin, **plugin_args) File "/usr/local/lib/python2.6/dist-packages/scikits.image-0.3dev-py2.6-linux-i686.egg/scikits/image/io/_plugins/plugin.py", line 88, in call* I check if I didn't modify some path or file, but I don't think so: *~/Applications/ImagesTest/MFISH$ ls Aqua.tif Case Info FarRed.tif G.png Kar.tif Red.tif B.png Dapi.tif Gold.tif Green.tif README.TXT R.png claire at claire-laptop:~/Applications/ImagesTest/MFISH$ pwd /home/claire/Applications/ImagesTest/MFISH* Best Regards Jean-Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanpatrick.pommier at gmail.com Tue May 24 05:14:43 2011 From: jeanpatrick.pommier at gmail.com (jip) Date: Tue, 24 May 2011 02:14:43 -0700 (PDT) Subject: =?UTF-8?Q?Re=C2=A0:_Re:_Re_:_Re:_Re_:_Re:_mu?= =?UTF-8?Q?ltispectral_imaging:_rgb_image?= In-Reply-To: <5446898.5797.1306226121080.JavaMail.geo-discussion-forums@yqmi17> Message-ID: <17426079.6121.1306228483566.JavaMail.geo-discussion-forums@yqhc1> It's fixed Thank you again Jean-Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mfish2.py Type: text/x-python Size: 998 bytes Desc: not available URL: From zachary.pincus at yale.edu Tue May 24 07:31:28 2011 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Tue, 24 May 2011 07:31:28 -0400 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> <4B864BA4-15FE-4B3B-A6C9-EF65F0CB13AD@yale.edu> <47A84913-6B0A-43D6-8536-E17FB748159B@yale.edu> <5EA2F707-E2EC-4976-BD97-9D4CED278F27@yale.edu> Message-ID: > On Tue, May 24, 2011 at 2:21 AM, Zachary Pincus wrote: >> Dan, your patch works fine on XP. I was in error in thinking that some other version of FreeImage.dll was compiled as cdecl. (Long story...) > > Does the patch work everywhere, then? I have no reason to believe it wouldn't, but I haven't tested exhaustively. (Packing for a trip right now...) Zach From stefan at sun.ac.za Tue May 24 03:40:20 2011 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 24 May 2011 09:40:20 +0200 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: <5EA2F707-E2EC-4976-BD97-9D4CED278F27@yale.edu> References: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> <4B864BA4-15FE-4B3B-A6C9-EF65F0CB13AD@yale.edu> <47A84913-6B0A-43D6-8536-E17FB748159B@yale.edu> <5EA2F707-E2EC-4976-BD97-9D4CED278F27@yale.edu> Message-ID: On Tue, May 24, 2011 at 2:21 AM, Zachary Pincus wrote: > Dan, your patch works fine on XP. I was in error in thinking that some other version of FreeImage.dll was compiled as cdecl. (Long story...) Does the patch work everywhere, then? St?fan From stefan at sun.ac.za Tue May 24 04:02:00 2011 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 24 May 2011 10:02:00 +0200 Subject: multispectral imaging: rgb image Message-ID: Hi Jean-Patrick 2011/5/23 jip : > Hi > I have written a simpler script without linear algebra. In the attached version I tried to clean up the script to avoid code repetition. Regards St?fan -------------- next part -------------- A non-text attachment was scrubbed... Name: mfish.py Type: text/x-python Size: 939 bytes Desc: not available URL: From jturner at gemini.edu Wed May 25 23:33:20 2011 From: jturner at gemini.edu (James Turner) Date: Wed, 25 May 2011 23:33:20 -0400 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> <4B864BA4-15FE-4B3B-A6C9-EF65F0CB13AD@yale.edu> <47A84913-6B0A-43D6-8536-E17FB748159B@yale.edu> <5EA2F707-E2EC-4976-BD97-9D4CED278F27@yale.edu> Message-ID: <4DDDCA00.5030506@gemini.edu> Hi Stefan & Chris, Just wondering whether you're planning on doing a sprint at SciPy this year? Cheers, James. From sccolbert at gmail.com Thu May 26 09:49:02 2011 From: sccolbert at gmail.com (Chris Colbert) Date: Thu, 26 May 2011 09:49:02 -0400 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> <4B864BA4-15FE-4B3B-A6C9-EF65F0CB13AD@yale.edu> <47A84913-6B0A-43D6-8536-E17FB748159B@yale.edu> <5EA2F707-E2EC-4976-BD97-9D4CED278F27@yale.edu> <4DDDCA00.5030506@gemini.edu> Message-ID: +1 On May 26, 2011 9:45 AM, "St?fan van der Walt" wrote: > On Thu, May 26, 2011 at 5:33 AM, James Turner wrote: >> Just wondering whether you're planning on doing a sprint at SciPy >> this year? > > I think that's a great idea, if we can get enough developers together. > By that stage, we should have the new backends in place, and there > are plenty of interesting side projects to integrate as well. Will > you be there? > > St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jturner at gemini.edu Thu May 26 11:00:39 2011 From: jturner at gemini.edu (James Turner) Date: Thu, 26 May 2011 11:00:39 -0400 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> <4B864BA4-15FE-4B3B-A6C9-EF65F0CB13AD@yale.edu> <47A84913-6B0A-43D6-8536-E17FB748159B@yale.edu> <5EA2F707-E2EC-4976-BD97-9D4CED278F27@yale.edu> <4DDDCA00.5030506@gemini.edu> Message-ID: <4DDE6B17.6040800@gemini.edu> > I think that's a great idea, if we can get enough developers together. > By that stage, we should have the new backends in place, and there > are plenty of interesting side projects to integrate as well. Will > you be there? Yes, I've signed up for the sprints without a clear agenda and am just finalizing my flights for my ~4 week trip. I might take off slightly early on 16th, as it's my birthday and a bit depressing to spend it all in the basement, but depends who's around and doing what :-). Hopefully I can help out a little bit (eg. never did the PyFITS save function from last year). Or maybe if I get a chance to think about it beforehand I could do something slightly more ambitious this time. I'll at least try to remind myself how git works :-). Cheers, James. From jturner at gemini.edu Thu May 26 13:34:54 2011 From: jturner at gemini.edu (James Turner) Date: Thu, 26 May 2011 13:34:54 -0400 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> <4B864BA4-15FE-4B3B-A6C9-EF65F0CB13AD@yale.edu> <47A84913-6B0A-43D6-8536-E17FB748159B@yale.edu> <5EA2F707-E2EC-4976-BD97-9D4CED278F27@yale.edu> <4DDDCA00.5030506@gemini.edu> <4DDE6B17.6040800@gemini.edu> Message-ID: <4DDE8F3E.6000209@gemini.edu> > There'll be plenty to do! It might be good to add some interpolation functions, but I'm not sure how realistic it is for 2 days' work (by me). There's some Netlib stuff that could probably "just" be wrapped, if you're interested, but it's ForTran and I don't know whether (doubt) you'd want to require that for compilation? Also, it might be too much along the lines of what I need and not what you want for the scikit, but it's just something to think about... Cheers, James. From stefan at sun.ac.za Thu May 26 09:45:00 2011 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 26 May 2011 15:45:00 +0200 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: <4DDDCA00.5030506@gemini.edu> References: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> <4B864BA4-15FE-4B3B-A6C9-EF65F0CB13AD@yale.edu> <47A84913-6B0A-43D6-8536-E17FB748159B@yale.edu> <5EA2F707-E2EC-4976-BD97-9D4CED278F27@yale.edu> <4DDDCA00.5030506@gemini.edu> Message-ID: On Thu, May 26, 2011 at 5:33 AM, James Turner wrote: > Just wondering whether you're planning on doing a sprint at SciPy > this year? I think that's a great idea, if we can get enough developers together. By that stage, we should have the new backends in place, and there are plenty of interesting side projects to integrate as well. Will you be there? St?fan From stefan at sun.ac.za Thu May 26 12:03:47 2011 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 26 May 2011 18:03:47 +0200 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: <4DDE6B17.6040800@gemini.edu> References: <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> <4B864BA4-15FE-4B3B-A6C9-EF65F0CB13AD@yale.edu> <47A84913-6B0A-43D6-8536-E17FB748159B@yale.edu> <5EA2F707-E2EC-4976-BD97-9D4CED278F27@yale.edu> <4DDDCA00.5030506@gemini.edu> <4DDE6B17.6040800@gemini.edu> Message-ID: On Thu, May 26, 2011 at 5:00 PM, James Turner wrote: > just finalizing my flights for my ~4 week trip. I might take off > slightly early on 16th, as it's my birthday and a bit depressing to > spend it all in the basement, but depends who's around and doing > what :-). We'll stick you for drinks if you work hard during the day ;) > Hopefully I can help out a little bit (eg. never did the > PyFITS save function from last year). Or maybe if I get a chance to There'll be plenty to do! Cheers St?fan From stefan at sun.ac.za Thu May 26 14:33:50 2011 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 26 May 2011 20:33:50 +0200 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: <4DDE8F3E.6000209@gemini.edu> References: <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> <4B864BA4-15FE-4B3B-A6C9-EF65F0CB13AD@yale.edu> <47A84913-6B0A-43D6-8536-E17FB748159B@yale.edu> <5EA2F707-E2EC-4976-BD97-9D4CED278F27@yale.edu> <4DDDCA00.5030506@gemini.edu> <4DDE6B17.6040800@gemini.edu> <4DDE8F3E.6000209@gemini.edu> Message-ID: On Thu, May 26, 2011 at 7:34 PM, James Turner wrote: > It might be good to add some interpolation functions, but I'm > not sure how realistic it is for 2 days' work (by me). There's > some Netlib stuff that could probably "just" be wrapped, if > you're interested, but it's ForTran and I don't know whether > (doubt) you'd want to require that for compilation? Also, it > might be too much along the lines of what I need and not what > you want for the scikit, but it's just something to think > about... Fast interpolation algorithms using PyOpenCL may be worth looking at. I heard today of an interesting interpolation method that does not go exactly through data-points, but is extremely efficient to implement--will look into that some more. Either way, being able to size up and down large images efficiently would certainly be useful. Scipy's ndimage does B-spline interpolation well, although I've never been able to decipher exactly what happens below the hood :) Cheers St?fan From ralf.gommers at googlemail.com Fri May 27 12:22:51 2011 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Fri, 27 May 2011 18:22:51 +0200 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> <4B864BA4-15FE-4B3B-A6C9-EF65F0CB13AD@yale.edu> <47A84913-6B0A-43D6-8536-E17FB748159B@yale.edu> <5EA2F707-E2EC-4976-BD97-9D4CED278F27@yale.edu> <4DDDCA00.5030506@gemini.edu> <4DDE6B17.6040800@gemini.edu> <4DDE8F3E.6000209@gemini.edu> Message-ID: 2011/5/26 St?fan van der Walt > On Thu, May 26, 2011 at 7:34 PM, James Turner wrote: > > It might be good to add some interpolation functions, but I'm > > not sure how realistic it is for 2 days' work (by me). There's > > some Netlib stuff that could probably "just" be wrapped, if > > you're interested, but it's ForTran and I don't know whether > > (doubt) you'd want to require that for compilation? Also, it > > might be too much along the lines of what I need and not what > > you want for the scikit, but it's just something to think > > about... > > Fast interpolation algorithms using PyOpenCL may be worth looking at. > I heard today of an interesting interpolation method that does not go > exactly through data-points, but is extremely efficient to > implement--will look into that some more. Either way, being able to > size up and down large images efficiently would certainly be useful. > > Is it just going "close enough" to the data points or does it do something like least-squares fitting to noisy data? If the latter, do you have a reference for this method? Thanks, Ralf > Scipy's ndimage does B-spline interpolation well, although I've never > been able to decipher exactly what happens below the hood :) > > Cheers > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emmanuelle.gouillart at normalesup.org Sat May 28 09:05:30 2011 From: emmanuelle.gouillart at normalesup.org (Emmanuelle Gouillart) Date: Sat, 28 May 2011 15:05:30 +0200 Subject: total variation denoising Message-ID: <20110528130530.GD24443@phare.normalesup.org> Dear all, I finally found some time to do some polishing on the TV denoising code that Ma??????l had written a while ago. I added a new module to my branch https://github.com/emmanuelle/scikits.image/tree/tv_denoise (https://github.com/emmanuelle/scikits.image/blob/tv_denoise/scikits/image/filter/tv_denoise.py). I'd like to have your opinion on how the code could be improved before a pull request. Cheers, Emmanuelle From mael.primet at gmail.com Sat May 28 09:09:26 2011 From: mael.primet at gmail.com (=?UTF-8?B?TWHDq2wgUHJpbWV0?=) Date: Sat, 28 May 2011 15:09:26 +0200 Subject: total variation denoising In-Reply-To: <20110528130530.GD24443@phare.normalesup.org> References: <20110528130530.GD24443@phare.normalesup.org> Message-ID: Great news! have you been able to do some benchmarks to see if the performance hit from Python is reasonnable? -------------- next part -------------- An HTML attachment was scrubbed... URL: From emmanuelle.gouillart at normalesup.org Sat May 28 10:07:01 2011 From: emmanuelle.gouillart at normalesup.org (Emmanuelle Gouillart) Date: Sat, 28 May 2011 16:07:01 +0200 Subject: total variation denoising In-Reply-To: References: <20110528130530.GD24443@phare.normalesup.org> Message-ID: <20110528140701.GE24443@phare.normalesup.org> > have you been able to do some benchmarks to see if the performance hit > from Python is reasonnable? I had done a rapid benchmark when I translated the C code into Python, and found that the Python code was 3 times slower compared to the C with Cython wrapping. But now I have improved the performance with a stop criterion on the energy, instead of a fixed number of iterations; hence it is difficult to compare now (of course, the stop criterion could be implemented in C too, but I was much more comfortable to do it in Python!). The performance has to be reasonable, because I have a student who is using this code to denoise large 3D images (512^3)! Emmanuelle ?????? From mael.primet at gmail.com Sat May 28 10:19:44 2011 From: mael.primet at gmail.com (=?UTF-8?B?TWHDq2wgUHJpbWV0?=) Date: Sat, 28 May 2011 16:19:44 +0200 Subject: total variation denoising In-Reply-To: <20110528140701.GE24443@phare.normalesup.org> References: <20110528130530.GD24443@phare.normalesup.org> <20110528140701.GE24443@phare.normalesup.org> Message-ID: great news :) On Sat, May 28, 2011 at 16:07, Emmanuelle Gouillart < emmanuelle.gouillart at normalesup.org> wrote: > > have you been able to do some benchmarks to see if the performance hit > > from Python is reasonnable? > > I had done a rapid benchmark when I translated the C code into Python, > and found that the Python code was 3 times slower compared to the C with > Cython wrapping. But now I have improved the performance with a stop > criterion on the energy, instead of a fixed number of iterations; hence > it is difficult to compare now (of course, the stop criterion could be > implemented in C too, but I was much more comfortable to do it in > Python!). > > The performance has to be reasonable, because I have a student who is > using this code to denoise large 3D images (512^3)! > > Emmanuelle > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Mon May 30 03:52:14 2011 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 30 May 2011 09:52:14 +0200 Subject: total variation denoising In-Reply-To: <20110528130530.GD24443@phare.normalesup.org> References: <20110528130530.GD24443@phare.normalesup.org> Message-ID: Hi Emmanuelle On Sat, May 28, 2011 at 3:05 PM, Emmanuelle Gouillart wrote: > ? ? ? ?I finally found some time to do some polishing on the TV > denoising code that Ma?l had written a while ago. I added a new module to > my branch https://github.com/emmanuelle/scikits.image/tree/tv_denoise > (https://github.com/emmanuelle/scikits.image/blob/tv_denoise/scikits/image/filter/tv_denoise.py). > > ? ? ? ?I'd like to have your opinion on how the code could be improved > before a pull request. The code looks great. Two minor things: a) let's move the tests into tests/test_tv_denoise.py b) Document the input dtype--currently data needs to be in floating point format--should it be in [0,1]? This is not quite clear. Thanks for taking the time to do this! Cheers St?fan From jturner at gemini.edu Mon May 30 13:15:38 2011 From: jturner at gemini.edu (James Turner) Date: Mon, 30 May 2011 13:15:38 -0400 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> <4B864BA4-15FE-4B3B-A6C9-EF65F0CB13AD@yale.edu> <47A84913-6B0A-43D6-8536-E17FB748159B@yale.edu> <5EA2F707-E2EC-4976-BD97-9D4CED278F27@yale.edu> <4DDDCA00.5030506@gemini.edu> <4DDE6B17.6040800@gemini.edu> <4DDE8F3E.6000209@gemini.edu> Message-ID: <4DE3D0BA.1030902@gemini.edu> > Fast interpolation algorithms using PyOpenCL may be worth looking at. > I heard today of an interesting interpolation method that does not go > exactly through data-points, but is extremely efficient to > implement--will look into that some more. Either way, being able to > size up and down large images efficiently would certainly be useful. I also noticed a SciPy abstract that sounded very interesting on this kind of thing... James. From dfarmernv at gmail.com Mon May 30 17:28:56 2011 From: dfarmernv at gmail.com (Dan Farmer) Date: Mon, 30 May 2011 14:28:56 -0700 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> <4B864BA4-15FE-4B3B-A6C9-EF65F0CB13AD@yale.edu> <47A84913-6B0A-43D6-8536-E17FB748159B@yale.edu> <5EA2F707-E2EC-4976-BD97-9D4CED278F27@yale.edu> Message-ID: Sorry, this thread sort of went sideways :P I just wanted to follow up and say that I've tested it on all of my machines (Win 7 and Ubuntu) and Zach tried it on his Win XP system -- I think that's all the testing we can come up with. I believe that this should be good to go. I'd still invite anyone else who uses the freeimage plugin to try it out if you have time, but I think in theory this is good to go. -Dan On Tue, May 24, 2011 at 4:31 AM, Zachary Pincus wrote: >> On Tue, May 24, 2011 at 2:21 AM, Zachary Pincus wrote: >>> Dan, your patch works fine on XP. I was in error in thinking that some other version of FreeImage.dll was compiled as cdecl. (Long story...) >> >> Does the patch work everywhere, then? > > I have no reason to believe it wouldn't, but I haven't tested exhaustively. (Packing for a trip right now...) > > Zach From dfarmernv at gmail.com Mon May 30 17:38:30 2011 From: dfarmernv at gmail.com (Dan Farmer) Date: Mon, 30 May 2011 14:38:30 -0700 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: <4DE40C91.3020802@gemini.edu> References: <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> <4B864BA4-15FE-4B3B-A6C9-EF65F0CB13AD@yale.edu> <47A84913-6B0A-43D6-8536-E17FB748159B@yale.edu> <5EA2F707-E2EC-4976-BD97-9D4CED278F27@yale.edu> <4DE40C91.3020802@gemini.edu> Message-ID: No big deal! I just figured I'd try to close out the last question before I forgot about it. On Mon, May 30, 2011 at 2:30 PM, James Turner wrote: >> Sorry, this thread sort of went sideways :P > > Oh, sorry I didn't change your title... > From jturner at gemini.edu Mon May 30 17:30:57 2011 From: jturner at gemini.edu (James Turner) Date: Mon, 30 May 2011 17:30:57 -0400 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> <4B864BA4-15FE-4B3B-A6C9-EF65F0CB13AD@yale.edu> <47A84913-6B0A-43D6-8536-E17FB748159B@yale.edu> <5EA2F707-E2EC-4976-BD97-9D4CED278F27@yale.edu> Message-ID: <4DE40C91.3020802@gemini.edu> > Sorry, this thread sort of went sideways :P Oh, sorry I didn't change your title... From emmanuelle.gouillart at normalesup.org Mon May 30 17:15:09 2011 From: emmanuelle.gouillart at normalesup.org (Emmanuelle Gouillart) Date: Mon, 30 May 2011 23:15:09 +0200 Subject: total variation denoising In-Reply-To: References: <20110528130530.GD24443@phare.normalesup.org> Message-ID: <20110530211509.GD7395@phare.normalesup.org> > The code looks great. Two minor things: a) let's move the tests into > tests/test_tv_denoise.py b) Document the input dtype--currently data > needs to be in floating point format--should it be in [0,1]? This is > not quite clear. Done; please tell me if it's ok. The input data can have any numerical dtype, actually, it doesn't have to be in [0, 1]. Cheers, Emmanuelle From stefan at sun.ac.za Tue May 31 06:49:06 2011 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 31 May 2011 12:49:06 +0200 Subject: total variation denoising In-Reply-To: <20110530211509.GD7395@phare.normalesup.org> References: <20110528130530.GD24443@phare.normalesup.org> <20110530211509.GD7395@phare.normalesup.org> Message-ID: Dear Emmanuelle and Ma?l On Mon, May 30, 2011 at 11:15 PM, Emmanuelle Gouillart wrote: >> The code looks great. ?Two minor things: a) let's move the tests into >> tests/test_tv_denoise.py b) Document the input dtype--currently data >> needs to be in floating point format--should it be in [0,1]? ?This is >> not quite clear. > > Done; please tell me if it's ok. The input data can have any numerical > dtype, actually, it doesn't have to be in [0, 1]. Thanks for all your effort. Your code has been merged into the main repository: https://github.com/stefanv/scikits.image/commit/ceb2e419c3eaf58cdc28062cca2e01dbe354cfd5 Regards St?fan From stefan at sun.ac.za Tue May 31 06:56:34 2011 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 31 May 2011 12:56:34 +0200 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> <4B864BA4-15FE-4B3B-A6C9-EF65F0CB13AD@yale.edu> <47A84913-6B0A-43D6-8536-E17FB748159B@yale.edu> <5EA2F707-E2EC-4976-BD97-9D4CED278F27@yale.edu> <4DDDCA00.5030506@gemini.edu> <4DDE6B17.6040800@gemini.edu> <4DDE8F3E.6000209@gemini.edu> Message-ID: On Fri, May 27, 2011 at 6:22 PM, Ralf Gommers wrote: >> Fast interpolation algorithms using PyOpenCL may be worth looking at. >> I heard today of an interesting interpolation method that does not go >> exactly through data-points, but is extremely efficient to >> implement--will look into that some more. ?Either way, being able to >> size up and down large images efficiently would certainly be useful. >> > Is it just going "close enough" to the data points or does it do something > like least-squares fitting to noisy data? If the latter, do you have a > reference for this method? http://dip.sun.ac.za/~herbst/research/publications/modeling.pdf Have a look at the new paragraph starting on p. 337. This stuff is really interesting :) Cheers St?fan From stefan at sun.ac.za Tue May 31 07:00:51 2011 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 31 May 2011 13:00:51 +0200 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: <9C7FF4C2-D5E5-419E-B6E5-49E9509888B7@yale.edu> <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> <4B864BA4-15FE-4B3B-A6C9-EF65F0CB13AD@yale.edu> <47A84913-6B0A-43D6-8536-E17FB748159B@yale.edu> <5EA2F707-E2EC-4976-BD97-9D4CED278F27@yale.edu> Message-ID: On Mon, May 30, 2011 at 11:28 PM, Dan Farmer wrote: > I just wanted to follow up and say that I've tested it on all of my > machines (Win 7 and Ubuntu) and Zach tried it on his Win XP system -- > I think that's all the testing we can come up with. I believe that > this should be good to go. I'd still invite anyone else who uses the > freeimage plugin to try it out if you have time, but I think in theory > this is good to go. Thanks, Dan! I've merged your changes and updated the contributors text. Cheers St?fan From emmanuelle.gouillart at normalesup.org Tue May 31 07:03:17 2011 From: emmanuelle.gouillart at normalesup.org (Emmanuelle Gouillart) Date: Tue, 31 May 2011 13:03:17 +0200 Subject: total variation denoising In-Reply-To: References: <20110528130530.GD24443@phare.normalesup.org> <20110530211509.GD7395@phare.normalesup.org> Message-ID: <20110531110317.GB17201@phare.normalesup.org> Thank you, St??????fan! On Tue, May 31, 2011 at 12:49:06PM +0200, St??????fan van der Walt wrote: > Dear Emmanuelle and Ma??????l > On Mon, May 30, 2011 at 11:15 PM, Emmanuelle Gouillart > wrote: > >> The code looks great. ??????Two minor things: a) let's move the tests into > >> tests/test_tv_denoise.py b) Document the input dtype--currently data > >> needs to be in floating point format--should it be in [0,1]? ??????This is > >> not quite clear. > > Done; please tell me if it's ok. The input data can have any numerical > > dtype, actually, it doesn't have to be in [0, 1]. > Thanks for all your effort. Your code has been merged into the main repository: > https://github.com/stefanv/scikits.image/commit/ceb2e419c3eaf58cdc28062cca2e01dbe354cfd5 > Regards > St??????fan From ralf.gommers at googlemail.com Tue May 31 17:32:42 2011 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Tue, 31 May 2011 23:32:42 +0200 Subject: FreeImage_GetPitch not found (on Win7 x64) In-Reply-To: References: <33CAB8FE-9B4C-48D7-A767-0771030A6C3E@yale.edu> <4B864BA4-15FE-4B3B-A6C9-EF65F0CB13AD@yale.edu> <47A84913-6B0A-43D6-8536-E17FB748159B@yale.edu> <5EA2F707-E2EC-4976-BD97-9D4CED278F27@yale.edu> <4DDDCA00.5030506@gemini.edu> <4DDE6B17.6040800@gemini.edu> <4DDE8F3E.6000209@gemini.edu> Message-ID: 2011/5/31 St?fan van der Walt > On Fri, May 27, 2011 at 6:22 PM, Ralf Gommers > wrote: > >> Fast interpolation algorithms using PyOpenCL may be worth looking at. > >> I heard today of an interesting interpolation method that does not go > >> exactly through data-points, but is extremely efficient to > >> implement--will look into that some more. Either way, being able to > >> size up and down large images efficiently would certainly be useful. > >> > > Is it just going "close enough" to the data points or does it do > something > > like least-squares fitting to noisy data? If the latter, do you have a > > reference for this method? > > http://dip.sun.ac.za/~herbst/research/publications/modeling.pdf > > Have a look at the new paragraph starting on p. 337. > > This stuff is really interesting :) > > It is. The technique is called subdivision surfaces, which I also didn't hear of before but which seems to be common in computer graphics. A good summary of related techniques and their applications is given in Chapter 2 of Krishnamurthy, "FITTING SMOOTH SURFACES TO DENSE POLYGON MESHES"; http://graphics.stanford.edu/papers/surfacefitting/surf_fit.pdf Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: