Mailman 3 May 2013 - scikit-image

Re: Converting a numpy array to grayscale
by Brickle Macho 17 May '13

17 May '13

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 > <bricklemacho(a)gmail.com <mailto:bricklemacho@gmail.com>> wrote: > > I porting a 8 line Matlab script. > > > <snip> > > > 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(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > >

1 0

Converting a numpy array to grayscale
by Brickle Macho 17 May '13

17 May '13

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. --

3 3

Re: Some ideas for skimage
by Johannes Schönberger 17 May '13

17 May '13

+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 <aaaagrawal(a)gmail.com>: > @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(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > >

2 1

Re: Some ideas for skimage
by Ankit Agrawal 17 May '13

17 May '13

@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.

1 0

Re: Some ideas for skimage
by Nelle Varoquaux 17 May '13

17 May '13

On 17 May 2013 09:29, Stéfan van der Walt <stefan(a)sun.ac.za> wrote: > On Fri, May 17, 2013 at 3:42 AM, Josh Warner <silvertrumpet999(a)gmail.com> > 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(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > >

1 0

Re: Some ideas for skimage
by Josh Warner 17 May '13

17 May '13

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 <aaaag...(a)gmail.com<javascript:>> > 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 >

2 1

Some ideas for skimage
by Ankit Agrawal 16 May '13

16 May '13

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<https://github.com/scikit-image/scikit-image/pulls/ankit-maverick>. Thank you. Regards, Ankit Agrawal, Communication and Signal Processing, IIT Bombay.

3 2

Re: GSoC: Photomontage and Panoram Stitching
by Fedor Morozov 12 May '13

12 May '13

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.

2 2

Re: skimage.filter.rank.percentile usage question
by Josh Warner 10 May '13

10 May '13

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 <dtype_t>(i) else: return <dtype_t>(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? >

2 1

skimage.filter.rank.percentile usage question
by Juan Nunez-Iglesias 09 May '13

09 May '13

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?

1 0