Mailman 3 October 2012 - scikit-image

Re: Docs
by Tony Yu 02 Oct '12

02 Oct '12

On Mon, Oct 1, 2012 at 10:42 AM, Tony Yu <tsyu80(a)gmail.com> wrote: > > On Mon, Oct 1, 2012 at 3:55 AM, Schönberger Johannes < > hannesschoenberger(a)gmail.com> wrote: > <snip> > 3. the updated API reference lists a lot of duplicates. I think, it is >> sufficient to list "subpackage.function" and leave out the >> "subpackage.file.function". My guess is that Sphinx 1.1.X caused this new >> behavior. >> > > Hmm, I'm not sure what could have changed this. Note that the duplicates > appear in `doc/source/api/api.txt`, which is generated by some combination > of apigen.py, docscrape.py, docscrape_sphinx.py, and numpydoc.py in > `doc/tools/` and `doc/ext/`. My guess is that the problem was caused by a > change to one of these files. I'm not sure where exactly. > > > -Tony > > So I tracked down this issue to apigen and submitted a PR to fix this issue: https://github.com/scikits-image/scikits-image/pull/334 Here's a long-winded explanation of the fix (which is a bit strange, since all it does is delete 2 blocks of code): Basically, apigen walks the directory tree and looks for all directories and files that are modules, thus building a package tree. Then, it removes the deepest level of the resulting package tree: https://github.com/scikits-image/scikits-image/blob/master/doc/tools/apigen… In our case, removing the deepest level meant that it didn't document ` skimage.filter.edges.py` as it's own module, which was perfect since the public functions were imported into `skimage.filter`. Now, the problem is that apigen looks for the deepest level of the entire tree and just removes that level. So if we add a subpackage that has an extra level---e.g., `skimage.viewer.plugin.lineprofile.py`---then `edges` won't get stripped when removing the deepest level (since that level is now higher---or lower, depending on how you view the tree ;) If we wanted to follow the same logic as the original code, then we can just strip the leaf modules from the package tree. The pull request I submitted takes a different approach: Don't try to document python files, just document subpackages. This solution may not be robust, but I'm not really sure ignoring all the leaf modules would be either. -Tony

1 0

Re: scikits-image or scikit-image?
by Stéfan van der Walt 01 Oct '12

01 Oct '12

On Mon, Oct 1, 2012 at 8:12 PM, Stéfan van der Walt <stefan(a)sun.ac.za> wrote: > To the rest of the team: are you OK with re-branding to > ``scikit-image``? I know it's painful, but I think it's important > that all the scikits present a unified brand. And do we rename the repos again as well, or just the branding? That was a major pain last time. Stéfan

1 0

Re: scikits-image or scikit-image?
by Stéfan van der Walt 01 Oct '12

01 Oct '12

Hi Mathieu On Mon, Oct 1, 2012 at 2:35 AM, Mathieu Blondel <mathieu(a)mblondel.org> wrote: > I didn't know that the project already went through a rename... I would > completely understand if people don't want to do it again. Originally, the packages were "scikits.learn" and "scikits.image", which then became "scikit-learn". I discussed this with Gael et al. back then, and told them that I don't feel exactly comfortable with the use of "the scikit-learn", and especially "the scikit-image" (which just sounds awkward to me); I assumed it was a grammar mistake that would be corrected. We've been talking about "the image processing scikit" or "scikits-image". The confusion was apparent even in the scikit-learn release notes for v0.10: http://mail.scipy.org/pipermail/scipy-dev/2012-January/016941.html > That said, the current situation is indeed unfortunate. The people at > statsmodels don't have this problem since they dropped the scikit prefix, > apparently :) Agreed, and we should probably just get this behind us ASAP. OK, I now own scikit-learn, scikits-image, skimage and scikit-image I've reconfigured all our domains to go to skimage.org, but this may take a while to propagate. Let's hope we don't have too much down-time. To the rest of the team: are you OK with re-branding to ``scikit-image``? I know it's painful, but I think it's important that all the scikits present a unified brand. Stéfan

1 0

Re: Coverage table on the website
by Tony Yu 01 Oct '12

01 Oct '12

On Mon, Oct 1, 2012 at 8:45 PM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: > Hi everyone, > > On Mon, Oct 1, 2012 at 4:15 PM, Josh Warner <silvertrumpet999(a)gmail.com> > wrote: > > Should function-for-function feature parity, even where this is not > > particularly useful, be a goal? That's what I get from this table. > > > [...] > > > > As a reformed Matlab user, I personally prefer the general Python way > which > > is not "everything and the kitchen sink" in one massive package, but more > > pick-and-choose from a diverse toolkit for the problem(s) at hand. But > > that's just me. > > Thanks for your thoughts, Josh, I agree with the points you make. > > In my recent talk at EuroSciPy, I mentioned that the MATLAB > compatibility table was probably a mistake on my part. At that time, > I was trying to find a way forward with skimage that would help us to > grow, and providing an easy route of transitioning for users from > other platforms seemed like a worthwhile goal. > > Looking back, especially at my experience with Octave, I realize that > trying to imitate another package squashes much innovation and does > not lead to well-designed or Pythonic solutions. In the mean time, > the core team has grown, with a very active role being played by > excellent coders such as Tony, Johannes, Andreas, and others, so I > feel much less pressured to continue along that path. > > I think the compatibility table could still be useful as a list of > "pointers", but unless someone updates it soon, we should think about > removing it. That role can also be played by the user guide > (unfortunately, one of our weak points, which I'd love to address). > > Stéfan > I agree: we probably don't want to match Matlab function-for-function. Nevertheless, it'd be nice to have some of the functions on the coverage table. Just out of curiosity: Are there any functions on that list that people are really yearning for? That's directed particularly at *users* of scikits-image, rather than the core developers. I'm not promising I (or anyone else) would implemented it, but it'd be nice to get a sense of what's missing from some people outside of the handful that regularly comment on the list. On a related note: I was thinking of removing the tasks from the contribution page: http://scikits-image.org/docs/dev/contribute.html And adding those tasks to a wiki page on github. Thoughts? -Tony

1 0

Re: Docs
by Johannes Schönberger 01 Oct '12

01 Oct '12

Hi, I had some spare time today and made this new design concept: https://www.dropbox.com/s/hful1w3vso3achp/skimage%20website.zip The code highlighting and the logo have not been integrated yet, so the navbar design is also not final. Does anyone have the original file of the logo? Tell me, what you think about it. Regards, Johannes Am Montag, 1. Oktober 2012 16:43:04 UTC+2 schrieb Tony S Yu: > > Hi Johannes, > > Forwarding to the list; I hope you don't mind. > > On Mon, Oct 1, 2012 at 3:55 AM, Schönberger Johannes < > hannessch...(a)gmail.com <javascript:>> wrote: > >> Hi, >> >> great you released 0.7. Lately I changed the font size of the >> documentation. Although there are some deficiencies with the docs: >> >> 1. images in the gallery are too wide: >> http://scikits-image.org/docs/dev/auto_examples/plot_polygon.html > > > > Arrgh. Unfortunately, the docs rely on figures being a certain size (or > less) in order to fit on the page. That page size was specified relative to > the font size (which changed recently). So the image sizes didn't change > (as far as I can tell), but the page width shrank. > > Really, we should just set the stylesheet to cap the image size (as > Andreas suggested months ago in some PR). > > >> 2. homepage size not consistent with the rest >> > > Indeed. I believe you have a PR to fix this ;) Sorry, it's been ignored > for so long. > > >> 3. the updated API reference lists a lot of duplicates. I think, it is >> sufficient to list "subpackage.function" and leave out the >> "subpackage.file.function". My guess is that Sphinx 1.1.X caused this new >> behavior. >> > > Hmm, I'm not sure what could have changed this. Note that the duplicates > appear in `doc/source/api/api.txt`, which is generated by some combination > of apigen.py, docscrape.py, docscrape_sphinx.py, and numpydoc.py in > `doc/tools/` and `doc/ext/`. My guess is that the problem was caused by a > change to one of these files. I'm not sure where exactly. > > > -Tony > > >> >> Regards, >> >> Johannes Schönberger >> >> >

3 2

Coverage table on the website
by Wei LI ＠kuantkid 01 Oct '12

01 Oct '12

Dear all, Just notice that the warning on the page is still there( http://scikits-image.org/docs/0.7.0/coverage_table.html). There are still more red than green :) I am not sure whether it is a good idea to update this page and set priorities on what to expect in the near future for this package i.e. next release? My personal feeling is maybe a table of what is still missing for this package will benefit those contributors which in turn will benefit the package itself. I myself love open source and try to make some contributions(if any) for those great packages that are related to my work(computer vision mostly) but sometimes just get confused what piece of codes will benefit others and could be included into the packages. IMHO, issue on github could be a guideline and is important, but seem not to be enough. Maybe a big picture at the website just as the coverage_table is equally important.(Or maybe there are some such pages I just missed). Best, Wei

3 2

Re: Docs
by Schönberger Johannes 01 Oct '12

01 Oct '12

Glad you like it. Updated with the logo: https://www.dropbox.com/s/iz5xssqheiug2l5/skimage%20website%202.zip Johannes Schönberger Am 01.10.2012 um 19:34 schrieb Tony Yu <tsyu80(a)gmail.com>: > > > On Mon, Oct 1, 2012 at 1:19 PM, Johannes Schönberger <hannesschoenberger(a)gmail.com> wrote: > Hi, > > I had some spare time today and made this new design concept: https://www.dropbox.com/s/hful1w3vso3achp/skimage%20website.zip > > The code highlighting and the logo have not been integrated yet, so the navbar design is also not final. Does anyone have the original file of the logo? > > Tell me, what you think about it. > > > I don't really have anything more constructive to say than: Wow, I like it. > > You can generate the logo using the code found here: > > https://github.com/scikits-image/scikits-image/blob/master/doc/logo/scikits… > > Cheers, > -Tony > > > Regards, > > Johannes

1 1

Re: Docs
by Tony Yu 01 Oct '12

01 Oct '12

Hi Johannes, Forwarding to the list; I hope you don't mind. On Mon, Oct 1, 2012 at 3:55 AM, Schönberger Johannes < hannesschoenberger(a)gmail.com> wrote: > Hi, > > great you released 0.7. Lately I changed the font size of the > documentation. Although there are some deficiencies with the docs: > > 1. images in the gallery are too wide: > http://scikits-image.org/docs/dev/auto_examples/plot_polygon.html Arrgh. Unfortunately, the docs rely on figures being a certain size (or less) in order to fit on the page. That page size was specified relative to the font size (which changed recently). So the image sizes didn't change (as far as I can tell), but the page width shrank. Really, we should just set the stylesheet to cap the image size (as Andreas suggested months ago in some PR). > 2. homepage size not consistent with the rest > Indeed. I believe you have a PR to fix this ;) Sorry, it's been ignored for so long. > 3. the updated API reference lists a lot of duplicates. I think, it is > sufficient to list "subpackage.function" and leave out the > "subpackage.file.function". My guess is that Sphinx 1.1.X caused this new > behavior. > Hmm, I'm not sure what could have changed this. Note that the duplicates appear in `doc/source/api/api.txt`, which is generated by some combination of apigen.py, docscrape.py, docscrape_sphinx.py, and numpydoc.py in `doc/tools/` and `doc/ext/`. My guess is that the problem was caused by a change to one of these files. I'm not sure where exactly. -Tony > > Regards, > > Johannes Schönberger > >

1 0

Re: scikits-image or scikit-image?
by Andreas Mueller 01 Oct '12

01 Oct '12

Hey Mathieu. I agree that it is a bit awkward at the moment. I remember that when we wanted to get the sklearn freenode channel, people asked "so is this an organization? and why are they called differently?". As scikits-image already went through a rename, I'm not sure we should do it again. I remember there was some discussion back then and I think the outcome was "well sklearn decided for scikit and skimage for scikits, that's unfortunate but so be it". Btw sorry for the "scikits-image core developer" on the bio. I think that is a bit exaggerated given what others did in the last release. I wrote that after Stephan gave me commit rights and I was psyched ;) Cheers, Andy Am 01.10.2012 08:56, schrieb Mathieu Blondel: > Hello, > > I could not help but notice that you guys were using scikits-image as > project name, rather than scikit-image (without the "s" at the end of > "scikit"). > > In scikit-learn, after a passionate discussion on the mailing-list, > "scikit-learn" as project and "sklearn" as package ("import sklearn") > emerged as the most popular naming convention. > > This may not seem like big deal but I think a little consistency would > be beneficial to both scikit-learn and scikit-image (have a look at > Andreas' bio at the end of this blog post > http://blog.kaggle.com/2012/09/26/impermium-andreas-blog/ ). > > So here it is: woud you be willing to transition to scikit-image? > (change the logo, buy the domain name, ...) > > Since scikit-learn and scikit-image are the two most popular scikits, > hopefully this would set the example and new scikits would follow the > same naming convention in the future. > > For scikit-learn, the transition went rather smoothly and now, most > people correctly call it "scikit-learn" (rather than scikits-learn or > scikits.learn). > > Thanks, > Mathieu

2 1

scikits-image or scikit-image?
by Mathieu Blondel 01 Oct '12

01 Oct '12

Hello, I could not help but notice that you guys were using scikits-image as project name, rather than scikit-image (without the "s" at the end of "scikit"). In scikit-learn, after a passionate discussion on the mailing-list, "scikit-learn" as project and "sklearn" as package ("import sklearn") emerged as the most popular naming convention. This may not seem like big deal but I think a little consistency would be beneficial to both scikit-learn and scikit-image (have a look at Andreas' bio at the end of this blog post http://blog.kaggle.com/2012/09/26/impermium-andreas-blog/ ). So here it is: woud you be willing to transition to scikit-image? (change the logo, buy the domain name, ...) Since scikit-learn and scikit-image are the two most popular scikits, hopefully this would set the example and new scikits would follow the same naming convention in the future. For scikit-learn, the transition went rather smoothly and now, most people correctly call it "scikit-learn" (rather than scikits-learn or scikits.learn). Thanks, Mathieu

1 0