From kuantkid at gmail.com Mon Oct 1 09:08:45 2012 From: kuantkid at gmail.com (Wei LI @kuantkid) Date: Mon, 1 Oct 2012 06:08:45 -0700 (PDT) Subject: Coverage table on the website Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannesschoenberger at gmail.com Mon Oct 1 13:19:59 2012 From: hannesschoenberger at gmail.com (=?UTF-8?Q?Johannes_Sch=C3=B6nberger?=) Date: Mon, 1 Oct 2012 10:19:59 -0700 (PDT) Subject: Docs In-Reply-To: References: <6BCD3541-35EA-4557-A49F-3EFCF6F46C11@gmail.com> Message-ID: 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... at 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 >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsyu80 at gmail.com Mon Oct 1 10:42:21 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Mon, 1 Oct 2012 10:42:21 -0400 Subject: Docs In-Reply-To: <6BCD3541-35EA-4557-A49F-3EFCF6F46C11@gmail.com> References: <6BCD3541-35EA-4557-A49F-3EFCF6F46C11@gmail.com> Message-ID: 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 at 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amueller at ais.uni-bonn.de Mon Oct 1 05:06:31 2012 From: amueller at ais.uni-bonn.de (Andreas Mueller) Date: Mon, 01 Oct 2012 11:06:31 +0200 Subject: scikits-image or scikit-image? In-Reply-To: References: Message-ID: <50695D17.5090203@ais.uni-bonn.de> 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 From tsyu80 at gmail.com Mon Oct 1 13:34:47 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Mon, 1 Oct 2012 13:34:47 -0400 Subject: Docs In-Reply-To: References: <6BCD3541-35EA-4557-A49F-3EFCF6F46C11@gmail.com> Message-ID: On Mon, Oct 1, 2012 at 1:19 PM, Johannes Sch?nberger < hannesschoenberger at 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_image_logo.py Cheers, -Tony > > Regards, > > Johannes > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu at mblondel.org Mon Oct 1 02:56:20 2012 From: mathieu at mblondel.org (Mathieu Blondel) Date: Mon, 1 Oct 2012 15:56:20 +0900 Subject: scikits-image or scikit-image? Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvertrumpet999 at gmail.com Mon Oct 1 19:15:29 2012 From: silvertrumpet999 at gmail.com (Josh Warner) Date: Mon, 1 Oct 2012 16:15:29 -0700 (PDT) Subject: Coverage table on the website In-Reply-To: References: Message-ID: I'm not a core developer, so anyone feel free to correct any inaccuracies in this post. - I think most of the subsection "Image Types and Type Conversions" is now handled by various utility functions in `skimage.util` (like `img_as_float`). - There are now some registration tools available in skimage. I see many other areas that are either included, or appear to be blind attempts to translate Matlab functions directly. I could easily write an `imsubtract`, for example, but that functionality exists for any base 2D ndarray! Should function-for-function feature parity, even where this is not particularly useful, be a goal? That's what I get from this table. A separate but related issue is reinventing the wheel. NiBabel can read/write most medical image formats, including Analyze 7.5, nifti, and DICOM. Other well-known packages do 2d static visualization very well, load R files, etc. I don't have an answer for this without either reinventing many wheels, bringing over code from other projects (with attendant licensing issues and updating with their codebase, concern for backward compatibility), or adding dependencies to many other packages. 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. On Monday, October 1, 2012 8:08:45 AM UTC-5, Wei LI @kuantkid wrote: > > 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Mon Oct 1 20:45:03 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 1 Oct 2012 17:45:03 -0700 Subject: Coverage table on the website In-Reply-To: References: Message-ID: Hi everyone, On Mon, Oct 1, 2012 at 4:15 PM, Josh Warner 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 From stefan at sun.ac.za Mon Oct 1 21:20:14 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 1 Oct 2012 18:20:14 -0700 Subject: Docs In-Reply-To: References: <6BCD3541-35EA-4557-A49F-3EFCF6F46C11@gmail.com> Message-ID: On Mon, Oct 1, 2012 at 10:19 AM, Johannes Sch?nberger wrote: > Tell me, what you think about it. That looks great! Could we scale up the logo a bit and move it a tad to the left? And perhaps add a slightly darker gray (than the box itself) background to the "Image processing in Python" box? Perhaps like the other boxes, my guess would be roughly border: 1px solid #ccc; Also, the CSS design team should be credited somewhere. With the very prominent "Download" button, we also don't need that at the top. Finally, we can use a different font to distinguish the website. Perhaps Raleway, Ubuntu, PT Sans or Duru Sans? Add to bootstrap.min.css's: font-family: "Raleway"; and to the head section of index.html: More fonts here: http://www.google.com/webfonts St?fan From mathieu at mblondel.org Mon Oct 1 05:35:24 2012 From: mathieu at mblondel.org (Mathieu Blondel) Date: Mon, 1 Oct 2012 18:35:24 +0900 Subject: scikits-image or scikit-image? In-Reply-To: <50695D17.5090203@ais.uni-bonn.de> References: <50695D17.5090203@ais.uni-bonn.de> Message-ID: On Mon, Oct 1, 2012 at 6:06 PM, Andreas Mueller wrote: > 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 didn't know that the project already went through a rename... I would completely understand if people don't want to do it again. That said, the current situation is indeed unfortunate. The people at statsmodels don't have this problem since they dropped the scikit prefix, apparently :) Cheers, Mathieu -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Mon Oct 1 23:12:08 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 1 Oct 2012 20:12:08 -0700 Subject: scikits-image or scikit-image? In-Reply-To: References: <50695D17.5090203@ais.uni-bonn.de> Message-ID: Hi Mathieu On Mon, Oct 1, 2012 at 2:35 AM, Mathieu Blondel 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 From stefan at sun.ac.za Mon Oct 1 23:19:34 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 1 Oct 2012 20:19:34 -0700 Subject: scikits-image or scikit-image? In-Reply-To: References: <50695D17.5090203@ais.uni-bonn.de> Message-ID: On Mon, Oct 1, 2012 at 8:12 PM, St?fan van der Walt 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 From tsyu80 at gmail.com Mon Oct 1 22:40:31 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Mon, 1 Oct 2012 22:40:31 -0400 Subject: Coverage table on the website In-Reply-To: References: Message-ID: On Mon, Oct 1, 2012 at 8:45 PM, St?fan van der Walt wrote: > Hi everyone, > > On Mon, Oct 1, 2012 at 4:15 PM, Josh Warner > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannesschoenberger at gmail.com Mon Oct 1 16:54:07 2012 From: hannesschoenberger at gmail.com (=?iso-8859-1?Q?Sch=F6nberger_Johannes?=) Date: Mon, 1 Oct 2012 22:54:07 +0200 Subject: Docs In-Reply-To: References: <6BCD3541-35EA-4557-A49F-3EFCF6F46C11@gmail.com> Message-ID: <9CE3B851-0B46-49D8-B4B1-5F3D693BE1DA@gmail.com> 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 : > > > On Mon, Oct 1, 2012 at 1:19 PM, Johannes Sch?nberger 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_image_logo.py > > Cheers, > -Tony > > > Regards, > > Johannes From hannesschoenberger at gmail.com Mon Oct 1 16:59:02 2012 From: hannesschoenberger at gmail.com (=?iso-8859-1?Q?Sch=F6nberger_Johannes?=) Date: Mon, 1 Oct 2012 22:59:02 +0200 Subject: Docs In-Reply-To: <9CE3B851-0B46-49D8-B4B1-5F3D693BE1DA@gmail.com> References: <6BCD3541-35EA-4557-A49F-3EFCF6F46C11@gmail.com> <9CE3B851-0B46-49D8-B4B1-5F3D693BE1DA@gmail.com> Message-ID: Sorry, wrong files, here you are: https://www.dropbox.com/s/hful1w3vso3achp/skimage%20website.zip Johannes Sch?nberger Am 01.10.2012 um 22:54 schrieb Sch?nberger Johannes : > 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 : > >> >> >> On Mon, Oct 1, 2012 at 1:19 PM, Johannes Sch?nberger 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_image_logo.py >> >> Cheers, >> -Tony >> >> >> Regards, >> >> Johannes > From stefan at sun.ac.za Tue Oct 2 02:38:07 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 1 Oct 2012 23:38:07 -0700 Subject: Coverage table on the website In-Reply-To: References: Message-ID: On Mon, Oct 1, 2012 at 7:40 PM, Tony Yu wrote: > 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? That's a great idea--it would make it much easier to update. St?fan From stefan at sun.ac.za Tue Oct 2 02:51:39 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 1 Oct 2012 23:51:39 -0700 Subject: Coverage table on the website In-Reply-To: References: Message-ID: On Mon, Oct 1, 2012 at 11:37 PM, Wei LI wrote: > For the functions, I personally need some functions like im2col in matlab > and I would be rather happy to implement in scikits-image. I think you can already do that, based on the image windows implemented by Nicolas Pinto et al. > @St?fan MATLAB compatibility table can provide us an example for how to > organize the functions for an image-processing toolbox and get more users to > transfer from matlab to use skimage. I just want to make myself clear of > what the project lacks currently and what priority is that. Agreed, as long as it is up to date; at the moment that table does not reflect the state of skimage. > IMHO, I think if the pages on the tasks in the contribution page can > describe each tasks in more details then it would be more friendly to new > contributors? Another thing is maybe adding one chapter to describe the core > API is quite useful, like the image classes and other developer utilities is > useful? +1 St?fan From stefan at sun.ac.za Tue Oct 2 02:53:25 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 1 Oct 2012 23:53:25 -0700 Subject: scikits-image or scikit-image? In-Reply-To: References: <50695D17.5090203@ais.uni-bonn.de> Message-ID: On Mon, Oct 1, 2012 at 11:09 PM, Sch?nberger Johannes wrote: > What problems do we get, if we also rename the repos - apart from slightly adapting our forks? Everyone needs to update their forks, we need to go through the docs carefully and make replacements, the website needs to be updated, the Google+ page, etc. Nothing impossible, just a hassle. But let's do this one more time, if the rest of the core team agrees. St?fan From stefan at sun.ac.za Tue Oct 2 03:06:23 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 2 Oct 2012 00:06:23 -0700 Subject: Docs In-Reply-To: <25B08EA4-A0BD-46EB-BE6A-97692C4BAEE1@gmail.com> References: <6BCD3541-35EA-4557-A49F-3EFCF6F46C11@gmail.com> <25B08EA4-A0BD-46EB-BE6A-97692C4BAEE1@gmail.com> Message-ID: On Mon, Oct 1, 2012 at 11:21 PM, Sch?nberger Johannes wrote: >> Also, the CSS design team should be credited somewhere. > > You mean the bootstrap team? I think it is best to list them in the footer next to the "sphinx" credit. Sounds good. > I really like the "Ralway" font. > > See: https://www.dropbox.com/s/hful1w3vso3achp/skimage%20website.zip > > If everything's fine so far, I'll create it a sphinx template for this. Perfect! St?fan From tsyu80 at gmail.com Tue Oct 2 00:49:51 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Tue, 2 Oct 2012 00:49:51 -0400 Subject: Docs In-Reply-To: References: <6BCD3541-35EA-4557-A49F-3EFCF6F46C11@gmail.com> Message-ID: On Mon, Oct 1, 2012 at 10:42 AM, Tony Yu wrote: > > On Mon, Oct 1, 2012 at 3:55 AM, Sch?nberger Johannes < > hannesschoenberger at gmail.com> wrote: > > 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.py#L430 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdholt1 at gmail.com Tue Oct 2 03:05:19 2012 From: bdholt1 at gmail.com (Brian Holt) Date: Tue, 2 Oct 2012 08:05:19 +0100 Subject: scikits-image or scikit-image? In-Reply-To: <20121002070253.GB18200@phare.normalesup.org> References: <50695D17.5090203@ais.uni-bonn.de> <20121002070253.GB18200@phare.normalesup.org> Message-ID: I agree. It's a bit painful but I think it's worth it. Brian On Oct 2, 2012 8:03 AM, "Emmanuelle Gouillart" < emmanuelle.gouillart at nsup.org> wrote: > On Mon, Oct 01, 2012 at 11:53:25PM -0700, St?fan van der Walt wrote: > > On Mon, Oct 1, 2012 at 11:09 PM, Sch?nberger Johannes > > wrote: > > > What problems do we get, if we also rename the repos - apart from > slightly adapting our forks? > > > Everyone needs to update their forks, we need to go through the docs > > carefully and make replacements, the website needs to be updated, the > > Google+ page, etc. Nothing impossible, just a hassle. But let's do > > this one more time, if the rest of the core team agrees. > > +1 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannesschoenberger at gmail.com Tue Oct 2 02:09:17 2012 From: hannesschoenberger at gmail.com (=?iso-8859-1?Q?Sch=F6nberger_Johannes?=) Date: Tue, 2 Oct 2012 08:09:17 +0200 Subject: scikits-image or scikit-image? In-Reply-To: References: <50695D17.5090203@ais.uni-bonn.de> Message-ID: I also think, that scikit-image is better. > And do we rename the repos again as well, or just the branding? That > was a major pain last time. What problems do we get, if we also rename the repos - apart from slightly adapting our forks? Johannes Sch?nberger Am 02.10.2012 um 05:19 schrieb St?fan van der Walt : > On Mon, Oct 1, 2012 at 8:12 PM, St?fan van der Walt 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 From hannesschoenberger at gmail.com Tue Oct 2 02:21:42 2012 From: hannesschoenberger at gmail.com (=?iso-8859-1?Q?Sch=F6nberger_Johannes?=) Date: Tue, 2 Oct 2012 08:21:42 +0200 Subject: Docs In-Reply-To: References: <6BCD3541-35EA-4557-A49F-3EFCF6F46C11@gmail.com> Message-ID: <25B08EA4-A0BD-46EB-BE6A-97692C4BAEE1@gmail.com> Hi, > Could we scale up the logo a bit and move it a tad to the left? And > perhaps add a slightly darker gray (than the box itself) background to > the "Image processing in Python" box? Perhaps like the other boxes, > my guess would be roughly > > border: 1px solid #ccc; Now looks like all the other boxes. > Also, the CSS design team should be credited somewhere. You mean the bootstrap team? I think it is best to list them in the footer next to the "sphinx" credit. > With the very prominent "Download" button, we also don't need that at the top. Right, removed. > Finally, we can use a different font to distinguish the website. > Perhaps Raleway, Ubuntu, PT Sans or Duru Sans? Add to > bootstrap.min.css's: I really like the "Ralway" font. See: https://www.dropbox.com/s/hful1w3vso3achp/skimage%20website.zip If everything's fine so far, I'll create it a sphinx template for this. Johannes From emmanuelle.gouillart at nsup.org Tue Oct 2 03:03:01 2012 From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart) Date: Tue, 2 Oct 2012 09:03:01 +0200 Subject: scikits-image or scikit-image? In-Reply-To: References: <50695D17.5090203@ais.uni-bonn.de> Message-ID: <20121002070253.GB18200@phare.normalesup.org> On Mon, Oct 01, 2012 at 11:53:25PM -0700, St??????fan van der Walt wrote: > On Mon, Oct 1, 2012 at 11:09 PM, Sch??????nberger Johannes > wrote: > > What problems do we get, if we also rename the repos - apart from slightly adapting our forks? > Everyone needs to update their forks, we need to go through the docs > carefully and make replacements, the website needs to be updated, the > Google+ page, etc. Nothing impossible, just a hassle. But let's do > this one more time, if the rest of the core team agrees. +1 From liwei at ee.cuhk.edu.hk Tue Oct 2 02:37:38 2012 From: liwei at ee.cuhk.edu.hk (Wei LI) Date: Tue, 2 Oct 2012 14:37:38 +0800 Subject: Coverage table on the website In-Reply-To: References: Message-ID: @Tony It may be more clear if all tasks in the contribution page have an issue :) For the functions, I personally need some functions like im2col in matlab and I would be rather happy to implement in scikits-image. @St?fan MATLAB compatibility table can provide us an example for how to organize the functions for an image-processing toolbox and get more users to transfer from matlab to use skimage. I just want to make myself clear of what the project lacks currently and what priority is that. IMHO, I think if the pages on the tasks in the contribution page can describe each tasks in more details then it would be more friendly to new contributors? Another thing is maybe adding one chapter to describe the core API is quite useful, like the image classes and other developer utilities is useful? Best, Wei On Tue, Oct 2, 2012 at 10:40 AM, Tony Yu wrote: > > > On Mon, Oct 1, 2012 at 8:45 PM, St?fan van der Walt wrote: > >> Hi everyone, >> >> On Mon, Oct 1, 2012 at 4:15 PM, Josh Warner >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Tue Oct 2 18:34:44 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 2 Oct 2012 15:34:44 -0700 Subject: scikits-image or scikit-image? In-Reply-To: <506B558A.9050500@ais.uni-bonn.de> References: <50695D17.5090203@ais.uni-bonn.de> <506B558A.9050500@ais.uni-bonn.de> Message-ID: On Tue, Oct 2, 2012 at 1:58 PM, Andreas Mueller wrote: >> 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. > > Not sure if that is expected but everything is down for me atm. > Just FYI. I've reconfigured the DNS servers, but they are not cooperating. I hope to have this resolved within the next few hours. St?fan From stefan at sun.ac.za Tue Oct 2 19:33:43 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 2 Oct 2012 16:33:43 -0700 Subject: scikits-image or scikit-image? In-Reply-To: References: <50695D17.5090203@ais.uni-bonn.de> <506B558A.9050500@ais.uni-bonn.de> Message-ID: On Tue, Oct 2, 2012 at 3:34 PM, St?fan van der Walt wrote: > On Tue, Oct 2, 2012 at 1:58 PM, Andreas Mueller > wrote: >>> 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. >> >> Not sure if that is expected but everything is down for me atm. >> Just FYI. > > I've reconfigured the DNS servers, but they are not cooperating. I > hope to have this resolved within the next few hours. I've been battling it out with ZoneEdit to no avail, so I've now re-created our DNS setup at NameCheap. Hopefully, changes should kick in within the next hour or so *hold thumbs* These changes will not affect scikit-learn.org. St?fan From stefan at sun.ac.za Tue Oct 2 20:24:35 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 2 Oct 2012 17:24:35 -0700 Subject: scikits-image or scikit-image? In-Reply-To: References: <50695D17.5090203@ais.uni-bonn.de> <506B558A.9050500@ais.uni-bonn.de> Message-ID: On Tue, Oct 2, 2012 at 4:33 PM, St?fan van der Walt wrote: >> I've reconfigured the DNS servers, but they are not cooperating. I >> hope to have this resolved within the next few hours. > > I've been battling it out with ZoneEdit to no avail, so I've now > re-created our DNS setup at NameCheap. Hopefully, changes should kick > in within the next hour or so *hold thumbs* Victory! All our sites look up correctly. You may still not be able to connect because of caching in your local nameserver, but if you use 8.8.8.8 (remember this one -- super handy whenever you need a server IP -- google-public-dns-a.google.com), everything should work smoothly. skimage.org. 1800 IN A 207.97.227.245 scikits-image.org. 1730 IN A 199.59.166.74 <- web redirect scikit-image.org. 1708 IN A 199.59.166.74 <- web redirect St?fan From tsyu80 at gmail.com Tue Oct 2 18:06:53 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Tue, 2 Oct 2012 18:06:53 -0400 Subject: scikits-image or scikit-image? In-Reply-To: <506B558A.9050500@ais.uni-bonn.de> References: <50695D17.5090203@ais.uni-bonn.de> <506B558A.9050500@ais.uni-bonn.de> Message-ID: On Tue, Oct 2, 2012 at 4:58 PM, Andreas Mueller wrote: > > 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. >> > Not sure if that is expected but everything is down for me atm. > Just FYI. Same here. 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. >> > +1 from my side. > I'm a +1 as well. It won't be as painful as last time since we won't be changing the namespace this time around. BTW, the extra "s" in the scikit-learn logo has always bugged me ;) -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannesschoenberger at gmail.com Tue Oct 2 13:10:32 2012 From: hannesschoenberger at gmail.com (=?iso-8859-1?Q?Sch=F6nberger_Johannes?=) Date: Tue, 2 Oct 2012 19:10:32 +0200 Subject: Docs In-Reply-To: References: <6BCD3541-35EA-4557-A49F-3EFCF6F46C11@gmail.com> <25B08EA4-A0BD-46EB-BE6A-97692C4BAEE1@gmail.com> Message-ID: <5B680338-098F-49DF-A316-A6E06D1146D8@gmail.com> I opened a PR for this: https://github.com/scikits-image/scikits-image/pull/335 Johannes Sch?nberger Am 02.10.2012 um 09:06 schrieb St?fan van der Walt : > On Mon, Oct 1, 2012 at 11:21 PM, Sch?nberger Johannes > wrote: >>> Also, the CSS design team should be credited somewhere. >> >> You mean the bootstrap team? I think it is best to list them in the footer next to the "sphinx" credit. > > Sounds good. > >> I really like the "Ralway" font. >> >> See: https://www.dropbox.com/s/hful1w3vso3achp/skimage%20website.zip >> >> If everything's fine so far, I'll create it a sphinx template for this. > > Perfect! > > St?fan From tsyu80 at gmail.com Tue Oct 2 20:07:54 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Tue, 2 Oct 2012 20:07:54 -0400 Subject: scikits-image or scikit-image? In-Reply-To: References: <50695D17.5090203@ais.uni-bonn.de> <506B558A.9050500@ais.uni-bonn.de> Message-ID: On Tue, Oct 2, 2012 at 7:33 PM, St?fan van der Walt wrote: > On Tue, Oct 2, 2012 at 3:34 PM, St?fan van der Walt > wrote: > > On Tue, Oct 2, 2012 at 1:58 PM, Andreas Mueller > > wrote: > >>> 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. > >> > >> Not sure if that is expected but everything is down for me atm. > >> Just FYI. > > > > I've reconfigured the DNS servers, but they are not cooperating. I > > hope to have this resolved within the next few hours. > > I've been battling it out with ZoneEdit to no avail, so I've now > re-created our DNS setup at NameCheap. Hopefully, changes should kick > in within the next hour or so *hold thumbs* > > These changes will not affect scikit-learn.org. > > St?fan > Everything seems to be working now. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From amueller at ais.uni-bonn.de Tue Oct 2 16:58:50 2012 From: amueller at ais.uni-bonn.de (Andreas Mueller) Date: Tue, 02 Oct 2012 21:58:50 +0100 Subject: scikits-image or scikit-image? In-Reply-To: References: <50695D17.5090203@ais.uni-bonn.de> Message-ID: <506B558A.9050500@ais.uni-bonn.de> > 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. Not sure if that is expected but everything is down for me atm. Just FYI. > 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. +1 from my side. From amueller at ais.uni-bonn.de Wed Oct 3 06:50:04 2012 From: amueller at ais.uni-bonn.de (Andreas Mueller) Date: Wed, 03 Oct 2012 11:50:04 +0100 Subject: scikits-image or scikit-image? In-Reply-To: References: <50695D17.5090203@ais.uni-bonn.de> <506B558A.9050500@ais.uni-bonn.de> Message-ID: <506C185C.4030408@ais.uni-bonn.de> > BTW, the extra "s" in the scikit-learn logo has always bugged me ;) > I fixed the logo last week or something :) From mathieu at mblondel.org Wed Oct 3 01:57:25 2012 From: mathieu at mblondel.org (Mathieu Blondel) Date: Wed, 3 Oct 2012 14:57:25 +0900 Subject: scikits-image or scikit-image? In-Reply-To: References: <50695D17.5090203@ais.uni-bonn.de> <506B558A.9050500@ais.uni-bonn.de> Message-ID: On Wed, Oct 3, 2012 at 7:06 AM, Tony Yu wrote: > > BTW, the extra "s" in the scikit-learn logo has always bugged me ;) > This has been fixed recently: http://scikit-learn.org/dev/ We just need to wait for a release so it appears in: http://scikit-learn.org/stable/ Cheers, Mathieu -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu at mblondel.org Wed Oct 3 02:05:49 2012 From: mathieu at mblondel.org (Mathieu Blondel) Date: Wed, 3 Oct 2012 15:05:49 +0900 Subject: scikits-image or scikit-image? In-Reply-To: References: <50695D17.5090203@ais.uni-bonn.de> Message-ID: On Tue, Oct 2, 2012 at 12:19 PM, St?fan van der Walt wrote: > And do we rename the repos again as well, or just the branding? That > was a major pain last time. > Not that my opinion counts but I think it's better to do it properly, hopefully this will be the last time. Also, github organizations and repos can be renamed so the "watchers" will not be lost. Regarding domain names, once the rebranding is done, it would be nice to use scikit-image.org as main domain and other domains as redirect. To celebrate this renaming, I was thinking scikit-learn and scikit-image could link to each other, a bit like "sister projects". Thanks for the positive feedback. I'm very happy that the two projects will now have consistent names! Cheers, Mathieu -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsyu80 at gmail.com Wed Oct 3 22:40:39 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Wed, 3 Oct 2012 22:40:39 -0400 Subject: Github repo renamed to scikit-image Message-ID: I noticed that the github repo was renamed, as discussed in a previous thread . For those who didn't follow that thread, the second "s" in "scikits" was removed. Right now if you go to https://github.com/scikits-image/scikits-image, you get a 404 error. Unfortunately, it doesn't seem like it's possible to have that repo redirect to the newly renamed repo. In case you're not familiar with how to rename repos, here's a short guide. (This may not be the best way, but it worked for me.) Rename main repo ================ To change your link to the main github repo (which I've named "upstream" below): git remote rm upstream git remote add upstream https://github.com/scikit-image/scikit-image.git *or* (SSH read/write): git remote add upstream git at github.com:scikit-image/scikit-image.git *or* (read-only): git remote add upstream git://github.com/scikit-image/scikit-image.git Rename personal repo ==================== On your personal github repo, go to the Admin tab near the top right and rename your repo from "scikits-image" to "scikit-image". To rename your personal, local repo (which I've named "origin" below): git remote rm origin git remote add origin git at github.com: your_github_username/scikit-image.git where you replace "your_github_username" with ... umm ... your github username :) Alternative link renaming ========================= Instead of `git remote rm/add` in both sections above, you can open your `.git/config` and change all "scikits-image: references to "scikit-image". -------------- next part -------------- An HTML attachment was scrubbed... URL: From kuantkid at gmail.com Thu Oct 4 03:35:39 2012 From: kuantkid at gmail.com (Wei LI @kuantkid) Date: Thu, 4 Oct 2012 00:35:39 -0700 (PDT) Subject: scikits-image or scikit-image? In-Reply-To: <506C185C.4030408@ais.uni-bonn.de> References: <50695D17.5090203@ais.uni-bonn.de> <506B558A.9050500@ais.uni-bonn.de> <506C185C.4030408@ais.uni-bonn.de> Message-ID: <18627c81-08d5-400e-a3e1-862cdf41914d@googlegroups.com> I took a quick grep on the index page for scikits, seems several links should be changed :) i.e. community of volunteers . is not scikits-image on ohloh, but scikit-image For curiosity, where index file is located in the source tree (or it is maintained separately)? On Wednesday, October 3, 2012 6:50:09 PM UTC+8, amue... at ais.uni-bonn.de wrote: > > > > BTW, the extra "s" in the scikit-learn logo has always bugged me ;) > > > I fixed the logo last week or something :) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Thu Oct 4 03:56:41 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 4 Oct 2012 00:56:41 -0700 Subject: Github repo renamed to scikit-image In-Reply-To: References: Message-ID: On Wed, Oct 3, 2012 at 7:40 PM, Tony Yu wrote: > I noticed that the github repo was renamed, as discussed in a previous > thread. For those who didn't follow that thread, the second "s" in "scikits" > was removed. Thanks for the update, Tony. Perhaps doing all this renaming while travelling wasn't the best of ideas, but it should now all be done. 1. Domains are registered and correctly configured (scikit-image.org/xyz -> skimage.org/xyz) 2. Web page is updated 3. Ohloh profile is renamed 4. Binary download paths updated, also Christoph's Windows binaries I have not yet updated the Debian package description. Should we do a 0.7.1 release before we push out the latest package? > Right now if you go to > https://github.com/scikits-image/scikits-image, you get a 404 error. > Unfortunately, it doesn't seem like it's possible to have that repo redirect > to the newly renamed repo. The only way to fix that is to create a new organization, I'm afraid. > Rename main repo > ================ > > To change your link to the main github repo (which I've named "upstream" > below): > > git remote rm upstream > git remote add upstream https://github.com/scikit-image/scikit-image.git > > *or* (SSH read/write): > > git remote add upstream git at github.com:scikit-image/scikit-image.git I always use this one (even for read-only repos), which works as long as you have your SSH keys set up with GitHub. St?fan From hannesschoenberger at gmail.com Thu Oct 4 03:37:28 2012 From: hannesschoenberger at gmail.com (=?iso-8859-1?Q?Sch=F6nberger_Johannes?=) Date: Thu, 4 Oct 2012 09:37:28 +0200 Subject: scikits-image or scikit-image? In-Reply-To: <18627c81-08d5-400e-a3e1-862cdf41914d@googlegroups.com> References: <50695D17.5090203@ais.uni-bonn.de> <506B558A.9050500@ais.uni-bonn.de> <506C185C.4030408@ais.uni-bonn.de> <18627c81-08d5-400e-a3e1-862cdf41914d@googlegroups.com> Message-ID: <7C71866F-D87E-4240-9ED4-5DFCD5F95249@gmail.com> This will be fixed shortly, if PR https://github.com/scikit-image/scikit-image-web/pull/6 gets merged. Johannes Sch?nberger Am 04.10.2012 um 09:35 schrieb "Wei LI @kuantkid" : > I took a quick grep on the index page for scikits, seems several links should be changed :) i.e. > community of volunteers. > is not scikits-image on ohloh, but scikit-image > > For curiosity, where index file is located in the source tree (or it is maintained separately)? > > On Wednesday, October 3, 2012 6:50:09 PM UTC+8, amue... at ais.uni-bonn.de wrote: > > > BTW, the extra "s" in the scikit-learn logo has always bugged me ;) > > > I fixed the logo last week or something :) > > -- > > From stefan at sun.ac.za Thu Oct 4 13:01:02 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 4 Oct 2012 10:01:02 -0700 Subject: Domain name: skimage.org vs scikit-image.org Message-ID: Hi, everyone The conversation on GitHub with Mathieu refers. I quite like "skimage.org" as a domain name because of its brevity, but I would like to hear the opinion of the rest of the team. If you prefer "scikit-image.org" because it is more descriptive, I'll change the setup accordingly. St?fan ---------- Forwarded message ---------- From: Mathieu Blondel Date: Thu, Oct 4, 2012 at 1:31 AM Subject: Re: [scikit-image] Change domain name (#342) To: scikit-image/scikit-image Cc: Stefan van der Walt In doc/source/themes/scikit-image/layout.html: > @@ -79,7 +79,7 @@ > {%- block extrahead %}{% endblock %} > > > - > + So are you planning to use skimage.org as the main domain name? I suspect that most people will start calling the project skimage if you do so... ? Reply to this email directly or view it on GitHub. -------------- next part -------------- An HTML attachment was scrubbed... URL: From deil.christoph at googlemail.com Thu Oct 4 04:10:54 2012 From: deil.christoph at googlemail.com (Christoph Deil) Date: Thu, 4 Oct 2012 10:10:54 +0200 Subject: Github repo renamed to scikit-image In-Reply-To: References: Message-ID: <2CF8003E-DDEC-49B8-99B8-9CD4C318D808@gmail.com> On Oct 4, 2012, at 9:56 AM, St?fan van der Walt wrote: > I have not yet updated the Debian package description. Should we do a > 0.7.1 release before we push out the latest package? Did you mean you wanted to update the packet name? In that case please note that for macports, a popular Mac package installer, the package names still contain the extra "s" and I guess should be made consistent at some point: $ port search py27-scikit py27-scikits-image @0.7.0 (python, science) Image processing algorithms for SciPy. py27-scikits-learn @0.12 (python, science) Easy-to-use and general-purpose machine learning in Python py27-scikits-module @0.1 (python) provides the files common to all scikits py27-scikits-statsmodels @0.4.3 (python, science) Statistical computations and models for use with SciPy py27-scikits-umfpack @1.0 (python, science) Classes and functions for solving unsymmetric sparse linear systems Found 5 ports. Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannesschoenberger at gmail.com Thu Oct 4 04:22:38 2012 From: hannesschoenberger at gmail.com (=?iso-8859-1?Q?Sch=F6nberger_Johannes?=) Date: Thu, 4 Oct 2012 10:22:38 +0200 Subject: Github repo renamed to scikit-image In-Reply-To: References: Message-ID: <77F4CCE1-14CD-4828-ACCA-EA7DAA15BDE4@gmail.com> We also need to rename the PyPI package name. Johannes Sch?nberger Am 04.10.2012 um 09:56 schrieb St?fan van der Walt : > On Wed, Oct 3, 2012 at 7:40 PM, Tony Yu wrote: >> I noticed that the github repo was renamed, as discussed in a previous >> thread. For those who didn't follow that thread, the second "s" in "scikits" >> was removed. > > Thanks for the update, Tony. Perhaps doing all this renaming while > travelling wasn't the best of ideas, but it should now all be done. > > 1. Domains are registered and correctly configured > (scikit-image.org/xyz -> skimage.org/xyz) > 2. Web page is updated > 3. Ohloh profile is renamed > 4. Binary download paths updated, also Christoph's Windows binaries > > I have not yet updated the Debian package description. Should we do a > 0.7.1 release before we push out the latest package? > >> Right now if you go to >> https://github.com/scikits-image/scikits-image, you get a 404 error. >> Unfortunately, it doesn't seem like it's possible to have that repo redirect >> to the newly renamed repo. > > The only way to fix that is to create a new organization, I'm afraid. > >> Rename main repo >> ================ >> >> To change your link to the main github repo (which I've named "upstream" >> below): >> >> git remote rm upstream >> git remote add upstream https://github.com/scikit-image/scikit-image.git >> >> *or* (SSH read/write): >> >> git remote add upstream git at github.com:scikit-image/scikit-image.git > > I always use this one (even for read-only repos), which works as long > as you have your SSH keys set up with GitHub. > > St?fan > > -- > > From stefan at sun.ac.za Thu Oct 4 13:23:53 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 4 Oct 2012 10:23:53 -0700 Subject: Domain name: skimage.org vs scikit-image.org In-Reply-To: References: Message-ID: On Thu, Oct 4, 2012 at 10:07 AM, James Bergstra wrote: > > +1 on skimage for repo (maybe github organization, maybe not) and python import name. > > Ditto for scikit-learn (sklearn repo and import). Wasn't the purpose of this renaming to team up with scikit-learn? Teaming up, in the sense of having a more unified brand, yes. At the moment we have: http://skimage.org -> website https://github.com/scikit-image -> org https://github.com/scikit-image/scikit-image -> repo I am OK with the repo having a slightly longer name, since I almost never have to type that in :) St?fan From thouis at gmail.com Thu Oct 4 13:02:28 2012 From: thouis at gmail.com (Thouis (Ray) Jones) Date: Thu, 4 Oct 2012 13:02:28 -0400 Subject: Domain name: skimage.org vs scikit-image.org In-Reply-To: References: Message-ID: +1 on skimage On Thu, Oct 4, 2012 at 1:01 PM, St?fan van der Walt wrote: > Hi, everyone > > The conversation on GitHub with Mathieu refers. I quite like "skimage.org" > as a domain name because of its brevity, but I would like to hear the > opinion of the rest of the team. If you prefer "scikit-image.org" > because it is more descriptive, I'll change the setup accordingly. > > St?fan > > ---------- Forwarded message ---------- > From: Mathieu Blondel > Date: Thu, Oct 4, 2012 at 1:31 AM > Subject: Re: [scikit-image] Change domain name (#342) > To: scikit-image/scikit-image > Cc: Stefan van der Walt > > > In doc/source/themes/scikit-image/layout.html: > > > @@ -79,7 +79,7 @@ > > {%- block extrahead %}{% endblock %} > > > > > > - > > + > > So are you planning to use skimage.org as the main domain name? I suspect > that most people will start calling the project skimage if you do so... > > ? > Reply to this email directly or view it on GitHub. > > > -- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.bergstra at gmail.com Thu Oct 4 13:07:00 2012 From: james.bergstra at gmail.com (James Bergstra) Date: Thu, 4 Oct 2012 13:07:00 -0400 Subject: Domain name: skimage.org vs scikit-image.org In-Reply-To: References: Message-ID: +1 on skimage for repo (maybe github organization, maybe not) and python import name. Ditto for scikit-learn (sklearn repo and import). Wasn't the purpose of this renaming to team up with scikit-learn? On Thu, Oct 4, 2012 at 1:02 PM, Thouis (Ray) Jones wrote: > +1 on skimage > > > On Thu, Oct 4, 2012 at 1:01 PM, St?fan van der Walt wrote: > >> Hi, everyone >> >> The conversation on GitHub with Mathieu refers. I quite like " >> skimage.org" as a domain name because of its brevity, but I would like >> to hear the opinion of the rest of the team. If you prefer " >> scikit-image.org" because it is more descriptive, I'll change the setup >> accordingly. >> >> St?fan >> >> ---------- Forwarded message ---------- >> From: Mathieu Blondel >> Date: Thu, Oct 4, 2012 at 1:31 AM >> Subject: Re: [scikit-image] Change domain name (#342) >> To: scikit-image/scikit-image >> Cc: Stefan van der Walt >> >> >> In doc/source/themes/scikit-image/layout.html: >> >> > @@ -79,7 +79,7 @@ >> > {%- block extrahead %}{% endblock %} >> > >> > >> > - >> > + >> >> So are you planning to use skimage.org as the main domain name? I >> suspect that most people will start calling the project skimage if you >> do so... >> >> ? >> Reply to this email directly or view it on GitHub. >> >> >> -- >> >> >> > > -- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Thu Oct 4 17:11:00 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 4 Oct 2012 14:11:00 -0700 Subject: Domain name: skimage.org vs scikit-image.org In-Reply-To: References: Message-ID: On Thu, Oct 4, 2012 at 10:38 AM, Brian Holt wrote: > I would actually rather go with scikit-image.org as the domain name > reflecting the name of the project. It's what I would expect most users > would search for as well. The domain is there and redirects to skimage.org as is. St?fan From bdholt1 at gmail.com Thu Oct 4 13:38:13 2012 From: bdholt1 at gmail.com (Brian Holt) Date: Thu, 4 Oct 2012 18:38:13 +0100 Subject: Domain name: skimage.org vs scikit-image.org In-Reply-To: References: Message-ID: I would actually rather go with scikit-image.org as the domain name reflecting the name of the project. It's what I would expect most users would search for as well. Brian On Oct 4, 2012 6:24 PM, "St?fan van der Walt" wrote: > On Thu, Oct 4, 2012 at 10:07 AM, James Bergstra > wrote: > > > > +1 on skimage for repo (maybe github organization, maybe not) and python > import name. > > > > Ditto for scikit-learn (sklearn repo and import). Wasn't the purpose of > this renaming to team up with scikit-learn? > > Teaming up, in the sense of having a more unified brand, yes. > > At the moment we have: > > http://skimage.org -> website > https://github.com/scikit-image -> org > https://github.com/scikit-image/scikit-image -> repo > > I am OK with the repo having a slightly longer name, since I almost > never have to type that in :) > > St?fan > > -- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannesschoenberger at gmail.com Thu Oct 4 14:23:28 2012 From: hannesschoenberger at gmail.com (=?UTF-8?Q?Johannes_Sch=C3=B6nberger?=) Date: Thu, 4 Oct 2012 20:23:28 +0200 Subject: Domain name: skimage.org vs scikit-image.org In-Reply-To: References: Message-ID: <1711702775356773566@unknownmsgid> +1 for scikit-image.org Johannes Sch?nberger Am 04.10.2012 um 19:38 schrieb Brian Holt : I would actually rather go with scikit-image.org as the domain name reflecting the name of the project. It's what I would expect most users would search for as well. Brian On Oct 4, 2012 6:24 PM, "St?fan van der Walt" wrote: > On Thu, Oct 4, 2012 at 10:07 AM, James Bergstra > wrote: > > > > +1 on skimage for repo (maybe github organization, maybe not) and python > import name. > > > > Ditto for scikit-learn (sklearn repo and import). Wasn't the purpose of > this renaming to team up with scikit-learn? > > Teaming up, in the sense of having a more unified brand, yes. > > At the moment we have: > > http://skimage.org -> website > https://github.com/scikit-image -> org > https://github.com/scikit-image/scikit-image -> repo > > I am OK with the repo having a slightly longer name, since I almost > never have to type that in :) > > St?fan > > -- > > > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Fri Oct 5 01:27:16 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 4 Oct 2012 22:27:16 -0700 Subject: Domain name: skimage.org vs scikit-image.org In-Reply-To: References: Message-ID: On Thu, Oct 4, 2012 at 8:13 PM, Tony Yu wrote: > But for branding, I'm inclined to use the longer "scikit-image" whenever > possible, so I'd be in favor of having skimage.org redirect to > scikit-image.org. It's not that big of a deal, but that's my take. It has been done... Now, on to graph cuts, blind deconvolution, in-painting, seam-carving, temporal highlighting, FFT-painting, panorama stitching, HDR mapping, binary features, and saving the world! St?fan From tsyu80 at gmail.com Thu Oct 4 23:13:07 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Thu, 4 Oct 2012 23:13:07 -0400 Subject: Domain name: skimage.org vs scikit-image.org In-Reply-To: References: Message-ID: On Thu, Oct 4, 2012 at 5:11 PM, St?fan van der Walt wrote: > On Thu, Oct 4, 2012 at 10:38 AM, Brian Holt wrote: > > I would actually rather go with scikit-image.org as the domain name > > reflecting the name of the project. It's what I would expect most users > > would search for as well. > > The domain is there and redirects to skimage.org as is. > > St?fan > I kind of see "skimage" as a practical name to use in code---both for shorter imports and to avoid the issue with namespace packages. But for branding, I'm inclined to use the longer "scikit-image" whenever possible, so I'd be in favor of having skimage.org redirect to scikit-image.org. It's not that big of a deal, but that's my take. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Fri Oct 5 03:01:27 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 5 Oct 2012 00:01:27 -0700 Subject: Domain name: skimage.org vs scikit-image.org In-Reply-To: References: Message-ID: On Thu, Oct 4, 2012 at 11:43 PM, Mathieu Blondel wrote: > I would be interested in tackling seam-carving at some point. I have code > that I could reuse (perhaps, the dynamic programming part could be rewritten > in Cython): > http://www.mblondel.org/journal/2010/02/09/seam-carving-in-python/ Neat! Long ago I tried using the minimum cost paths inside skimage: https://github.com/stefanv/scikit-image/blob/seam_carving/doc/examples/plot_seam_carving.py Unfortunately, this is also way too slow; we'll need to do some Cython to track the removed paths somehow. St?fan From mathieu at mblondel.org Fri Oct 5 02:43:41 2012 From: mathieu at mblondel.org (Mathieu Blondel) Date: Fri, 5 Oct 2012 15:43:41 +0900 Subject: Domain name: skimage.org vs scikit-image.org In-Reply-To: References: Message-ID: I would be interested in tackling seam-carving at some point. I have code that I could reuse (perhaps, the dynamic programming part could be rewritten in Cython): http://www.mblondel.org/journal/2010/02/09/seam-carving-in-python/ Mathieu -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannesschoenberger at gmail.com Mon Oct 8 13:11:51 2012 From: hannesschoenberger at gmail.com (=?UTF-8?Q?Johannes_Sch=C3=B6nberger?=) Date: Mon, 8 Oct 2012 10:11:51 -0700 (PDT) Subject: Cython fused types Message-ID: <3daf638d-9de1-4847-ac42-9682ffed7396@googlegroups.com> Hi, I'm not sure if everyone has already noticed, that there is support for "fused types" in the recently released Cython 0.17 (http://docs.cython.org/src/userguide/fusedtypes.html). This may be extremely useful to support different dtypes without doing a explicit conversion of arrays. It's probably too early to use this feature as it is still marked as "experimental"... but we should consider to use this feature in future. Regards, Johannes -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Mon Oct 8 14:47:23 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 8 Oct 2012 11:47:23 -0700 Subject: Cython fused types In-Reply-To: References: <3daf638d-9de1-4847-ac42-9682ffed7396@googlegroups.com> Message-ID: On Mon, Oct 8, 2012 at 10:38 AM, Mathieu Blondel wrote: > Fused types were actually introduced in v0.16 > (http://wiki.cython.org/ReleaseNotes-0.16) so v0.17 is the second release > supporting them. The problem I see with fused types is that they generate very large binaries. As far as I know, this is also why they are not being used in SciPy currently. St?fan From tsyu80 at gmail.com Mon Oct 8 14:17:49 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Mon, 8 Oct 2012 14:17:49 -0400 Subject: Cython fused types In-Reply-To: References: <3daf638d-9de1-4847-ac42-9682ffed7396@googlegroups.com> Message-ID: On Mon, Oct 8, 2012 at 1:38 PM, Mathieu Blondel wrote: > > > On Tue, Oct 9, 2012 at 2:11 AM, Johannes Sch?nberger < > hannesschoenberger at gmail.com> wrote: > >> I'm not sure if everyone has already noticed, that there is support for >> "fused types" in the recently released Cython 0.17 ( >> http://docs.cython.org/src/userguide/fusedtypes.html). >> > > Fused types were actually introduced in v0.16 ( > http://wiki.cython.org/ReleaseNotes-0.16) so v0.17 is the second release > supporting them. > > Mathieu > > -- > I actually tried to bump up the Cython requirement to 0.16 (see https://groups.google.com/forum/?fromgroups=#!topic/scikit-image/Fzdtoo8AUZ0) about a month ago, but that turned out to be **way** too soon. For example, the current Ubuntu, 12.04, ships with Cython 0.15. I guess Ubuntu 12.10 will be released soon, and that release includes Cython 0.16. That said, I'm not sure if targeting the most recent Ubuntu is what we want to do (since it will be too fast for some people). Andreas or Mathieu: Does scikit-learn have a policy for upgrading dependencies (in particular Cython)? I'd lean toward more conservative versions of numpy, but more recent versions of Cython. I'm not sure how that would actually translate into hard numbers. Maybe numpy matches latest Ubuntu LTS, cython matches latest Ubuntu? (I don't run Ubuntu, btw, I just find it a convenient reference.) Or maybe some predetermined time delay after those releases? Best, -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Mon Oct 8 20:04:56 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 8 Oct 2012 17:04:56 -0700 Subject: v0.8 release In-Reply-To: References: Message-ID: Hello, everyone With all the renaming of the past week, it would be good if we could make a new release. Are there any outstanding PRs we should consider including? I may also push 0.7.1 as a bug-fix release for building on OSX. St?fan From tsyu80 at gmail.com Mon Oct 8 22:20:28 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Mon, 8 Oct 2012 22:20:28 -0400 Subject: v0.8 release In-Reply-To: References: Message-ID: On Mon, Oct 8, 2012 at 8:04 PM, St?fan van der Walt wrote: > Hello, everyone > > With all the renaming of the past week, it would be good if we could > make a new release. Are there any outstanding PRs we should consider > including? > > I may also push 0.7.1 as a bug-fix release for building on OSX. > > St?fan > > -- > Yeah, the renaming definitely wreaked havoc on the 0.7.0 release. Let's try to avoid another rename ;) There are definitely a few good PRs waiting to be reviewed, but I'm inclined to wait until they've had some thorough vetting. (We could really use some help with review, if anyone out there has some free time---especially on some of the longer PRs.) That said, I'm inclined to merge PR #351and PR #360 . Are you planning to release both 0.7.1 *and* 0.8? Is there any reason why we shouldn't just point users to 0.8? -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Tue Oct 9 03:27:01 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 9 Oct 2012 00:27:01 -0700 Subject: v0.8 release In-Reply-To: References: Message-ID: On Mon, Oct 8, 2012 at 7:20 PM, Tony Yu wrote: > That said, I'm inclined to merge PR #351 and PR #360. PR #351 looks good to me. > Are you planning to release both 0.7.1 *and* 0.8? Is there any reason why we > shouldn't just point users to 0.8? Some people will still try to install "scikits-image", which currently gives 0.7--broken on OSX. As such, it would be nice to at least have a working 0.7. St?fan From mathieu at mblondel.org Mon Oct 8 13:38:17 2012 From: mathieu at mblondel.org (Mathieu Blondel) Date: Tue, 9 Oct 2012 02:38:17 +0900 Subject: Cython fused types In-Reply-To: <3daf638d-9de1-4847-ac42-9682ffed7396@googlegroups.com> References: <3daf638d-9de1-4847-ac42-9682ffed7396@googlegroups.com> Message-ID: On Tue, Oct 9, 2012 at 2:11 AM, Johannes Sch?nberger < hannesschoenberger at gmail.com> wrote: > I'm not sure if everyone has already noticed, that there is support for > "fused types" in the recently released Cython 0.17 ( > http://docs.cython.org/src/userguide/fusedtypes.html). > Fused types were actually introduced in v0.16 ( http://wiki.cython.org/ReleaseNotes-0.16) so v0.17 is the second release supporting them. Mathieu -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu at mblondel.org Mon Oct 8 15:27:19 2012 From: mathieu at mblondel.org (Mathieu Blondel) Date: Tue, 9 Oct 2012 04:27:19 +0900 Subject: Cython fused types In-Reply-To: References: <3daf638d-9de1-4847-ac42-9682ffed7396@googlegroups.com> Message-ID: On Tue, Oct 9, 2012 at 3:17 AM, Tony Yu wrote: > > I actually tried to bump up the Cython requirement to 0.16 (see > https://groups.google.com/forum/?fromgroups=#!topic/scikit-image/Fzdtoo8AUZ0) > about a month ago, but that turned out to be **way** too soon. > > For example, the current Ubuntu, 12.04, ships with Cython 0.15. I guess > Ubuntu 12.10 will be released soon, and that release includes Cython 0.16. > That said, I'm not sure if targeting the most recent Ubuntu is what we want > to do (since it will be too fast for some people). > > Andreas or Mathieu: Does scikit-learn have a policy for upgrading > dependencies (in particular Cython)? > In scikit-learn, we've decided to use Cython 0.17 but we include generated .c files in the git repository so the dependency is only for developers who want to regenerate a particular .c file from the corresponding .pyx file... A downside is that this generates large and hard to read diffs but we recently merged a .gitattributes file that should alleviate this problem: https://github.com/scikit-learn/scikit-learn/blob/master/.gitattributes Mathieu -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannesschoenberger at gmail.com Fri Oct 12 13:35:59 2012 From: hannesschoenberger at gmail.com (=?UTF-8?Q?Johannes_Sch=C3=B6nberger?=) Date: Fri, 12 Oct 2012 10:35:59 -0700 (PDT) Subject: v0.8 release In-Reply-To: References: Message-ID: I would release a 0.7.1 to address the renaming and use 0.8 for new features. So, make a feature freeze at the moment - until 0.7.1 is released. Am Dienstag, 9. Oktober 2012 09:27:22 UTC+2 schrieb Stefan van der Walt: > > On Mon, Oct 8, 2012 at 7:20 PM, Tony Yu > > wrote: > > That said, I'm inclined to merge PR #351 and PR #360. > > PR #351 looks good to me. > > > Are you planning to release both 0.7.1 *and* 0.8? Is there any reason > why we > > shouldn't just point users to 0.8? > > Some people will still try to install "scikits-image", which currently > gives 0.7--broken on OSX. As such, it would be nice to at least have > a working 0.7. > > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannesschoenberger at gmail.com Fri Oct 12 13:38:31 2012 From: hannesschoenberger at gmail.com (=?UTF-8?Q?Johannes_Sch=C3=B6nberger?=) Date: Fri, 12 Oct 2012 10:38:31 -0700 (PDT) Subject: Cython fused types In-Reply-To: References: <3daf638d-9de1-4847-ac42-9682ffed7396@googlegroups.com> Message-ID: Are those binaries really that huge? I just tested this locally and the binaries were larger, but imho not too big. The question is who actually cares about a few extra KB disk space taken by a binary? Am Montag, 8. Oktober 2012 20:47:45 UTC+2 schrieb Stefan van der Walt: > > On Mon, Oct 8, 2012 at 10:38 AM, Mathieu Blondel > > wrote: > > Fused types were actually introduced in v0.16 > > (http://wiki.cython.org/ReleaseNotes-0.16) so v0.17 is the second > release > > supporting them. > > The problem I see with fused types is that they generate very large > binaries. As far as I know, this is also why they are not being used > in SciPy currently. > > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Fri Oct 12 18:05:32 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 12 Oct 2012 15:05:32 -0700 Subject: Cython fused types In-Reply-To: References: <3daf638d-9de1-4847-ac42-9682ffed7396@googlegroups.com> Message-ID: On Fri, Oct 12, 2012 at 10:38 AM, Johannes Sch?nberger wrote: > Are those binaries really that huge? I just tested this locally and the > binaries were larger, but imho not too big. The question is who actually > cares about a few extra KB disk space taken by a binary? In SciPy, we were looking at huge files, much longer compilation times, increased memory use, etc. Maybe you can compare these factors and see how it goes? I don't know if it can be avoided, on principle, since you basically have to generate separate functions for each type combination, which makes things explode combinatorially. St?fan From stefan at sun.ac.za Fri Oct 12 18:07:50 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 12 Oct 2012 15:07:50 -0700 Subject: v0.8 release In-Reply-To: References: Message-ID: On Fri, Oct 12, 2012 at 10:35 AM, Johannes Sch?nberger wrote: > I would release a 0.7.1 to address the renaming and use 0.8 for new > features. So, make a feature freeze at the moment - until 0.7.1 is released. I'll create a 0.7.x branch, port those changes, and make one more release of scikits-image. Then I'll change the package name and release 0.7.2 as scikit-image (without the s). That way we have a clear distinction between the two. The next feature release, in about a month or two, will then be 0.8.0. Thanks! St?fan From hannesschoenberger at gmail.com Sat Oct 13 02:26:39 2012 From: hannesschoenberger at gmail.com (=?UTF-8?Q?Johannes_Sch=C3=B6nberger?=) Date: Fri, 12 Oct 2012 23:26:39 -0700 (PDT) Subject: Scikits project homepage Message-ID: <0174064a-bdbe-47cc-a6f8-1e959487b026@googlegroups.com> I just came across http://scikits.appspot.com/scikits and currently scikit-image is not listed here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Sat Oct 13 14:59:54 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sat, 13 Oct 2012 11:59:54 -0700 Subject: Scikits project homepage In-Reply-To: <0174064a-bdbe-47cc-a6f8-1e959487b026@googlegroups.com> References: <0174064a-bdbe-47cc-a6f8-1e959487b026@googlegroups.com> Message-ID: On Fri, Oct 12, 2012 at 11:26 PM, Johannes Sch?nberger wrote: > I just came across http://scikits.appspot.com/scikits and currently > scikit-image is not listed here. This will fix itself automatically as soon as I tag v0.7.1 and v0.7.2. From stefan at sun.ac.za Tue Oct 16 01:37:34 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 15 Oct 2012 22:37:34 -0700 Subject: each_channel decorator In-Reply-To: References: Message-ID: On Mon, Oct 15, 2012 at 8:30 PM, Tony Yu wrote: > After my failed @grayscale decorator suggestion (sorry again Johannes for > all the unnecessary work this caused you), I was thinking it might be nice > to add an @each_channel decorator. The basic idea is that the decorator > would check if the input image is RGB, and applies the grayscale function to > each channel of an RGB image. Now, here we have a winner :) St?fan From tsyu80 at gmail.com Mon Oct 15 23:30:17 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Mon, 15 Oct 2012 23:30:17 -0400 Subject: each_channel decorator Message-ID: After my failed @grayscale decorator suggestion (sorry again Johannes for all the unnecessary work this caused you), I was thinking it might be nice to add an @each_channel decorator. The basic idea is that the decorator would check if the input image is RGB, and applies the grayscale function to each channel of an RGB image. Cheers, -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Tue Oct 16 14:42:14 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 16 Oct 2012 11:42:14 -0700 Subject: each_channel decorator In-Reply-To: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> References: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> Message-ID: On Tue, Oct 16, 2012 at 7:13 AM, Sch?nberger Johannes wrote: > Sorry, but I do not understand what this decorator does. Could you provide a short example? @each_channel def some_gray_level_filter(): return gray_image image = data.something() gray_image = color.rgb2gray(image) some_gray_level_filter(gray_image) some_gray_level_filter(image) <-- this works too From stefan at sun.ac.za Tue Oct 16 18:33:06 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 16 Oct 2012 15:33:06 -0700 Subject: each_channel decorator In-Reply-To: <7CECE99A-48BD-40F2-A13D-8F6A55392B6E@gmail.com> References: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> <7CECE99A-48BD-40F2-A13D-8F6A55392B6E@gmail.com> Message-ID: On Tue, Oct 16, 2012 at 1:54 PM, Sch?nberger Johannes wrote: > OK, so it is basically just a decorator which calls color.rgb2gray and passes the converted image to the function? No, it is a function that passes each layer through the filter, and then assembles the results back into a color image. From hannesschoenberger at gmail.com Tue Oct 16 10:13:31 2012 From: hannesschoenberger at gmail.com (=?iso-8859-1?Q?Sch=F6nberger_Johannes?=) Date: Tue, 16 Oct 2012 16:13:31 +0200 Subject: each_channel decorator In-Reply-To: References: Message-ID: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> No problem @Tony. Sorry, but I do not understand what this decorator does. Could you provide a short example? Johannes Sch?nberger Am 16.10.2012 um 05:30 schrieb Tony Yu : > After my failed @grayscale decorator suggestion (sorry again Johannes for all the unnecessary work this caused you), I was thinking it might be nice to add an @each_channel decorator. The basic idea is that the decorator would check if the input image is RGB, and applies the grayscale function to each channel of an RGB image. > > Cheers, > -Tony > > -- > > From steven.silvester at gmail.com Tue Oct 16 19:59:19 2012 From: steven.silvester at gmail.com (Steven Silvester) Date: Tue, 16 Oct 2012 16:59:19 -0700 (PDT) Subject: each_channel decorator In-Reply-To: References: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> <7CECE99A-48BD-40F2-A13D-8F6A55392B6E@gmail.com> Message-ID: I would suggest the following instead: Convert to LAB Perform transform on lightness channel Convert back to RGB Because, red, green, and blue are not really independent "channels" to the human eye. I used this method on the adapthist pull request when handling RGB images. From stefan at sun.ac.za Tue Oct 16 20:41:47 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 16 Oct 2012 17:41:47 -0700 Subject: each_channel decorator In-Reply-To: References: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> <7CECE99A-48BD-40F2-A13D-8F6A55392B6E@gmail.com> Message-ID: On Tue, Oct 16, 2012 at 4:59 PM, Steven Silvester wrote: > I would suggest the following instead: > Convert to LAB > Perform transform on lightness channel > Convert back to RGB That seems like a sound approach to me. Tony, Andreas? > Because, red, green, and blue are not really independent "channels" to the human eye. I used this method on the adapthist pull request when handling RGB images. By the way, thanks for that PR--now that 0.7.2 is out the door, I reviewed it. St?fan From tsyu80 at gmail.com Tue Oct 16 20:11:10 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Tue, 16 Oct 2012 20:11:10 -0400 Subject: each_channel decorator In-Reply-To: References: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> <7CECE99A-48BD-40F2-A13D-8F6A55392B6E@gmail.com> Message-ID: On Tue, Oct 16, 2012 at 7:59 PM, Steven Silvester < steven.silvester at gmail.com> wrote: > I would suggest the following instead: > Convert to LAB > Perform transform on lightness channel > Convert back to RGB > > Because, red, green, and blue are not really independent "channels" to the > human eye. I used this method on the adapthist pull request when handling > RGB images. > I was originally thinking the same as St?fan (i.e. operating on each RGB channel and re-assembling), but I like the idea of operating on the lightness channel. (Sorry your adapthist PR has sat unreviewed for so long) -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannesschoenberger at gmail.com Tue Oct 16 16:54:23 2012 From: hannesschoenberger at gmail.com (=?iso-8859-1?Q?Sch=F6nberger_Johannes?=) Date: Tue, 16 Oct 2012 22:54:23 +0200 Subject: each_channel decorator In-Reply-To: References: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> Message-ID: <7CECE99A-48BD-40F2-A13D-8F6A55392B6E@gmail.com> OK, so it is basically just a decorator which calls color.rgb2gray and passes the converted image to the function? Johannes Sch?nberger Am 16.10.2012 um 20:42 schrieb St?fan van der Walt : > On Tue, Oct 16, 2012 at 7:13 AM, Sch?nberger Johannes > wrote: >> Sorry, but I do not understand what this decorator does. Could you provide a short example? > > @each_channel > def some_gray_level_filter(): > return gray_image > > image = data.something() > gray_image = color.rgb2gray(image) > > some_gray_level_filter(gray_image) > some_gray_level_filter(image) <-- this works too > > -- > > From luis at luispedro.org Wed Oct 17 10:47:38 2012 From: luis at luispedro.org (Luis Pedro Coelho) Date: Wed, 17 Oct 2012 07:47:38 -0700 (PDT) Subject: Cython fused types In-Reply-To: References: <3daf638d-9de1-4847-ac42-9682ffed7396@googlegroups.com> Message-ID: <73510ab3-135c-4f4b-8056-a90b31ce6a25@googlegroups.com> Caveat: I no nothing about fused types in Cython. In mahotas, I use C++ templates to achieve a similar effect. I don't however, do all combinations. For example erode(image, structuring_element) will convert structuring_element to the type of image. This way only one instance for type is generated (also, structuring_element is guaranteed to be PyArray_CARRAY). structuring_element is often really small, so the time cost is negligable. Similarly, operations on labeled objects [for example, labeled_sum, which gives you the same of pixel values inside each region] require int32 labels, which is what ``label`` returns, but can have anything on the image side (again, only one per type, not an explosion). I think that the size of resulting binaries is quite reasonable as it is most often only an inner loop that gets replicated 6 times or so. My initial variants did generate all combinations and it rapidly became very large (a few MB for morphological functions, for example). My two euro-cent, Luis PS: support for multiple types without a performance cost was one of the original reasons why I rejected Cython in favour of C++ (the other was that, when I started mahotas, Cython was still Pyrex and still a major pain for users to install). On Friday, October 12, 2012 11:05:54 PM UTC+1, Stefan van der Walt wrote: > > On Fri, Oct 12, 2012 at 10:38 AM, Johannes Sch?nberger > > wrote: > > Are those binaries really that huge? I just tested this locally and the > > binaries were larger, but imho not too big. The question is who actually > > cares about a few extra KB disk space taken by a binary? > > In SciPy, we were looking at huge files, much longer compilation > times, increased memory use, etc. Maybe you can compare these factors > and see how it goes? I don't know if it can be avoided, on principle, > since you basically have to generate separate functions for each type > combination, which makes things explode combinatorially. > > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Wed Oct 17 16:37:03 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 17 Oct 2012 13:37:03 -0700 Subject: each_channel decorator In-Reply-To: References: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> <7CECE99A-48BD-40F2-A13D-8F6A55392B6E@gmail.com> Message-ID: On Wed, Oct 17, 2012 at 7:39 AM, Sch?nberger Johannes wrote: > Sounds good. Do you have a paper or any reliable source about this? Just interested in this... The question is, should we make this a decorator, or simply provide it as utility functions? I'm wondering, because now we already have two different ways of handling color images: split them up, RGB, or convert them to LAB and apply the filter to LAB. How do we expose both of these sensible alternatives to the user? We can have a *default*, so that all single-channel filters are done on the luminance layer, but then combine that with utility functions. E.g. @luminance_filter def gray_filter(image, ...): ... gray_filter(color_image, params) --> convert to LAB, filter on L, convert back filter_layers(color_image, gray_filter, params) -> filter each layer separately and combine Alternatively, skip the decorators completely, and just provide two utility functions: filter_layers and filter_luminance. Let's hear what the API artists have to say :) Cheers St?fan From stefan at sun.ac.za Wed Oct 17 16:44:11 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 17 Oct 2012 13:44:11 -0700 Subject: Cython fused types In-Reply-To: <73510ab3-135c-4f4b-8056-a90b31ce6a25@googlegroups.com> References: <3daf638d-9de1-4847-ac42-9682ffed7396@googlegroups.com> <73510ab3-135c-4f4b-8056-a90b31ce6a25@googlegroups.com> Message-ID: Hi Luis On Wed, Oct 17, 2012 at 7:47 AM, Luis Pedro Coelho wrote: > I don't however, do all combinations. For example > > erode(image, structuring_element) > > will convert structuring_element to the type of image. This way only one > instance for type is generated (also, structuring_element is guaranteed to > be PyArray_CARRAY). structuring_element is often really small, so the time > cost is negligable. I think that is some very sensible and pragmatic advice; thank you! > My initial variants did generate all combinations and it rapidly became very > large (a few MB for morphological functions, for example). OK, so we definitely have to be careful. > PS: support for multiple types without a performance cost was one of the > original reasons why I rejected Cython in favour of C++ (the other was that, > when I started mahotas, Cython was still Pyrex and still a major pain for > users to install). That was probably a good choice; we made a design decision to almost always operate on floating point images internally, but that comes with its own pros and cons (e.g., memory use with very large images). On the other hand, it also means that a lot of the overhead previous devoted to thinking about ranges can now be dropped (I find it a lot simpler to code up an algorithm, knowing I'm dealing with values in [0, 1]). Cheers St?fan From hannesschoenberger at gmail.com Wed Oct 17 10:39:26 2012 From: hannesschoenberger at gmail.com (=?iso-8859-1?Q?Sch=F6nberger_Johannes?=) Date: Wed, 17 Oct 2012 16:39:26 +0200 Subject: each_channel decorator In-Reply-To: References: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> <7CECE99A-48BD-40F2-A13D-8F6A55392B6E@gmail.com> Message-ID: Now I understand. Thank you! > I would suggest the following instead: > Convert to LAB > Perform transform on lightness channel > Convert back to RGB Sounds good. Do you have a paper or any reliable source about this? Just interested in this... Johannes Sch?nberger Am 17.10.2012 um 02:41 schrieb St?fan van der Walt : > On Tue, Oct 16, 2012 at 4:59 PM, Steven Silvester > wrote: >> I would suggest the following instead: >> Convert to LAB >> Perform transform on lightness channel >> Convert back to RGB > > That seems like a sound approach to me. Tony, Andreas? > >> Because, red, green, and blue are not really independent "channels" to the human eye. I used this method on the adapthist pull request when handling RGB images. > > By the way, thanks for that PR--now that 0.7.2 is out the door, I reviewed it. > > St?fan > > -- > > From steven.silvester at gmail.com Wed Oct 17 21:08:36 2012 From: steven.silvester at gmail.com (Steven Silvester) Date: Wed, 17 Oct 2012 18:08:36 -0700 (PDT) Subject: each_channel decorator In-Reply-To: References: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> <7CECE99A-48BD-40F2-A13D-8F6A55392B6E@gmail.com> Message-ID: <450facd3-fb05-4698-8be7-1a92c8df8ecd@googlegroups.com> No paper off the top of my head. I got the idea from a Matlab blog: http://blogs.mathworks.com/steve/2010/12/23/two-dimensional-histograms/ Empirically, when I applied an equalization to the lena image on each RGB channel, the result was a distorted image (color-wise). Applying the LAB method shed the original image of the soft focus the photographer had used, and presented a harsher lighting that showed more detail, while preserving the colors. From steven.silvester at gmail.com Wed Oct 17 21:13:08 2012 From: steven.silvester at gmail.com (Steven Silvester) Date: Wed, 17 Oct 2012 18:13:08 -0700 (PDT) Subject: each_channel decorator In-Reply-To: <450facd3-fb05-4698-8be7-1a92c8df8ecd@googlegroups.com> References: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> <7CECE99A-48BD-40F2-A13D-8F6A55392B6E@gmail.com> <450facd3-fb05-4698-8be7-1a92c8df8ecd@googlegroups.com> Message-ID: <81fd74f8-b671-4fc5-810d-5adb627a9fcf@googlegroups.com> Also the help file for the Matlab adapthisteq function demostrates this method: http://www.mathworks.com/help/images/ref/adapthisteq.html From steven.silvester at gmail.com Wed Oct 17 23:01:40 2012 From: steven.silvester at gmail.com (Steven Silvester) Date: Wed, 17 Oct 2012 20:01:40 -0700 (PDT) Subject: each_channel decorator In-Reply-To: References: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> <7CECE99A-48BD-40F2-A13D-8F6A55392B6E@gmail.com> Message-ID: Tony, How about a third option, computing on each channel in LAB space? elif rgb_behavior == 'lab': lab = color.rgb2lab(image) c_new = [image_filter(c) for c in np.rollaxis(lab, -1)] out = np.rollaxis(np.array(c_new), 0, 3) out = color.lab2rgb(out) I tried this with "edges", and it produced a pretty interesting image. On Wednesday, October 17, 2012 8:48:58 PM UTC-5, Tony S Yu wrote: > > > > On Wed, Oct 17, 2012 at 4:37 PM, St?fan van der Walt > > wrote: > >> On Wed, Oct 17, 2012 at 7:39 AM, Sch?nberger Johannes >> > wrote: >> > Sounds good. Do you have a paper or any reliable source about this? >> Just interested in this... >> >> The question is, should we make this a decorator, or simply provide it >> as utility functions? I'm wondering, because now we already have two >> different ways of handling color images: split them up, RGB, or >> convert them to LAB and apply the filter to LAB. How do we expose >> both of these sensible alternatives to the user? >> >> We can have a *default*, so that all single-channel filters are done >> on the luminance layer, but then combine that with utility functions. >> E.g. >> >> @luminance_filter >> def gray_filter(image, ...): >> ... >> >> gray_filter(color_image, params) --> convert to LAB, filter on L, convert >> back >> filter_layers(color_image, gray_filter, params) -> filter each layer >> separately and combine >> >> Alternatively, skip the decorators completely, and just provide two >> utility functions: filter_layers and filter_luminance. >> > > > I'm not really sure how a utility function would work. Wouldn't you need > to provide at least 2 utility functions when converting to LAB: > > image, ab = prepare_rgb(image) > # ... code to generate `filtered_image` from `image` > filtered_image = finalize_rgb(filtered_image, ab) > > Here, `ab` would be some dummy value if the input image is already gray. > This is actually a bit cryptic in order to prevent special-casing for RGB > images. Otherwise, you'd have to add some conditionals as well. And don't > even know how the layer-by-layer approach would work as a utility function. > > Basically, that's all to say that I think a decorator makes a lot more > sense in this case. In fact, you can handle the different behaviors > (layer-by-layer vs lightness channel) by either introducing a parameter to > decorator or the wrapped filter (or both---the decorator parameter would > set the default, which you could override at runtime). Here's a mock up > adding a parameter to the filter: > > https://gist.github.com/3909400 > > The edge filter example is a bit strange: if you filter by lightness > (Oops, I called it "luminance" in the example), then you get weird results. > > -Tony > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsyu80 at gmail.com Wed Oct 17 21:48:17 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Wed, 17 Oct 2012 21:48:17 -0400 Subject: each_channel decorator In-Reply-To: References: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> <7CECE99A-48BD-40F2-A13D-8F6A55392B6E@gmail.com> Message-ID: On Wed, Oct 17, 2012 at 4:37 PM, St?fan van der Walt wrote: > On Wed, Oct 17, 2012 at 7:39 AM, Sch?nberger Johannes > wrote: > > Sounds good. Do you have a paper or any reliable source about this? Just > interested in this... > > The question is, should we make this a decorator, or simply provide it > as utility functions? I'm wondering, because now we already have two > different ways of handling color images: split them up, RGB, or > convert them to LAB and apply the filter to LAB. How do we expose > both of these sensible alternatives to the user? > > We can have a *default*, so that all single-channel filters are done > on the luminance layer, but then combine that with utility functions. > E.g. > > @luminance_filter > def gray_filter(image, ...): > ... > > gray_filter(color_image, params) --> convert to LAB, filter on L, convert > back > filter_layers(color_image, gray_filter, params) -> filter each layer > separately and combine > > Alternatively, skip the decorators completely, and just provide two > utility functions: filter_layers and filter_luminance. > I'm not really sure how a utility function would work. Wouldn't you need to provide at least 2 utility functions when converting to LAB: image, ab = prepare_rgb(image) # ... code to generate `filtered_image` from `image` filtered_image = finalize_rgb(filtered_image, ab) Here, `ab` would be some dummy value if the input image is already gray. This is actually a bit cryptic in order to prevent special-casing for RGB images. Otherwise, you'd have to add some conditionals as well. And don't even know how the layer-by-layer approach would work as a utility function. Basically, that's all to say that I think a decorator makes a lot more sense in this case. In fact, you can handle the different behaviors (layer-by-layer vs lightness channel) by either introducing a parameter to decorator or the wrapped filter (or both---the decorator parameter would set the default, which you could override at runtime). Here's a mock up adding a parameter to the filter: https://gist.github.com/3909400 The edge filter example is a bit strange: if you filter by lightness (Oops, I called it "luminance" in the example), then you get weird results. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsyu80 at gmail.com Wed Oct 17 23:17:21 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Wed, 17 Oct 2012 23:17:21 -0400 Subject: each_channel decorator In-Reply-To: References: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> <7CECE99A-48BD-40F2-A13D-8F6A55392B6E@gmail.com> Message-ID: On Wed, Oct 17, 2012 at 11:01 PM, Steven Silvester < steven.silvester at gmail.com> wrote: > Tony, > > How about a third option, computing on each channel in LAB space? > > elif rgb_behavior == 'lab': > lab = color.rgb2lab(image) > c_new = [image_filter(c) for c in np.rollaxis(lab, -1)] > out = np.rollaxis(np.array(c_new), 0, 3) > out = color.lab2rgb(out) > > I tried this with "edges", and it produced a pretty interesting image. > Interesting! That's closer to what I would have expected when operating on the lightness channel (but still not quite what I expected). And it gives reasonable results with the smoothing operation. You've made me realize that I don't understand the LAB color space at all. :P -Tony > On Wednesday, October 17, 2012 8:48:58 PM UTC-5, Tony S Yu wrote: >> >> >> >> On Wed, Oct 17, 2012 at 4:37 PM, St?fan van der Walt wrote: >> >>> On Wed, Oct 17, 2012 at 7:39 AM, Sch?nberger Johannes >>> wrote: >>> > Sounds good. Do you have a paper or any reliable source about this? >>> Just interested in this... >>> >>> The question is, should we make this a decorator, or simply provide it >>> as utility functions? I'm wondering, because now we already have two >>> different ways of handling color images: split them up, RGB, or >>> convert them to LAB and apply the filter to LAB. How do we expose >>> both of these sensible alternatives to the user? >>> >>> We can have a *default*, so that all single-channel filters are done >>> on the luminance layer, but then combine that with utility functions. >>> E.g. >>> >>> @luminance_filter >>> def gray_filter(image, ...): >>> ... >>> >>> gray_filter(color_image, params) --> convert to LAB, filter on L, >>> convert back >>> filter_layers(color_image, gray_filter, params) -> filter each layer >>> separately and combine >>> >>> Alternatively, skip the decorators completely, and just provide two >>> utility functions: filter_layers and filter_luminance. >>> >> >> >> I'm not really sure how a utility function would work. Wouldn't you need >> to provide at least 2 utility functions when converting to LAB: >> >> image, ab = prepare_rgb(image) >> # ... code to generate `filtered_image` from `image` >> filtered_image = finalize_rgb(filtered_image, ab) >> >> Here, `ab` would be some dummy value if the input image is already gray. >> This is actually a bit cryptic in order to prevent special-casing for RGB >> images. Otherwise, you'd have to add some conditionals as well. And don't >> even know how the layer-by-layer approach would work as a utility function. >> >> Basically, that's all to say that I think a decorator makes a lot more >> sense in this case. In fact, you can handle the different behaviors >> (layer-by-layer vs lightness channel) by either introducing a parameter to >> decorator or the wrapped filter (or both---the decorator parameter would >> set the default, which you could override at runtime). Here's a mock up >> adding a parameter to the filter: >> >> https://gist.github.com/**3909400 >> >> The edge filter example is a bit strange: if you filter by lightness >> (Oops, I called it "luminance" in the example), then you get weird results. >> >> -Tony >> >> >> >> -- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thouis at gmail.com Thu Oct 18 12:57:52 2012 From: thouis at gmail.com (Thouis (Ray) Jones) Date: Thu, 18 Oct 2012 12:57:52 -0400 Subject: Python for image processing on Wikipedia In-Reply-To: <3986761.Gz1EPsQfVQ@peterrabbit> References: <3986761.Gz1EPsQfVQ@peterrabbit> Message-ID: On Thu, Oct 18, 2012 at 10:42 AM, Luis Pedro Coelho wrote: > While looking for something else, I ran across this: > > http://en.wikipedia.org/wiki/Comparison_of_image_processing_software > > and added the Python column. I think a better ideas is to mark the article for deletion (and I've done so), as it's meaningless (any of those algorithms could be coded in python, matlab, or mathematica), it doesn't list arguably more popular image processing tools (e.g., ImageJ, OpenCV), and the list seems arbitrarily constructed. Far better would be to add links from each of the algorithms' pages to the software that implements that particular algorithm. Ray Jones From luis at luispedro.org Thu Oct 18 10:42:20 2012 From: luis at luispedro.org (Luis Pedro Coelho) Date: Thu, 18 Oct 2012 15:42:20 +0100 Subject: Python for image processing on Wikipedia Message-ID: <3986761.Gz1EPsQfVQ@peterrabbit> While looking for something else, I ran across this: http://en.wikipedia.org/wiki/Comparison_of_image_processing_software and added the Python column. I think some of the "No"s could be turned into "Yes"s, except that I don't know all about all Python packages. * I don't even understand what some of the headings are supposed to mean and I work in computer vision research as they seem incredibly generic. For example, "Image validate", "Image adjustment", ... Best, -- Luis Pedro Coelho | Institute for Molecular Medicine | http://luispedro.org From otto.fajardob at gmail.com Thu Oct 18 11:46:36 2012 From: otto.fajardob at gmail.com (Otto Fajardo) Date: Thu, 18 Oct 2012 17:46:36 +0200 Subject: Python for image processing on Wikipedia In-Reply-To: <3986761.Gz1EPsQfVQ@peterrabbit> References: <3986761.Gz1EPsQfVQ@peterrabbit> Message-ID: Some items in python could be turned into "yes" if you take into account opencv for python: http://opencv.willowgarage.com/documentation/python/index.html http://docs.opencv.org/index.html 2012/10/18 Luis Pedro Coelho > While looking for something else, I ran across this: > > http://en.wikipedia.org/wiki/Comparison_of_image_processing_software > > and added the Python column. > > I think some of the "No"s could be turned into "Yes"s, except that I don't > know all about all Python packages. > > * > > I don't even understand what some of the headings are supposed to mean and > I > work in computer vision research as they seem incredibly generic. For > example, > "Image validate", "Image adjustment", ... > > Best, > -- > Luis Pedro Coelho | Institute for Molecular Medicine | > http://luispedro.org > > -- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luis at luispedro.org Thu Oct 18 12:52:49 2012 From: luis at luispedro.org (Luis Pedro Coelho) Date: Thu, 18 Oct 2012 17:52:49 +0100 Subject: Python for image processing on Wikipedia In-Reply-To: References: <3986761.Gz1EPsQfVQ@peterrabbit> Message-ID: <2420949.IWpTVzATTK@peterrabbit> Fair enough. It is a pretty bad article as it is. Luis On Thursday, October 18, 2012 12:57:52 PM Thouis Jones wrote: > I think a better ideas is to mark the article for deletion (and I've > done so), as it's meaningless (any of those algorithms could be coded > in python, matlab, or mathematica), it doesn't list arguably more > popular image processing tools (e.g., ImageJ, OpenCV), and the list > seems arbitrarily constructed. Far better would be to add links from > each of the algorithms' pages to the software that implements that > particular algorithm. > > Ray Jones -- Luis Pedro Coelho | Institute for Molecular Medicine | http://luispedro.org From otto.fajardob at gmail.com Thu Oct 18 12:30:41 2012 From: otto.fajardob at gmail.com (Otto Fajardo) Date: Thu, 18 Oct 2012 18:30:41 +0200 Subject: Python for image processing on Wikipedia In-Reply-To: References: <3986761.Gz1EPsQfVQ@peterrabbit> Message-ID: oh, I'm sorry! only now I read that opencv was already included! ... but ... for example Hough line detection, it says No in python, but I think it's in opencv (maybe I am wrong again?) http://opencv.willowgarage.com/documentation/python/imgproc_feature_detection.html?highlight=hough#HoughLines2 By the way, another interesting library, that maybe not many people is aware of, is pink. It's opensource. It has tons of functions originally written in C, and they are now wrapping it for python. It is not numpy-friendly (apparently they want to change this now), and it's difficult to compile. But maybe interesting to take a look: http://www.esiee.fr/~coupriem/Pink/doc/html/index.html https://www.pinkhq.com/homepage/ 2012/10/18 Otto Fajardo > Some items in python could be turned into "yes" if you take into account > opencv for python: > > http://opencv.willowgarage.com/documentation/python/index.html > http://docs.opencv.org/index.html > > > > 2012/10/18 Luis Pedro Coelho > >> While looking for something else, I ran across this: >> >> http://en.wikipedia.org/wiki/Comparison_of_image_processing_software >> >> and added the Python column. >> >> I think some of the "No"s could be turned into "Yes"s, except that I don't >> know all about all Python packages. >> >> * >> >> I don't even understand what some of the headings are supposed to mean >> and I >> work in computer vision research as they seem incredibly generic. For >> example, >> "Image validate", "Image adjustment", ... >> >> Best, >> -- >> Luis Pedro Coelho | Institute for Molecular Medicine | >> http://luispedro.org >> >> -- >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannesschoenberger at gmail.com Thu Oct 18 12:59:34 2012 From: hannesschoenberger at gmail.com (=?UTF-8?Q?Johannes_Sch=C3=B6nberger?=) Date: Thu, 18 Oct 2012 18:59:34 +0200 Subject: Python for image processing on Wikipedia In-Reply-To: References: <3986761.Gz1EPsQfVQ@peterrabbit> Message-ID: > I think a better ideas is to mark the article for deletion (and I've > done so), as it's meaningless (any of those algorithms could be coded > in python, matlab, or mathematica), it doesn't list arguably more > popular image processing tools (e.g., ImageJ, OpenCV), and the list > seems arbitrarily constructed. Far better would be to add links from > each of the algorithms' pages to the software that implements that > particular algorithm. I totally agree here. From stefan at sun.ac.za Fri Oct 19 16:24:56 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 19 Oct 2012 13:24:56 -0700 Subject: each_channel decorator In-Reply-To: <450facd3-fb05-4698-8be7-1a92c8df8ecd@googlegroups.com> References: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> <7CECE99A-48BD-40F2-A13D-8F6A55392B6E@gmail.com> <450facd3-fb05-4698-8be7-1a92c8df8ecd@googlegroups.com> Message-ID: On Wed, Oct 17, 2012 at 6:08 PM, Steven Silvester wrote: > No paper off the top of my head. I got the idea from a Matlab blog: > http://blogs.mathworks.com/steve/2010/12/23/two-dimensional-histograms/ Neat! Here's an implementation in Python: https://github.com/stefanv/scikit-image-demos/blob/master/mm_color_select.py Tony, what do you think about a painting / mask selection tool for the visualization toolbox? St?fan From stefan at sun.ac.za Fri Oct 19 16:35:35 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 19 Oct 2012 13:35:35 -0700 Subject: each_channel decorator In-Reply-To: References: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> <7CECE99A-48BD-40F2-A13D-8F6A55392B6E@gmail.com> Message-ID: On Wed, Oct 17, 2012 at 6:48 PM, Tony Yu wrote: > I'm not really sure how a utility function would work. Wouldn't you need to > provide at least 2 utility functions when converting to LAB: > > image, ab = prepare_rgb(image) > # ... code to generate `filtered_image` from `image` > filtered_image = finalize_rgb(filtered_image, ab) A utility function would simply take an image and apply the specified filter to all its layers (which are pre-and post-converted in some way), e.g. apply_to_rgb(image, filter) > Basically, that's all to say that I think a decorator makes a lot more sense > in this case. But it does mean introducing a flag. I'm debating which is clearer and more explicit: apply_to_luminance(image, filter) vs filter(image, rgb_behavior='luminance') (with the caveat that rgb_behavior has to be documented in each and every filter function--and that we have to figure out a way of preserving signatures and docstrings with decorators) St?fan From stefan at sun.ac.za Fri Oct 19 17:29:41 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 19 Oct 2012 14:29:41 -0700 Subject: each_channel decorator In-Reply-To: References: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> <7CECE99A-48BD-40F2-A13D-8F6A55392B6E@gmail.com> <450facd3-fb05-4698-8be7-1a92c8df8ecd@googlegroups.com> Message-ID: On Fri, Oct 19, 2012 at 2:17 PM, Tony Yu wrote: > This is awesome! We need a good stock image that we can include in the > package, so that this example can be included in the docs. OK, so whoever wants to join the scikit-image team next has to prove their dedication by spreading a packet of brightly colored M&M's on a lightly colored, wooden textured surface, photograph it, and release the photo into the public domain :-) Bonus marks if you can arrange them exactly like the ones in Steve's photo! St?fan From stefan at sun.ac.za Fri Oct 19 17:40:35 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 19 Oct 2012 14:40:35 -0700 Subject: each_channel decorator In-Reply-To: References: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> <7CECE99A-48BD-40F2-A13D-8F6A55392B6E@gmail.com> Message-ID: On Fri, Oct 19, 2012 at 2:31 PM, Tony Yu wrote: > I agree that documenting the extra filter parameter could be problematic. I > guess that the decorator could inject that into the filter's docstring, but > that's probably too magical. We could make it a hidden parameter and provide > utility functions that just change the default behavior. I'd prefer for the parameter to be visible and documented for each function that chooses to use it. I think we should just make application to each individual layer the default, since that's the most obvious generalization to RGB. St?fan From tsyu80 at gmail.com Fri Oct 19 17:17:55 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Fri, 19 Oct 2012 17:17:55 -0400 Subject: each_channel decorator In-Reply-To: References: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> <7CECE99A-48BD-40F2-A13D-8F6A55392B6E@gmail.com> <450facd3-fb05-4698-8be7-1a92c8df8ecd@googlegroups.com> Message-ID: On Fri, Oct 19, 2012 at 4:24 PM, St?fan van der Walt wrote: > On Wed, Oct 17, 2012 at 6:08 PM, Steven Silvester > wrote: > > No paper off the top of my head. I got the idea from a Matlab blog: > > http://blogs.mathworks.com/steve/2010/12/23/two-dimensional-histograms/ > > Neat! > > Here's an implementation in Python: > > > https://github.com/stefanv/scikit-image-demos/blob/master/mm_color_select.py This is awesome! We need a good stock image that we can include in the package, so that this example can be included in the docs. > Tony, what do you think about a painting / mask selection tool for the > visualization toolbox? > Yeah, this has been on my Todo list for a very long time. Unfortunately, it may have to stay there for at least another month or so. :/ St?fan > > -- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsyu80 at gmail.com Fri Oct 19 17:31:57 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Fri, 19 Oct 2012 17:31:57 -0400 Subject: each_channel decorator In-Reply-To: References: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> <7CECE99A-48BD-40F2-A13D-8F6A55392B6E@gmail.com> Message-ID: On Fri, Oct 19, 2012 at 4:35 PM, St?fan van der Walt wrote: > On Wed, Oct 17, 2012 at 6:48 PM, Tony Yu wrote: > > I'm not really sure how a utility function would work. Wouldn't you need > to > > provide at least 2 utility functions when converting to LAB: > > > > image, ab = prepare_rgb(image) > > # ... code to generate `filtered_image` from `image` > > filtered_image = finalize_rgb(filtered_image, ab) > > A utility function would simply take an image and apply the specified > filter to all its layers (which are pre-and post-converted in some > way), e.g. > > apply_to_rgb(image, filter) > > > Basically, that's all to say that I think a decorator makes a lot more > sense > > in this case. > > But it does mean introducing a flag. I'm debating which is clearer > and more explicit: > > apply_to_luminance(image, filter) > > vs > > filter(image, rgb_behavior='luminance') > > (with the caveat that rgb_behavior has to be documented in each and > every filter function--and that we have to figure out a way of > preserving signatures and docstrings with decorators) > > St?fan > Oh, I see: Utility functions for users to apply a grayscale filter to their color image. I was thinking of utility functions that allows us to add RGB-handling to scikit-image functions (so that it just works without the user needing to think about it). Personally, I'd prefer RGB images to just work. For most filters, there's probably a preferred way to handle an RGB image (e.g, Lightness channel, RGB layers, grayscale), and that would just be the default (I guess the *preferred* way may not always be obvious). I agree that documenting the extra filter parameter could be problematic. I guess that the decorator could inject that into the filter's docstring, but that's probably too magical. We could make it a hidden parameter and provide utility functions that just change the default behavior. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannesschoenberger at gmail.com Sat Oct 20 02:13:08 2012 From: hannesschoenberger at gmail.com (=?windows-1252?Q?Sch=F6nberger_Johannes?=) Date: Sat, 20 Oct 2012 08:13:08 +0200 Subject: each_channel decorator In-Reply-To: References: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> <7CECE99A-48BD-40F2-A13D-8F6A55392B6E@gmail.com> Message-ID: <07B907C4-A5B5-4B8B-BCC5-664271EAFA54@gmail.com> Hm, I get the feeling that this decorator gets too complex and "magic"? Is this really a standard use case? If someone really wants to apply a filter to the luminance channel of an image, why not let them use ***2lab function? Johannes Sch?nberger Am 19.10.2012 um 23:40 schrieb St?fan van der Walt : > On Fri, Oct 19, 2012 at 2:31 PM, Tony Yu wrote: >> I agree that documenting the extra filter parameter could be problematic. I >> guess that the decorator could inject that into the filter's docstring, but >> that's probably too magical. We could make it a hidden parameter and provide >> utility functions that just change the default behavior. > > I'd prefer for the parameter to be visible and documented for each > function that chooses to use it. I think we should just make > application to each individual layer the default, since that's the > most obvious generalization to RGB. > > St?fan > > -- > > From tsyu80 at gmail.com Sat Oct 20 08:36:20 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Sat, 20 Oct 2012 08:36:20 -0400 Subject: each_channel decorator In-Reply-To: <07B907C4-A5B5-4B8B-BCC5-664271EAFA54@gmail.com> References: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> <7CECE99A-48BD-40F2-A13D-8F6A55392B6E@gmail.com> <07B907C4-A5B5-4B8B-BCC5-664271EAFA54@gmail.com> Message-ID: On Sat, Oct 20, 2012 at 2:13 AM, Sch?nberger Johannes < hannesschoenberger at gmail.com> wrote: > Hm, I get the feeling that this decorator gets too complex and "magic"? Is > this really a standard use case? If someone really wants to apply a filter > to the luminance channel of an image, why not let them use ***2lab function? > > > Johannes Sch?nberger > "Hidden" and "magic" may have been the wrong wording. Providing decorators allows filter writers to provide a default RGB behavior. There doesn't really need to be an `rgb_behavior` parameter at all (i.e. no user-settable parameter). Regardless of what the filter writer decides, the user can adapt the grayscale filter however he or she wants---either with utility functions or explicitly with, e.g., rgb2lab. My main hesitation with utility functions is that they make argument passing a bit ugly. On the other hand, I think doing it explicitly is quite involved (e.g. LAB: 1. convert to LAB, 2. grab the channel, 3. rescale values, 4. filter, 5. rescale values, 6. replace channel, 7. convert to RGB). After playing around with this a bit more, I agree that defaulting to filtering each layer of RGB images is the way to go (in most cases). -Tony Updated @adapt_rgb: https://gist.github.com/3909400 I'm inclined to move away from the "one decorator to rule them all" approach, and use separate @rgb_channel_filter (or @each_channel, or whatever), @lightness_filter, etc. > > Am 19.10.2012 um 23:40 schrieb St?fan van der Walt : > > > On Fri, Oct 19, 2012 at 2:31 PM, Tony Yu wrote: > >> I agree that documenting the extra filter parameter could be > problematic. I > >> guess that the decorator could inject that into the filter's docstring, > but > >> that's probably too magical. We could make it a hidden parameter and > provide > >> utility functions that just change the default behavior. > > > > I'd prefer for the parameter to be visible and documented for each > > function that chooses to use it. I think we should just make > > application to each individual layer the default, since that's the > > most obvious generalization to RGB. > > > > St?fan > > > > -- > > > > > > -- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Sun Oct 21 04:32:57 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 21 Oct 2012 01:32:57 -0700 Subject: each_channel decorator In-Reply-To: References: <1C8D42BA-93AF-45F8-8A97-2C8F24AD0EA1@gmail.com> <7CECE99A-48BD-40F2-A13D-8F6A55392B6E@gmail.com> <07B907C4-A5B5-4B8B-BCC5-664271EAFA54@gmail.com> Message-ID: On Sat, Oct 20, 2012 at 5:36 AM, Tony Yu wrote: > Updated @adapt_rgb: https://gist.github.com/3909400 > I'm inclined to move away from the "one decorator to rule them all" > approach, and use separate @rgb_channel_filter (or @each_channel, or > whatever), @lightness_filter, etc. This should help to preserve to docstring: http://docs.python.org/library/functools.html#functools.wraps St?fan From guillaume.calmettes at gmail.com Mon Oct 22 03:05:18 2012 From: guillaume.calmettes at gmail.com (Guillaume Calmettes) Date: Mon, 22 Oct 2012 00:05:18 -0700 Subject: De-Blurring Message-ID: Hello, I just went through an interesting post on restoration of defocused and blurred images (with Matlab code provided), that you might find interesting: http://yuzhikov.com/articles/BlurredImagesRestoration1.htm guillaume -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Mon Oct 22 03:13:34 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 22 Oct 2012 00:13:34 -0700 Subject: De-Blurring In-Reply-To: References: Message-ID: On Mon, Oct 22, 2012 at 12:05 AM, Guillaume Calmettes wrote: > I just went through an interesting post on restoration of defocused and > blurred images (with Matlab code provided), that you might find interesting: > http://yuzhikov.com/articles/BlurredImagesRestoration1.htm Blind decovolution is high up on my priority list for skimage. In the mean time, improving the existing Wiener inverse filter to support kernels would be good. Also, adding Thikonov's inverse method. Thanks for the link! St?fan From stefan at sun.ac.za Wed Oct 24 02:28:48 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 23 Oct 2012 23:28:48 -0700 Subject: LPI filter framework redesign Message-ID: Hi all, I just revisited the LPI filter framework for the first time in many years, and...err...it's pretty bad :) I wrote this originally to simulate the effect of a specific point-spread-function on an image--and for that purpose it works OK. But for restoring images based on a kernel, the interface doesn't work. I'd like to redesign this functionality, and would like to have your input. Does anyone here have much experience in this type of filtering and deblurring images? My bigger aim is to implement fairly robust blind deconvolution. St?fan From stefan at sun.ac.za Wed Oct 24 17:27:59 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 24 Oct 2012 14:27:59 -0700 Subject: Motion deblurring challenge Message-ID: Hi, all Every year, I give the students in our image processing course the challenge of deblurring the following image: https://github.com/stefanv/scikit-image-demos/blob/master/data/clock_motion.png Now, the question is whether the experts on this mailing list decipher the time on the wall clock! Here's my attempt so far: https://github.com/stefanv/scikit-image-demos/blob/master/clock_deblur.py -- mine tells the time already, so don't look if you want to figure this one out yourself. Cheers St?fan From cjgohlke at gmail.com Thu Oct 25 20:38:37 2012 From: cjgohlke at gmail.com (Christoph Gohlke) Date: Thu, 25 Oct 2012 17:38:37 -0700 Subject: Motion deblurring challenge In-Reply-To: References: Message-ID: <5089DB8D.9020100@gmail.com> On 10/24/2012 2:27 PM, St??????fan van der Walt wrote: > Hi, all > > Every year, I give the students in our image processing course the > challenge of deblurring the following image: > > https://github.com/stefanv/scikit-image-demos/blob/master/data/clock_motion.png > > Now, the question is whether the experts on this mailing list decipher > the time on the wall clock! > > Here's my attempt so far: > https://github.com/stefanv/scikit-image-demos/blob/master/clock_deblur.py > -- mine tells the time already, so don't look if you want to figure > this one out yourself. > > Cheers > St??????fan > A Q&D deconvolution with a kernel guesstimated from the blurred image (~35 px horizontally) seems to be good enough to read the time. Christoph From hannesschoenberger at gmail.com Thu Oct 25 13:21:07 2012 From: hannesschoenberger at gmail.com (=?UTF-8?Q?Johannes_Sch=C3=B6nberger?=) Date: Thu, 25 Oct 2012 19:21:07 +0200 Subject: Motion deblurring challenge In-Reply-To: References: Message-ID: <-7448335146270862974@unknownmsgid> Hi, hopefully I'll have time to try to solve this. Unfortunately I'm short of time at the moment... Johannes Sch?nberger Am 24.10.2012 um 23:28 schrieb "St?fan van der Walt" : > Hi, all > > Every year, I give the students in our image processing course the > challenge of deblurring the following image: > > https://github.com/stefanv/scikit-image-demos/blob/master/data/clock_motion.png > > Now, the question is whether the experts on this mailing list decipher > the time on the wall clock! > > Here's my attempt so far: > https://github.com/stefanv/scikit-image-demos/blob/master/clock_deblur.py > -- mine tells the time already, so don't look if you want to figure > this one out yourself. > > Cheers > St?fan > > -- > > From tsyu80 at gmail.com Mon Oct 29 18:09:24 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Mon, 29 Oct 2012 18:09:24 -0400 Subject: Reading .jp2 in skimage In-Reply-To: References: Message-ID: On Mon, Oct 29, 2012 at 5:53 PM, Jaidev Deshpande < deshpande.jaidev at gmail.com> wrote: > Hello, > > Are jpeg 2000 images supported in skimage? I tried looking for it in > the docs but didn't find anything. > > Thanks > > -- > JD > > Hey JD, skimage doesn't implement image readers, but instead, uses other i/o libraries as plugins (so there's no good way to list image format support). For me, `skimage.io.imread` doesn't read jp2 by default (my default plugin is 'PIL'), but I can set the plugin to 'freeimage' to read jp2 images; e.g. from skimage import io io.imread('some_image.jp2', plugin='freeimage') which uses freeimage just for that one call or io.use_plugin('freeimage') io.imread('some_image.jp2') which changes your default io plugin to freeimage. You'd need to have the freeimage library installed on your system to use this plugin: http://freeimage.sourceforge.net/ There may be other skimage plugins that support jp2, but I'm not sure. Best, -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsyu80 at gmail.com Mon Oct 29 18:39:45 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Mon, 29 Oct 2012 18:39:45 -0400 Subject: Reading .jp2 in skimage In-Reply-To: References: Message-ID: On Mon, Oct 29, 2012 at 6:23 PM, Jaidev Deshpande < deshpande.jaidev at gmail.com> wrote: > On Tue, Oct 30, 2012 at 3:39 AM, Tony Yu wrote: > > > > > > On Mon, Oct 29, 2012 at 5:53 PM, Jaidev Deshpande > > wrote: > >> > > > > > > skimage doesn't implement image readers, but instead, uses other i/o > > libraries as plugins (so there's no good way to list image format > support). > > Out of curiosity, does matplotlib's imread do the same, using other > plugins? > I think Matplotlib uses libpng for PNGs and then PIL for everything else. I tried loading a jp2 image with the matplotlib plugin and it raises a PIL error. > For me, `skimage.io.imread` doesn't read jp2 by default (my default plugin > > is 'PIL'), but I can set the plugin to 'freeimage' to read jp2 images; > e.g. > > > > from skimage import io > > io.imread('some_image.jp2', plugin='freeimage') > > > > which uses freeimage just for that one call or > > > > io.use_plugin('freeimage') > > io.imread('some_image.jp2') > > > > which changes your default io plugin to freeimage. You'd need to have the > > freeimage library installed on your system to use this plugin: > > > > http://freeimage.sourceforge.net/ > > Thanks! That did it. > Great! We should probably update info in the docs about what plugins we support. Freeimage is already listed in our install page, but there are actually a few others that aren't: http://scikit-image.org/docs/dev/install.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From deshpande.jaidev at gmail.com Mon Oct 29 17:53:59 2012 From: deshpande.jaidev at gmail.com (Jaidev Deshpande) Date: Tue, 30 Oct 2012 03:23:59 +0530 Subject: Reading .jp2 in skimage In-Reply-To: References: Message-ID: Hello, Are jpeg 2000 images supported in skimage? I tried looking for it in the docs but didn't find anything. Thanks -- JD From deshpande.jaidev at gmail.com Mon Oct 29 18:23:34 2012 From: deshpande.jaidev at gmail.com (Jaidev Deshpande) Date: Tue, 30 Oct 2012 03:53:34 +0530 Subject: Reading .jp2 in skimage In-Reply-To: References: Message-ID: On Tue, Oct 30, 2012 at 3:39 AM, Tony Yu wrote: > > > On Mon, Oct 29, 2012 at 5:53 PM, Jaidev Deshpande > wrote: >> >> Hello, >> >> Are jpeg 2000 images supported in skimage? I tried looking for it in >> the docs but didn't find anything. >> >> Thanks >> >> -- >> JD >> > > Hey JD, > > skimage doesn't implement image readers, but instead, uses other i/o > libraries as plugins (so there's no good way to list image format support). Out of curiosity, does matplotlib's imread do the same, using other plugins? > For me, `skimage.io.imread` doesn't read jp2 by default (my default plugin > is 'PIL'), but I can set the plugin to 'freeimage' to read jp2 images; e.g. > > from skimage import io > io.imread('some_image.jp2', plugin='freeimage') > > which uses freeimage just for that one call or > > io.use_plugin('freeimage') > io.imread('some_image.jp2') > > which changes your default io plugin to freeimage. You'd need to have the > freeimage library installed on your system to use this plugin: > > http://freeimage.sourceforge.net/ Thanks! That did it. > > There may be other skimage plugins that support jp2, but I'm not sure. > > Best, > -Tony > > -- > > -- JD