Re: contributing C/Cython code to the scikit
![](https://secure.gravatar.com/avatar/af6c39d6943bd4b0e1fde23161e7bb8c.jpg?s=120&d=mm&r=g)
Hi Mael Welcome! On Mon, Sep 20, 2010 at 7:02 PM, mael <mael.primet@gmail.com> wrote:
here is a first code draft, including two basic filters http://github.com/maelp/scikits.image
First feedback: be sure to update the contributors.txt. We won't accept patches without it :)
could you tell me if the way I started it seems okay with you? (eg I've been hacking in some files to have everything compile.. am I doing it as it should be done?)
Some general comments: - We follow PEP7 and 8 regarding code style - Docstrings with usable examples are really important. We have a "plot" directive for including those in the docs as well. - Unit tests should be included in the standard test suite. All functions, including utility functions, should be tested and documented. - The 'shapes' sub-module is included twice? - Your patch removes the 'opencv' module for some reason. At the last sprint, we briefly spoke about how to handle different data types. IIRC, the idea was to support float and integer arrays, and to write a general utility function, used by most other functions, to convert the input image appropriately. This isn't in place yet, so we'll leave that discussion for another day. Thanks again for contributing! Regards Stéfan
![](https://secure.gravatar.com/avatar/9b5315c3555aa5fe090f656e02a46557.jpg?s=120&d=mm&r=g)
Thanks for the input Stéfan, I will try to gradually improve my python code style, have you specifics you have seen in my code that were out of the way? I removed opencv on my laptop because this wouldn't build (I'll try to figure out why) for the data types, the discussion is very interesting, most of the algorithms could be adapted for different data-types by some preprocessor-like translation, however, this might create some problems (floating point comparison etc). Plus, our feeling with the previous library we were using (Megawave) was that it was better not to provide an algorithm for each and every possible datatype, as it forced the end-user to ponder whether the algorithm he was trying to use was suited to his case etc. But I concur that writing float (possibly float and doubles) and integer (int and unsigned char?) arrays should be made as easy as possible. I'm in the process of writing docstrings and some unit testing I'll come back to you once I'll have played a bit with the library, hope we'll gain some momentum by adding a few interesting algorithms and get people to use the library as the Python standard btw we're also interested in coding some powerful visualization function. I guess we'd rather not clutter the scikit with dependencies to pyQt or other libraries. How would you go about doing something like this? Use some library like chaco? Write from scratch a PyQt viewer? I'm not really that good a coder, so I'd be happy to have you guys refactor some of my code and tell me the best way to go about it, particularly to avoid copying arrays over and over. We want to have simple contiguous arrays though, because we don't want to bother with complex array iteration in our C code. Is the way I'm doing it (that was given to us by Emmanuelle) the proper way of getting our arrays as contiguous C arrays or are there some more efficient and/or elegant way to do this?
participants (2)
-
mael
-
Stéfan van der Walt