From aaaagrawal at gmail.com Wed May 1 13:42:38 2013 From: aaaagrawal at gmail.com (Ankit Agrawal) Date: Wed, 1 May 2013 10:42:38 -0700 (PDT) Subject: GSoC 2013 Proposal : Implementation of STAR and Binary Feature Detectors and Descriptors Message-ID: <334fc123-39c7-4fe2-a0ef-f2f1f62440b6@googlegroups.com> Hi everyone, I have made the first draft of my proposaland uploaded it on our github wiki. I would like all the mentors and community members to review it and comment for any possible improvements and suggestions. I have some of personal comments on it : 1] I feel that implementing all the four features is slightly ambitious and implementing three of them would be the best. After skimming through papers, this is the order of difficulty in terms of implementation : BRIEF < STAR < FREAK < BRISK(most difficult) 2] As mentioned in the BRISK paper, BRISK detector makes use of FAST detectorin the process. If it comes down to implementing 3 instead of 4 features, it would be best that I implement FAST as the 4th feature instead of BRISK, which would relax the timeline a bit and will give me more time for testing and optimizing. I suggest all members to review and share their opinions on it as soon as possible so that I can make the changes and upload it on gsoc-melange site. Thank you for your time. Regards, Ankit Agrawal, Communication and Signal Processing, IIT Bombay. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschoenberger at demuc.de Wed May 1 10:00:10 2013 From: jschoenberger at demuc.de (=?iso-8859-1?Q?Johannes_Sch=F6nberger?=) Date: Wed, 1 May 2013 16:00:10 +0200 Subject: scikit-image Tutorial Message-ID: Hi, I've just found an interesting presentation from one of the guys of Continuum analytics. http://vimeo.com/63258721 Johannes Sch?nberger From aaaagrawal at gmail.com Wed May 1 20:38:11 2013 From: aaaagrawal at gmail.com (Ankit Agrawal) Date: Wed, 1 May 2013 17:38:11 -0700 (PDT) Subject: GSoC 2013 Proposal : Implementation of STAR and Binary Feature Detectors and Descriptors In-Reply-To: References: <334fc123-39c7-4fe2-a0ef-f2f1f62440b6@googlegroups.com> Message-ID: <750d5640-a961-4725-9633-cfa6867ba3ce@googlegroups.com> Stefan, Can you point me to that code? Thanks. I request all the community members to review my proposal and comment for any possible improvements. Thanks. Regards, Ankit. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaaagrawal at gmail.com Wed May 1 21:16:39 2013 From: aaaagrawal at gmail.com (Ankit Agrawal) Date: Wed, 1 May 2013 18:16:39 -0700 (PDT) Subject: GSoC 2013 Proposal : Implementation of STAR and Binary Feature Detectors and Descriptors In-Reply-To: References: <334fc123-39c7-4fe2-a0ef-f2f1f62440b6@googlegroups.com> <750d5640-a961-4725-9633-cfa6867ba3ce@googlegroups.com> Message-ID: <9c41da96-0262-4522-86b8-32bee64500cb@googlegroups.com> > It's also pretty easy to wrap his C code (as done here: > https://github.com/stefanv/supreme/tree/master/supreme/lib/fast) but > maybe implementing from scratch is best. > @Stefan and Tony : Did you get a chance to go over my proposal, especially the implementation timeline? I think that implementing FAST instead of BRISK during the summer would make the timeline schedule better. I will implement the BRISK after the Summer of Code. Your thoughts on this? Regards, Ankit. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsyu80 at gmail.com Wed May 1 21:04:02 2013 From: tsyu80 at gmail.com (Tony Yu) Date: Wed, 1 May 2013 20:04:02 -0500 Subject: GSoC 2013 Proposal : Implementation of STAR and Binary Feature Detectors and Descriptors In-Reply-To: References: <334fc123-39c7-4fe2-a0ef-f2f1f62440b6@googlegroups.com> <750d5640-a961-4725-9633-cfa6867ba3ce@googlegroups.com> Message-ID: On Wed, May 1, 2013 at 7:45 PM, St?fan van der Walt wrote: > On Thu, May 2, 2013 at 2:38 AM, Ankit Agrawal > wrote: > > Can you point me to that code? Thanks. > > I see Rosten himself now has NumPy code available: > > http://www.edwardrosten.com/work/fast.html > > St?fan > I'm not sure I'd call that NumPy code. I think the code is auto generated. My guess is that it would be simpler to start fresh. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Wed May 1 16:37:47 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 1 May 2013 22:37:47 +0200 Subject: GSoC 2013 Proposal : Implementation of STAR and Binary Feature Detectors and Descriptors In-Reply-To: <334fc123-39c7-4fe2-a0ef-f2f1f62440b6@googlegroups.com> References: <334fc123-39c7-4fe2-a0ef-f2f1f62440b6@googlegroups.com> Message-ID: On Wed, May 1, 2013 at 7:42 PM, Ankit Agrawal wrote: > 2] As mentioned in the BRISK paper, BRISK detector makes use of FAST > detector in the process. If it comes down to implementing 3 instead of 4 > features, it would be best that I implement FAST as the 4th feature instead > of BRISK, which would relax the timeline a bit and will give me more time > for testing and optimizing. I already have some FAST code available, if that helps. St?fan From tsyu80 at gmail.com Wed May 1 23:50:49 2013 From: tsyu80 at gmail.com (Tony Yu) Date: Wed, 1 May 2013 22:50:49 -0500 Subject: GSoC 2013 Proposal : Implementation of STAR and Binary Feature Detectors and Descriptors In-Reply-To: References: <334fc123-39c7-4fe2-a0ef-f2f1f62440b6@googlegroups.com> <750d5640-a961-4725-9633-cfa6867ba3ce@googlegroups.com> <9c41da96-0262-4522-86b8-32bee64500cb@googlegroups.com> Message-ID: On Wed, May 1, 2013 at 8:39 PM, St?fan van der Walt wrote: > Hi Ankit > > On Thu, May 2, 2013 at 3:16 AM, Ankit Agrawal > wrote: > > @Stefan and Tony : Did you get a chance to go over my proposal, > especially > > the implementation timeline? I think that implementing FAST instead of > BRISK > > during the summer would make the timeline schedule better. I will > implement > > the BRISK after the Summer of Code. Your thoughts on this? > > The proposal looks good; I think we'll have a better idea of a > realistic timeline once we start coding, but that seems like a > reasonable estimate. > > I think it would be helpful if you could Google for some of the recent > papers that compared many of these binary features, to see which work > best, and then motivate which should be implemented first. > > Regards > St?fan > > Hi Ankit, My free time has been pretty limited, so I can only give a quick response. The proposal looks good to me too. Here's a couple of feature detection comparisons that may be useful for choosing between implementations: http://computer-vision-talks.com/2011/01/comparison-of-the-opencvs-feature-detection-algorithms-2/ http://computer-vision-talks.com/2011/07/comparison-of-the-opencvs-feature-detection-algorithms-ii/ Cheers, -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Wed May 1 18:41:39 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 2 May 2013 00:41:39 +0200 Subject: GSoC: Photomontage and Panoram Stitching In-Reply-To: References: Message-ID: On Wed, May 1, 2013 at 1:04 AM, Fedor Morozov wrote: > I have just made a pull request with wu's circle generation (one of the > "Requested features"). > It has nothing to do with the proposed project, but now I can build skimage > and understand how to commit my changes. > Circle images are attached to this post. Thanks very much! We'll continue the discussion on the PR. St?fan From aaaagrawal at gmail.com Thu May 2 04:17:18 2013 From: aaaagrawal at gmail.com (Ankit Agrawal) Date: Thu, 2 May 2013 01:17:18 -0700 (PDT) Subject: GSoC 2013 Proposal : Implementation of STAR and Binary Feature Detectors and Descriptors In-Reply-To: References: <334fc123-39c7-4fe2-a0ef-f2f1f62440b6@googlegroups.com> <750d5640-a961-4725-9633-cfa6867ba3ce@googlegroups.com> <9c41da96-0262-4522-86b8-32bee64500cb@googlegroups.com> Message-ID: Hi Stefan and Tony, Thanks for your time and feedback. I have referred to the following links to compare feature detectors and descriptors. 1] Comparative Evaluation of Binary Features 2] Comparison of Feature Detection Algorithms 3] Feature Descriptor Comparison report 4] Battle of Feature Descriptors My conclusion about their comparative performance(time), quality(% of correct descriptor matches) and implementation time are as follows - Feature Detectors : (best)FAST > STAR :: Performance(time) (best)STAR > FAST :: Quality Implementation time :: 3 weeks each Binary Feature Descriptors : (best)BRIEF > ORB> FREAK > BRISK :: Performance(time) (best)BRISK > FREAK >= ORB > BRIEF :: Quality(Averaging effects of Scaling, Rotation and Viewpoint change) BRIEF works best among the above four for Non-geometric transforms like change in brightness and exposure Implementation time :: Brisk - 5 weeks; FREAK and ORB - 2 weeks(provided BRIEF has been implemented, see NOTE), BRIEF - 2 weeks Note :: BRISK is dependent on FAST and ORB on BRIEF. Based on the above observations and implementation time details, please help me in choosing those that should be implemented during the course of summer. Thanks again for your time and please reply as soon it is possible for you because the gsoc-melange site is known to have gone down in the past on the last day. Thanks. Regards, Ankit Agrawal, Communication and Signal Processing, IIT Bombay. -------------- next part -------------- An HTML attachment was scrubbed... URL: From usharma01 at gmail.com Thu May 2 05:04:23 2013 From: usharma01 at gmail.com (Umesh Sharma) Date: Thu, 2 May 2013 02:04:23 -0700 (PDT) Subject: Gsoc 2013 Proposal In-Reply-To: References: Message-ID: <85075aef-4510-4f88-9807-a6144d12b198@googlegroups.com> Hello , due to my btech project i was unable to keep in touch, so i was unable to discuss the proposal with community members , I am thinking of working on graph but segmentation and i also found the paper which i am thinking of implementing "A Multilevel Banded Graph Cuts Method for Fast Image Segmentation" paper . I have briefly read the paper , and added implementation details in the proposal. Here is my Gsoc Proposal https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/umeshksharma/1# @stefan and @Tony , do i need to make any other changes ?? Thanks Umesh Kumar Sharma -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaaagrawal at gmail.com Thu May 2 05:42:11 2013 From: aaaagrawal at gmail.com (Ankit Agrawal) Date: Thu, 2 May 2013 02:42:11 -0700 (PDT) Subject: GSoC 2013 Proposal : Implementation of STAR and Binary Feature Detectors and Descriptors In-Reply-To: References: <334fc123-39c7-4fe2-a0ef-f2f1f62440b6@googlegroups.com> <750d5640-a961-4725-9633-cfa6867ba3ce@googlegroups.com> <9c41da96-0262-4522-86b8-32bee64500cb@googlegroups.com> Message-ID: Hi Stefan, On Thursday, May 2, 2013 2:15:11 PM UTC+5:30, Stefan van der Walt wrote: > > Looks like BRIEF, Star, ORB, FREAK then... > I will start making the corresponding changes in my proposal. Thank you. Regards, Ankit Agrawal, Communication and Signal Processing, IIT Bombay. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Wed May 1 20:45:54 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 2 May 2013 02:45:54 +0200 Subject: GSoC 2013 Proposal : Implementation of STAR and Binary Feature Detectors and Descriptors In-Reply-To: <750d5640-a961-4725-9633-cfa6867ba3ce@googlegroups.com> References: <334fc123-39c7-4fe2-a0ef-f2f1f62440b6@googlegroups.com> <750d5640-a961-4725-9633-cfa6867ba3ce@googlegroups.com> Message-ID: On Thu, May 2, 2013 at 2:38 AM, Ankit Agrawal wrote: > Can you point me to that code? Thanks. I see Rosten himself now has NumPy code available: http://www.edwardrosten.com/work/fast.html St?fan From stefan at sun.ac.za Wed May 1 21:06:33 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 2 May 2013 03:06:33 +0200 Subject: GSoC 2013 Proposal : Implementation of STAR and Binary Feature Detectors and Descriptors In-Reply-To: References: <334fc123-39c7-4fe2-a0ef-f2f1f62440b6@googlegroups.com> <750d5640-a961-4725-9633-cfa6867ba3ce@googlegroups.com> Message-ID: On Thu, May 2, 2013 at 3:04 AM, Tony Yu wrote: > I'm not sure I'd call that NumPy code. I think the code is auto generated. > My guess is that it would be simpler to start fresh. It's also pretty easy to wrap his C code (as done here: https://github.com/stefanv/supreme/tree/master/supreme/lib/fast) but maybe implementing from scratch is best. St?fan From stefan at sun.ac.za Wed May 1 21:39:55 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 2 May 2013 03:39:55 +0200 Subject: GSoC 2013 Proposal : Implementation of STAR and Binary Feature Detectors and Descriptors In-Reply-To: <9c41da96-0262-4522-86b8-32bee64500cb@googlegroups.com> References: <334fc123-39c7-4fe2-a0ef-f2f1f62440b6@googlegroups.com> <750d5640-a961-4725-9633-cfa6867ba3ce@googlegroups.com> <9c41da96-0262-4522-86b8-32bee64500cb@googlegroups.com> Message-ID: Hi Ankit On Thu, May 2, 2013 at 3:16 AM, Ankit Agrawal wrote: > @Stefan and Tony : Did you get a chance to go over my proposal, especially > the implementation timeline? I think that implementing FAST instead of BRISK > during the summer would make the timeline schedule better. I will implement > the BRISK after the Summer of Code. Your thoughts on this? The proposal looks good; I think we'll have a better idea of a realistic timeline once we start coding, but that seems like a reasonable estimate. I think it would be helpful if you could Google for some of the recent papers that compared many of these binary features, to see which work best, and then motivate which should be implemented first. Regards St?fan From aaaagrawal at gmail.com Thu May 2 11:29:31 2013 From: aaaagrawal at gmail.com (Ankit Agrawal) Date: Thu, 2 May 2013 08:29:31 -0700 (PDT) Subject: GSoC 2013 Proposal : Implementation of STAR and Binary Feature Detectors and Descriptors In-Reply-To: References: <334fc123-39c7-4fe2-a0ef-f2f1f62440b6@googlegroups.com> <750d5640-a961-4725-9633-cfa6867ba3ce@googlegroups.com> <9c41da96-0262-4522-86b8-32bee64500cb@googlegroups.com> Message-ID: <9fc4196d-87f7-43cb-b555-bf9567263b2c@googlegroups.com> Hi everyone, I have made the modifications based on the above discussion in my proposal. Please review it and share your comments/suggestions. Thanks. Regards, Ankit Agrawal, Communication and Signal Processing, IIT Bombay. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaaagrawal at gmail.com Thu May 2 13:04:29 2013 From: aaaagrawal at gmail.com (Ankit Agrawal) Date: Thu, 2 May 2013 10:04:29 -0700 (PDT) Subject: GSoC 2013 Proposal : Implementation of STAR and Binary Feature Detectors and Descriptors In-Reply-To: References: <334fc123-39c7-4fe2-a0ef-f2f1f62440b6@googlegroups.com> <750d5640-a961-4725-9633-cfa6867ba3ce@googlegroups.com> <9c41da96-0262-4522-86b8-32bee64500cb@googlegroups.com> <9fc4196d-87f7-43cb-b555-bf9567263b2c@googlegroups.com> Message-ID: Hi Johannes, Thanks a lot for your encouragement. I have also updated the proposalon gsoc-melange site. I have included a link to my github proposal page in additional info box as the github markup is better than that on melange site. Also any changes regarding Implementation Details can be made and reviewed after the deadline on the github proposal page. Thanks again. Regards, Ankit Agrawal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Thu May 2 04:45:11 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 2 May 2013 10:45:11 +0200 Subject: GSoC 2013 Proposal : Implementation of STAR and Binary Feature Detectors and Descriptors In-Reply-To: References: <334fc123-39c7-4fe2-a0ef-f2f1f62440b6@googlegroups.com> <750d5640-a961-4725-9633-cfa6867ba3ce@googlegroups.com> <9c41da96-0262-4522-86b8-32bee64500cb@googlegroups.com> Message-ID: Looks like BRIEF, Star, ORB, FREAK then... -------------- next part -------------- An HTML attachment was scrubbed... URL: From chintaksheth at gmail.com Thu May 2 05:30:43 2013 From: chintaksheth at gmail.com (Chintak Sheth) Date: Thu, 2 May 2013 15:00:43 +0530 Subject: GSoC 2013 Final idea - Inpainting Message-ID: Hi, After quite a bit of thought, I've decided to go ahead with Image inpainting (thanks Tony for suggesting this idea!) as my GSoC project. I'll keep Active contours for after GSoC if it yet remains undone. I've incorporated some changes as pointed out by Stefan and an additional reference by Tony (thanks both of you'll!). I've put up the proposal on google-melange site. Kindly let me know if there are any changes necessary or anything I'm missing out on. scikit-image: Image Inpainting for Restoration Thanks, Chintak -------------- next part -------------- An HTML attachment was scrubbed... URL: From f-morozov at ya.ru Thu May 2 19:32:52 2013 From: f-morozov at ya.ru (Fedor Morozov) Date: Thu, 2 May 2013 16:32:52 -0700 (PDT) Subject: GSoC: Photomontage and Panoram Stitching In-Reply-To: References: Message-ID: <6e8efca6-5512-4af9-a447-0fee8676a32f@googlegroups.com> Hi. Here is the proposal: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/fm/10001 ???????, 30 ?????? 2013 ?., 2:54:43 UTC+4 ???????????? Fedor Morozov ???????: > > Hello. > My name is Fedor Morozov and I am a 2nd year computer science student in > Moscow State University. > > A few words about me: > I specialize in computer vision and my recent projects include various > vision tasks: car numbers recognition, > road signs classification and some small tasks to get a hands-on > experience with different techniques like SIFT, Hough transform etc. > Last year I successfully participated in GSoC with an HDR imaging project, > recently I've been working on implementing some HDR > algorithms on GPU for Photorealistic Rendering course. > > I usually use Matlab and C++ for imaging tasks, mostly because I am used > to them and it is stated in the task. > Nevertheless, I often use Python for scripting tasks, programming contests > and children education, > and it would be great for vision applications. > > About the project: > There are some very interesting ideas in the proposed list, but most of > them are not big enough for gsoc. > Since I believe that a project should be solid and complete, I would like > to add some of these tools to > scikit-image and combine them to an image stitching framework, that can > serve as the main project goal, > useful application and a showcase for the implemented features. > > Let us assume that there is a set of images, that we want to combine into > a panorama. > First, we should extract local features (using STAR or other detector) and > use them to properly place the images > by estimating the transform model using methods like RANSAC or by using > pyimreg. > Then, graph-cut can be used to choose, where to cut, and the images can be > finally blended, > using simple laplacian pyramid approach or gradien domain fusion, that is > akin to one of the coolest > high dynamic range reduction algorithms. > > This pipeline requires feature detection, image registration and graph-cut > support. > > What do you think about such project? I guess, it's rather ambitious, yet > it is diverse, interesting > and will keep me from slacking. If some of the mentioned ideas get > separate projects, they can be > adopted during summer. > > I am sorry for writing so late, there were a few deadlines recently and I > couldn't find courage to write a proposal. > Qualification pull request is coming soon. > > Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschoenberger at demuc.de Thu May 2 12:44:51 2013 From: jschoenberger at demuc.de (=?iso-8859-1?Q?Johannes_Sch=F6nberger?=) Date: Thu, 2 May 2013 18:44:51 +0200 Subject: GSoC 2013 Proposal : Implementation of STAR and Binary Feature Detectors and Descriptors In-Reply-To: <9fc4196d-87f7-43cb-b555-bf9567263b2c@googlegroups.com> References: <334fc123-39c7-4fe2-a0ef-f2f1f62440b6@googlegroups.com> <750d5640-a961-4725-9633-cfa6867ba3ce@googlegroups.com> <9c41da96-0262-4522-86b8-32bee64500cb@googlegroups.com> <9fc4196d-87f7-43cb-b555-bf9567263b2c@googlegroups.com> Message-ID: Your proposal looks very good to me so far! Johannes Sch?nberger Am 02.05.2013 um 17:29 schrieb Ankit Agrawal : > Hi everyone, > > I have made the modifications based on the above discussion in my proposal. Please review it and share your comments/suggestions. Thanks. > > Regards, > Ankit Agrawal, > Communication and Signal Processing, > IIT Bombay. > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > From aaaagrawal at gmail.com Fri May 3 00:04:15 2013 From: aaaagrawal at gmail.com (Ankit Agrawal) Date: Thu, 2 May 2013 21:04:15 -0700 (PDT) Subject: GSoC: Photomontage and Panoram Stitching In-Reply-To: <6e8efca6-5512-4af9-a447-0fee8676a32f@googlegroups.com> References: <6e8efca6-5512-4af9-a447-0fee8676a32f@googlegroups.com> Message-ID: <82502ecf-f9fc-44ae-8854-4cf63f897eb0@googlegroups.com> Hi Fedor, I plan to implement the STAR feature descriptor as mentioned in my proposal. Instead, it would be great if you could implement FASTcorner detector, which I could not cover in my proposal. Also, including a reference section in your proposal would be great and make it better for other community members to review it. I would also like to know how you intend to implement photo-stitching. Some of the references you can refer to for Photo-stitching : CV by Szeliski, Chap 6, Feature based Alignment and this paper Automatic Panoramic Image Stitching using Invariant Features. The paper makes use of SIFT, which is patented as informed by Stefan and hence you might need to look for an alternate Invariant feature descriptor. Thank you. Regards, Ankit Agrawal, Communication and Signal Processing, IIT Bombay. -------------- next part -------------- An HTML attachment was scrubbed... URL: From deklerkmc at gmail.com Sat May 4 02:07:21 2013 From: deklerkmc at gmail.com (Marc de Klerk) Date: Fri, 3 May 2013 23:07:21 -0700 (PDT) Subject: GSoC Proposal Message-ID: <0f98605a-8ab3-4b0a-b1d7-376cc53ad807@googlegroups.com> Hello Everyone, I just wanted to post my proposal for the GSoC: https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/deklerkmc/1 I hope it sparks a bit of interest :) Looking forward to hearing any feedback... Cheers Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From almar.klein at gmail.com Sat May 4 19:56:54 2013 From: almar.klein at gmail.com (Almar Klein) Date: Sun, 5 May 2013 01:56:54 +0200 Subject: imageio progress In-Reply-To: References: Message-ID: I just moved imageio to github. Anyone who has an interest in collaborating in this project, please let me know so I can give you write access. - Almar On 27 April 2013 23:10, Almar Klein wrote: > > Is there a way to add plugins by simply "dumping" plugin files into >> place? This was part of the thinking when we designed the skimage.io >> plugin infrastructure (so it would be easy for, e.g., Debian to add >> new formats by simply unpacking into the right location). >> >> I am not entirely happy with the complexity of the io module in >> skimage, and would love to hear ideas about how it can be simplified, >> perhaps integrating with imageio. >> > > The way in which this is currently implemented in imagio is that each > plugin module implements a Format class (with associated Reader and Writer > classes), and registers an instance of this Format class with the imagio > format manager: > > format = FormatDefinedInThisModule('dummy', 'An example format that > does nothing.') > imageio.formats.add_format(format) > > For a more complete example see plugins/example.py. > In effect, plugins can be defines anywhere, also in 3d party packages. The > plugins/__init__.py simply imports has one line of code per plugin to > import it. > > You/we could extend it and make plugins/__init__.py search the whole > directory and import all found modules. I've done similar things in visvis, > but in retrospect I prefer explicitly importing the modules (also less > trouble with e.g. freezing). But perhaps the use case that you described > justifies such an approach. > > > Adding new formats is then a matter of dumping in a file containing read() >> and write() functions, and importing that in the __init__.py file. This >> results in very clean syntax: > > > Imagio currently does something similar. A plugin (or format as its called > in imageio) must implement three classes: Format to describe meta > information about the format (name, short description and docs), as well as > functionality to determine whether a given file(name) can be read/written > by the format or not. Reader and Writer are overloaded classes used to read > and write image data. They should implement a specific set of methods, but > may also implement additional methods in cases it makes sense to complement > the default interface. > > When the user tries to read an image (e.g. using imageio.imread()) the > format manager picks the first format that says it can read the data, and > uses an instance of its Reader class to do the reading. Alternatively > imagio.read() gives the user an instance of the Reader class for more > control. If the user wants to use a specific format he/she can use > imageio.imread(filename, format=X), where X can be the name of a format, > its extension, or a Format instance. > > > ... perhaps integrating with imageio. > > > I took imageio out of skimage because I think that reading/saving images > is useful to many people that do not necessarily need skimage. But I was > indeed hoping for some form of integration with skimage. > > Also, I'm hoping that imageio can be a place to place functionality for > reading specific formats (such as TIFF or .mhd (ITK)). An environment such > as github should make it fairly easy for multiple people to maintain their > own plugin in a collaborative repository. > > - Almar > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Sun May 5 15:57:41 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 5 May 2013 21:57:41 +0200 Subject: imageio progress In-Reply-To: References: Message-ID: On Sun, May 5, 2013 at 1:56 AM, Almar Klein wrote: > I just moved imageio to github. Anyone who has an interest in collaborating > in this project, please let me know so I can give you write access. I can highly recommend working via pull requests. This has made such a big difference to the skimage development process, that I can't even imagine developing without it now. St?fan From tsyu80 at gmail.com Mon May 6 01:06:14 2013 From: tsyu80 at gmail.com (Tony Yu) Date: Mon, 6 May 2013 00:06:14 -0500 Subject: Robert's Edge Detection. Part of [GsoC13] In-Reply-To: References: <6de2943b-e2c5-4896-8291-df7af8a07431@googlegroups.com> Message-ID: On Thu, Apr 25, 2013 at 8:14 AM, Umesh Sharma wrote: > Thanks Tony , > I have removed that part from my commit , > now the latest commit contains the robert's edge detector .... > Hi Umesh, Thanks again for the PR. I just wanted to clarify that I was suggesting that the Frei-Chen functions be moved to a new PR---not removed completely. That said, it would probably be best to wait until some upcoming changes to the edge filters are merged, so there aren't too many merge conflicts. I'm thinking specifically of this PR: https://github.com/scikit-image/scikit-image/pull/536 Best, -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From jni.soma at gmail.com Wed May 8 22:59:45 2013 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Thu, 9 May 2013 12:59:45 +1000 Subject: skimage.filter.rank.percentile usage question Message-ID: Hey guys, I'm wanting to use the rank filter module in skimage, but I'm not sure about the usage of percentile(). My intuition of how a percentile filter should work is: for each pixel: grab all the values in the structuring element centred at that pixel sort them find the requested percentile; interpolate if necessary replace pixel with that value However, the function doesn't require one percentile but two, p0 and p1. The docstring says "Only levels between percentiles [p0, p1] are used", but I don't understand what this means. What if three different values fall between p0 and p1? What if no values fall between them? -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvertrumpet999 at gmail.com Thu May 9 19:24:50 2013 From: silvertrumpet999 at gmail.com (Josh Warner) Date: Thu, 9 May 2013 16:24:50 -0700 (PDT) Subject: skimage.filter.rank.percentile usage question In-Reply-To: References: Message-ID: <475e6470-ef06-4a24-b224-84d63dd82d21@googlegroups.com> Looks like the relevant _crank8 function for filter.rank.percentile doesn't use p1 at all. cdef inline dtype_t kernel_percentile(Py_ssize_t * histo, float pop, dtype_t g, float p0, float p1, Py_ssize_t s0, Py_ssize_t s1): cdef int i cdef float sum = 0. if pop: for i in range(256): sum += histo[i] if sum >= p0 * pop: break return (i) else: return (0) That said, some of the other `percentile_*` functions do in fact use both `p0` and `p1`. At minimum, there is room for docstring clarification here. On Wednesday, May 8, 2013 9:59:45 PM UTC-5, Juan Nunez-Iglesias wrote: Hey guys, > > I'm wanting to use the rank filter module in skimage, but I'm not sure > about the usage of percentile(). My intuition of how a percentile filter > should work is: > > for each pixel: > grab all the values in the structuring element centred at that pixel > sort them > find the requested percentile; interpolate if necessary > replace pixel with that value > > However, the function doesn't require one percentile but two, p0 and p1. > The docstring says "Only levels between percentiles [p0, p1] are used", but > I don't understand what this means. What if three different values fall > between p0 and p1? What if no values fall between them? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jni.soma at gmail.com Fri May 10 01:41:11 2013 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Fri, 10 May 2013 15:41:11 +1000 Subject: skimage.filter.rank.percentile usage question In-Reply-To: <475e6470-ef06-4a24-b224-84d63dd82d21@googlegroups.com> References: <475e6470-ef06-4a24-b224-84d63dd82d21@googlegroups.com> Message-ID: On Fri, May 10, 2013 at 9:24 AM, Josh Warner wrote: > At minimum, there is room for docstring clarification here. > "At a minimum" is right! =) Thanks for the code-digging! -------------- next part -------------- An HTML attachment was scrubbed... URL: From f-morozov at ya.ru Sat May 11 20:45:44 2013 From: f-morozov at ya.ru (Fedor Morozov) Date: Sat, 11 May 2013 17:45:44 -0700 (PDT) Subject: GSoC: Photomontage and Panoram Stitching In-Reply-To: <82502ecf-f9fc-44ae-8854-4cf63f897eb0@googlegroups.com> References: <6e8efca6-5512-4af9-a447-0fee8676a32f@googlegroups.com> <82502ecf-f9fc-44ae-8854-4cf63f897eb0@googlegroups.com> Message-ID: In case there already is a descriptor when I need it, I might spend more time on other parts of the framework. Anyway, I'll look into FAST and will try to work on it if time allows. Thanks for the advice about references, I thought them unnecessary since most of the mentioned algorithms speak for themselves, but I think I will add a list of articles soon. I had a very bad or no internet connection recently, so there was some mess instead of the message and I didn't notice it. I'll make the article list tomorrow. ???????, 3 ??? 2013 ?., 8:04:15 UTC+4 ???????????? Ankit Agrawal ???????: > > Hi Fedor, > > I plan to implement the STAR feature descriptor as mentioned in > my proposal. Instead, it would be great if you could implement FASTcorner detector, which I could not cover in my proposal. Also, including a > reference section in your proposal would be great and make it better for > other community members to review it. I would also like to know how you > intend to implement photo-stitching. Some of the references you can refer > to for Photo-stitching : CV by Szeliski, Chap 6, Feature based Alignment and > this paper Automatic Panoramic Image Stitching using Invariant Features. > The paper makes use of SIFT, which is patented as informed by Stefan and > hence you might need to look for an alternate Invariant feature descriptor. > Thank you. > > Regards, > Ankit Agrawal, > Communication and Signal Processing, > IIT Bombay. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaaagrawal at gmail.com Mon May 13 16:39:31 2013 From: aaaagrawal at gmail.com (Ankit Agrawal) Date: Mon, 13 May 2013 13:39:31 -0700 (PDT) Subject: Some ideas for skimage Message-ID: Hi everyone, I have a few ideas that could be incorporated in scikit-image and would like your opinions on them. 1] Examples in docstring for every api function : Sympy's documentation seems very comprehensive as all the api-functions have atleast one example in the doc. By examples in skimage, I mean the commands operated on standard images(lena, camera or a particular ndarray that can explain the functionality better) which a user can try out himself in his own shell. 2] Code quality/PEP8 checks in Travis tests : This could reduce the energy spent on discussing code quality errors while reviewing pull requests made by new contributors and concentrate more on other aspects of the code. 3] IRC channel #skimage : For some kind of queries/discussions, IRC channel proves more useful and provides a fluid connectivity between the community members. All the conversations can be logged so that they can be referenced in the mailing list or github if needed. I would also like you to review/answer my unanswered queries in these PRs. Thank you. Regards, Ankit Agrawal, Communication and Signal Processing, IIT Bombay. -------------- next part -------------- An HTML attachment was scrubbed... URL: From f-morozov at ya.ru Mon May 13 17:10:30 2013 From: f-morozov at ya.ru (Fedor Morozov) Date: Mon, 13 May 2013 14:10:30 -0700 (PDT) Subject: Some ideas for skimage In-Reply-To: References: Message-ID: The second one would be great. ???????, 14 ??? 2013 ?., 0:39:31 UTC+4 ???????????? Ankit Agrawal ???????: > > Hi everyone, > > I have a few ideas that could be incorporated in scikit-image and > would like your opinions on them. > > 1] Examples in docstring for every api function : Sympy's documentation > seems very comprehensive as all the api-functions have atleast one example > in the doc. By examples in skimage, I mean the commands operated on > standard images(lena, camera or a particular ndarray that can explain the > functionality better) which a user can try out himself in his own shell. > > 2] Code quality/PEP8 checks in Travis tests : This could reduce the energy > spent on discussing code quality errors while reviewing pull requests made > by new contributors and concentrate more on other aspects of the code. > > 3] IRC channel #skimage : For some kind of queries/discussions, IRC > channel proves more useful and provides a fluid connectivity between the > community members. All the conversations can be logged so that they can be > referenced in the mailing list or github if needed. > > I would also like you to review/answer my unanswered queries in these PRs. > Thank you. > > Regards, > Ankit Agrawal, > Communication and Signal Processing, > IIT Bombay. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Thu May 16 11:22:54 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 16 May 2013 17:22:54 +0200 Subject: Some ideas for skimage In-Reply-To: References: Message-ID: Hi Ankit On Mon, May 13, 2013 at 10:39 PM, Ankit Agrawal wrote: > 1] Examples in docstring for every api function : Sympy's documentation > seems very comprehensive as all the api-functions have atleast one example > in the doc. By examples in skimage, I mean the commands operated on standard > images(lena, camera or a particular ndarray that can explain the > functionality better) which a user can try out himself in his own shell. We'd love to have more examples, but we should first update our test machinery (specifically .travis.yml, make test) to run those as well. > 2] Code quality/PEP8 checks in Travis tests : This could reduce the energy > spent on discussing code quality errors while reviewing pull requests made > by new contributors and concentrate more on other aspects of the code. +1! > 3] IRC channel #skimage : For some kind of queries/discussions, IRC channel > proves more useful and provides a fluid connectivity between the community > members. All the conversations can be logged so that they can be referenced > in the mailing list or github if needed. I don't mind an IRC channel, but I don't really use that mode of communication often. How about the others? St?fan From silvertrumpet999 at gmail.com Thu May 16 21:42:08 2013 From: silvertrumpet999 at gmail.com (Josh Warner) Date: Thu, 16 May 2013 18:42:08 -0700 (PDT) Subject: Some ideas for skimage In-Reply-To: References: Message-ID: <77472ff4-84f1-445e-8db1-12444b9d88bd@googlegroups.com> More examples - and validated examples - would be excellent! I'll take the opposite position for purposes of debate on PEP8 in Travis. I'm reluctant to include this for a few reasons that really boil down to "the standard itself says to ignore the standard if it's more readable to ignore the standard." All of the checkers are relatively stupid, so no reasonable/readable exceptions will pass. Also, when the rubber meets the road the purpose of Travis is to tell us *if it works or if something broke*, not piddle around with style. I want to know if it works, not dig around in a multi-thousand-line Travis log to determine if style was off or - maybe - I have a real problem. Lastly, there are a significant amount of PEP8 exceptions in the repo right now, so getting this working even at baseline would involve significant (IMO, not very productive) effort. With practice and a decent editor it's fairly easy to write PEP8 compliant code from the start. For new submitters this can seem a bit pedantic, but treat it more of a learning experience rather than criticism. I very rarely use IRC. Even if we had a channel, I'd be infinitely more responsive via email / GitHub discussions. Josh On Thursday, May 16, 2013 10:22:54 AM UTC-5, Stefan van der Walt wrote: > > Hi Ankit > > On Mon, May 13, 2013 at 10:39 PM, Ankit Agrawal > > wrote: > > 1] Examples in docstring for every api function : Sympy's documentation > > seems very comprehensive as all the api-functions have atleast one > example > > in the doc. By examples in skimage, I mean the commands operated on > standard > > images(lena, camera or a particular ndarray that can explain the > > functionality better) which a user can try out himself in his own shell. > > We'd love to have more examples, but we should first update our test > machinery (specifically .travis.yml, make test) to run those as well. > > > 2] Code quality/PEP8 checks in Travis tests : This could reduce the > energy > > spent on discussing code quality errors while reviewing pull requests > made > > by new contributors and concentrate more on other aspects of the code. > > +1! > > > 3] IRC channel #skimage : For some kind of queries/discussions, IRC > channel > > proves more useful and provides a fluid connectivity between the > community > > members. All the conversations can be logged so that they can be > referenced > > in the mailing list or github if needed. > > I don't mind an IRC channel, but I don't really use that mode of > communication often. How about the others? > > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Fri May 17 03:29:48 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 17 May 2013 09:29:48 +0200 Subject: Some ideas for skimage In-Reply-To: <77472ff4-84f1-445e-8db1-12444b9d88bd@googlegroups.com> References: <77472ff4-84f1-445e-8db1-12444b9d88bd@googlegroups.com> Message-ID: On Fri, May 17, 2013 at 3:42 AM, Josh Warner wrote: > I'll take the opposite position for purposes of debate on PEP8 in Travis. How about only including it as part of the Travis build report (but not failing)? St?fan From nelle.varoquaux at gmail.com Fri May 17 03:42:43 2013 From: nelle.varoquaux at gmail.com (Nelle Varoquaux) Date: Fri, 17 May 2013 09:42:43 +0200 Subject: Some ideas for skimage In-Reply-To: References: <77472ff4-84f1-445e-8db1-12444b9d88bd@googlegroups.com> Message-ID: On 17 May 2013 09:29, St?fan van der Walt wrote: > On Fri, May 17, 2013 at 3:42 AM, Josh Warner > wrote: > > I'll take the opposite position for purposes of debate on PEP8 in Travis. > > How about only including it as part of the Travis build report (but > not failing)? > We do this on sklearn with ShiningPanda: it means we can see regressions in pep8 compliance code. That also means you need someone to regularly check ShiningPanda. Cheers, N > > St?fan > > -- > You received this message because you are subscribed to the Google Groups > "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronnie.ghose at gmail.com Fri May 17 09:58:38 2013 From: ronnie.ghose at gmail.com (Ronnie Ghose) Date: Fri, 17 May 2013 09:58:38 -0400 Subject: numexpr In-Reply-To: <9DA42682-B478-40F2-AE16-7E35FD6696F5@demuc.de> References: <9DA42682-B478-40F2-AE16-7E35FD6696F5@demuc.de> Message-ID: hmm +1. use it only for matrix ops as a numpy extension? On Fri, May 17, 2013 at 9:56 AM, Johannes Sch?nberger < jschoenberger at demuc.de> wrote: > Hi everyone, > > I have just come to know the 'numexpr' package and could speed up some of > my personnel projects relatively easy. > > I think, this could also improve performance of some functions in skimage. > What's your opinion on adding this as a new dependency? > > Regards, > > Johannes Sch?nberger > > -- > You received this message because you are subscribed to the Google Groups > "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschoenberger at demuc.de Fri May 17 04:05:07 2013 From: jschoenberger at demuc.de (=?windows-1252?Q?Johannes_Sch=F6nberger?=) Date: Fri, 17 May 2013 10:05:07 +0200 Subject: Some ideas for skimage In-Reply-To: References: <77472ff4-84f1-445e-8db1-12444b9d88bd@googlegroups.com> Message-ID: +1 on including it as a build report, but please at the end of the build process. In case we agree to add this feature, it's probably best if I include it as part of this PR: https://github.com/scikit-image/scikit-image/pull/538 ? this actually shouldn't be more than 2 extra lines? any preferences regarding the style guide checker (pep8.py, pyflakes, ?)? Johannes Sch?nberger Am 17.05.2013 um 09:53 schrieb Ankit Agrawal : > @Josh : I agree that most of PEP8 tests are flexible in order to give priority to readability. Perhaps, I was thinking to have tests for style-guidelines that are rigid, for eg : trailing whitespaces, spaces around '/', '*' etc, file ending with a newline etc. > > How about only including it as part of the Travis build report (but > not failing)? > > @Stefan : This seems a good middle way. > > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > From stefan at sun.ac.za Fri May 17 04:26:20 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 17 May 2013 10:26:20 +0200 Subject: Some ideas for skimage In-Reply-To: References: <77472ff4-84f1-445e-8db1-12444b9d88bd@googlegroups.com> Message-ID: On Fri, May 17, 2013 at 10:05 AM, Johannes Sch?nberger wrote: > In case we agree to add this feature, it's probably best if I include it as part of this PR: https://github.com/scikit-image/scikit-image/pull/538 ? this actually shouldn't be more than 2 extra lines? any preferences regarding the style guide checker (pep8.py, pyflakes, ?)? That'd be great. Both of those, please! pyflakes $1 echo "## pyflakes above, pep8 below ##" pep8 --repeat $1 St?fan From tsyu80 at gmail.com Fri May 17 13:25:18 2013 From: tsyu80 at gmail.com (Tony Yu) Date: Fri, 17 May 2013 12:25:18 -0500 Subject: Converting a numpy array to grayscale In-Reply-To: <519665AF.6030307@gmail.com> References: <519665AF.6030307@gmail.com> Message-ID: On Fri, May 17, 2013 at 12:15 PM, Brickle Macho wrote: > I porting a 8 line Matlab script. > > So what is the difference between converting an array to gray scale verse > reading it in as grayscale? Have I done something wrong? Is there another > way to convert a numpy array to grayscale? > > Any help appreciated. > > Michael. > -- > Hi Michael, They're just different color conversion factors. Based on http://www.mathworks.com/help/images/ref/rgb2gray.html, Matlab uses: 0.2989 R + 0.5870 G + 0.1140 B Based on the docstring for `color.rgb2gray`: 0.2125 R + 0.7154 G + 0.0721 B Wikipedia (http://en.wikipedia.org/wiki/Grayscale) seems to suggest that Matlab's is an older standard while the one in scikit-image is a more recent spec. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschoenberger at demuc.de Fri May 17 09:56:06 2013 From: jschoenberger at demuc.de (=?utf-8?B?Sm9oYW5uZXMgU2Now7ZuYmVyZ2Vy?=) Date: Fri, 17 May 2013 13:56:06 +0000 Subject: numexpr Message-ID: <9DA42682-B478-40F2-AE16-7E35FD6696F5@demuc.de> Hi everyone, I have just come to know the 'numexpr' package and could speed up some of my personnel projects relatively easy. I think, this could also improve performance of some functions in skimage. What's your opinion on adding this as a new dependency? Regards, Johannes Sch?nberger From aaaagrawal at gmail.com Fri May 17 03:53:48 2013 From: aaaagrawal at gmail.com (Ankit Agrawal) Date: Fri, 17 May 2013 15:53:48 +0800 Subject: Some ideas for skimage In-Reply-To: References: <77472ff4-84f1-445e-8db1-12444b9d88bd@googlegroups.com> Message-ID: @Josh : I agree that most of PEP8 tests are flexible in order to give priority to readability. Perhaps, I was thinking to have tests for style-guidelines that are rigid, for eg : trailing whitespaces, spaces around '/', '*' etc, file ending with a newline etc. How about only including it as part of the Travis build report (but > not failing)? @Stefan : This seems a good middle way. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschoenberger at demuc.de Fri May 17 13:19:04 2013 From: jschoenberger at demuc.de (=?iso-8859-1?Q?Johannes_Sch=F6nberger?=) Date: Fri, 17 May 2013 19:19:04 +0200 Subject: Converting a numpy array to grayscale In-Reply-To: <519665AF.6030307@gmail.com> References: <519665AF.6030307@gmail.com> Message-ID: <3B43D21B-97A3-406B-BCDA-8C59CDBE517C@demuc.de> Hi, Could you provide us with both the grayscale and RGB version of your image? Johannes Sch?nberger Am 17.05.2013 um 19:15 schrieb Brickle Macho : > I porting a 8 line Matlab script. Basically I read in am image, down sample the image, perform some FFT operations and output a final smoothed image. I am porting this to a standalone function. The problem is that I am getting different from my python script to what Matlab was outputs > > After comparing the contents of the array/matrix in python/matlab I noticed the values were different after the image was converted to grayscale. That is, when the image is read in, the values are the same, once converted they begin to differ around the first/second decimal place. > > If I read in the file using ndimage.imread( flatten=true) then I get the same value as matlab correct to 5 decimal places, whereas using color.rgb2gray() is only correct to 2 decimal places. In the final version of the code I will only have access to the numpy array after it has been loaded into memory, so using imread() was just for tracing/locating/identifying the problem. Here is a snippet of code: > > >>> gray = ndimage.imread('1.jpg',flatten=True) > >>> gray /= gray.max() > >>> gray > array([[ 0.30133331, 0.2895686 , 0.28172547, ... > ... > > >>> gray2 = color.rgb2gray(rgb) > >>> gray2 > array([[ 0.31065608, 0.29889137, 0.29104824, ..., > ... > > I believe this difference is causing the problem. Note if I convert the image to grayscale using a external tool and read this in then the values of the numpy array match similar/same to Matlab matrix. > > So what is the difference between converting an array to gray scale verse reading it in as grayscale? Have I done something wrong? Is there another way to convert a numpy array to grayscale? > > Any help appreciated. > > Michael. > -- > > > > > > > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > From bricklemacho at gmail.com Fri May 17 13:15:27 2013 From: bricklemacho at gmail.com (Brickle Macho) Date: Sat, 18 May 2013 01:15:27 +0800 Subject: Converting a numpy array to grayscale Message-ID: <519665AF.6030307@gmail.com> I porting a 8 line Matlab script. Basically I read in am image, down sample the image, perform some FFT operations and output a final smoothed image. I am porting this to a standalone function. The problem is that I am getting different from my python script to what Matlab was outputs After comparing the contents of the array/matrix in python/matlab I noticed the values were different after the image was converted to grayscale. That is, when the image is read in, the values are the same, once converted they begin to differ around the first/second decimal place. If I read in the file using ndimage.imread( flatten=true) then I get the same value as matlab correct to 5 decimal places, whereas using color.rgb2gray() is only correct to 2 decimal places. In the final version of the code I will only have access to the numpy array after it has been loaded into memory, so using imread() was just for tracing/locating/identifying the problem. Here is a snippet of code: >>> gray = ndimage.imread('1.jpg',flatten=True) >>> gray /= gray.max() >>> gray array([[ 0.30133331, 0.2895686 , 0.28172547, ... ... >>> gray2 = color.rgb2gray(rgb) >>> gray2 array([[ 0.31065608, 0.29889137, 0.29104824, ..., ... I believe this difference is causing the problem. Note if I convert the image to grayscale using a external tool and read this in then the values of the numpy array match similar/same to Matlab matrix. So what is the difference between converting an array to gray scale verse reading it in as grayscale? Have I done something wrong? Is there another way to convert a numpy array to grayscale? Any help appreciated. Michael. -- From bricklemacho at gmail.com Fri May 17 13:54:25 2013 From: bricklemacho at gmail.com (Brickle Macho) Date: Sat, 18 May 2013 01:54:25 +0800 Subject: Converting a numpy array to grayscale In-Reply-To: <3B43D21B-97A3-406B-BCDA-8C59CDBE517C@demuc.de> References: <519665AF.6030307@gmail.com> <3B43D21B-97A3-406B-BCDA-8C59CDBE517C@demuc.de> Message-ID: <51966ED1.1050908@gmail.com> On 18/05/13 1:19 AM, Johannes Sch??????nberger wrote: > Hi, > > Could you provide us with both the grayscale and RGB version of your image? Sure. Here is a link to the images: [1] http://i.imgur.com/jxBoL93.jpg [2] http://i.imgur.com/q5jFcgL.jpg Regards, Michel. -- From bricklemacho at gmail.com Fri May 17 13:56:04 2013 From: bricklemacho at gmail.com (Brickle Macho) Date: Sat, 18 May 2013 01:56:04 +0800 Subject: Converting a numpy array to grayscale In-Reply-To: References: <519665AF.6030307@gmail.com> Message-ID: <51966F34.8070801@gmail.com> Hi tony, Thanks. I suspect then that ndimage.imread(, flatten=True) is using the older standard, hence why the image values appeared the same. For testing purposes, I will use Matlab's conversion factor to see if I get the same output as the paper. Once I am happy it is the same, then I will go back to using color.rgb2gray. Thanks for your help. Michael. -- On 18/05/13 1:25 AM, Tony Yu wrote: > > > > On Fri, May 17, 2013 at 12:15 PM, Brickle Macho > > wrote: > > I porting a 8 line Matlab script. > > > > > > So what is the difference between converting an array to gray > scale verse reading it in as grayscale? Have I done something > wrong? Is there another way to convert a numpy array to grayscale? > > Any help appreciated. > > Michael. > -- > > Hi Michael, > > They're just different color conversion factors. Based on > http://www.mathworks.com/help/images/ref/rgb2gray.html, Matlab uses: > 0.2989 R + 0.5870 G + 0.1140 B > > Based on the docstring for `color.rgb2gray`: > 0.2125 R + 0.7154 G + 0.0721 B > > Wikipedia (http://en.wikipedia.org/wiki/Grayscale) seems to suggest > that Matlab's is an older standard while the one in scikit-image is a > more recent spec. > > -- > You received this message because you are subscribed to the Google > Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chintaksheth at gmail.com Sat May 18 05:16:18 2013 From: chintaksheth at gmail.com (Chintak Sheth) Date: Sat, 18 May 2013 14:46:18 +0530 Subject: Convex Hull Object function Message-ID: Hi everyone, Its been a while since my last correspondence. I had my exams and then went for a small trip with family. So I was working on adding a convex_hull_object function to skimage. I had earlier written code for this, but now I've incorporated certain changes in convex_hull.py as pointed out by you'll. https://github.com/chintak/scikit-image/tree/convex_hull/skimage/morphology I am using label() to generate a mask for extracting the different connected components and then adding up all the separate convex hull's of different objects. However, I was wondering if there is a better way of combining the different hulls as opposed to just logical ADD. Any thoughts ? Chintak -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvertrumpet999 at gmail.com Sun May 19 02:39:14 2013 From: silvertrumpet999 at gmail.com (Josh Warner) Date: Sat, 18 May 2013 23:39:14 -0700 (PDT) Subject: Convex Hull Object function In-Reply-To: References: Message-ID: Hi Chintak, It appears Matlab does it your way, combining with OR (with a toggle for 4- or 8-connected neighborhood to identify connected components). I'm not convinced this is the best way, since the convex hulls of separate objects can easily overlap. This is a challenging problem. To do this truly correctly you need the ability for each voxel to belong to more than one object, or to return a separate array for each individual connected component. Either of these is possible. Bit depth is probably the limiting factor in the first case (64 or 128 unique objects max), while memory is probably going to become problematic for the second. On the other hand, we could leave it alone, accept your current implementation, and make these Matlab-like limitations clear to the user in the docstring. If they care about potential overlap, they can always use the original `convex_hull_image` repeatedly on each label. This is probably the best way forward from the perspective of user expectations. Josh On Saturday, May 18, 2013 4:16:18 AM UTC-5, Chintak Sheth wrote: > > Hi everyone, > > Its been a while since my last correspondence. I had my exams and then > went for a small trip with family. > > So I was working on adding a convex_hull_object function to skimage. I had > earlier written code for this, but now I've incorporated certain changes in > convex_hull.py as pointed out by you'll. > https://github.com/chintak/scikit-image/tree/convex_hull/skimage/morphology > > I am using label() to generate a mask for extracting the different > connected components and then adding up all the separate convex hull's of > different objects. However, I was wondering if there is a better way of > combining the different hulls as opposed to just logical ADD. > > Any thoughts ? > > Chintak > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronnie.ghose at gmail.com Sun May 19 02:23:32 2013 From: ronnie.ghose at gmail.com (Ronnie Ghose) Date: Sun, 19 May 2013 02:23:32 -0400 Subject: No subject Message-ID: the transform.resize function does not work for 1-d arrays as it expects a (#,#) instead of (#,) .. should this be changed or is this as intended? Thanks, Ronnie -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronnie.ghose at gmail.com Sun May 19 03:16:07 2013 From: ronnie.ghose at gmail.com (Ronnie Ghose) Date: Sun, 19 May 2013 03:16:07 -0400 Subject: No subject In-Reply-To: References: Message-ID: that's a possibility, let me try that :D. also props for whoever made the _geometric.py, that doesn't look fun o-o. On Sun, May 19, 2013 at 2:36 AM, Johannes Sch?nberger < jschoenberger at demuc.de> wrote: > I have only implemented it for 2D but a PR to add functionality for 1D > arrays is highly welcome ;-) > > ------------------------------ > *Von:* scikit-image at googlegroups.com [scikit-image at googlegroups.com]" im > Auftrag von "Ronnie Ghose [ronnie.ghose at gmail.com] > *Gesendet:* Sonntag, 19. Mai 2013 08:23 > *An:* scikit-image at googlegroups.com > *Betreff:* > > the transform.resize function does not work for 1-d arrays as it > expects a (#,#) instead of (#,) .. should this be changed or is this as > intended? > > Thanks, > Ronnie > > -- > You received this message because you are subscribed to the Google Groups > "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > You received this message because you are subscribed to the Google Groups > "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronnie.ghose at gmail.com Sun May 19 03:18:41 2013 From: ronnie.ghose at gmail.com (Ronnie Ghose) Date: Sun, 19 May 2013 03:18:41 -0400 Subject: No subject In-Reply-To: References: Message-ID: also what do you think about using Bento to build the files? On Sun, May 19, 2013 at 3:16 AM, Ronnie Ghose wrote: > that's a possibility, let me try that :D. also props for whoever made the > _geometric.py, that doesn't look fun o-o. > > > On Sun, May 19, 2013 at 2:36 AM, Johannes Sch?nberger < > jschoenberger at demuc.de> wrote: > >> I have only implemented it for 2D but a PR to add functionality for 1D >> arrays is highly welcome ;-) >> >> ------------------------------ >> *Von:* scikit-image at googlegroups.com [scikit-image at googlegroups.com]" im >> Auftrag von "Ronnie Ghose [ronnie.ghose at gmail.com] >> *Gesendet:* Sonntag, 19. Mai 2013 08:23 >> *An:* scikit-image at googlegroups.com >> *Betreff:* >> >> the transform.resize function does not work for 1-d arrays as it >> expects a (#,#) instead of (#,) .. should this be changed or is this as >> intended? >> >> Thanks, >> Ronnie >> >> -- >> You received this message because you are subscribed to the Google Groups >> "scikit-image" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to scikit-image+unsubscribe at googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "scikit-image" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to scikit-image+unsubscribe at googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronnie.ghose at gmail.com Sun May 19 03:34:42 2013 From: ronnie.ghose at gmail.com (Ronnie Ghose) Date: Sun, 19 May 2013 03:34:42 -0400 Subject: No subject In-Reply-To: <43A65B64-9797-4EA1-8D54-C6E022F0CF3E@demuc.de> References: <43A65B64-9797-4EA1-8D54-C6E022F0CF3E@demuc.de> Message-ID: oh ignore the bento remark, I missed it the first time - sorry about that On Sun, May 19, 2013 at 3:19 AM, Johannes Sch?nberger < jschoenberger at demuc.de> wrote: > Thanks, that was me? but it actually was fun for me ;-) > > Johannes Sch?nberger > > Am 19.05.2013 um 09:16 schrieb Ronnie Ghose : > > > that's a possibility, let me try that :D. also props for whoever made > the _geometric.py, that doesn't look fun o-o. > > > > > > On Sun, May 19, 2013 at 2:36 AM, Johannes Sch?nberger < > jschoenberger at demuc.de> wrote: > > I have only implemented it for 2D but a PR to add functionality for 1D > arrays is highly welcome ;-) > > > > Von: scikit-image at googlegroups.com [scikit-image at googlegroups.com]" im > Auftrag von "Ronnie Ghose [ronnie.ghose at gmail.com] > > Gesendet: Sonntag, 19. Mai 2013 08:23 > > An: scikit-image at googlegroups.com > > Betreff: > > > > the transform.resize function does not work for 1-d arrays as it expects > a (#,#) instead of (#,) .. should this be changed or is this as intended? > > > > Thanks, > > Ronnie > > > > -- > > You received this message because you are subscribed to the Google > Groups "scikit-image" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to scikit-image+unsubscribe at googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > -- > > You received this message because you are subscribed to the Google > Groups "scikit-image" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to scikit-image+unsubscribe at googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > -- > > You received this message because you are subscribed to the Google > Groups "scikit-image" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to scikit-image+unsubscribe at googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > -- > You received this message because you are subscribed to the Google Groups > "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschoenberger at demuc.de Sun May 19 02:36:39 2013 From: jschoenberger at demuc.de (=?iso-8859-1?Q?Johannes_Sch=F6nberger?=) Date: Sun, 19 May 2013 06:36:39 +0000 Subject: AW: In-Reply-To: References: Message-ID: I have only implemented it for 2D but a PR to add functionality for 1D arrays is highly welcome ;-) ________________________________ Von: scikit-image at googlegroups.com [scikit-image at googlegroups.com]" im Auftrag von "Ronnie Ghose [ronnie.ghose at gmail.com] Gesendet: Sonntag, 19. Mai 2013 08:23 An: scikit-image at googlegroups.com Betreff: the transform.resize function does not work for 1-d arrays as it expects a (#,#) instead of (#,) .. should this be changed or is this as intended? Thanks, Ronnie -- You received this message because you are subscribed to the Google Groups "scikit-image" group. To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschoenberger at demuc.de Sun May 19 03:19:25 2013 From: jschoenberger at demuc.de (=?windows-1252?Q?Johannes_Sch=F6nberger?=) Date: Sun, 19 May 2013 09:19:25 +0200 Subject: No subject In-Reply-To: References: Message-ID: <43A65B64-9797-4EA1-8D54-C6E022F0CF3E@demuc.de> Thanks, that was me? but it actually was fun for me ;-) Johannes Sch?nberger Am 19.05.2013 um 09:16 schrieb Ronnie Ghose : > that's a possibility, let me try that :D. also props for whoever made the _geometric.py, that doesn't look fun o-o. > > > On Sun, May 19, 2013 at 2:36 AM, Johannes Sch?nberger wrote: > I have only implemented it for 2D but a PR to add functionality for 1D arrays is highly welcome ;-) > > Von: scikit-image at googlegroups.com [scikit-image at googlegroups.com]" im Auftrag von "Ronnie Ghose [ronnie.ghose at gmail.com] > Gesendet: Sonntag, 19. Mai 2013 08:23 > An: scikit-image at googlegroups.com > Betreff: > > the transform.resize function does not work for 1-d arrays as it expects a (#,#) instead of (#,) .. should this be changed or is this as intended? > > Thanks, > Ronnie > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > From ronnie.ghose at gmail.com Mon May 20 07:10:17 2013 From: ronnie.ghose at gmail.com (Ronnie Ghose) Date: Mon, 20 May 2013 07:10:17 -0400 Subject: numexpr In-Reply-To: References: <9DA42682-B478-40F2-AE16-7E35FD6696F5@demuc.de> Message-ID: i would think it's faster than Cython since it parallel-izes On Mon, May 20, 2013 at 6:58 AM, St?fan van der Walt wrote: > Hi Johannes > > On Fri, May 17, 2013 at 3:56 PM, Johannes Sch?nberger > wrote: > > I think, this could also improve performance of some functions in > skimage. What's your opinion on adding this as a new dependency? > > Do you think there's any advantage of using numexpr over Cython? > > St?fan > > -- > You received this message because you are subscribed to the Google Groups > "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Mon May 20 05:56:40 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 20 May 2013 11:56:40 +0200 Subject: ENH: improved, faster algorithm for array padding Message-ID: Kudos to Josh Warner for getting this patch into NumPy so quickly! ---------- Forwarded message ---------- From: GitHub Date: Sun, May 19, 2013 at 9:50 PM Subject: [Numpy-svn] [numpy/numpy] 246c06: ENH: improved, faster algorithm for array padding Branch: refs/heads/master Home: https://github.com/numpy/numpy Commit: 246c06d2475718ec36ba193494444464e497c69a https://github.com/numpy/numpy/commit/246c06d2475718ec36ba193494444464e497c69a Author: Josh Warner (Mac) Date: 2013-05-19 (Sun, 19 May 2013) Changed paths: M doc/release/1.8.0-notes.rst M numpy/lib/arraypad.py M numpy/lib/tests/test_arraypad.py Log Message: ----------- ENH: improved, faster algorithm for array padding New padding method which scales much better with dimensionality. This new implementation is fully vectorized, builds each abstracted n-dimensional padding block in a single step, and takes advantage of separability. The API is completely preserved, and the old algorithm is used if a vector function is input for `mode`. The new algorithm is faster for all tested combinations of inputs, and scales much better with dimensionality. Execution time reductions from ~25% for small rank 1 arrays to >99% for rank 4+ arrays observed. Commit: 7d188bf1c9ac5bf7ee41e0794d59771802b345bf https://github.com/numpy/numpy/commit/7d188bf1c9ac5bf7ee41e0794d59771802b345bf Author: Charles Harris Date: 2013-05-19 (Sun, 19 May 2013) Changed paths: M doc/release/1.8.0-notes.rst M numpy/lib/arraypad.py M numpy/lib/tests/test_arraypad.py Log Message: ----------- Merge pull request #3329 from JDWarner/faster_arraypad ENH: improved, faster algorithm for array padding Compare: https://github.com/numpy/numpy/compare/5b28d185a494...7d188bf1c9ac From stefan at sun.ac.za Mon May 20 06:58:15 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 20 May 2013 12:58:15 +0200 Subject: numexpr In-Reply-To: <9DA42682-B478-40F2-AE16-7E35FD6696F5@demuc.de> References: <9DA42682-B478-40F2-AE16-7E35FD6696F5@demuc.de> Message-ID: Hi Johannes On Fri, May 17, 2013 at 3:56 PM, Johannes Sch?nberger wrote: > I think, this could also improve performance of some functions in skimage. What's your opinion on adding this as a new dependency? Do you think there's any advantage of using numexpr over Cython? St?fan From jschoenberger at demuc.de Mon May 20 07:16:43 2013 From: jschoenberger at demuc.de (=?iso-8859-1?Q?Johannes_Sch=F6nberger?=) Date: Mon, 20 May 2013 13:16:43 +0200 Subject: numexpr In-Reply-To: References: <9DA42682-B478-40F2-AE16-7E35FD6696F5@demuc.de> Message-ID: <9E74ED80-7FC0-4A8C-94CA-B3961C9962C6@demuc.de> With numexpr you can pass plain Python code, in Cython you have to re-implement the loop by hand. Also, it supports multi-threading by default without any further coding. Johannes Sch?nberger Am 20.05.2013 um 12:58 schrieb St?fan van der Walt : > Hi Johannes > > On Fri, May 17, 2013 at 3:56 PM, Johannes Sch?nberger > wrote: >> I think, this could also improve performance of some functions in skimage. What's your opinion on adding this as a new dependency? > > Do you think there's any advantage of using numexpr over Cython? > > St?fan > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > From jschoenberger at demuc.de Mon May 20 07:17:34 2013 From: jschoenberger at demuc.de (=?iso-8859-1?Q?Johannes_Sch=F6nberger?=) Date: Mon, 20 May 2013 13:17:34 +0200 Subject: numexpr In-Reply-To: <9E74ED80-7FC0-4A8C-94CA-B3961C9962C6@demuc.de> References: <9DA42682-B478-40F2-AE16-7E35FD6696F5@demuc.de> <9E74ED80-7FC0-4A8C-94CA-B3961C9962C6@demuc.de> Message-ID: Just have a look at https://code.google.com/p/numexpr/ - the site pretty much covers the advantages of numexpr. Johannes Sch?nberger Am 20.05.2013 um 13:16 schrieb Johannes Sch?nberger : > With numexpr you can pass plain Python code, in Cython you have to re-implement the loop by hand. Also, it supports multi-threading by default without any further coding. > > Johannes Sch?nberger > > Am 20.05.2013 um 12:58 schrieb St?fan van der Walt : > >> Hi Johannes >> >> On Fri, May 17, 2013 at 3:56 PM, Johannes Sch?nberger >> wrote: >>> I think, this could also improve performance of some functions in skimage. What's your opinion on adding this as a new dependency? >> >> Do you think there's any advantage of using numexpr over Cython? >> >> St?fan >> >> -- >> You received this message because you are subscribed to the Google Groups "scikit-image" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > From stefan at sun.ac.za Mon May 20 07:20:18 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 20 May 2013 13:20:18 +0200 Subject: numexpr In-Reply-To: References: <9DA42682-B478-40F2-AE16-7E35FD6696F5@demuc.de> <9E74ED80-7FC0-4A8C-94CA-B3961C9962C6@demuc.de> Message-ID: On Mon, May 20, 2013 at 1:17 PM, Johannes Sch?nberger wrote: > Just have a look at https://code.google.com/p/numexpr/ - the site pretty much covers the advantages of numexpr. I'm familiar with the package, but I'm not sure how it benefits us. It's mainly for speeding up single-line expressions done on all the data, i.e. the kind of thing that numpy is pretty good for it does a little bit faster. Are you thinking of something like the recent exposure adjustment functions? St?fan From jschoenberger at demuc.de Mon May 20 07:47:15 2013 From: jschoenberger at demuc.de (=?iso-8859-1?Q?Johannes_Sch=F6nberger?=) Date: Mon, 20 May 2013 13:47:15 +0200 Subject: numexpr In-Reply-To: References: <9DA42682-B478-40F2-AE16-7E35FD6696F5@demuc.de> <9E74ED80-7FC0-4A8C-94CA-B3961C9962C6@demuc.de> Message-ID: <2D69606F-E9EE-433C-9A13-6F188C22A443@demuc.de> Yes, exposure, edge detection, namely all functions that rely on basic array multiplication / ufuncs. Johannes Sch?nberger Am 20.05.2013 um 13:20 schrieb St?fan van der Walt : > On Mon, May 20, 2013 at 1:17 PM, Johannes Sch?nberger > wrote: >> Just have a look at https://code.google.com/p/numexpr/ - the site pretty much covers the advantages of numexpr. > > I'm familiar with the package, but I'm not sure how it benefits us. > It's mainly for speeding up single-line expressions done on all the > data, i.e. the kind of thing that numpy is pretty good for it does a > little bit faster. Are you thinking of something like the recent > exposure adjustment functions? > > St?fan > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > From stefan at sun.ac.za Mon May 20 07:58:52 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 20 May 2013 13:58:52 +0200 Subject: numexpr In-Reply-To: <2D69606F-E9EE-433C-9A13-6F188C22A443@demuc.de> References: <9DA42682-B478-40F2-AE16-7E35FD6696F5@demuc.de> <9E74ED80-7FC0-4A8C-94CA-B3961C9962C6@demuc.de> <2D69606F-E9EE-433C-9A13-6F188C22A443@demuc.de> Message-ID: On Mon, May 20, 2013 at 1:47 PM, Johannes Sch?nberger wrote: > Yes, exposure, edge detection, namely all functions that rely on basic array multiplication / ufuncs. I'm hesitant. The added dependency and code modification adds complexity, and I don't know how much improvement we will get. Could you do a benchmark of a typical function? St?fan From chintaksheth at gmail.com Mon May 20 06:06:31 2013 From: chintaksheth at gmail.com (Chintak Sheth) Date: Mon, 20 May 2013 15:36:31 +0530 Subject: ENH: improved, faster algorithm for array padding In-Reply-To: References: Message-ID: Cheers Josh! On May 20, 2013 3:27 PM, "St?fan van der Walt" wrote: > Kudos to Josh Warner for getting this patch into NumPy so quickly! > > ---------- Forwarded message ---------- > From: GitHub > Date: Sun, May 19, 2013 at 9:50 PM > Subject: [Numpy-svn] [numpy/numpy] 246c06: ENH: improved, faster > algorithm for array padding > > Branch: refs/heads/master > Home: https://github.com/numpy/numpy > Commit: 246c06d2475718ec36ba193494444464e497c69a > > https://github.com/numpy/numpy/commit/246c06d2475718ec36ba193494444464e497c69a > Author: Josh Warner (Mac) > Date: 2013-05-19 (Sun, 19 May 2013) > > Changed paths: > M doc/release/1.8.0-notes.rst > M numpy/lib/arraypad.py > M numpy/lib/tests/test_arraypad.py > > Log Message: > ----------- > ENH: improved, faster algorithm for array padding > > New padding method which scales much better with dimensionality. > This new implementation is fully vectorized, builds each abstracted > n-dimensional padding block in a single step, and takes advantage > of separability. The API is completely preserved, and the old > algorithm is used if a vector function is input for `mode`. > > The new algorithm is faster for all tested combinations of inputs, > and scales much better with dimensionality. Execution time reductions > from ~25% for small rank 1 arrays to >99% for rank 4+ arrays observed. > > > Commit: 7d188bf1c9ac5bf7ee41e0794d59771802b345bf > > https://github.com/numpy/numpy/commit/7d188bf1c9ac5bf7ee41e0794d59771802b345bf > Author: Charles Harris > Date: 2013-05-19 (Sun, 19 May 2013) > > Changed paths: > M doc/release/1.8.0-notes.rst > M numpy/lib/arraypad.py > M numpy/lib/tests/test_arraypad.py > > Log Message: > ----------- > Merge pull request #3329 from JDWarner/faster_arraypad > > ENH: improved, faster algorithm for array padding > > > Compare: > https://github.com/numpy/numpy/compare/5b28d185a494...7d188bf1c9ac > > -- > You received this message because you are subscribed to the Google Groups > "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From francesc at continuum.io Mon May 20 11:46:54 2013 From: francesc at continuum.io (Francesc Alted) Date: Mon, 20 May 2013 17:46:54 +0200 Subject: numexpr In-Reply-To: References: <9DA42682-B478-40F2-AE16-7E35FD6696F5@demuc.de> <9E74ED80-7FC0-4A8C-94CA-B3961C9962C6@demuc.de> <2D69606F-E9EE-433C-9A13-6F188C22A443@demuc.de> Message-ID: <519A456E.6090602@continuum.io> On 5/20/13 1:58 PM, St??????fan van der Walt wrote: > On Mon, May 20, 2013 at 1:47 PM, Johannes Sch??????nberger > wrote: >> Yes, exposure, edge detection, namely all functions that rely on basic array multiplication / ufuncs. > I'm hesitant. The added dependency and code modification adds > complexity, and I don't know how much improvement we will get. Could > you do a benchmark of a typical function? Yes, benchmarking is always a must before taking decisions like this. At any rate, you don't need to make a hard dependency of numexpr. This is what I typically do: try: import numexpr numexpr_ispresent = True except ImportError: numexpr_ispresent = False and then, in your code: if numexpr_ispresent: # you numexpr code here else: # your other code path here That means two code paths, which is a bit more complex, but still acceptable in many cases. -- Francesc Alted From silvertrumpet999 at gmail.com Mon May 20 21:05:54 2013 From: silvertrumpet999 at gmail.com (Josh Warner) Date: Mon, 20 May 2013 18:05:54 -0700 (PDT) Subject: ENH: improved, faster algorithm for array padding In-Reply-To: References: Message-ID: <69d36316-b68d-4f98-9cb7-baa499a2541a@googlegroups.com> Thanks guys! I'll be bringing a version of this over to scikit-image.utilin the very near future, to be used if NumPy < 1.8.x. On Monday, May 20, 2013 5:06:31 AM UTC-5, Chintak Sheth wrote: Cheers Josh! > On May 20, 2013 3:27 PM, "St?fan van der Walt" > > wrote: > >> Kudos to Josh Warner for getting this patch into NumPy so quickly! >> >> ---------- Forwarded message ---------- >> From: GitHub >> Date: Sun, May 19, 2013 at 9:50 PM >> Subject: [Numpy-svn] [numpy/numpy] 246c06: ENH: improved, faster >> algorithm for array padding >> >> Branch: refs/heads/master >> Home: https://github.com/numpy/numpy >> Commit: 246c06d2475718ec36ba193494444464e497c69a >> >> https://github.com/numpy/numpy/commit/246c06d2475718ec36ba193494444464e497c69a >> Author: Josh Warner (Mac) > >> Date: 2013-05-19 (Sun, 19 May 2013) >> >> Changed paths: >> M doc/release/1.8.0-notes.rst >> M numpy/lib/arraypad.py >> M numpy/lib/tests/test_arraypad.py >> >> Log Message: >> ----------- >> ENH: improved, faster algorithm for array padding >> >> New padding method which scales much better with dimensionality. >> This new implementation is fully vectorized, builds each abstracted >> n-dimensional padding block in a single step, and takes advantage >> of separability. The API is completely preserved, and the old >> algorithm is used if a vector function is input for `mode`. >> >> The new algorithm is faster for all tested combinations of inputs, >> and scales much better with dimensionality. Execution time reductions >> from ~25% for small rank 1 arrays to >99% for rank 4+ arrays observed. >> >> >> Commit: 7d188bf1c9ac5bf7ee41e0794d59771802b345bf >> >> https://github.com/numpy/numpy/commit/7d188bf1c9ac5bf7ee41e0794d59771802b345bf >> Author: Charles Harris > >> Date: 2013-05-19 (Sun, 19 May 2013) >> >> Changed paths: >> M doc/release/1.8.0-notes.rst >> M numpy/lib/arraypad.py >> M numpy/lib/tests/test_arraypad.py >> >> Log Message: >> ----------- >> Merge pull request #3329 from JDWarner/faster_arraypad >> >> ENH: improved, faster algorithm for array padding >> >> >> Compare: >> https://github.com/numpy/numpy/compare/5b28d185a494...7d188bf1c9ac >> >> -- >> You received this message because you are subscribed to the Google Groups >> "scikit-image" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to scikit-image... at googlegroups.com . >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaaagrawal at gmail.com Wed May 22 00:09:59 2013 From: aaaagrawal at gmail.com (Ankit Agrawal) Date: Tue, 21 May 2013 21:09:59 -0700 (PDT) Subject: Some ideas for skimage In-Reply-To: References: <77472ff4-84f1-445e-8db1-12444b9d88bd@googlegroups.com> Message-ID: Does 'make coverage' test the examples in docstrings? If not, is there any separate command to test them? -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvertrumpet999 at gmail.com Wed May 22 20:02:30 2013 From: silvertrumpet999 at gmail.com (Josh Warner) Date: Wed, 22 May 2013 17:02:30 -0700 (PDT) Subject: Some ideas for skimage In-Reply-To: References: <77472ff4-84f1-445e-8db1-12444b9d88bd@googlegroups.com> Message-ID: Right now `make coverage` only runs unit tests, no examples. This would definitely be useful functionality to add. On Tuesday, May 21, 2013 11:09:59 PM UTC-5, Ankit Agrawal wrote: > > Does 'make coverage' test the examples in docstrings? If not, is there any > separate command to test them? -------------- next part -------------- An HTML attachment was scrubbed... URL: From abidrahman2 at gmail.com Fri May 24 06:46:49 2013 From: abidrahman2 at gmail.com (abid rahman) Date: Fri, 24 May 2013 16:16:49 +0530 Subject: numexpr In-Reply-To: <519A456E.6090602@continuum.io> References: <9DA42682-B478-40F2-AE16-7E35FD6696F5@demuc.de> <9E74ED80-7FC0-4A8C-94CA-B3961C9962C6@demuc.de> <2D69606F-E9EE-433C-9A13-6F188C22A443@demuc.de> <519A456E.6090602@continuum.io> Message-ID: I haven't watched below video, but after seeing the discussion, may be it will be useful : http://marakana.com/s/post/1105/2012_pydata_workshop_boosting_numpy_numbexpr_and_cython_video Abid K. opencvpython.blogspot.com On Mon, May 20, 2013 at 9:16 PM, Francesc Alted wrote: > On 5/20/13 1:58 PM, St?fan van der Walt wrote: > >> On Mon, May 20, 2013 at 1:47 PM, Johannes Sch?nberger >> wrote: >> >>> Yes, exposure, edge detection, namely all functions that rely on basic >>> array multiplication / ufuncs. >>> >> I'm hesitant. The added dependency and code modification adds >> complexity, and I don't know how much improvement we will get. Could >> you do a benchmark of a typical function? >> > > Yes, benchmarking is always a must before taking decisions like this. At > any rate, you don't need to make a hard dependency of numexpr. This is > what I typically do: > > try: > import numexpr > numexpr_ispresent = True > except ImportError: > numexpr_ispresent = False > > and then, in your code: > > if numexpr_ispresent: > # you numexpr code here > else: > # your other code path here > > That means two code paths, which is a bit more complex, but still > acceptable in many cases. > > -- > Francesc Alted > > > -- > You received this message because you are subscribed to the Google Groups > "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to scikit-image+unsubscribe@**googlegroups.com > . > For more options, visit https://groups.google.com/**groups/opt_out > . > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cjgohlke at gmail.com Mon May 27 00:32:37 2013 From: cjgohlke at gmail.com (Christoph Gohlke) Date: Sun, 26 May 2013 21:32:37 -0700 Subject: Weird imsave inverting behaviour In-Reply-To: References: Message-ID: <51A2E1E5.3000804@gmail.com> On 5/26/2013 8:31 PM, Juan Nunez-Iglesias wrote: > Hey all, > > I noticed that some of my microscopy images appeared inverted after > saving them with skimage.io.imsave. After some testing, here's some of > the weirdness. My image is called s: > > ```python > In [37]: np.min(s) > Out[37]: 119 > > In [38]: np.max(s) > Out[38]: 4095 > > In [39]: s.shape > Out[39]: (1040, 1392) > > In [40]: s.dtype > Out[40]: dtype('uint16') > > In [41]: io.imsave('/Users/nuneziglesiasj/Desktop/im.tif', s) > > In [42]: sr = io.imread('/Users/nuneziglesiasj/Desktop/im.tif') > > In [43]: (s == sr).all() > Out[43]: Image(False, dtype=bool) > > In [44]: sr.min() > Out[44]: Image(0, dtype=uint8) > > In [45]: sr.max() > Out[45]: Image(255, dtype=uint8) > ``` > > Ok, already this is not desirable... One would hope than an imsave > followed by an imread would be a no-op, but whatever, let's accept for > argument's sake that we want to limit ourselves to uint8. Here's the > real downer: > > ```python > In [46]: np.corrcoef(s.ravel(), sr.ravel()) > Out[46]: > array([[ 1. , -0.29849602], > [-0.29849602, 1. ]]) > ``` > > This is simply unacceptable. I haven't explored any more than this yet > but maybe someone has an idea about what is going on here? If it helps, > the problem is with imsave ?????? opening the images in Apple Preview shows > the inversion. I just wanted to know if it was some weird > incompatibility between skimage and Preview, rather than skimage acting > stupid. Sadly, it appears to be the latter. > > PS: I just tested with png and get the exact same result. > Not many skimage.io plugins are capable of handling 16 bit data. Use gdal (read only), tifffile (uncompressed tiff only), or freeimage, e.g. `io.use_plugin('freeimage')` Christoph From ronnie.ghose at gmail.com Mon May 27 02:55:01 2013 From: ronnie.ghose at gmail.com (Ronnie Ghose) Date: Mon, 27 May 2013 02:55:01 -0400 Subject: Weird imsave inverting behaviour In-Reply-To: References: <51A2E1E5.3000804@gmail.com> Message-ID: while we're on the subject, it seems algorithms / arrays are mixing using / wanting as input, [0,1] and [0,256] for grayscale, which leads to unexpected results On Mon, May 27, 2013 at 2:51 AM, Johannes Sch?nberger < jschoenberger at demuc.de> wrote: > To be honest I agree, right now it is a mess, which is also the reason why > I have not touched this package yet. Things I noticed: > > - depending on the plugin, the code and comment / doc string quality > should be improved > - what's the purpose of _colormixer.pyx, _histogram.pyx, q_histogram.py, > q_color_mixer.py etc. and why are they in the io plugin directory? > - the way plugins are managed should be overhauled and we should discuss > it together before implementation > > My ideas: > > - rather than having .ini files I would opt for `register(plugin, desc, > funcs, setup_func, *args, **kwargs)` and `unregister(plugin)` functions. > This enables also users to add new plugins at runtime. > > - `setup_func` should check whether the plugin is available on this system. > > - what is indicated as `args` and `kwargs` above should definitely contain > two more things: an explicit whitelist of supported file formats, > extensions and dtypes or an explicit blacklist of file formats, extensions > and dtypes. This could be represented as a dictionary: > > {['png']: ['uint8', 'float', '?'], ['tif', 'tiff']: ? } > > It allows us to automatically select an available plugin for the given > data or raise an error. > > - Explicitly selecting a plugin should be possible through an extra > argument to `imread`, `imsave`. E.g. `imsave(file, data, > plugin='freeimage')`. > > > > > Johannes Sch?nberger > > Am 27.05.2013 um 07:27 schrieb Juan Nunez-Iglesias : > > > OH. Right. That's what's happening, it's not inverted, it's looping > around with the overflow! (I was wondering why the correlation was not > closer to -1.) > > > > Guh. imho: > > > > - This really shouldn't happen. The plugin selection should be aware of > the data type, and use only a plugin that can handle it (if available) > > - PIL can definitely do 16bit PNG, so either it is being used > incorrectly, or the imsave docstring stating that PIL is the first > selection is wrong. I just tested this on my PIL-based Gala library, which > is 3D so it required a bit of modification: > > > > In [66]: imio.write_png_image_stack(s[np.newaxis, ...], > '~/Desktop/im%02i.png', axis=0 > > ) > > > > In [ > > 67]: srg = imio.read_image_stack('/Users/nuneziglesiasj/Desktop/im0*.png' > > ) > > > > In [ > > 68 > > ]: srg.shape > > Out[ > > 68]: (1040, 1392 > > ) > > > > In [ > > 69 > > ]: (s == srg).all() > > Out[ > > 69]: True > > > > - The IO module is a mess! I know Stefan mentioned overhauling it > briefly, but I didn't quite realise how urgent that was. In particular: > > - is `from blah import *` used as a matter of policy or is it a > remnant of an earlier age? Took me ages to find the `call` function. > > - `plugin_store`? I have no idea where this gets updated. > > > > So, to the core skimage devs: what is the scope for updating this? Am I > allowed to break some functionality in a PR? Or are we sticking with this > API? > > > > > > On Mon, May 27, 2013 at 2:32 PM, Christoph Gohlke > wrote: > > On 5/26/2013 8:31 PM, Juan Nunez-Iglesias wrote: > > Hey all, > > > > I noticed that some of my microscopy images appeared inverted after > > saving them with skimage.io.imsave. After some testing, here's some of > > the weirdness. My image is called s: > > > > ```python > > In [37]: np.min(s) > > Out[37]: 119 > > > > In [38]: np.max(s) > > Out[38]: 4095 > > > > In [39]: s.shape > > Out[39]: (1040, 1392) > > > > In [40]: s.dtype > > Out[40]: dtype('uint16') > > > > In [41]: io.imsave('/Users/nuneziglesiasj/Desktop/im.tif', s) > > > > In [42]: sr = io.imread('/Users/nuneziglesiasj/Desktop/im.tif') > > > > In [43]: (s == sr).all() > > Out[43]: Image(False, dtype=bool) > > > > In [44]: sr.min() > > Out[44]: Image(0, dtype=uint8) > > > > In [45]: sr.max() > > Out[45]: Image(255, dtype=uint8) > > ``` > > > > Ok, already this is not desirable... One would hope than an imsave > > followed by an imread would be a no-op, but whatever, let's accept for > > argument's sake that we want to limit ourselves to uint8. Here's the > > real downer: > > > > ```python > > In [46]: np.corrcoef(s.ravel(), sr.ravel()) > > Out[46]: > > array([[ 1. , -0.29849602], > > [-0.29849602, 1. ]]) > > ``` > > > > This is simply unacceptable. I haven't explored any more than this yet > > but maybe someone has an idea about what is going on here? If it helps, > > the problem is with imsave ? opening the images in Apple Preview shows > > the inversion. I just wanted to know if it was some weird > > incompatibility between skimage and Preview, rather than skimage acting > > stupid. Sadly, it appears to be the latter. > > > > PS: I just tested with png and get the exact same result. > > > > > > Not many skimage.io plugins are capable of handling 16 bit data. Use > gdal (read only), tifffile (uncompressed tiff only), or freeimage, e.g. > `io.use_plugin('freeimage')` > > > > Christoph > > > > -- > > You received this message because you are subscribed to the Google > Groups "scikit-image" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to scikit-image+unsubscribe at googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > -- > > You received this message because you are subscribed to the Google > Groups "scikit-image" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to scikit-image+unsubscribe at googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > -- > You received this message because you are subscribed to the Google Groups > "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronnie.ghose at gmail.com Mon May 27 02:56:11 2013 From: ronnie.ghose at gmail.com (Ronnie Ghose) Date: Mon, 27 May 2013 02:56:11 -0400 Subject: Weird imsave inverting behaviour In-Reply-To: References: <51A2E1E5.3000804@gmail.com> Message-ID: can we just standardize it so that _everything_ uses one of the two representations? If an algorithm needs it differently, it can do the 256*array or array/256 and then again output this standard format On Mon, May 27, 2013 at 2:55 AM, Ronnie Ghose wrote: > while we're on the subject, it seems algorithms / arrays are mixing using > / wanting as input, [0,1] and [0,256] for grayscale, which leads to > unexpected results > > > On Mon, May 27, 2013 at 2:51 AM, Johannes Sch?nberger < > jschoenberger at demuc.de> wrote: > >> To be honest I agree, right now it is a mess, which is also the reason >> why I have not touched this package yet. Things I noticed: >> >> - depending on the plugin, the code and comment / doc string quality >> should be improved >> - what's the purpose of _colormixer.pyx, _histogram.pyx, q_histogram.py, >> q_color_mixer.py etc. and why are they in the io plugin directory? >> - the way plugins are managed should be overhauled and we should discuss >> it together before implementation >> >> My ideas: >> >> - rather than having .ini files I would opt for `register(plugin, desc, >> funcs, setup_func, *args, **kwargs)` and `unregister(plugin)` functions. >> This enables also users to add new plugins at runtime. >> >> - `setup_func` should check whether the plugin is available on this >> system. >> >> - what is indicated as `args` and `kwargs` above should definitely >> contain two more things: an explicit whitelist of supported file formats, >> extensions and dtypes or an explicit blacklist of file formats, extensions >> and dtypes. This could be represented as a dictionary: >> >> {['png']: ['uint8', 'float', '?'], ['tif', 'tiff']: ? } >> >> It allows us to automatically select an available plugin for the >> given data or raise an error. >> >> - Explicitly selecting a plugin should be possible through an extra >> argument to `imread`, `imsave`. E.g. `imsave(file, data, >> plugin='freeimage')`. >> >> >> >> >> Johannes Sch?nberger >> >> Am 27.05.2013 um 07:27 schrieb Juan Nunez-Iglesias : >> >> > OH. Right. That's what's happening, it's not inverted, it's looping >> around with the overflow! (I was wondering why the correlation was not >> closer to -1.) >> > >> > Guh. imho: >> > >> > - This really shouldn't happen. The plugin selection should be aware of >> the data type, and use only a plugin that can handle it (if available) >> > - PIL can definitely do 16bit PNG, so either it is being used >> incorrectly, or the imsave docstring stating that PIL is the first >> selection is wrong. I just tested this on my PIL-based Gala library, which >> is 3D so it required a bit of modification: >> > >> > In [66]: imio.write_png_image_stack(s[np.newaxis, ...], >> '~/Desktop/im%02i.png', axis=0 >> > ) >> > >> > In [ >> > 67]: srg = >> imio.read_image_stack('/Users/nuneziglesiasj/Desktop/im0*.png' >> > ) >> > >> > In [ >> > 68 >> > ]: srg.shape >> > Out[ >> > 68]: (1040, 1392 >> > ) >> > >> > In [ >> > 69 >> > ]: (s == srg).all() >> > Out[ >> > 69]: True >> > >> > - The IO module is a mess! I know Stefan mentioned overhauling it >> briefly, but I didn't quite realise how urgent that was. In particular: >> > - is `from blah import *` used as a matter of policy or is it a >> remnant of an earlier age? Took me ages to find the `call` function. >> > - `plugin_store`? I have no idea where this gets updated. >> > >> > So, to the core skimage devs: what is the scope for updating this? Am I >> allowed to break some functionality in a PR? Or are we sticking with this >> API? >> > >> > >> > On Mon, May 27, 2013 at 2:32 PM, Christoph Gohlke >> wrote: >> > On 5/26/2013 8:31 PM, Juan Nunez-Iglesias wrote: >> > Hey all, >> > >> > I noticed that some of my microscopy images appeared inverted after >> > saving them with skimage.io.imsave. After some testing, here's some of >> > the weirdness. My image is called s: >> > >> > ```python >> > In [37]: np.min(s) >> > Out[37]: 119 >> > >> > In [38]: np.max(s) >> > Out[38]: 4095 >> > >> > In [39]: s.shape >> > Out[39]: (1040, 1392) >> > >> > In [40]: s.dtype >> > Out[40]: dtype('uint16') >> > >> > In [41]: io.imsave('/Users/nuneziglesiasj/Desktop/im.tif', s) >> > >> > In [42]: sr = io.imread('/Users/nuneziglesiasj/Desktop/im.tif') >> > >> > In [43]: (s == sr).all() >> > Out[43]: Image(False, dtype=bool) >> > >> > In [44]: sr.min() >> > Out[44]: Image(0, dtype=uint8) >> > >> > In [45]: sr.max() >> > Out[45]: Image(255, dtype=uint8) >> > ``` >> > >> > Ok, already this is not desirable... One would hope than an imsave >> > followed by an imread would be a no-op, but whatever, let's accept for >> > argument's sake that we want to limit ourselves to uint8. Here's the >> > real downer: >> > >> > ```python >> > In [46]: np.corrcoef(s.ravel(), sr.ravel()) >> > Out[46]: >> > array([[ 1. , -0.29849602], >> > [-0.29849602, 1. ]]) >> > ``` >> > >> > This is simply unacceptable. I haven't explored any more than this yet >> > but maybe someone has an idea about what is going on here? If it helps, >> > the problem is with imsave ? opening the images in Apple Preview shows >> > the inversion. I just wanted to know if it was some weird >> > incompatibility between skimage and Preview, rather than skimage acting >> > stupid. Sadly, it appears to be the latter. >> > >> > PS: I just tested with png and get the exact same result. >> > >> > >> > Not many skimage.io plugins are capable of handling 16 bit data. Use >> gdal (read only), tifffile (uncompressed tiff only), or freeimage, e.g. >> `io.use_plugin('freeimage')` >> > >> > Christoph >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups "scikit-image" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to scikit-image+unsubscribe at googlegroups.com. >> > For more options, visit https://groups.google.com/groups/opt_out. >> > >> > >> > >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups "scikit-image" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to scikit-image+unsubscribe at googlegroups.com. >> > For more options, visit https://groups.google.com/groups/opt_out. >> > >> > >> >> -- >> You received this message because you are subscribed to the Google Groups >> "scikit-image" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to scikit-image+unsubscribe at googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronnie.ghose at gmail.com Mon May 27 03:03:34 2013 From: ronnie.ghose at gmail.com (Ronnie Ghose) Date: Mon, 27 May 2013 03:03:34 -0400 Subject: Weird imsave inverting behaviour In-Reply-To: <7CCE1EFC-4581-4C41-8978-81F9FDA7FA46@demuc.de> References: <51A2E1E5.3000804@gmail.com> <7CCE1EFC-4581-4C41-8978-81F9FDA7FA46@demuc.de> Message-ID: Can I add that in the docs somewhere? hmm... the question is where should general guidelines go.... On Mon, May 27, 2013 at 3:02 AM, Johannes Sch?nberger < jschoenberger at demuc.de> wrote: > IMO the convention is to use double ([0, 1]) everywhere, except in rare > cases?? > > Johannes Sch?nberger > > Am 27.05.2013 um 08:56 schrieb Ronnie Ghose : > > > can we just standardize it so that _everything_ uses one of the two > representations? If an algorithm needs it differently, it can do the > 256*array or array/256 and then again output this standard format > > > > > > On Mon, May 27, 2013 at 2:55 AM, Ronnie Ghose > wrote: > > while we're on the subject, it seems algorithms / arrays are mixing > using / wanting as input, [0,1] and [0,256] for grayscale, which leads to > unexpected results > > > > > > On Mon, May 27, 2013 at 2:51 AM, Johannes Sch?nberger < > jschoenberger at demuc.de> wrote: > > To be honest I agree, right now it is a mess, which is also the reason > why I have not touched this package yet. Things I noticed: > > > > - depending on the plugin, the code and comment / doc string quality > should be improved > > - what's the purpose of _colormixer.pyx, _histogram.pyx, > q_histogram.py, q_color_mixer.py etc. and why are they in the io plugin > directory? > > - the way plugins are managed should be overhauled and we should > discuss it together before implementation > > > > My ideas: > > > > - rather than having .ini files I would opt for `register(plugin, desc, > funcs, setup_func, *args, **kwargs)` and `unregister(plugin)` functions. > This enables also users to add new plugins at runtime. > > > > - `setup_func` should check whether the plugin is available on this > system. > > > > - what is indicated as `args` and `kwargs` above should definitely > contain two more things: an explicit whitelist of supported file formats, > extensions and dtypes or an explicit blacklist of file formats, extensions > and dtypes. This could be represented as a dictionary: > > > > {['png']: ['uint8', 'float', '?'], ['tif', 'tiff']: ? } > > > > It allows us to automatically select an available plugin for the > given data or raise an error. > > > > - Explicitly selecting a plugin should be possible through an extra > argument to `imread`, `imsave`. E.g. `imsave(file, data, > plugin='freeimage')`. > > > > > > > > > > Johannes Sch?nberger > > > > Am 27.05.2013 um 07:27 schrieb Juan Nunez-Iglesias : > > > > > OH. Right. That's what's happening, it's not inverted, it's looping > around with the overflow! (I was wondering why the correlation was not > closer to -1.) > > > > > > Guh. imho: > > > > > > - This really shouldn't happen. The plugin selection should be aware > of the data type, and use only a plugin that can handle it (if available) > > > - PIL can definitely do 16bit PNG, so either it is being used > incorrectly, or the imsave docstring stating that PIL is the first > selection is wrong. I just tested this on my PIL-based Gala library, which > is 3D so it required a bit of modification: > > > > > > In [66]: imio.write_png_image_stack(s[np.newaxis, ...], > '~/Desktop/im%02i.png', axis=0 > > > ) > > > > > > In [ > > > 67]: srg = > imio.read_image_stack('/Users/nuneziglesiasj/Desktop/im0*.png' > > > ) > > > > > > In [ > > > 68 > > > ]: srg.shape > > > Out[ > > > 68]: (1040, 1392 > > > ) > > > > > > In [ > > > 69 > > > ]: (s == srg).all() > > > Out[ > > > 69]: True > > > > > > - The IO module is a mess! I know Stefan mentioned overhauling it > briefly, but I didn't quite realise how urgent that was. In particular: > > > - is `from blah import *` used as a matter of policy or is it a > remnant of an earlier age? Took me ages to find the `call` function. > > > - `plugin_store`? I have no idea where this gets updated. > > > > > > So, to the core skimage devs: what is the scope for updating this? Am > I allowed to break some functionality in a PR? Or are we sticking with this > API? > > > > > > > > > On Mon, May 27, 2013 at 2:32 PM, Christoph Gohlke > wrote: > > > On 5/26/2013 8:31 PM, Juan Nunez-Iglesias wrote: > > > Hey all, > > > > > > I noticed that some of my microscopy images appeared inverted after > > > saving them with skimage.io.imsave. After some testing, here's some of > > > the weirdness. My image is called s: > > > > > > ```python > > > In [37]: np.min(s) > > > Out[37]: 119 > > > > > > In [38]: np.max(s) > > > Out[38]: 4095 > > > > > > In [39]: s.shape > > > Out[39]: (1040, 1392) > > > > > > In [40]: s.dtype > > > Out[40]: dtype('uint16') > > > > > > In [41]: io.imsave('/Users/nuneziglesiasj/Desktop/im.tif', s) > > > > > > In [42]: sr = io.imread('/Users/nuneziglesiasj/Desktop/im.tif') > > > > > > In [43]: (s == sr).all() > > > Out[43]: Image(False, dtype=bool) > > > > > > In [44]: sr.min() > > > Out[44]: Image(0, dtype=uint8) > > > > > > In [45]: sr.max() > > > Out[45]: Image(255, dtype=uint8) > > > ``` > > > > > > Ok, already this is not desirable... One would hope than an imsave > > > followed by an imread would be a no-op, but whatever, let's accept for > > > argument's sake that we want to limit ourselves to uint8. Here's the > > > real downer: > > > > > > ```python > > > In [46]: np.corrcoef(s.ravel(), sr.ravel()) > > > Out[46]: > > > array([[ 1. , -0.29849602], > > > [-0.29849602, 1. ]]) > > > ``` > > > > > > This is simply unacceptable. I haven't explored any more than this yet > > > but maybe someone has an idea about what is going on here? If it helps, > > > the problem is with imsave ? opening the images in Apple Preview shows > > > the inversion. I just wanted to know if it was some weird > > > incompatibility between skimage and Preview, rather than skimage acting > > > stupid. Sadly, it appears to be the latter. > > > > > > PS: I just tested with png and get the exact same result. > > > > > > > > > Not many skimage.io plugins are capable of handling 16 bit data. Use > gdal (read only), tifffile (uncompressed tiff only), or freeimage, e.g. > `io.use_plugin('freeimage')` > > > > > > Christoph > > > > > > -- > > > You received this message because you are subscribed to the Google > Groups "scikit-image" group. > > > To unsubscribe from this group and stop receiving emails from it, send > an email to scikit-image+unsubscribe at googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google > Groups "scikit-image" group. > > > To unsubscribe from this group and stop receiving emails from it, send > an email to scikit-image+unsubscribe at googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > -- > > You received this message because you are subscribed to the Google > Groups "scikit-image" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to scikit-image+unsubscribe at googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > > > -- > > You received this message because you are subscribed to the Google > Groups "scikit-image" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to scikit-image+unsubscribe at googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > -- > You received this message because you are subscribed to the Google Groups > "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschoenberger at demuc.de Mon May 27 02:51:59 2013 From: jschoenberger at demuc.de (=?windows-1252?Q?Johannes_Sch=F6nberger?=) Date: Mon, 27 May 2013 08:51:59 +0200 Subject: Weird imsave inverting behaviour In-Reply-To: References: <51A2E1E5.3000804@gmail.com> Message-ID: To be honest I agree, right now it is a mess, which is also the reason why I have not touched this package yet. Things I noticed: - depending on the plugin, the code and comment / doc string quality should be improved - what's the purpose of _colormixer.pyx, _histogram.pyx, q_histogram.py, q_color_mixer.py etc. and why are they in the io plugin directory? - the way plugins are managed should be overhauled and we should discuss it together before implementation My ideas: - rather than having .ini files I would opt for `register(plugin, desc, funcs, setup_func, *args, **kwargs)` and `unregister(plugin)` functions. This enables also users to add new plugins at runtime. - `setup_func` should check whether the plugin is available on this system. - what is indicated as `args` and `kwargs` above should definitely contain two more things: an explicit whitelist of supported file formats, extensions and dtypes or an explicit blacklist of file formats, extensions and dtypes. This could be represented as a dictionary: {['png']: ['uint8', 'float', '?'], ['tif', 'tiff']: ? } It allows us to automatically select an available plugin for the given data or raise an error. - Explicitly selecting a plugin should be possible through an extra argument to `imread`, `imsave`. E.g. `imsave(file, data, plugin='freeimage')`. Johannes Sch?nberger Am 27.05.2013 um 07:27 schrieb Juan Nunez-Iglesias : > OH. Right. That's what's happening, it's not inverted, it's looping around with the overflow! (I was wondering why the correlation was not closer to -1.) > > Guh. imho: > > - This really shouldn't happen. The plugin selection should be aware of the data type, and use only a plugin that can handle it (if available) > - PIL can definitely do 16bit PNG, so either it is being used incorrectly, or the imsave docstring stating that PIL is the first selection is wrong. I just tested this on my PIL-based Gala library, which is 3D so it required a bit of modification: > > In [66]: imio.write_png_image_stack(s[np.newaxis, ...], '~/Desktop/im%02i.png', axis=0 > ) > > In [ > 67]: srg = imio.read_image_stack('/Users/nuneziglesiasj/Desktop/im0*.png' > ) > > In [ > 68 > ]: srg.shape > Out[ > 68]: (1040, 1392 > ) > > In [ > 69 > ]: (s == srg).all() > Out[ > 69]: True > > - The IO module is a mess! I know Stefan mentioned overhauling it briefly, but I didn't quite realise how urgent that was. In particular: > - is `from blah import *` used as a matter of policy or is it a remnant of an earlier age? Took me ages to find the `call` function. > - `plugin_store`? I have no idea where this gets updated. > > So, to the core skimage devs: what is the scope for updating this? Am I allowed to break some functionality in a PR? Or are we sticking with this API? > > > On Mon, May 27, 2013 at 2:32 PM, Christoph Gohlke wrote: > On 5/26/2013 8:31 PM, Juan Nunez-Iglesias wrote: > Hey all, > > I noticed that some of my microscopy images appeared inverted after > saving them with skimage.io.imsave. After some testing, here's some of > the weirdness. My image is called s: > > ```python > In [37]: np.min(s) > Out[37]: 119 > > In [38]: np.max(s) > Out[38]: 4095 > > In [39]: s.shape > Out[39]: (1040, 1392) > > In [40]: s.dtype > Out[40]: dtype('uint16') > > In [41]: io.imsave('/Users/nuneziglesiasj/Desktop/im.tif', s) > > In [42]: sr = io.imread('/Users/nuneziglesiasj/Desktop/im.tif') > > In [43]: (s == sr).all() > Out[43]: Image(False, dtype=bool) > > In [44]: sr.min() > Out[44]: Image(0, dtype=uint8) > > In [45]: sr.max() > Out[45]: Image(255, dtype=uint8) > ``` > > Ok, already this is not desirable... One would hope than an imsave > followed by an imread would be a no-op, but whatever, let's accept for > argument's sake that we want to limit ourselves to uint8. Here's the > real downer: > > ```python > In [46]: np.corrcoef(s.ravel(), sr.ravel()) > Out[46]: > array([[ 1. , -0.29849602], > [-0.29849602, 1. ]]) > ``` > > This is simply unacceptable. I haven't explored any more than this yet > but maybe someone has an idea about what is going on here? If it helps, > the problem is with imsave ? opening the images in Apple Preview shows > the inversion. I just wanted to know if it was some weird > incompatibility between skimage and Preview, rather than skimage acting > stupid. Sadly, it appears to be the latter. > > PS: I just tested with png and get the exact same result. > > > Not many skimage.io plugins are capable of handling 16 bit data. Use gdal (read only), tifffile (uncompressed tiff only), or freeimage, e.g. `io.use_plugin('freeimage')` > > Christoph > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > From jschoenberger at demuc.de Mon May 27 03:02:10 2013 From: jschoenberger at demuc.de (=?windows-1252?Q?Johannes_Sch=F6nberger?=) Date: Mon, 27 May 2013 09:02:10 +0200 Subject: Weird imsave inverting behaviour In-Reply-To: References: <51A2E1E5.3000804@gmail.com> Message-ID: <7CCE1EFC-4581-4C41-8978-81F9FDA7FA46@demuc.de> IMO the convention is to use double ([0, 1]) everywhere, except in rare cases?? Johannes Sch?nberger Am 27.05.2013 um 08:56 schrieb Ronnie Ghose : > can we just standardize it so that _everything_ uses one of the two representations? If an algorithm needs it differently, it can do the 256*array or array/256 and then again output this standard format > > > On Mon, May 27, 2013 at 2:55 AM, Ronnie Ghose wrote: > while we're on the subject, it seems algorithms / arrays are mixing using / wanting as input, [0,1] and [0,256] for grayscale, which leads to unexpected results > > > On Mon, May 27, 2013 at 2:51 AM, Johannes Sch?nberger wrote: > To be honest I agree, right now it is a mess, which is also the reason why I have not touched this package yet. Things I noticed: > > - depending on the plugin, the code and comment / doc string quality should be improved > - what's the purpose of _colormixer.pyx, _histogram.pyx, q_histogram.py, q_color_mixer.py etc. and why are they in the io plugin directory? > - the way plugins are managed should be overhauled and we should discuss it together before implementation > > My ideas: > > - rather than having .ini files I would opt for `register(plugin, desc, funcs, setup_func, *args, **kwargs)` and `unregister(plugin)` functions. This enables also users to add new plugins at runtime. > > - `setup_func` should check whether the plugin is available on this system. > > - what is indicated as `args` and `kwargs` above should definitely contain two more things: an explicit whitelist of supported file formats, extensions and dtypes or an explicit blacklist of file formats, extensions and dtypes. This could be represented as a dictionary: > > {['png']: ['uint8', 'float', '?'], ['tif', 'tiff']: ? } > > It allows us to automatically select an available plugin for the given data or raise an error. > > - Explicitly selecting a plugin should be possible through an extra argument to `imread`, `imsave`. E.g. `imsave(file, data, plugin='freeimage')`. > > > > > Johannes Sch?nberger > > Am 27.05.2013 um 07:27 schrieb Juan Nunez-Iglesias : > > > OH. Right. That's what's happening, it's not inverted, it's looping around with the overflow! (I was wondering why the correlation was not closer to -1.) > > > > Guh. imho: > > > > - This really shouldn't happen. The plugin selection should be aware of the data type, and use only a plugin that can handle it (if available) > > - PIL can definitely do 16bit PNG, so either it is being used incorrectly, or the imsave docstring stating that PIL is the first selection is wrong. I just tested this on my PIL-based Gala library, which is 3D so it required a bit of modification: > > > > In [66]: imio.write_png_image_stack(s[np.newaxis, ...], '~/Desktop/im%02i.png', axis=0 > > ) > > > > In [ > > 67]: srg = imio.read_image_stack('/Users/nuneziglesiasj/Desktop/im0*.png' > > ) > > > > In [ > > 68 > > ]: srg.shape > > Out[ > > 68]: (1040, 1392 > > ) > > > > In [ > > 69 > > ]: (s == srg).all() > > Out[ > > 69]: True > > > > - The IO module is a mess! I know Stefan mentioned overhauling it briefly, but I didn't quite realise how urgent that was. In particular: > > - is `from blah import *` used as a matter of policy or is it a remnant of an earlier age? Took me ages to find the `call` function. > > - `plugin_store`? I have no idea where this gets updated. > > > > So, to the core skimage devs: what is the scope for updating this? Am I allowed to break some functionality in a PR? Or are we sticking with this API? > > > > > > On Mon, May 27, 2013 at 2:32 PM, Christoph Gohlke wrote: > > On 5/26/2013 8:31 PM, Juan Nunez-Iglesias wrote: > > Hey all, > > > > I noticed that some of my microscopy images appeared inverted after > > saving them with skimage.io.imsave. After some testing, here's some of > > the weirdness. My image is called s: > > > > ```python > > In [37]: np.min(s) > > Out[37]: 119 > > > > In [38]: np.max(s) > > Out[38]: 4095 > > > > In [39]: s.shape > > Out[39]: (1040, 1392) > > > > In [40]: s.dtype > > Out[40]: dtype('uint16') > > > > In [41]: io.imsave('/Users/nuneziglesiasj/Desktop/im.tif', s) > > > > In [42]: sr = io.imread('/Users/nuneziglesiasj/Desktop/im.tif') > > > > In [43]: (s == sr).all() > > Out[43]: Image(False, dtype=bool) > > > > In [44]: sr.min() > > Out[44]: Image(0, dtype=uint8) > > > > In [45]: sr.max() > > Out[45]: Image(255, dtype=uint8) > > ``` > > > > Ok, already this is not desirable... One would hope than an imsave > > followed by an imread would be a no-op, but whatever, let's accept for > > argument's sake that we want to limit ourselves to uint8. Here's the > > real downer: > > > > ```python > > In [46]: np.corrcoef(s.ravel(), sr.ravel()) > > Out[46]: > > array([[ 1. , -0.29849602], > > [-0.29849602, 1. ]]) > > ``` > > > > This is simply unacceptable. I haven't explored any more than this yet > > but maybe someone has an idea about what is going on here? If it helps, > > the problem is with imsave ? opening the images in Apple Preview shows > > the inversion. I just wanted to know if it was some weird > > incompatibility between skimage and Preview, rather than skimage acting > > stupid. Sadly, it appears to be the latter. > > > > PS: I just tested with png and get the exact same result. > > > > > > Not many skimage.io plugins are capable of handling 16 bit data. Use gdal (read only), tifffile (uncompressed tiff only), or freeimage, e.g. `io.use_plugin('freeimage')` > > > > Christoph > > > > -- > > You received this message because you are subscribed to the Google Groups "scikit-image" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > -- > > You received this message because you are subscribed to the Google Groups "scikit-image" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > From jschoenberger at demuc.de Mon May 27 03:29:10 2013 From: jschoenberger at demuc.de (=?windows-1252?Q?Johannes_Sch=F6nberger?=) Date: Mon, 27 May 2013 09:29:10 +0200 Subject: Weird imsave inverting behaviour In-Reply-To: References: <51A2E1E5.3000804@gmail.com> <7CCE1EFC-4581-4C41-8978-81F9FDA7FA46@demuc.de> Message-ID: `CONTRIBUTING.txt` Johannes Sch?nberger Am 27.05.2013 um 09:03 schrieb Ronnie Ghose : > Can I add that in the docs somewhere? hmm... the question is where should general guidelines go.... > > > On Mon, May 27, 2013 at 3:02 AM, Johannes Sch?nberger wrote: > IMO the convention is to use double ([0, 1]) everywhere, except in rare cases?? > > Johannes Sch?nberger > > Am 27.05.2013 um 08:56 schrieb Ronnie Ghose : > > > can we just standardize it so that _everything_ uses one of the two representations? If an algorithm needs it differently, it can do the 256*array or array/256 and then again output this standard format > > > > > > On Mon, May 27, 2013 at 2:55 AM, Ronnie Ghose wrote: > > while we're on the subject, it seems algorithms / arrays are mixing using / wanting as input, [0,1] and [0,256] for grayscale, which leads to unexpected results > > > > > > On Mon, May 27, 2013 at 2:51 AM, Johannes Sch?nberger wrote: > > To be honest I agree, right now it is a mess, which is also the reason why I have not touched this package yet. Things I noticed: > > > > - depending on the plugin, the code and comment / doc string quality should be improved > > - what's the purpose of _colormixer.pyx, _histogram.pyx, q_histogram.py, q_color_mixer.py etc. and why are they in the io plugin directory? > > - the way plugins are managed should be overhauled and we should discuss it together before implementation > > > > My ideas: > > > > - rather than having .ini files I would opt for `register(plugin, desc, funcs, setup_func, *args, **kwargs)` and `unregister(plugin)` functions. This enables also users to add new plugins at runtime. > > > > - `setup_func` should check whether the plugin is available on this system. > > > > - what is indicated as `args` and `kwargs` above should definitely contain two more things: an explicit whitelist of supported file formats, extensions and dtypes or an explicit blacklist of file formats, extensions and dtypes. This could be represented as a dictionary: > > > > {['png']: ['uint8', 'float', '?'], ['tif', 'tiff']: ? } > > > > It allows us to automatically select an available plugin for the given data or raise an error. > > > > - Explicitly selecting a plugin should be possible through an extra argument to `imread`, `imsave`. E.g. `imsave(file, data, plugin='freeimage')`. > > > > > > > > > > Johannes Sch?nberger > > > > Am 27.05.2013 um 07:27 schrieb Juan Nunez-Iglesias : > > > > > OH. Right. That's what's happening, it's not inverted, it's looping around with the overflow! (I was wondering why the correlation was not closer to -1.) > > > > > > Guh. imho: > > > > > > - This really shouldn't happen. The plugin selection should be aware of the data type, and use only a plugin that can handle it (if available) > > > - PIL can definitely do 16bit PNG, so either it is being used incorrectly, or the imsave docstring stating that PIL is the first selection is wrong. I just tested this on my PIL-based Gala library, which is 3D so it required a bit of modification: > > > > > > In [66]: imio.write_png_image_stack(s[np.newaxis, ...], '~/Desktop/im%02i.png', axis=0 > > > ) > > > > > > In [ > > > 67]: srg = imio.read_image_stack('/Users/nuneziglesiasj/Desktop/im0*.png' > > > ) > > > > > > In [ > > > 68 > > > ]: srg.shape > > > Out[ > > > 68]: (1040, 1392 > > > ) > > > > > > In [ > > > 69 > > > ]: (s == srg).all() > > > Out[ > > > 69]: True > > > > > > - The IO module is a mess! I know Stefan mentioned overhauling it briefly, but I didn't quite realise how urgent that was. In particular: > > > - is `from blah import *` used as a matter of policy or is it a remnant of an earlier age? Took me ages to find the `call` function. > > > - `plugin_store`? I have no idea where this gets updated. > > > > > > So, to the core skimage devs: what is the scope for updating this? Am I allowed to break some functionality in a PR? Or are we sticking with this API? > > > > > > > > > On Mon, May 27, 2013 at 2:32 PM, Christoph Gohlke wrote: > > > On 5/26/2013 8:31 PM, Juan Nunez-Iglesias wrote: > > > Hey all, > > > > > > I noticed that some of my microscopy images appeared inverted after > > > saving them with skimage.io.imsave. After some testing, here's some of > > > the weirdness. My image is called s: > > > > > > ```python > > > In [37]: np.min(s) > > > Out[37]: 119 > > > > > > In [38]: np.max(s) > > > Out[38]: 4095 > > > > > > In [39]: s.shape > > > Out[39]: (1040, 1392) > > > > > > In [40]: s.dtype > > > Out[40]: dtype('uint16') > > > > > > In [41]: io.imsave('/Users/nuneziglesiasj/Desktop/im.tif', s) > > > > > > In [42]: sr = io.imread('/Users/nuneziglesiasj/Desktop/im.tif') > > > > > > In [43]: (s == sr).all() > > > Out[43]: Image(False, dtype=bool) > > > > > > In [44]: sr.min() > > > Out[44]: Image(0, dtype=uint8) > > > > > > In [45]: sr.max() > > > Out[45]: Image(255, dtype=uint8) > > > ``` > > > > > > Ok, already this is not desirable... One would hope than an imsave > > > followed by an imread would be a no-op, but whatever, let's accept for > > > argument's sake that we want to limit ourselves to uint8. Here's the > > > real downer: > > > > > > ```python > > > In [46]: np.corrcoef(s.ravel(), sr.ravel()) > > > Out[46]: > > > array([[ 1. , -0.29849602], > > > [-0.29849602, 1. ]]) > > > ``` > > > > > > This is simply unacceptable. I haven't explored any more than this yet > > > but maybe someone has an idea about what is going on here? If it helps, > > > the problem is with imsave ? opening the images in Apple Preview shows > > > the inversion. I just wanted to know if it was some weird > > > incompatibility between skimage and Preview, rather than skimage acting > > > stupid. Sadly, it appears to be the latter. > > > > > > PS: I just tested with png and get the exact same result. > > > > > > > > > Not many skimage.io plugins are capable of handling 16 bit data. Use gdal (read only), tifffile (uncompressed tiff only), or freeimage, e.g. `io.use_plugin('freeimage')` > > > > > > Christoph > > > > > > -- > > > You received this message because you are subscribed to the Google Groups "scikit-image" group. > > > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google Groups "scikit-image" group. > > > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > -- > > You received this message because you are subscribed to the Google Groups "scikit-image" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > > > -- > > You received this message because you are subscribed to the Google Groups "scikit-image" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > From jschoenberger at demuc.de Mon May 27 03:49:18 2013 From: jschoenberger at demuc.de (=?windows-1252?Q?Johannes_Sch=F6nberger?=) Date: Mon, 27 May 2013 09:49:18 +0200 Subject: Weird imsave inverting behaviour In-Reply-To: References: <51A2E1E5.3000804@gmail.com> <7CCE1EFC-4581-4C41-8978-81F9FDA7FA46@demuc.de> Message-ID: <66E49BBD-B7C9-4393-B89B-BE71A5DB6FF3@demuc.de> I was just talking of functions? io should always preserve the input data type and range. Johannes Sch?nberger Am 27.05.2013 um 09:36 schrieb Juan Nunez-Iglesias : > Well, [0, 1] is great for working, but useless for saving. So what should the convention be for saving? And should we use single or double precision floats? I think in general it's hard to choose for users, and the best thing is to try to preserve user input type unless there's a good reason not to do so. > > Note that 16 bit grayscale images are fairly common, so assuming uint8 for the output is a no-no. > > > On Mon, May 27, 2013 at 5:29 PM, Johannes Sch?nberger wrote: > `CONTRIBUTING.txt` > > Johannes Sch?nberger > > Am 27.05.2013 um 09:03 schrieb Ronnie Ghose : > > > Can I add that in the docs somewhere? hmm... the question is where should general guidelines go.... > > > > > > On Mon, May 27, 2013 at 3:02 AM, Johannes Sch?nberger wrote: > > IMO the convention is to use double ([0, 1]) everywhere, except in rare cases?? > > > > Johannes Sch?nberger > > > > Am 27.05.2013 um 08:56 schrieb Ronnie Ghose : > > > > > can we just standardize it so that _everything_ uses one of the two representations? If an algorithm needs it differently, it can do the 256*array or array/256 and then again output this standard format > > > > > > > > > On Mon, May 27, 2013 at 2:55 AM, Ronnie Ghose wrote: > > > while we're on the subject, it seems algorithms / arrays are mixing using / wanting as input, [0,1] and [0,256] for grayscale, which leads to unexpected results > > > > > > > > > On Mon, May 27, 2013 at 2:51 AM, Johannes Sch?nberger wrote: > > > To be honest I agree, right now it is a mess, which is also the reason why I have not touched this package yet. Things I noticed: > > > > > > - depending on the plugin, the code and comment / doc string quality should be improved > > > - what's the purpose of _colormixer.pyx, _histogram.pyx, q_histogram.py, q_color_mixer.py etc. and why are they in the io plugin directory? > > > - the way plugins are managed should be overhauled and we should discuss it together before implementation > > > > > > My ideas: > > > > > > - rather than having .ini files I would opt for `register(plugin, desc, funcs, setup_func, *args, **kwargs)` and `unregister(plugin)` functions. This enables also users to add new plugins at runtime. > > > > > > - `setup_func` should check whether the plugin is available on this system. > > > > > > - what is indicated as `args` and `kwargs` above should definitely contain two more things: an explicit whitelist of supported file formats, extensions and dtypes or an explicit blacklist of file formats, extensions and dtypes. This could be represented as a dictionary: > > > > > > {['png']: ['uint8', 'float', '?'], ['tif', 'tiff']: ? } > > > > > > It allows us to automatically select an available plugin for the given data or raise an error. > > > > > > - Explicitly selecting a plugin should be possible through an extra argument to `imread`, `imsave`. E.g. `imsave(file, data, plugin='freeimage')`. > > > > > > > > > > > > > > > Johannes Sch?nberger > > > > > > Am 27.05.2013 um 07:27 schrieb Juan Nunez-Iglesias : > > > > > > > OH. Right. That's what's happening, it's not inverted, it's looping around with the overflow! (I was wondering why the correlation was not closer to -1.) > > > > > > > > Guh. imho: > > > > > > > > - This really shouldn't happen. The plugin selection should be aware of the data type, and use only a plugin that can handle it (if available) > > > > - PIL can definitely do 16bit PNG, so either it is being used incorrectly, or the imsave docstring stating that PIL is the first selection is wrong. I just tested this on my PIL-based Gala library, which is 3D so it required a bit of modification: > > > > > > > > In [66]: imio.write_png_image_stack(s[np.newaxis, ...], '~/Desktop/im%02i.png', axis=0 > > > > ) > > > > > > > > In [ > > > > 67]: srg = imio.read_image_stack('/Users/nuneziglesiasj/Desktop/im0*.png' > > > > ) > > > > > > > > In [ > > > > 68 > > > > ]: srg.shape > > > > Out[ > > > > 68]: (1040, 1392 > > > > ) > > > > > > > > In [ > > > > 69 > > > > ]: (s == srg).all() > > > > Out[ > > > > 69]: True > > > > > > > > - The IO module is a mess! I know Stefan mentioned overhauling it briefly, but I didn't quite realise how urgent that was. In particular: > > > > - is `from blah import *` used as a matter of policy or is it a remnant of an earlier age? Took me ages to find the `call` function. > > > > - `plugin_store`? I have no idea where this gets updated. > > > > > > > > So, to the core skimage devs: what is the scope for updating this? Am I allowed to break some functionality in a PR? Or are we sticking with this API? > > > > > > > > > > > > On Mon, May 27, 2013 at 2:32 PM, Christoph Gohlke wrote: > > > > On 5/26/2013 8:31 PM, Juan Nunez-Iglesias wrote: > > > > Hey all, > > > > > > > > I noticed that some of my microscopy images appeared inverted after > > > > saving them with skimage.io.imsave. After some testing, here's some of > > > > the weirdness. My image is called s: > > > > > > > > ```python > > > > In [37]: np.min(s) > > > > Out[37]: 119 > > > > > > > > In [38]: np.max(s) > > > > Out[38]: 4095 > > > > > > > > In [39]: s.shape > > > > Out[39]: (1040, 1392) > > > > > > > > In [40]: s.dtype > > > > Out[40]: dtype('uint16') > > > > > > > > In [41]: io.imsave('/Users/nuneziglesiasj/Desktop/im.tif', s) > > > > > > > > In [42]: sr = io.imread('/Users/nuneziglesiasj/Desktop/im.tif') > > > > > > > > In [43]: (s == sr).all() > > > > Out[43]: Image(False, dtype=bool) > > > > > > > > In [44]: sr.min() > > > > Out[44]: Image(0, dtype=uint8) > > > > > > > > In [45]: sr.max() > > > > Out[45]: Image(255, dtype=uint8) > > > > ``` > > > > > > > > Ok, already this is not desirable... One would hope than an imsave > > > > followed by an imread would be a no-op, but whatever, let's accept for > > > > argument's sake that we want to limit ourselves to uint8. Here's the > > > > real downer: > > > > > > > > ```python > > > > In [46]: np.corrcoef(s.ravel(), sr.ravel()) > > > > Out[46]: > > > > array([[ 1. , -0.29849602], > > > > [-0.29849602, 1. ]]) > > > > ``` > > > > > > > > This is simply unacceptable. I haven't explored any more than this yet > > > > but maybe someone has an idea about what is going on here? If it helps, > > > > the problem is with imsave ? opening the images in Apple Preview shows > > > > the inversion. I just wanted to know if it was some weird > > > > incompatibility between skimage and Preview, rather than skimage acting > > > > stupid. Sadly, it appears to be the latter. > > > > > > > > PS: I just tested with png and get the exact same result. > > > > > > > > > > > > Not many skimage.io plugins are capable of handling 16 bit data. Use gdal (read only), tifffile (uncompressed tiff only), or freeimage, e.g. `io.use_plugin('freeimage')` > > > > > > > > Christoph > > > > > > > > -- > > > > You received this message because you are subscribed to the Google Groups "scikit-image" group. > > > > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > > > > > > > > > > > -- > > > > You received this message because you are subscribed to the Google Groups "scikit-image" group. > > > > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google Groups "scikit-image" group. > > > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google Groups "scikit-image" group. > > > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > -- > > You received this message because you are subscribed to the Google Groups "scikit-image" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > -- > > You received this message because you are subscribed to the Google Groups "scikit-image" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > From stefan at sun.ac.za Mon May 27 05:35:45 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 27 May 2013 11:35:45 +0200 Subject: Weird imsave inverting behaviour In-Reply-To: References: <51A2E1E5.3000804@gmail.com> Message-ID: On Mon, May 27, 2013 at 8:51 AM, Johannes Sch?nberger wrote: > > - depending on the plugin, the code and comment / doc string quality should be improved > - what's the purpose of _colormixer.pyx, _histogram.pyx, q_histogram.py, q_color_mixer.py etc. and why are they in the io plugin directory? These are used in the fancy QT image viewer, i.e. "imshow(image, fancy=True)". > - the way plugins are managed should be overhauled and we should discuss it together before implementation > > My ideas: > > - rather than having .ini files I would opt for `register(plugin, desc, funcs, setup_func, *args, **kwargs)` and `unregister(plugin)` functions. This enables also users to add new plugins at runtime. This sounds very similar to the ideas mentioned by Almar Klein earlier this month: https://groups.google.com/d/msg/imageio/jNwYY6B8n7Y/svdUiYWA4mMJ Unfortunately, there's a trade-off between having things "just work" and the amount of magic that happens behind the scene. When starting scikit-image, we set it as a priority that a person should be able to do ``imread(...)`` on almost any system and have it work. I think this was an important requirement for having demos Just Work. > - what is indicated as `args` and `kwargs` above should definitely contain two more things: an explicit whitelist of supported file formats, extensions and dtypes or an explicit blacklist of file formats, extensions and dtypes. This could be represented as a dictionary: > > {['png']: ['uint8', 'float', '?'], ['tif', 'tiff']: ? } > > It allows us to automatically select an available plugin for the given data or raise an error. Having formats and data-types specified is a good idea. It can also be done using the ini-file format, but I'd prefer the approach you suggest. That said, let me motivate those configuration files: the idea was that one could add plugins by simply dropping the appropriate files in-place. However, the right place for those plugins to live would probably be inside the skimage repository, so it doesn't matters that much. > - Explicitly selecting a plugin should be possible through an extra argument to `imread`, `imsave`. E.g. `imsave(file, data, plugin='freeimage')`. Just verifying that this is the way it currently functions. St?fan From stefan at sun.ac.za Mon May 27 05:37:43 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 27 May 2013 11:37:43 +0200 Subject: Weird imsave inverting behaviour In-Reply-To: References: <51A2E1E5.3000804@gmail.com> <7CCE1EFC-4581-4C41-8978-81F9FDA7FA46@demuc.de> Message-ID: On Mon, May 27, 2013 at 9:03 AM, Ronnie Ghose wrote: > Can I add that in the docs somewhere? hmm... the question is where should > general guidelines go.... http://scikit-image.org/docs/dev/user_guide/data_types.html Our policy is: anything in, whatever the algorithm prefers out. The data type determines the range: float : [-1, 1] or [0, 1] uint8: [0, 255] St?fan From ronnie.ghose at gmail.com Mon May 27 12:16:21 2013 From: ronnie.ghose at gmail.com (Ronnie Ghose) Date: Mon, 27 May 2013 12:16:21 -0400 Subject: Mini Project Message-ID: Scikit-img, Would you guys per chance have any ideas for a mini project that would/could demonstrate some of the capabilities of both the library/image processing in general? Ideally with regard to a real world application? Thanks, Ronnie -------------- next part -------------- An HTML attachment was scrubbed... URL: From jni.soma at gmail.com Sun May 26 23:31:14 2013 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Mon, 27 May 2013 13:31:14 +1000 Subject: Weird imsave inverting behaviour Message-ID: Hey all, I noticed that some of my microscopy images appeared inverted after saving them with skimage.io.imsave. After some testing, here's some of the weirdness. My image is called s: ```python In [37]: np.min(s) Out[37]: 119 In [38]: np.max(s) Out[38]: 4095 In [39]: s.shape Out[39]: (1040, 1392) In [40]: s.dtype Out[40]: dtype('uint16') In [41]: io.imsave('/Users/nuneziglesiasj/Desktop/im.tif', s) In [42]: sr = io.imread('/Users/nuneziglesiasj/Desktop/im.tif') In [43]: (s == sr).all() Out[43]: Image(False, dtype=bool) In [44]: sr.min() Out[44]: Image(0, dtype=uint8) In [45]: sr.max() Out[45]: Image(255, dtype=uint8) ``` Ok, already this is not desirable... One would hope than an imsave followed by an imread would be a no-op, but whatever, let's accept for argument's sake that we want to limit ourselves to uint8. Here's the real downer: ```python In [46]: np.corrcoef(s.ravel(), sr.ravel()) Out[46]: array([[ 1. , -0.29849602], [-0.29849602, 1. ]]) ``` This is simply unacceptable. I haven't explored any more than this yet but maybe someone has an idea about what is going on here? If it helps, the problem is with imsave ? opening the images in Apple Preview shows the inversion. I just wanted to know if it was some weird incompatibility between skimage and Preview, rather than skimage acting stupid. Sadly, it appears to be the latter. PS: I just tested with png and get the exact same result. -------------- next part -------------- An HTML attachment was scrubbed... URL: From deklerkmc at gmail.com Mon May 27 16:55:47 2013 From: deklerkmc at gmail.com (Marc de Klerk) Date: Mon, 27 May 2013 13:55:47 -0700 (PDT) Subject: Cython / c++ help Message-ID: Hi Guys, I'm hoping that I could get some help and advice on c++ and Cython. I've written an OpenCL implementation for the prefix-sum algorithm which I use for generating a compacted lookup table for sparse binary array (called stream compacting) The algorithm isn't really important right now, but just to show what it does here's an example? In the end, the result is a nice compact array of the indices that were flagged? I'm mainly using it to know which tiles to process for grow cut of graph cut on the gpu like this: This operation has to happen a lot? so I really need it to be fast. The problem I'm having is that the when I isolate and measure the execution time of the gpu code it's much faster than that of the c++ or Cython wrapper - which I cannot really do without. So I'm kinda hoping someone can help me to really squash the additional execution time from the overhead of the wrapper. Originally I wrote a Python then Cython wrapper and when looking at the difference between the execution time of just the gnu code vs the total time, I thought it must be from the overhead of the Python/Cython. But I've just written a c++ wrapper and it's not a whole lot faster than Python/Cython, but I'm still hoping there's a lot that can be done? Here are two graphs that might help explain? The one below is measuring the execution time of just the gpu code in the 3 implementations. They should be exactly the same and they are more or less. The problem is this next graph?. Besides the difference between the c++ and the other two, there's still a large difference between the c++ plot and the plots in the graph above... The code is all on https://github.com/mdeklerk/cl-util The files of interest are pyPrefixSum.py, PrefixSum.pyx, which can be tested with test_PrefixSum and PrefixSum.cpp which just needs to be compiled ran? If you've gotten this far, thanks for reading it, I hope it's clear :) I'll greatly appreciate any help, even pointing me more or less in the right direction etc? Cheers, Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jni.soma at gmail.com Mon May 27 01:27:10 2013 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Mon, 27 May 2013 15:27:10 +1000 Subject: Weird imsave inverting behaviour In-Reply-To: <51A2E1E5.3000804@gmail.com> References: <51A2E1E5.3000804@gmail.com> Message-ID: OH. Right. That's what's happening, it's not inverted, it's looping around with the overflow! (I was wondering why the correlation was not closer to -1.) Guh. imho: - This really shouldn't happen. The plugin selection should be aware of the data type, and use only a plugin that can handle it (if available) - PIL can definitely do 16bit PNG, so either it is being used incorrectly, or the imsave docstring stating that PIL is the first selection is wrong. I just tested this on my PIL-based Gala library, which is 3D so it required a bit of modification: In [66]: imio.write_png_image_stack(s[np.newaxis, ...], '~/Desktop/im%02i.png', axis=0) In [67]: srg = imio.read_image_stack('/Users/nuneziglesiasj/Desktop/im0*.png') In [68]: srg.shape Out[68]: (1040, 1392) In [69]: (s == srg).all() Out[69]: True - The IO module is a mess! I know Stefan mentioned overhauling it briefly, but I didn't quite realise how urgent that was. In particular: - is `from blah import *` used as a matter of policy or is it a remnant of an earlier age? Took me ages to find the `call` function. - `plugin_store`? I have no idea where this gets updated. So, to the core skimage devs: what is the scope for updating this? Am I allowed to break some functionality in a PR? Or are we sticking with this API? On Mon, May 27, 2013 at 2:32 PM, Christoph Gohlke wrote: > On 5/26/2013 8:31 PM, Juan Nunez-Iglesias wrote: > >> Hey all, >> >> I noticed that some of my microscopy images appeared inverted after >> saving them with skimage.io.imsave. After some testing, here's some of >> the weirdness. My image is called s: >> >> ```python >> In [37]: np.min(s) >> Out[37]: 119 >> >> In [38]: np.max(s) >> Out[38]: 4095 >> >> In [39]: s.shape >> Out[39]: (1040, 1392) >> >> In [40]: s.dtype >> Out[40]: dtype('uint16') >> >> In [41]: io.imsave('/Users/**nuneziglesiasj/Desktop/im.tif'**, s) >> >> In [42]: sr = io.imread('/Users/**nuneziglesiasj/Desktop/im.tif'**) >> >> In [43]: (s == sr).all() >> Out[43]: Image(False, dtype=bool) >> >> In [44]: sr.min() >> Out[44]: Image(0, dtype=uint8) >> >> In [45]: sr.max() >> Out[45]: Image(255, dtype=uint8) >> ``` >> >> Ok, already this is not desirable... One would hope than an imsave >> followed by an imread would be a no-op, but whatever, let's accept for >> argument's sake that we want to limit ourselves to uint8. Here's the >> real downer: >> >> ```python >> In [46]: np.corrcoef(s.ravel(), sr.ravel()) >> Out[46]: >> array([[ 1. , -0.29849602], >> [-0.29849602, 1. ]]) >> ``` >> >> This is simply unacceptable. I haven't explored any more than this yet >> but maybe someone has an idea about what is going on here? If it helps, >> the problem is with imsave ? opening the images in Apple Preview shows >> the inversion. I just wanted to know if it was some weird >> incompatibility between skimage and Preview, rather than skimage acting >> stupid. Sadly, it appears to be the latter. >> >> PS: I just tested with png and get the exact same result. >> >> > Not many skimage.io plugins are capable of handling 16 bit data. Use gdal > (read only), tifffile (uncompressed tiff only), or freeimage, e.g. > `io.use_plugin('freeimage')` > > Christoph > > -- > You received this message because you are subscribed to the Google Groups > "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to scikit-image+unsubscribe@**googlegroups.com > . > For more options, visit https://groups.google.com/**groups/opt_out > . > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Mon May 27 09:48:46 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 27 May 2013 15:48:46 +0200 Subject: Weird imsave inverting behaviour In-Reply-To: References: <51A2E1E5.3000804@gmail.com> Message-ID: On Mon, May 27, 2013 at 3:08 PM, Juan Nunez-Iglesias wrote: > I think you have the right approach, ie imread() should just work. However, > what started this post is that it doesn't. =) Yes, that's a bug and should be fixed. St?fan From jni.soma at gmail.com Mon May 27 03:36:37 2013 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Mon, 27 May 2013 17:36:37 +1000 Subject: Weird imsave inverting behaviour In-Reply-To: References: <51A2E1E5.3000804@gmail.com> <7CCE1EFC-4581-4C41-8978-81F9FDA7FA46@demuc.de> Message-ID: Well, [0, 1] is great for working, but useless for saving. So what should the convention be for saving? And should we use single or double precision floats? I think in general it's hard to choose for users, and the best thing is to try to preserve user input type unless there's a good reason not to do so. Note that 16 bit grayscale images are fairly common, so assuming uint8 for the output is a no-no. On Mon, May 27, 2013 at 5:29 PM, Johannes Sch?nberger < jschoenberger at demuc.de> wrote: > `CONTRIBUTING.txt` > > Johannes Sch?nberger > > Am 27.05.2013 um 09:03 schrieb Ronnie Ghose : > > > Can I add that in the docs somewhere? hmm... the question is where > should general guidelines go.... > > > > > > On Mon, May 27, 2013 at 3:02 AM, Johannes Sch?nberger < > jschoenberger at demuc.de> wrote: > > IMO the convention is to use double ([0, 1]) everywhere, except in rare > cases?? > > > > Johannes Sch?nberger > > > > Am 27.05.2013 um 08:56 schrieb Ronnie Ghose : > > > > > can we just standardize it so that _everything_ uses one of the two > representations? If an algorithm needs it differently, it can do the > 256*array or array/256 and then again output this standard format > > > > > > > > > On Mon, May 27, 2013 at 2:55 AM, Ronnie Ghose > wrote: > > > while we're on the subject, it seems algorithms / arrays are mixing > using / wanting as input, [0,1] and [0,256] for grayscale, which leads to > unexpected results > > > > > > > > > On Mon, May 27, 2013 at 2:51 AM, Johannes Sch?nberger < > jschoenberger at demuc.de> wrote: > > > To be honest I agree, right now it is a mess, which is also the reason > why I have not touched this package yet. Things I noticed: > > > > > > - depending on the plugin, the code and comment / doc string quality > should be improved > > > - what's the purpose of _colormixer.pyx, _histogram.pyx, > q_histogram.py, q_color_mixer.py etc. and why are they in the io plugin > directory? > > > - the way plugins are managed should be overhauled and we should > discuss it together before implementation > > > > > > My ideas: > > > > > > - rather than having .ini files I would opt for `register(plugin, > desc, funcs, setup_func, *args, **kwargs)` and `unregister(plugin)` > functions. This enables also users to add new plugins at runtime. > > > > > > - `setup_func` should check whether the plugin is available on this > system. > > > > > > - what is indicated as `args` and `kwargs` above should definitely > contain two more things: an explicit whitelist of supported file formats, > extensions and dtypes or an explicit blacklist of file formats, extensions > and dtypes. This could be represented as a dictionary: > > > > > > {['png']: ['uint8', 'float', '?'], ['tif', 'tiff']: ? } > > > > > > It allows us to automatically select an available plugin for the > given data or raise an error. > > > > > > - Explicitly selecting a plugin should be possible through an extra > argument to `imread`, `imsave`. E.g. `imsave(file, data, > plugin='freeimage')`. > > > > > > > > > > > > > > > Johannes Sch?nberger > > > > > > Am 27.05.2013 um 07:27 schrieb Juan Nunez-Iglesias >: > > > > > > > OH. Right. That's what's happening, it's not inverted, it's looping > around with the overflow! (I was wondering why the correlation was not > closer to -1.) > > > > > > > > Guh. imho: > > > > > > > > - This really shouldn't happen. The plugin selection should be aware > of the data type, and use only a plugin that can handle it (if available) > > > > - PIL can definitely do 16bit PNG, so either it is being used > incorrectly, or the imsave docstring stating that PIL is the first > selection is wrong. I just tested this on my PIL-based Gala library, which > is 3D so it required a bit of modification: > > > > > > > > In [66]: imio.write_png_image_stack(s[np.newaxis, ...], > '~/Desktop/im%02i.png', axis=0 > > > > ) > > > > > > > > In [ > > > > 67]: srg = > imio.read_image_stack('/Users/nuneziglesiasj/Desktop/im0*.png' > > > > ) > > > > > > > > In [ > > > > 68 > > > > ]: srg.shape > > > > Out[ > > > > 68]: (1040, 1392 > > > > ) > > > > > > > > In [ > > > > 69 > > > > ]: (s == srg).all() > > > > Out[ > > > > 69]: True > > > > > > > > - The IO module is a mess! I know Stefan mentioned overhauling it > briefly, but I didn't quite realise how urgent that was. In particular: > > > > - is `from blah import *` used as a matter of policy or is it a > remnant of an earlier age? Took me ages to find the `call` function. > > > > - `plugin_store`? I have no idea where this gets updated. > > > > > > > > So, to the core skimage devs: what is the scope for updating this? > Am I allowed to break some functionality in a PR? Or are we sticking with > this API? > > > > > > > > > > > > On Mon, May 27, 2013 at 2:32 PM, Christoph Gohlke < > cjgohlke at gmail.com> wrote: > > > > On 5/26/2013 8:31 PM, Juan Nunez-Iglesias wrote: > > > > Hey all, > > > > > > > > I noticed that some of my microscopy images appeared inverted after > > > > saving them with skimage.io.imsave. After some testing, here's some > of > > > > the weirdness. My image is called s: > > > > > > > > ```python > > > > In [37]: np.min(s) > > > > Out[37]: 119 > > > > > > > > In [38]: np.max(s) > > > > Out[38]: 4095 > > > > > > > > In [39]: s.shape > > > > Out[39]: (1040, 1392) > > > > > > > > In [40]: s.dtype > > > > Out[40]: dtype('uint16') > > > > > > > > In [41]: io.imsave('/Users/nuneziglesiasj/Desktop/im.tif', s) > > > > > > > > In [42]: sr = io.imread('/Users/nuneziglesiasj/Desktop/im.tif') > > > > > > > > In [43]: (s == sr).all() > > > > Out[43]: Image(False, dtype=bool) > > > > > > > > In [44]: sr.min() > > > > Out[44]: Image(0, dtype=uint8) > > > > > > > > In [45]: sr.max() > > > > Out[45]: Image(255, dtype=uint8) > > > > ``` > > > > > > > > Ok, already this is not desirable... One would hope than an imsave > > > > followed by an imread would be a no-op, but whatever, let's accept > for > > > > argument's sake that we want to limit ourselves to uint8. Here's the > > > > real downer: > > > > > > > > ```python > > > > In [46]: np.corrcoef(s.ravel(), sr.ravel()) > > > > Out[46]: > > > > array([[ 1. , -0.29849602], > > > > [-0.29849602, 1. ]]) > > > > ``` > > > > > > > > This is simply unacceptable. I haven't explored any more than this > yet > > > > but maybe someone has an idea about what is going on here? If it > helps, > > > > the problem is with imsave ? opening the images in Apple Preview > shows > > > > the inversion. I just wanted to know if it was some weird > > > > incompatibility between skimage and Preview, rather than skimage > acting > > > > stupid. Sadly, it appears to be the latter. > > > > > > > > PS: I just tested with png and get the exact same result. > > > > > > > > > > > > Not many skimage.io plugins are capable of handling 16 bit data. > Use gdal (read only), tifffile (uncompressed tiff only), or freeimage, e.g. > `io.use_plugin('freeimage')` > > > > > > > > Christoph > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > Groups "scikit-image" group. > > > > To unsubscribe from this group and stop receiving emails from it, > send an email to scikit-image+unsubscribe at googlegroups.com. > > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > > > > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > Groups "scikit-image" group. > > > > To unsubscribe from this group and stop receiving emails from it, > send an email to scikit-image+unsubscribe at googlegroups.com. > > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google > Groups "scikit-image" group. > > > To unsubscribe from this group and stop receiving emails from it, send > an email to scikit-image+unsubscribe at googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google > Groups "scikit-image" group. > > > To unsubscribe from this group and stop receiving emails from it, send > an email to scikit-image+unsubscribe at googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > -- > > You received this message because you are subscribed to the Google > Groups "scikit-image" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to scikit-image+unsubscribe at googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > -- > > You received this message because you are subscribed to the Google > Groups "scikit-image" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to scikit-image+unsubscribe at googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > -- > You received this message because you are subscribed to the Google Groups > "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Mon May 27 14:22:14 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 27 May 2013 20:22:14 +0200 Subject: Mini Project In-Reply-To: References: Message-ID: Hi Ronnie Here's a little warm up project I ran into today that might be fun: http://encompass.gsfc.nasa.gov/caseStudies/CiSE-PIV.pdf Or you can try the deconvolution challenge: https://groups.google.com/d/msg/scikit-image/qW52uGjBhWc/tdk8Av4wDLEJ Or, if you want something more challenging, help this guy find a thief using super-resolution: http://www.reddit.com/r/AskReddit/comments/ch3t7/reddit_last_week_you_helped_me_look_for_the_guy/ Data set here: http://dl.dropbox.com/u/380268/stolen_car_subset.tar St?fan From stefan at sun.ac.za Mon May 27 14:25:58 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 27 May 2013 20:25:58 +0200 Subject: Mini Project In-Reply-To: References: Message-ID: Oh, and if that's not enough here's a whole slew of interesting topics to study: https://www.ceremade.dauphine.fr/~peyre/numerical-tour/tours/ From jni.soma at gmail.com Mon May 27 09:08:27 2013 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Mon, 27 May 2013 23:08:27 +1000 Subject: Weird imsave inverting behaviour In-Reply-To: References: <51A2E1E5.3000804@gmail.com> Message-ID: @stefanv On Mon, May 27, 2013 at 7:35 PM, St?fan van der Walt wrote: > > Unfortunately, there's a trade-off between having things "just work" > and the amount of magic that happens behind the scene. I think you have the right approach, ie imread() should just work. However, what started this post is that it doesn't. =) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschoenberger at demuc.de Mon May 27 17:39:58 2013 From: jschoenberger at demuc.de (=?windows-1252?Q?Johannes_Sch=F6nberger?=) Date: Mon, 27 May 2013 23:39:58 +0200 Subject: Cython / c++ help In-Reply-To: References: Message-ID: Where can I find clutil.py? Johannes Sch?nberger Am 27.05.2013 um 22:55 schrieb Marc de Klerk : > Hi Guys, > > I'm hoping that I could get some help and advice on c++ and Cython. > > I've written an OpenCL implementation for the prefix-sum algorithm which I use for generating a compacted lookup table for sparse binary array (called stream compacting) > The algorithm isn't really important right now, but just to show what it does here's an example? > > > > > > > > > > > > > > > > > > > > In the end, the result is a nice compact array of the indices that were flagged? > I'm mainly using it to know which tiles to process for grow cut of graph cut on the gpu like this: > > > This operation has to happen a lot? so I really need it to be fast. The problem I'm having is that the when I isolate and measure the execution time of the gpu code it's much faster than that of the c++ or Cython wrapper - which I cannot really do without. > > So I'm kinda hoping someone can help me to really squash the additional execution time from the overhead of the wrapper. > > Originally I wrote a Python then Cython wrapper and when looking at the difference between the execution time of just the gnu code vs the total time, I thought it must be from the overhead of the Python/Cython. But I've just written a c++ wrapper and it's not a whole lot faster than Python/Cython, but I'm still hoping there's a lot that can be done? > > Here are two graphs that might help explain? > The one below is measuring the execution time of just the gpu code in the 3 implementations. They should be exactly the same and > they are more or less. > > > > The problem is this next graph?. Besides the difference between the c++ and the other two, there's still a large difference between the c++ > plot and the plots in the graph above... > > > > The code is all on https://github.com/mdeklerk/cl-util > The files of interest are pyPrefixSum.py, PrefixSum.pyx, which can be tested with test_PrefixSum and PrefixSum.cpp which just needs to be compiled ran? > > If you've gotten this far, thanks for reading it, I hope it's clear :) > I'll greatly appreciate any help, even pointing me more or less in the right direction etc? > > Cheers, > Marc > > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > From jschoenberger at demuc.de Mon May 27 17:41:49 2013 From: jschoenberger at demuc.de (=?windows-1252?Q?Johannes_Sch=F6nberger?=) Date: Mon, 27 May 2013 23:41:49 +0200 Subject: Cython / c++ help In-Reply-To: References: Message-ID: <535558E0-D351-469D-9A06-1EAE11A8439B@demuc.de> Sorry, do not know why I did not see it ? Johannes Sch?nberger Am 27.05.2013 um 23:39 schrieb Johannes Sch?nberger : > Where can I find clutil.py? > > Johannes Sch?nberger > > Am 27.05.2013 um 22:55 schrieb Marc de Klerk : > >> Hi Guys, >> >> I'm hoping that I could get some help and advice on c++ and Cython. >> >> I've written an OpenCL implementation for the prefix-sum algorithm which I use for generating a compacted lookup table for sparse binary array (called stream compacting) >> The algorithm isn't really important right now, but just to show what it does here's an example? >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> In the end, the result is a nice compact array of the indices that were flagged? >> I'm mainly using it to know which tiles to process for grow cut of graph cut on the gpu like this: >> >> >> This operation has to happen a lot? so I really need it to be fast. The problem I'm having is that the when I isolate and measure the execution time of the gpu code it's much faster than that of the c++ or Cython wrapper - which I cannot really do without. >> >> So I'm kinda hoping someone can help me to really squash the additional execution time from the overhead of the wrapper. >> >> Originally I wrote a Python then Cython wrapper and when looking at the difference between the execution time of just the gnu code vs the total time, I thought it must be from the overhead of the Python/Cython. But I've just written a c++ wrapper and it's not a whole lot faster than Python/Cython, but I'm still hoping there's a lot that can be done? >> >> Here are two graphs that might help explain? >> The one below is measuring the execution time of just the gpu code in the 3 implementations. They should be exactly the same and >> they are more or less. >> >> >> >> The problem is this next graph?. Besides the difference between the c++ and the other two, there's still a large difference between the c++ >> plot and the plots in the graph above... >> >> >> >> The code is all on https://github.com/mdeklerk/cl-util >> The files of interest are pyPrefixSum.py, PrefixSum.pyx, which can be tested with test_PrefixSum and PrefixSum.cpp which just needs to be compiled ran? >> >> If you've gotten this far, thanks for reading it, I hope it's clear :) >> I'll greatly appreciate any help, even pointing me more or less in the right direction etc? >> >> Cheers, >> Marc >> >> >> -- >> You received this message because you are subscribed to the Google Groups "scikit-image" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> > From stefan at sun.ac.za Mon May 27 17:54:50 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 27 May 2013 23:54:50 +0200 Subject: Cython / c++ help In-Reply-To: References: Message-ID: On Mon, May 27, 2013 at 10:55 PM, Marc de Klerk wrote: > This operation has to happen a lot? so I really need it to be fast. The > problem I'm having is that the when I isolate and measure the execution > time of the gpu code it's much faster than that of the c++ or Cython > wrapper - which I cannot really do without. > Another option is also to call into the NumPy C API to evoke essentially the equivalent of np.nonzero(np.diff(np.cumsum(x)))[0] + 1 St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Mon May 27 17:59:03 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 27 May 2013 23:59:03 +0200 Subject: Cython / c++ help In-Reply-To: References: Message-ID: On Mon, May 27, 2013 at 10:55 PM, Marc de Klerk wrote: > The problem is this next graph?. Besides the difference between the c++ > and the other two, there's still a large difference between the c++ > Can you just explain again the difference between the two plots above? St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From deklerkmc at gmail.com Tue May 28 08:37:49 2013 From: deklerkmc at gmail.com (Marc de Klerk) Date: Tue, 28 May 2013 05:37:49 -0700 (PDT) Subject: Cython / c++ help In-Reply-To: References: Message-ID: Hi St?fan, Johannes, Thanks for having a read through this... I've tried to explain the reason why I shouldn't perform the prefix/cumulative sum on the CPU using numpy etc in this diagram... In method 1 I have to ship the entire flag array, build the compacted array and ship it back. I've also tested cumsum with timeit and I'm certain the CPU prefix-sum algorithms are simply too slow.. >> timeit.timeit('np.cumsum(x)', setup='import numpy as np; x = np.random.random_integers(0, 10, 1850)') >> 8.654011964797974 Method 2 just requires that the length of the queue be shipped across to the CPU to know have many threads to execture the GPU method gpu_process_tiles() with. On Monday, May 27, 2013 11:54:50 PM UTC+2, Stefan van der Walt wrote: > > On Mon, May 27, 2013 at 10:55 PM, Marc de Klerk > > wrote: > >> This operation has to happen a lot? so I really need it to be fast. The >> problem I'm having is that the when I isolate and measure the execution >> time of the gpu code it's much faster than that of the c++ or Cython >> wrapper - which I cannot really do without. >> > > Another option is also to call into the NumPy C API to evoke essentially > the equivalent of > > np.nonzero(np.diff(np.cumsum(x)))[0] + 1 > > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deklerkmc at gmail.com Tue May 28 08:42:08 2013 From: deklerkmc at gmail.com (Marc de Klerk) Date: Tue, 28 May 2013 05:42:08 -0700 (PDT) Subject: Cython / c++ help In-Reply-To: References: Message-ID: <9a012cb1-fa78-4051-af7e-d51be94786c0@googlegroups.com> Hi Johannes, Yeah I was thinking about that... The gpu code doesn't execute straight away - it's scheduled by the OpenCL implementation... So it usually just executes when the GPU is not busy doing it's usual rendering job. There''s not going to be any way to avoid the wait... I haven't had much experience with profiling c++ code like you did in the previous screenshot - could you tell me how to go about it? I think the matter is closed then. Thanks very much for the help! On Tuesday, May 28, 2013 8:00:03 AM UTC+2, Johannes Sch?nberger wrote: > > Maybe this can help you: http://pastebin.com/raw.php?i=vPwFpVRt > > You mostly wait for event.wait()? > > > Johannes Sch?nberger > > Am 27.05.2013 um 23:59 schrieb St?fan van der Walt >: > > > > On Mon, May 27, 2013 at 10:55 PM, Marc de Klerk > > wrote: > > The problem is this next graph?. Besides the difference between the c++ > and the other two, there's still a large difference between the c++ > > > > Can you just explain again the difference between the two plots above? > > > > St?fan > > > > -- > > You received this message because you are subscribed to the Google > Groups "scikit-image" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to scikit-image... at googlegroups.com . > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschoenberger at demuc.de Tue May 28 02:00:03 2013 From: jschoenberger at demuc.de (=?windows-1252?Q?Johannes_Sch=F6nberger?=) Date: Tue, 28 May 2013 08:00:03 +0200 Subject: Cython / c++ help In-Reply-To: References: Message-ID: Maybe this can help you: http://pastebin.com/raw.php?i=vPwFpVRt You mostly wait for event.wait()? Johannes Sch?nberger Am 27.05.2013 um 23:59 schrieb St?fan van der Walt : > On Mon, May 27, 2013 at 10:55 PM, Marc de Klerk wrote: > The problem is this next graph?. Besides the difference between the c++ and the other two, there's still a large difference between the c++ > > Can you just explain again the difference between the two plots above? > > St?fan > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > From dfarmernv at gmail.com Tue May 28 12:43:59 2013 From: dfarmernv at gmail.com (Dan Farmer) Date: Tue, 28 May 2013 09:43:59 -0700 (PDT) Subject: Walking circle_perimeter Message-ID: Hi Guys, I'm trying to subsample the points returned by circle_perimeter and I'm having trouble. Since the points are calculated in octants (and reflected?) it makes walking it somewhat confusing (see below) Does anyone know off hand how I could walk this thing clockwise for example (or produce a sensible subsample of e.g., every other point or every 4th point, etc). To be a little more concrete: from skimage.draw import circle_perimeter rr, cc = circle_perimeter(12, 12, 10) im = zeros((40,40)) im[rr[::4],cc[::4]] = 1 imshow(im, cmap=cm.gray) # returns one quadrant of the circle Still Googling, but I'd appreciate any help =) Thanks, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschoenberger at demuc.de Tue May 28 09:00:39 2013 From: jschoenberger at demuc.de (=?windows-1252?Q?Johannes_Sch=F6nberger?=) Date: Tue, 28 May 2013 15:00:39 +0200 Subject: Cython / c++ help In-Reply-To: <9a012cb1-fa78-4051-af7e-d51be94786c0@googlegroups.com> References: <9a012cb1-fa78-4051-af7e-d51be94786c0@googlegroups.com> Message-ID: <6DFFF2A2-C7CF-48CB-9195-7226BD187546@demuc.de> I used the line_profiler package on the Python side, but for C/C++ debugging I recommend gdb / gprof / valgrind. Johannes Sch?nberger Am 28.05.2013 um 14:42 schrieb Marc de Klerk : > Hi Johannes, > > Yeah I was thinking about that... The gpu code doesn't execute straight away - it's scheduled by the OpenCL implementation... > So it usually just executes when the GPU is not busy doing it's usual rendering job. > There''s not going to be any way to avoid the wait... > > I haven't had much experience with profiling c++ code like you did in the previous screenshot - could you tell me how to go about it? > > I think the matter is closed then. > Thanks very much for the help! > > > On Tuesday, May 28, 2013 8:00:03 AM UTC+2, Johannes Sch?nberger wrote: > Maybe this can help you: http://pastebin.com/raw.php?i=vPwFpVRt > > You mostly wait for event.wait()? > > > Johannes Sch?nberger > > Am 27.05.2013 um 23:59 schrieb St?fan van der Walt : > > > On Mon, May 27, 2013 at 10:55 PM, Marc de Klerk wrote: > > The problem is this next graph?. Besides the difference between the c++ and the other two, there's still a large difference between the c++ > > > > Can you just explain again the difference between the two plots above? > > > > St?fan > > > > -- > > You received this message because you are subscribed to the Google Groups "scikit-image" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image... at googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > From stefan at sun.ac.za Tue May 28 10:46:23 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 28 May 2013 16:46:23 +0200 Subject: Cython / c++ help In-Reply-To: <6DFFF2A2-C7CF-48CB-9195-7226BD187546@demuc.de> References: <9a012cb1-fa78-4051-af7e-d51be94786c0@googlegroups.com> <6DFFF2A2-C7CF-48CB-9195-7226BD187546@demuc.de> Message-ID: On Tue, May 28, 2013 at 3:00 PM, Johannes Sch?nberger wrote: > I used the line_profiler package on the Python side, but for C/C++ debugging I recommend gdb / gprof / valgrind. I usually combine Valgrind with kcachegrind--the visualization sometimes helps a lot. St?fan From stefan at sun.ac.za Tue May 28 10:46:53 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 28 May 2013 16:46:53 +0200 Subject: Cython / c++ help In-Reply-To: References: <9a012cb1-fa78-4051-af7e-d51be94786c0@googlegroups.com> <6DFFF2A2-C7CF-48CB-9195-7226BD187546@demuc.de> Message-ID: On Tue, May 28, 2013 at 4:46 PM, St?fan van der Walt wrote: > On Tue, May 28, 2013 at 3:00 PM, Johannes Sch?nberger > wrote: >> I used the line_profiler package on the Python side, but for C/C++ debugging I recommend gdb / gprof / valgrind. > > I usually combine Valgrind with kcachegrind--the visualization > sometimes helps a lot. Oh, and since you are on OSX, you can probably use their Instruments package just as easily. St?fan From jschoenberger at demuc.de Tue May 28 16:40:05 2013 From: jschoenberger at demuc.de (=?windows-1252?Q?Johannes_Sch=F6nberger?=) Date: Tue, 28 May 2013 22:40:05 +0200 Subject: Walking circle_perimeter In-Reply-To: References: Message-ID: <99FAD891-9909-45FA-A137-C561580B1E82@demuc.de> This should do the trick? import numpy as np import pylab from skimage.draw import circle_perimeter img = np.zeros((41, 41)) rr, cc = circle_perimeter(20, 20, 18) SKIP_SIZE = 3 img[rr, cc] = 5 for i in range(4): rri = rr[i::4] cci = cc[i::4] rri_sorted = np.argsort(rri) rri = rri[rri_sorted] cci = cci[rri_sorted] cci_sorted = np.argsort(cci) rri = rri[cci_sorted] cci = cci[cci_sorted] img[rri[::SKIP_SIZE], cci[::SKIP_SIZE]] = 1 pylab.imshow(img, interpolation='nearest') pylab.show() Johannes Sch?nberger Am 28.05.2013 um 18:43 schrieb Dan Farmer : > Hi Guys, > > I'm trying to subsample the points returned by circle_perimeter and I'm having trouble. Since the points are calculated in octants (and reflected?) it makes walking it somewhat confusing (see below) Does anyone know off hand how I could walk this thing clockwise for example (or produce a sensible subsample of e.g., every other point or every 4th point, etc). > > To be a little more concrete: > > from skimage.draw import circle_perimeter > > rr, cc = circle_perimeter(12, 12, 10) > im = zeros((40,40)) > im[rr[::4],cc[::4]] = 1 > imshow(im, cmap=cm.gray) > # returns one quadrant of the circle > > Still Googling, but I'd appreciate any help =) > > Thanks, > Dan > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > From jschoenberger at demuc.de Tue May 28 16:45:26 2013 From: jschoenberger at demuc.de (=?windows-1252?Q?Johannes_Sch=F6nberger?=) Date: Tue, 28 May 2013 22:45:26 +0200 Subject: Walking circle_perimeter In-Reply-To: <99FAD891-9909-45FA-A137-C561580B1E82@demuc.de> References: <99FAD891-9909-45FA-A137-C561580B1E82@demuc.de> Message-ID: <8D1A7079-C372-498F-8B4B-8BC64A1F2018@demuc.de> A much better way came to my mind: import numpy as np import pylab from skimage.draw import circle_perimeter img = np.zeros((41, 41)) center_r = center_c = 20 rr, cc = circle_perimeter(center_r, center_c, 18) t = np.arctan2(rr - center_r, cc - center_c) t_sorted = np.argsort(t) rr = rr[t_sorted] cc = cc[t_sorted] img[rr[::4], cc[::4]] = 1 pylab.imshow(img, interpolation='nearest') pylab.show() Johannes Sch?nberger Am 28.05.2013 um 22:40 schrieb Johannes Sch?nberger : > This should do the trick? > > import numpy as np > import pylab > from skimage.draw import circle_perimeter > > img = np.zeros((41, 41)) > rr, cc = circle_perimeter(20, 20, 18) > > SKIP_SIZE = 3 > > img[rr, cc] = 5 > > for i in range(4): > rri = rr[i::4] > cci = cc[i::4] > rri_sorted = np.argsort(rri) > rri = rri[rri_sorted] > cci = cci[rri_sorted] > cci_sorted = np.argsort(cci) > rri = rri[cci_sorted] > cci = cci[cci_sorted] > img[rri[::SKIP_SIZE], cci[::SKIP_SIZE]] = 1 > > pylab.imshow(img, interpolation='nearest') > pylab.show() > > > Johannes Sch?nberger > > Am 28.05.2013 um 18:43 schrieb Dan Farmer : > >> Hi Guys, >> >> I'm trying to subsample the points returned by circle_perimeter and I'm having trouble. Since the points are calculated in octants (and reflected?) it makes walking it somewhat confusing (see below) Does anyone know off hand how I could walk this thing clockwise for example (or produce a sensible subsample of e.g., every other point or every 4th point, etc). >> >> To be a little more concrete: >> >> from skimage.draw import circle_perimeter >> >> rr, cc = circle_perimeter(12, 12, 10) >> im = zeros((40,40)) >> im[rr[::4],cc[::4]] = 1 >> imshow(im, cmap=cm.gray) >> # returns one quadrant of the circle >> >> Still Googling, but I'd appreciate any help =) >> >> Thanks, >> Dan >> >> -- >> You received this message because you are subscribed to the Google Groups "scikit-image" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > From deklerkmc at gmail.com Wed May 29 02:35:25 2013 From: deklerkmc at gmail.com (Marc de Klerk) Date: Tue, 28 May 2013 23:35:25 -0700 (PDT) Subject: Cython / c++ help In-Reply-To: References: <9a012cb1-fa78-4051-af7e-d51be94786c0@googlegroups.com> <6DFFF2A2-C7CF-48CB-9195-7226BD187546@demuc.de> Message-ID: <8216f819-95f4-4001-8740-c7822fd6539f@googlegroups.com> Will give them a try - thanks guys On Tuesday, May 28, 2013 4:46:53 PM UTC+2, Stefan van der Walt wrote: > > On Tue, May 28, 2013 at 4:46 PM, St?fan van der Walt > > wrote: > > On Tue, May 28, 2013 at 3:00 PM, Johannes Sch?nberger > > > wrote: > >> I used the line_profiler package on the Python side, but for C/C++ > debugging I recommend gdb / gprof / valgrind. > > > > I usually combine Valgrind with kcachegrind--the visualization > > sometimes helps a lot. > > Oh, and since you are on OSX, you can probably use their Instruments > package just as easily. > > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Wed May 29 06:37:01 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 29 May 2013 12:37:01 +0200 Subject: Cython guidelines Message-ID: Hi everyone Two Cython related suggestions: 1) We should raise the dependency to 0.16 and start using memoryviews (they are much faster) 2) When documenting Cython functions, remember to include default values in the docstring--one cannot introspect these function signatures from IPython! St?fan From silvertrumpet999 at gmail.com Wed May 29 19:26:34 2013 From: silvertrumpet999 at gmail.com (Josh Warner) Date: Wed, 29 May 2013 16:26:34 -0700 (PDT) Subject: Cython guidelines In-Reply-To: References: Message-ID: <784ff92b-0705-45a3-be99-35b2670e8c34@googlegroups.com> +1 for both of these. Should we add them to `CONTRIBUTING.txt`? One gotcha I ran into with memoryviews that might be relevant to others: I got over-exuberant and memoryviewed everything, including the output array, which created problems. Unless I missed something, to return NumPy arrays we still need the `cnp.ndarray(...)` syntax for output(s). On Wednesday, May 29, 2013 5:37:01 AM UTC-5, Stefan van der Walt wrote: > > Hi everyone > > Two Cython related suggestions: > > 1) We should raise the dependency to 0.16 and start using memoryviews > (they are much faster) > 2) When documenting Cython functions, remember to include default > values in the docstring--one cannot introspect these function > signatures from IPython! > > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Wed May 29 20:37:37 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 30 May 2013 02:37:37 +0200 Subject: Cython guidelines In-Reply-To: <784ff92b-0705-45a3-be99-35b2670e8c34@googlegroups.com> References: <784ff92b-0705-45a3-be99-35b2670e8c34@googlegroups.com> Message-ID: On May 30, 2013 1:26 AM, "Josh Warner" wrote: > > +1 for both of these. Should we add them to `CONTRIBUTING.txt`? Sure, go ahead please. > I got over-exuberant and memoryviewed everything, including the output array, which created problems. Unless I missed something, to return NumPy arrays we still need the `cnp.ndarray(...)` syntax for output(s). Yes, you need to wrap the output in an np.asarray statement to convert a memoryview to an ndarray. St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: