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 <zachary.pincus@yale.edu> 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 <dfarmernv@gmail.com> 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