From mob.irl at gmail.com Fri Mar 3 09:43:24 2017 From: mob.irl at gmail.com (Michael O'Brien) Date: Fri, 03 Mar 2017 14:43:24 +0000 Subject: [scikit-image] Converting RGB values from pandas dataframe to LAB Message-ID: Hi all, I was hoping the community may be able to help me. I want to convert rgb values to their L*A*B* value but I'm not sure of the best way to do so so the setup will scale when the dataframe size increases. I saw on stackoverflow that skimage's conversion method http://scikit-image.org/docs/dev/api/skimage.color.html?highlight=rgb2lab#skimage.color.rgb2lab was suggested to be faster than alternatives but I'm having trouble understanding how to use my dataframe as the input instead of an image and if the conversion is successful how I can store the LAB values back into the dataframe. At the moment my dataframe has a shape ? (827, 8) where Rgb_r, Rgb_g, Rgb_b are the column names I'm interested in, you could think of the dataframe of 827 individual pixels with associated metadata. Is it possible to pass a pandas dataframe to scikit-image color.rgb2.lab or should I do row by row calculates for the situation where the number of rows increases to possibly 200,000 or more Hope you can help me Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From jni.soma at gmail.com Fri Mar 3 18:48:06 2017 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Sat, 4 Mar 2017 10:48:06 +1100 Subject: [scikit-image] Converting RGB values from pandas dataframe to LAB In-Reply-To: References: Message-ID: Hi Michael, You can use the `.values` property to get a NumPy array out of a pandas DataFrame. After that it?s just a matter of slight reshaping to make skimage think that it?s a long, thin image. =) ======================================== In [1]: x = np.array([[0, 0, 255], [55, 0, 25], [4, 0, 5]]).astype(np.uint8) In [2]: from skimage import img_as_float, color In [12]: x = img_as_float(x) In [15]: df = pd.DataFrame(dict(RGB_r=x[:, 0], RGB_g=x[:, 1], RGB_b=x[:, 2])) In [16]: df[['RGB_r', 'RGB_g', 'RGB_b']].values Out[16]: array([[ 0. ? ? ? ?, ?0. ? ? ? ?, ?1. ? ? ? ?], ? ? ? ?[ 0.21568627, ?0. ? ? ? ?, ?0.09803922], ? ? ? ?[ 0.01568627, ?0. ? ? ? ?, ?0.01960784]]) In [17]: lab = color.rgb2lab(df[['RGB_r', 'RGB_g?, 'RGB_b']].values[np.newaxis])[0] In [18]: lab Out[18]: array([[ ?32.29567257, ? 79.18559091, -107.85730021], ? ? ? ?[ ? 7.97293614, ? 28.7263062 , ? -0.51735934], ? ? ? ?[ ? 0.33216914, ? ?1.74121634, ? -1.52356365]]) In [19]: df['Lab_l'], df['Lab_a'], df['Lab_b'] = lab.T In [20]: df Out[20]: ? ? ? RGB_b ?RGB_g ? ? RGB_r ? ? ?Lab_l ? ? ?Lab_a ? ? ? Lab_b 0 ?1.000000 ? ?0.0 ?0.000000 ?32.295673 ?79.185591 -107.857300 1 ?0.098039 ? ?0.0 ?0.215686 ? 7.972936 ?28.726306 ? -0.517359 2 ?0.019608 ? ?0.0 ?0.015686 ? 0.332169 ? 1.741216 ? -1.523564 ======================================== Just make sure your RGB values are in the right data type and range for scikit-image: http://scikit-image.org/docs/dev/user_guide/data_types.html Typically that means uint8s in [0, 255] or floats in [0, 1]. Hope this helps! Juan. On 4 Mar 2017, 1:44 AM +1100, Michael O'Brien , wrote: > Hi all, > > I was hoping the community may be able to help me. I want to convert rgb values to their L*A*B* value but I'm not sure of the best way to do so so the setup will scale when the dataframe size increases. > > I saw on stackoverflow that skimage's conversion method http://scikit-image.org/docs/dev/api/skimage.color.html?highlight=rgb2lab#skimage.color.rgb2lab ?was suggested to be faster than alternatives but I'm having trouble understanding how to use my dataframe as the input instead of an image and if the conversion is successful how I can store the LAB values back into the dataframe. At the moment my dataframe has a shape > > (827, 8) where Rgb_r, Rgb_g, Rgb_b are the column names I'm interested in, you could think of the dataframe of 827 individual pixels with associated metadata. > > Is it possible to pass a pandas dataframe to scikit-image color.rgb2.lab or should I do row by row calculates for the situation where the number of rows increases to possibly 200,000 or more > > Hope you can help me > > Michael > _______________________________________________ > scikit-image mailing list > scikit-image at python.org > https://mail.python.org/mailman/listinfo/scikit-image -------------- next part -------------- An HTML attachment was scrubbed... URL: From mob.irl at gmail.com Sun Mar 5 12:50:50 2017 From: mob.irl at gmail.com (Michael O'Brien) Date: Sun, 05 Mar 2017 17:50:50 +0000 Subject: [scikit-image] Converting RGB values from pandas dataframe to LAB In-Reply-To: References: Message-ID: Thanks Juan and Michael for your knowledge and time. I did have to convert my dtype int64 rgb values to uint8 then used went with Juan's suggestion to use img_as_float to scale them to floating point values within the confines required by scikit-image and then added a newaxis to make the input np array suitable for rgb2lab which returned me a structure ? (1, 827, 3) so used [0] to get a shape of (827,3) before transposing L*, A* and B* into my original dataframe. Thanks Gents, learned alot but I suspect its only the start of my required learning :) On Fri, 3 Mar 2017 at 23:51 Juan Nunez-Iglesias wrote: > Hi Michael, > > You can use the `.values` property to get a NumPy array out of a pandas > DataFrame. After that it?s just a matter of slight reshaping to make > skimage think that it?s a long, thin image. =) > > ======================================== > > In [1]: x = np.array([[0, 0, 255], [55, 0, 25], [4, 0, > 5]]).astype(np.uint8) > > In [2]: from skimage import img_as_float, color > > In [12]: x = img_as_float(x) > > In [15]: df = pd.DataFrame(dict(RGB_r=x[:, 0], RGB_g=x[:, 1], RGB_b=x[:, > 2])) > > In [16]: df[['RGB_r', 'RGB_g', 'RGB_b']].values > Out[16]: > array([[ 0. , 0. , 1. ], > [ 0.21568627, 0. , 0.09803922], > [ 0.01568627, 0. , 0.01960784]]) > > In [17]: lab = color.rgb2lab(df[['RGB_r', 'RGB_g?, > 'RGB_b']].values[np.newaxis])[0] > > In [18]: lab > Out[18]: > array([[ 32.29567257, 79.18559091, -107.85730021], > [ 7.97293614, 28.7263062 , -0.51735934], > [ 0.33216914, 1.74121634, -1.52356365]]) > > In [19]: df['Lab_l'], df['Lab_a'], df['Lab_b'] = lab.T > > In [20]: df > Out[20]: > RGB_b RGB_g RGB_r Lab_l Lab_a Lab_b > 0 1.000000 0.0 0.000000 32.295673 79.185591 -107.857300 > 1 0.098039 0.0 0.215686 7.972936 28.726306 -0.517359 > 2 0.019608 0.0 0.015686 0.332169 1.741216 -1.523564 > > ======================================== > > Just make sure your RGB values are in the right data type and range for > scikit-image: > http://scikit-image.org/docs/dev/user_guide/data_types.html > > Typically that means uint8s in [0, 255] or floats in [0, 1]. > > Hope this helps! > > Juan. > > On 4 Mar 2017, 1:44 AM +1100, Michael O'Brien , wrote: > > Hi all, > > I was hoping the community may be able to help me. I want to convert rgb > values to their L*A*B* value but I'm not sure of the best way to do so so > the setup will scale when the dataframe size increases. > > I saw on stackoverflow that skimage's conversion method > http://scikit-image.org/docs/dev/api/skimage.color.html?highlight=rgb2lab#skimage.color.rgb2lab > was suggested to be faster than alternatives but I'm having trouble > understanding how to use my dataframe as the input instead of an image and > if the conversion is successful how I can store the LAB values back into > the dataframe. At the moment my dataframe has a shape ? > > (827, 8) where Rgb_r, Rgb_g, Rgb_b are the column names I'm interested in, you could think of the dataframe of 827 individual pixels with associated metadata. > > Is it possible to pass a pandas dataframe to scikit-image color.rgb2.lab or should I do row by row calculates for the situation where the number of rows increases to possibly 200,000 or more > > Hope you can help me > > Michael > > _______________________________________________ > scikit-image mailing list > scikit-image at python.org > https://mail.python.org/mailman/listinfo/scikit-image > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Sun Mar 5 17:48:58 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Sun, 05 Mar 2017 14:48:58 -0800 Subject: [scikit-image] Docathon starting tomorrow Message-ID: <1488754138.93666.901256048.44C35BFC@webmail.messagingengine.com> Hi, everyone A reminder that the Docathon starts tomorrow, 6 March. Please join us by improving the documentation for your favorite function, adding an example to the gallery, or helping with the docs tooling for scikit-image. https://bids.github.io/docathon/pages/projects/scikit-image.html Please prefix all documentation commits with "DOC:" so that we can get ahead in the leaderboard :) Best regards St?fan From sohamidha at gmail.com Tue Mar 7 09:11:25 2017 From: sohamidha at gmail.com (Soha Midha) Date: Tue, 7 Mar 2017 19:41:25 +0530 Subject: [scikit-image] Regarding RGSoC'17 Message-ID: Hi, Good Evening! My team applying for the RGSoC'17. We are interested in the project scikit-image. We understand and can write code in Python and have been learning Python past one month. Also we have already worked with Image Processing Toolbox of MATLAB in one of our project (implemented a code for Finger Vein Recognition Based on a Personalized Best Bit Map) and are familiar with the various terminologies used in image analysis with 2-D images. There are various resources to learn as mentioned in the project page of RGSoC ,so, it won't be difficult t pick up this project .But there are so many tasks, it's kind of difficult to choose a focused goal that could be completed in three months. Can anyone please guide me what tasks and features are best suited for us? Thanks, Soha Midha -------------- next part -------------- An HTML attachment was scrubbed... URL: From marianne.corvellec at ens-lyon.org Thu Mar 9 10:21:51 2017 From: marianne.corvellec at ens-lyon.org (Marianne Corvellec) Date: Thu, 9 Mar 2017 10:21:51 -0500 Subject: [scikit-image] IPTA Message-ID: Hello, Only lurking on this list and in the world of image processing... By any chance, do some scikit-image folks participate in http://www.ipta-conference.com/ipta17/ ? Thank you, Marianne From jni.soma at gmail.com Fri Mar 10 03:57:54 2017 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Fri, 10 Mar 2017 19:57:54 +1100 Subject: [scikit-image] Regarding RGSoC'17 In-Reply-To: References: Message-ID: <15566f87-ff86-4c45-aaed-ba156fe4dec1@Spark> Hi Soha, Sorry for the delay in responding. Are you asking about what you can do as a project, or a small task to make a contribution to include in your application? For the project task, please look at our two papers, which include some ideas for a roadmap. For a small task, you can look at our github issues list, as well as image analysis questions on stack overflow for Python. Many of them contain great ideas for documentation improvements! Juan. On 8 Mar 2017, 1:11 AM +1100, Soha Midha , wrote: > Hi, > > Good Evening! > My team applying for the RGSoC'17. We are interested in the project scikit-image. We understand and can write code in Python and have been learning Python past one month. Also we have already worked with Image Processing Toolbox of MATLAB in one of our project (implemented a code for Finger Vein Recognition Based on a Personalized Best Bit Map) and are familiar with the various terminologies used in image analysis with 2-D images. There are various resources? to learn as mentioned in the project page of RGSoC ,so, it won't be difficult t pick up this project .But there are so many tasks, it's kind of difficult to choose a focused goal that could be completed in three months. > Can anyone please guide me what tasks and features are best suited for us? > > Thanks, > Soha Midha > _______________________________________________ > scikit-image mailing list > scikit-image at python.org > https://mail.python.org/mailman/listinfo/scikit-image -------------- next part -------------- An HTML attachment was scrubbed... URL: From noflaco at gmail.com Wed Mar 15 12:05:23 2017 From: noflaco at gmail.com (Carlton Banks) Date: Wed, 15 Mar 2017 17:05:23 +0100 Subject: [scikit-image] Warning from view_as_blocks Message-ID: I am currently using view_as_blocks to extract sub matrices from a bigger matrices, these submatrices has to non-overlapping. but i am getting this error: /usr/local/lib/python2.7/dist-packages/skimage/util/shape.py:94: RuntimeWarning: Cannot provide views on a non-contiguous input array without copying. warn(RuntimeWarning("Cannot provide views on a non-contiguous input " Something i should be worried about? -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Wed Mar 15 12:59:42 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Wed, 15 Mar 2017 09:59:42 -0700 Subject: [scikit-image] Warning from view_as_blocks In-Reply-To: References: Message-ID: <1489597182.1008511.912374216.1416DF16@webmail.messagingengine.com> Hi Carlton On Wed, Mar 15, 2017, at 09:05, Carlton Banks wrote: > but i am getting this error: > > /usr/local/lib/python2.7/dist-packages/skimage/util/shape.py:94: > RuntimeWarning: Cannot provide views on a non-contiguous input array > without copying. warn(RuntimeWarning("Cannot provide views on a non- > contiguous input " > > Something i should be worried about? If you start with a contiguous array (roughly speaking, where all values are stored in a single block of memory), view_as_blocks can provide a new "view" on the array without making any copies of the underlying data: it does this by manipulating the array strides. This is not always possible, so while it will still create the structure you seek, it makes a copy underneath the hood. We warn users about this, because it may be slow, and it may impact memory use. Best regards St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From himanshu.mishra.kgp at gmail.com Mon Mar 20 15:24:33 2017 From: himanshu.mishra.kgp at gmail.com (Himanshu Mishra) Date: Mon, 20 Mar 2017 19:24:33 +0000 Subject: [scikit-image] Request to try a GitHub integration for automatic code style review | "PEP8Speaks" Message-ID: Hello everyone, I had made small contributions to scikit-image during January 2016 during my initial days of learning Image Processing. It was really fun and I am thankful to the community. I am not sure if this is the right place to talk about it, but a lot of times I have witnessed reviewers leave a little comment after reviewing the whole PR, and it is more or less about "some style issues. :)". It should be better for the reviewer to focus more on the implementation of the PR and leave the style issues to a bot. Thinking this in mind, a while ago, I created a Github Integration called PEP8 Speaks which automatically reviews the code style and comments on the Pull Request. It is written in Python and is open source. Github - https://github.com/orkohunter/pep8speaks Few pointers about it: 1. The bot puts all its efforts in not being annoying. It makes a single comment (within seconds), and keeps updating it as the user updates the PR. 2. It supports all of the configurations of pycodestyle (formerly known as pep8)[1]. So, line length, specific error ignores, etc. are all possible and can be customized. 3. The bot upon asking, can suggest a diff of changes and/or create a PR against that branch with the fixes. Few users of the integration include SunPy and scikit-learn-contrib. I would appreciate any feedback from the scikit-image community about the idea or the integration. Keenly looking forward to the discussion. [1]. https://github.com/PyCQA/pycodestyle Thank you. -- Himanshu Mishra Third Year Undergraduate Mathematics and Computing IIT Kharagpur https://orkohunter.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Mon Mar 20 17:33:14 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Mon, 20 Mar 2017 14:33:14 -0700 Subject: [scikit-image] Request to try a GitHub integration for automatic code style review | "PEP8Speaks" In-Reply-To: References: Message-ID: <1490045594.2804236.917709664.5A62E0CC@webmail.messagingengine.com> Hi Himanshu On Mon, Mar 20, 2017, at 12:24, Himanshu Mishra wrote: > I am not sure if this is the right place to talk about it, but a lot > of times I have witnessed reviewers leave a little comment after > reviewing the whole PR, and it is more or less about "some style > issues. :)". It should be better for the reviewer to focus more on the > implementation of the PR and leave the style issues to a bot. Thinking > this in mind, a while ago, I created a Github Integration called PEP8 > Speaks which automatically reviews the code style and comments on the > Pull Request. It is written in Python and is open source. Github - > https://github.com/orkohunter/pep8speaks I've been wanting to put something like this in place for a while; so, if you're willing to help out, we'd be grateful. We've also looked at Code Climate before; do you know how your proposed solution compares? Thanks! St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Mon Mar 20 19:08:36 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Mon, 20 Mar 2017 16:08:36 -0700 Subject: [scikit-image] Request to try a GitHub integration for automatic code style review | "PEP8Speaks" In-Reply-To: <1490045594.2804236.917709664.5A62E0CC@webmail.messagingengine.com> References: <1490045594.2804236.917709664.5A62E0CC@webmail.messagingengine.com> Message-ID: <1490051316.3691255.917797344.5C2E5B43@webmail.messagingengine.com> This also came across my radar today: https://landscape.io/ St?fan On Mon, Mar 20, 2017, at 14:33, Stefan van der Walt wrote: > Hi Himanshu > > On Mon, Mar 20, 2017, at 12:24, Himanshu Mishra wrote: >> I am not sure if this is the right place to talk about it, but a lot >> of times I have witnessed reviewers leave a little comment after >> reviewing the whole PR, and it is more or less about "some style >> issues. :)". It should be better for the reviewer to focus more on >> the implementation of the PR and leave the style issues to a bot. >> Thinking this in mind, a while ago, I created a Github Integration >> called PEP8 Speaks which automatically reviews the code style and >> comments on the Pull Request. It is written in Python and is open >> source. Github - https://github.com/orkohunter/pep8speaks > > I've been wanting to put something like this in place for a while; so, > if you're willing to help out, we'd be grateful. > > We've also looked at Code Climate before; do you know how your > proposed solution compares? > > Thanks! > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From egor.v.panfilov at gmail.com Tue Mar 21 03:46:09 2017 From: egor.v.panfilov at gmail.com (Egor Panfilov) Date: Tue, 21 Mar 2017 10:46:09 +0300 Subject: [scikit-image] Request to try a GitHub integration for automatic code style review | "PEP8Speaks" In-Reply-To: <1490051316.3691255.917797344.5C2E5B43@webmail.messagingengine.com> References: <1490045594.2804236.917709664.5A62E0CC@webmail.messagingengine.com> <1490051316.3691255.917797344.5C2E5B43@webmail.messagingengine.com> Message-ID: Hi Himanshu, The bot looks really nice! What would be the pre-requisites from our side to deploy it? @scikit-image/core, I'd vote to give it a try. What do you think about 3-4 months probation period for the bot? During the period we could evaluate how well it supplements our current practices, and how the contributors are responding. Regards, Egor 2017-03-21 2:08 GMT+03:00 Stefan van der Walt : > This also came across my radar today: > > https://landscape.io/ > > St?fan > > > On Mon, Mar 20, 2017, at 14:33, Stefan van der Walt wrote: > > Hi Himanshu > > On Mon, Mar 20, 2017, at 12:24, Himanshu Mishra wrote: > > I am not sure if this is the right place to talk about it, but a lot of > times I have witnessed reviewers leave a little comment after reviewing the > whole PR, and it is more or less about "some style issues. :)". It should > be better for the reviewer to focus more on the implementation of the PR > and leave the style issues to a bot. Thinking this in mind, a while ago, I > created a Github Integration called PEP8 Speaks which automatically reviews > the code style and comments on the Pull Request. It is written in Python > and is open source. Github - https://github.com/orkohunter/pep8speaks > > > I've been wanting to put something like this in place for a while; so, if > you're willing to help out, we'd be grateful. > > We've also looked at Code Climate before; do you know how your proposed > solution compares? > > Thanks! > St?fan > > > > _______________________________________________ > scikit-image mailing list > scikit-image at python.org > https://mail.python.org/mailman/listinfo/scikit-image > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.silvester at gmail.com Tue Mar 21 04:00:17 2017 From: steven.silvester at gmail.com (Steven Silvester) Date: Tue, 21 Mar 2017 03:00:17 -0500 Subject: [scikit-image] Request to try a GitHub integration for automatic code style review | "PEP8Speaks" In-Reply-To: References: <1490045594.2804236.917709664.5A62E0CC@webmail.messagingengine.com> <1490051316.3691255.917797344.5C2E5B43@webmail.messagingengine.com> Message-ID: <5E5D71A3-F98C-43FD-88A4-735115F28A00@gmail.com> I second Egor?s motion. Regards, Steve > On Mar 21, 2017, at 2:46 AM, Egor Panfilov wrote: > > Hi Himanshu, > > The bot looks really nice! What would be the pre-requisites from our side to deploy it? > > @scikit-image/core, > > I'd vote to give it a try. What do you think about 3-4 months probation period for the bot? During the period we could evaluate how well it supplements our current practices, and how the contributors are responding. > > Regards, > Egor > > 2017-03-21 2:08 GMT+03:00 Stefan van der Walt >: > This also came across my radar today: > > https://landscape.io/ > > St?fan > > > On Mon, Mar 20, 2017, at 14:33, Stefan van der Walt wrote: >> Hi Himanshu >> >> On Mon, Mar 20, 2017, at 12:24, Himanshu Mishra wrote: >>> I am not sure if this is the right place to talk about it, but a lot of times I have witnessed reviewers leave a little comment after reviewing the whole PR, and it is more or less about "some style issues. :)". It should be better for the reviewer to focus more on the implementation of the PR and leave the style issues to a bot. Thinking this in mind, a while ago, I created a Github Integration called PEP8 Speaks which automatically reviews the code style and comments on the Pull Request. It is written in Python and is open source. Github - https://github.com/orkohunter/pep8speaks >> >> I've been wanting to put something like this in place for a while; so, if you're willing to help out, we'd be grateful. >> >> We've also looked at Code Climate before; do you know how your proposed solution compares? >> >> Thanks! >> St?fan >> > > > _______________________________________________ > scikit-image mailing list > scikit-image at python.org > https://mail.python.org/mailman/listinfo/scikit-image > > > _______________________________________________ > scikit-image mailing list > scikit-image at python.org > https://mail.python.org/mailman/listinfo/scikit-image -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssouravsingh12 at gmail.com Tue Mar 21 04:10:32 2017 From: ssouravsingh12 at gmail.com (Sourav Singh) Date: Tue, 21 Mar 2017 13:40:32 +0530 Subject: [scikit-image] Request to try a GitHub integration for automatic code style review | "PEP8Speaks" In-Reply-To: <5E5D71A3-F98C-43FD-88A4-735115F28A00@gmail.com> References: <1490045594.2804236.917709664.5A62E0CC@webmail.messagingengine.com> <1490051316.3691255.917797344.5C2E5B43@webmail.messagingengine.com> <5E5D71A3-F98C-43FD-88A4-735115F28A00@gmail.com> Message-ID: Hello, Just putting my two cents here. I believe we have something like this done. Take a look at Coala and Gitmate . The Gitmate is a bot which can check your PRs for all the stuff( PEP8, Lint Errors and such ) and tell the contributor about the exact problems in the code. The Gitmate requires coala to run, maybe we can discuss with Coala devs regarding the integration of the bot, since the bot can do more than just PEP8 checks. Regards, Sourav ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From himanshu.mishra.kgp at gmail.com Tue Mar 21 04:23:28 2017 From: himanshu.mishra.kgp at gmail.com (Himanshu Mishra) Date: Tue, 21 Mar 2017 08:23:28 +0000 Subject: [scikit-image] Request to try a GitHub integration for automatic code style review | "PEP8Speaks" (Egor Panfilov) In-Reply-To: References: Message-ID: > > > This also came across my radar today: > > https://landscape.io/ Hey Stefan, I like landscape.io very much. landscape.io is *very* useful in detecting potential errors and code smells. But it nags a lot like other bots. So, disabling comments is ultimately the solution. Tried on StingraySoftware. Hi Himanshu, > > The bot looks really nice! What would be the pre-requisites from our side > to deploy it? > > @scikit-image/core, > > I'd vote to give it a try. What do you think about 3-4 months probation > period for the bot? During the period we could evaluate how well it > supplements our current practices, and how the contributors are responding. > > Regards, > Egor > > There are no prerequisites as of now. The integration can be simply enabled from https://github.com/integration/pep8-speaks A .pep8speaks.yml file can help in several configurations : https://github.com/orkohunter/pep8speaks#configuration but is not required. (This works quite similar to Travis) Plus the integration is written as open source in Python and I would really love to change around, as the community would expect. Thank you. -- Himanshu Mishra Third Year Undergraduate Mathematics and Computing IIT Kharagpur https://orkohunter.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jni.soma at gmail.com Sat Mar 25 11:37:05 2017 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Sat, 25 Mar 2017 11:37:05 -0400 Subject: [scikit-image] Gearing up for 0.13 Message-ID: <8a5bc4a9-d989-4d7d-b035-a4ac78dbc7b6@Spark> Hi everyone, We?ve had these two 32-bit blockers holding up 0.13 for a couple of months now. Importantly, both of these bugs: - existed in 0.12 - are only testing bugs, not actual bugs (as far as I can tell) Therefore, I?ve proposed to ship 0.13.0 before fixing them. When we do fix them, we can back-port to 0.13.1/2/3. St?fan was on board with this plan. If there are no objections, I?ll get the ball rolling shortly on the release. But, I wanted to give people a chance to comment on the decision before starting. =) Juan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nelle.varoquaux at gmail.com Sat Mar 25 11:57:18 2017 From: nelle.varoquaux at gmail.com (Nelle Varoquaux) Date: Sat, 25 Mar 2017 08:57:18 -0700 Subject: [scikit-image] Gearing up for 0.13 In-Reply-To: <8a5bc4a9-d989-4d7d-b035-a4ac78dbc7b6@Spark> References: <8a5bc4a9-d989-4d7d-b035-a4ac78dbc7b6@Spark> Message-ID: On 25 March 2017 at 08:37, Juan Nunez-Iglesias wrote: > Hi everyone, > > We?ve had these two 32-bit blockers > holding up > 0.13 for a couple of months now. Importantly, both of these bugs: > - existed in 0.12 > - are only testing bugs, not actual bugs (as far as I can tell) > > Therefore, I?ve proposed to ship 0.13.0 before fixing them. When we do fix > them, we can back-port to 0.13.1/2/3. St?fan was on board with this plan. > If there are no objections, I?ll get the ball rolling shortly on the > release. But, I wanted to give people a chance to comment on the decision > before starting. =) > St?fan wanted my pytest PR in before the release. Is that still the case? Cheers, N > > Juan. > > _______________________________________________ > scikit-image mailing list > scikit-image at python.org > https://mail.python.org/mailman/listinfo/scikit-image > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jni.soma at gmail.com Sat Mar 25 12:19:26 2017 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Sat, 25 Mar 2017 12:19:26 -0400 Subject: [scikit-image] Gearing up for 0.13 In-Reply-To: References: <8a5bc4a9-d989-4d7d-b035-a4ac78dbc7b6@Spark> <0c308881-0850-4996-84f1-47d853ed58bf@Spark> Message-ID: <8c30924d-2d07-4eaa-8385-30a36cf66586@Spark> That?s fine. My general approach is to merge things as they?re ready. That?s the point of continuous integration. =) Would you like to have a stab at the rebase? If you ping me here I?ll review ASAP. CC list: sorry, I forgot to reply-all earlier. Full (tiny) thread below. On 25 Mar 2017, 12:09 PM -0400, Nelle Varoquaux , wrote: > His point was that backporting would be easier if it was merged before. > > > On 25 March 2017 at 09:03, Juan Nunez-Iglesias wrote: > > > Oh! I thought the consensus was to have it *after* the release! #releasemanagerfail =P But it?s still on the 0.14 milestone. And looking at the comments it?s not clear that he wanted that? Anyway, I?m personally happy to merge if a rebase fixes the failing travis build. > > > > > > On 25 Mar 2017, 11:57 AM -0400, Nelle Varoquaux , wrote: > > > > > > > > > > > > > On 25 March 2017 at 08:37, Juan Nunez-Iglesias wrote: > > > > > > Hi everyone, > > > > > > > > > > > > We?ve had these two 32-bit blockers holding up 0.13 for a couple of months now. Importantly, both of these bugs: > > > > > > - existed in 0.12 > > > > > > - are only testing bugs, not actual bugs (as far as I can tell) > > > > > > > > > > > > Therefore, I?ve proposed to ship 0.13.0 before fixing them. When we do fix them, we can back-port to 0.13.1/2/3. St?fan was on board with this plan. If there are no objections, I?ll get the ball rolling shortly on the release. But, I wanted to give people a chance to comment on the decision before starting. =) > > > > > > > > > > St?fan wanted my pytest PR in before the release. Is that still the case? > > > > > > > > > > Cheers, > > > > > N > > > > > > > > > > > > > > > > > Juan. > > > > > > > > > > > > _______________________________________________ > > > > > > scikit-image mailing list > > > > > > scikit-image at python.org > > > > > > https://mail.python.org/mailman/listinfo/scikit-image > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsch at demuc.de Sat Mar 25 12:47:22 2017 From: jsch at demuc.de (=?utf-8?Q?Johannes=20Sch=C3=B6nberger?=) Date: Sat, 25 Mar 2017 17:47:22 +0100 Subject: [scikit-image] Gearing up for 0.13 In-Reply-To: <8c30924d-2d07-4eaa-8385-30a36cf66586@Spark> References: <8a5bc4a9-d989-4d7d-b035-a4ac78dbc7b6@Spark> <0c308881-0850-4996-84f1-47d853ed58bf@Spark> <8c30924d-2d07-4eaa-8385-30a36cf66586@Spark> Message-ID: <1490460442.3073840.923235704.3D3F698C@webmail.messagingengine.com> Trying to ship 0.13 sounds good to me! And those 32-bit bugs can be back-ported. Cheers, Johannes On Sat, Mar 25, 2017, at 05:19 PM, Juan Nunez-Iglesias wrote: > That?s fine. My general approach is to merge things as they?re ready. > That?s the point of continuous integration. =) Would you like to have > a stab at the rebase? If you ping me here I?ll review ASAP. > > CC list: sorry, I forgot to reply-all earlier. Full (tiny) > thread below. > > On 25 Mar 2017, 12:09 PM -0400, Nelle Varoquaux > , wrote: > >> His point was that backporting would be easier if it was merged >> before. >> >> On 25 March 2017 at 09:03, Juan Nunez-Iglesias >> wrote: >> >>> Oh! I thought the consensus was to have it *after* the release! >>> #releasemanagerfail =P But it?s still on the 0.14 milestone. And >>> looking at the comments it?s not clear that he wanted that? Anyway, >>> I?m personally happy to merge if a rebase fixes the failing travis >>> build. >>> >>> On 25 Mar 2017, 11:57 AM -0400, Nelle Varoquaux >>> , wrote: >>> >>>> >>>> >>>> On 25 March 2017 at 08:37, Juan Nunez-Iglesias >>>> wrote: >>>> >>>>> Hi everyone, >>>>> >>>>> We?ve had these two 32-bit blockers[1] holding up 0.13 for a >>>>> couple of months now. Importantly, both of these bugs: >>>>> - existed in 0.12 >>>>> - are only testing bugs, not actual bugs (as far as I can tell) >>>>> >>>>> Therefore, I?ve proposed to ship 0.13.0 before fixing them. When >>>>> we do fix them, we can back-port to 0.13.1/2/3. St?fan was on >>>>> board with this plan. If there are no objections, I?ll get the >>>>> ball rolling shortly on the release. But, I wanted to give people >>>>> a chance to comment on the decision before starting. =) >>>> >>>> St?fan wanted my pytest PR in before the release. Is that still the >>>> case? >>>> >>>> Cheers, >>>> N >>>> >>>>> >>>>> Juan. >>>>> >>>>> _______________________________________________ >>>>> scikit-image mailing list >>>>> scikit-image at python.org >>>>> https://mail.python.org/mailman/listinfo/scikit-image >>>>> > _________________________________________________ > scikit-image mailing list > scikit-image at python.org > https://mail.python.org/mailman/listinfo/scikit-image Links: 1. https://github.com/scikit-image/scikit-image/milestone/6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.silvester at gmail.com Sat Mar 25 12:53:26 2017 From: steven.silvester at gmail.com (Steven Silvester) Date: Sat, 25 Mar 2017 16:53:26 +0000 Subject: [scikit-image] Gearing up for 0.13 In-Reply-To: <1490460442.3073840.923235704.3D3F698C@webmail.messagingengine.com> References: <8a5bc4a9-d989-4d7d-b035-a4ac78dbc7b6@Spark> <0c308881-0850-4996-84f1-47d853ed58bf@Spark> <8c30924d-2d07-4eaa-8385-30a36cf66586@Spark>, <1490460442.3073840.923235704.3D3F698C@webmail.messagingengine.com> Message-ID: +1 for a release without the testing fixes. Sent from phone. ________________________________ From: scikit-image on behalf of Johannes Sch?nberger Sent: Saturday, March 25, 2017 11:47:22 AM To: scikit-image at python.org Subject: Re: [scikit-image] Gearing up for 0.13 Trying to ship 0.13 sounds good to me! And those 32-bit bugs can be back-ported. Cheers, Johannes On Sat, Mar 25, 2017, at 05:19 PM, Juan Nunez-Iglesias wrote: That?s fine. My general approach is to merge things as they?re ready. That?s the point of continuous integration. =) Would you like to have a stab at the rebase? If you ping me here I?ll review ASAP. CC list: sorry, I forgot to reply-all earlier. Full (tiny) thread below. On 25 Mar 2017, 12:09 PM -0400, Nelle Varoquaux , wrote: His point was that backporting would be easier if it was merged before. On 25 March 2017 at 09:03, Juan Nunez-Iglesias > wrote: Oh! I thought the consensus was to have it *after* the release! #releasemanagerfail =P But it?s still on the 0.14 milestone. And looking at the comments it?s not clear that he wanted that? Anyway, I?m personally happy to merge if a rebase fixes the failing travis build. On 25 Mar 2017, 11:57 AM -0400, Nelle Varoquaux >, wrote: On 25 March 2017 at 08:37, Juan Nunez-Iglesias > wrote: Hi everyone, We?ve had these two 32-bit blockers holding up 0.13 for a couple of months now. Importantly, both of these bugs: - existed in 0.12 - are only testing bugs, not actual bugs (as far as I can tell) Therefore, I?ve proposed to ship 0.13.0 before fixing them. When we do fix them, we can back-port to 0.13.1/2/3. St?fan was on board with this plan. If there are no objections, I?ll get the ball rolling shortly on the release. But, I wanted to give people a chance to comment on the decision before starting. =) St?fan wanted my pytest PR in before the release. Is that still the case? Cheers, N Juan. _______________________________________________ scikit-image mailing list scikit-image at python.org https://mail.python.org/mailman/listinfo/scikit-image _______________________________________________ scikit-image mailing list scikit-image at python.org https://mail.python.org/mailman/listinfo/scikit-image -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.silvester at gmail.com Sat Mar 25 12:55:15 2017 From: steven.silvester at gmail.com (Steven Silvester) Date: Sat, 25 Mar 2017 16:55:15 +0000 Subject: [scikit-image] Gearing up for 0.13 In-Reply-To: References: <8a5bc4a9-d989-4d7d-b035-a4ac78dbc7b6@Spark> <0c308881-0850-4996-84f1-47d853ed58bf@Spark> <8c30924d-2d07-4eaa-8385-30a36cf66586@Spark>, <1490460442.3073840.923235704.3D3F698C@webmail.messagingengine.com>, Message-ID: To be clear, I meant the 32 bit fixes. Happy to include Nelle's PR. Sent from phone. ________________________________ From: Steven Silvester Sent: Saturday, March 25, 2017 11:53:26 AM To: scikit-image at python.org; Johannes Sch?nberger Subject: Re: [scikit-image] Gearing up for 0.13 +1 for a release without the testing fixes. Sent from phone. ________________________________ From: scikit-image on behalf of Johannes Sch?nberger Sent: Saturday, March 25, 2017 11:47:22 AM To: scikit-image at python.org Subject: Re: [scikit-image] Gearing up for 0.13 Trying to ship 0.13 sounds good to me! And those 32-bit bugs can be back-ported. Cheers, Johannes On Sat, Mar 25, 2017, at 05:19 PM, Juan Nunez-Iglesias wrote: That?s fine. My general approach is to merge things as they?re ready. That?s the point of continuous integration. =) Would you like to have a stab at the rebase? If you ping me here I?ll review ASAP. CC list: sorry, I forgot to reply-all earlier. Full (tiny) thread below. On 25 Mar 2017, 12:09 PM -0400, Nelle Varoquaux , wrote: His point was that backporting would be easier if it was merged before. On 25 March 2017 at 09:03, Juan Nunez-Iglesias > wrote: Oh! I thought the consensus was to have it *after* the release! #releasemanagerfail =P But it?s still on the 0.14 milestone. And looking at the comments it?s not clear that he wanted that? Anyway, I?m personally happy to merge if a rebase fixes the failing travis build. On 25 Mar 2017, 11:57 AM -0400, Nelle Varoquaux >, wrote: On 25 March 2017 at 08:37, Juan Nunez-Iglesias > wrote: Hi everyone, We?ve had these two 32-bit blockers holding up 0.13 for a couple of months now. Importantly, both of these bugs: - existed in 0.12 - are only testing bugs, not actual bugs (as far as I can tell) Therefore, I?ve proposed to ship 0.13.0 before fixing them. When we do fix them, we can back-port to 0.13.1/2/3. St?fan was on board with this plan. If there are no objections, I?ll get the ball rolling shortly on the release. But, I wanted to give people a chance to comment on the decision before starting. =) St?fan wanted my pytest PR in before the release. Is that still the case? Cheers, N Juan. _______________________________________________ scikit-image mailing list scikit-image at python.org https://mail.python.org/mailman/listinfo/scikit-image _______________________________________________ scikit-image mailing list scikit-image at python.org https://mail.python.org/mailman/listinfo/scikit-image -------------- next part -------------- An HTML attachment was scrubbed... URL: From egor.v.panfilov at gmail.com Sat Mar 25 13:50:21 2017 From: egor.v.panfilov at gmail.com (Egor Panfilov) Date: Sat, 25 Mar 2017 20:50:21 +0300 Subject: [scikit-image] Gearing up for 0.13 In-Reply-To: References: <8a5bc4a9-d989-4d7d-b035-a4ac78dbc7b6@Spark> <0c308881-0850-4996-84f1-47d853ed58bf@Spark> <8c30924d-2d07-4eaa-8385-30a36cf66586@Spark> <1490460442.3073840.923235704.3D3F698C@webmail.messagingengine.com> Message-ID: Hi all, +1 from me to go on with the release. Those bugs are the long-lasting ones, and don't seem to be easily fixed. As for pytest migration, I think we can't reschedule it for 0.13.1 or something. Most of the work is done there, we just need to re-iterate with the recent additions. Regards, Egor 2017-03-25 19:55 GMT+03:00 Steven Silvester : > To be clear, I meant the 32 bit fixes. Happy to include Nelle's PR. > > > Sent from phone. > > ------------------------------ > *From:* Steven Silvester > *Sent:* Saturday, March 25, 2017 11:53:26 AM > *To:* scikit-image at python.org; Johannes Sch?nberger > > *Subject:* Re: [scikit-image] Gearing up for 0.13 > > +1 for a release without the testing fixes. > > > Sent from phone. > > ------------------------------ > *From:* scikit-image gmail.com at python.org> on behalf of Johannes Sch?nberger > *Sent:* Saturday, March 25, 2017 11:47:22 AM > *To:* scikit-image at python.org > *Subject:* Re: [scikit-image] Gearing up for 0.13 > > Trying to ship 0.13 sounds good to me! And those 32-bit bugs can be > back-ported. > > Cheers, > Johannes > > On Sat, Mar 25, 2017, at 05:19 PM, Juan Nunez-Iglesias wrote: > > That?s fine. My general approach is to merge things as they?re ready. > That?s the point of continuous integration. =) Would you like to have a > stab at the rebase? If you ping me here I?ll review ASAP. > > CC list: sorry, I forgot to reply-all earlier. Full (tiny) thread below. > > On 25 Mar 2017, 12:09 PM -0400, Nelle Varoquaux , > wrote: > > His point was that backporting would be easier if it was merged before. > > On 25 March 2017 at 09:03, Juan Nunez-Iglesias wrote: > > Oh! I thought the consensus was to have it *after* the release! > #releasemanagerfail =P But it?s still on the 0.14 milestone. And looking at > the comments it?s not clear that he wanted that? Anyway, I?m personally > happy to merge if a rebase fixes the failing travis build. > > On 25 Mar 2017, 11:57 AM -0400, Nelle Varoquaux , > wrote: > > > > On 25 March 2017 at 08:37, Juan Nunez-Iglesias wrote: > > Hi everyone, > > We?ve had these two 32-bit blockers > holding up > 0.13 for a couple of months now. Importantly, both of these bugs: > - existed in 0.12 > - are only testing bugs, not actual bugs (as far as I can tell) > > Therefore, I?ve proposed to ship 0.13.0 before fixing them. When we do fix > them, we can back-port to 0.13.1/2/3. St?fan was on board with this plan. > If there are no objections, I?ll get the ball rolling shortly on the > release. But, I wanted to give people a chance to comment on the decision > before starting. =) > > > St?fan wanted my pytest PR in before the release. Is that still the case? > > Cheers, > N > > > > Juan. > > _______________________________________________ > scikit-image mailing list > scikit-image at python.org > https://mail.python.org/mailman/listinfo/scikit-image > > *_______________________________________________* > scikit-image mailing list > scikit-image at python.org > https://mail.python.org/mailman/listinfo/scikit-image > > > > _______________________________________________ > scikit-image mailing list > scikit-image at python.org > https://mail.python.org/mailman/listinfo/scikit-image > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Sat Mar 25 22:39:28 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Sat, 25 Mar 2017 19:39:28 -0700 Subject: [scikit-image] Gearing up for 0.13 In-Reply-To: References: <8a5bc4a9-d989-4d7d-b035-a4ac78dbc7b6@Spark> Message-ID: <1490495968.2747464.923522432.25780073@webmail.messagingengine.com> On Sat, Mar 25, 2017, at 08:57, Nelle Varoquaux wrote: > > On 25 March 2017 at 08:37, Juan Nunez-Iglesias > wrote: >> Hi everyone, >> >> We?ve had these two 32-bit blockers[1] holding up 0.13 for a couple >> of months now. Importantly, both of these bugs: >> - existed in 0.12 >> - are only testing bugs, not actual bugs (as far as I can tell) >> >> Therefore, I?ve proposed to ship 0.13.0 before fixing them. When we >> do fix them, we can back-port to 0.13.1/2/3. St?fan was on board with >> this plan. If there are no objections, I?ll get the ball rolling >> shortly on the release. But, I wanted to give people a chance to >> comment on the decision before starting. =) > > St?fan wanted my pytest PR in before the release. Is that still > the case? If we can make that happen in the next day or two, I think we should. But it should not block the release. St?fan Links: 1. https://github.com/scikit-image/scikit-image/milestone/6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Sat Mar 25 23:25:41 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sun, 26 Mar 2017 16:25:41 +1300 Subject: [scikit-image] Gearing up for 0.13 In-Reply-To: <8a5bc4a9-d989-4d7d-b035-a4ac78dbc7b6@Spark> References: <8a5bc4a9-d989-4d7d-b035-a4ac78dbc7b6@Spark> Message-ID: On Sun, Mar 26, 2017 at 4:37 AM, Juan Nunez-Iglesias wrote: > Hi everyone, > > We?ve had these two 32-bit blockers > holding up > 0.13 for a couple of months now. Importantly, both of these bugs: > - existed in 0.12 > - are only testing bugs, not actual bugs (as far as I can tell) > My main development setup is 32-bit, so I ran the test suite. Result is 6 failures and a bunch of warnings that may need some attention: https://gist.github.com/rgommers/b06981f89fb67eb6c1e643cab565419d Nothing looks really critical though. Cheers, Ralf > Therefore, I?ve proposed to ship 0.13.0 before fixing them. When we do fix > them, we can back-port to 0.13.1/2/3. St?fan was on board with this plan. > If there are no objections, I?ll get the ball rolling shortly on the > release. But, I wanted to give people a chance to comment on the decision > before starting. =) > > Juan. > > _______________________________________________ > scikit-image mailing list > scikit-image at python.org > https://mail.python.org/mailman/listinfo/scikit-image > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mob.irl at gmail.com Mon Mar 27 09:01:55 2017 From: mob.irl at gmail.com (Michael O'Brien) Date: Mon, 27 Mar 2017 13:01:55 +0000 Subject: [scikit-image] color.lab2rgb output differs from colormine.org Message-ID: Hi all, If I use the following array of LAB values array([[[ 48.07851346, -14.69400135, 25.2170507 ], [ 63.21232753, -3.65444198, 6.67734193], [ 45.80027308, -2.47952304, 11.5073341 ], [ 46.84900559, -10.37025167, 19.92527996], [ 44.92476952, 19.36861848, 2.97238555], [ 35.50132805, 5.89086564, 1.95259827]]]) and use the following code to pass the array to lab2rgb rgbcolours =color.lab2rgb(ClusterColours.values[np.newaxis]) I get the array array([[[ 0.40929448, 0.47071505, 0.27701891], [ 0.59383913, 0.60611158, 0.55329837], [ 0.4393785 , 0.4276561 , 0.34999225], [ 0.4159481 , 0.4516056 , 0.3026519 ], [ 0.54449997, 0.36963636, 0.4001209 ], [ 0.36970012, 0.3145826 , 0.315974 ]]]) but on colormine.org if I enter the 1st of the LAB values I get 105,119,70 for RGB and not colours so close to black Where am I going wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From isaac.gerg at gergltd.com Mon Mar 27 09:14:44 2017 From: isaac.gerg at gergltd.com (Isaac Gerg) Date: Mon, 27 Mar 2017 09:14:44 -0400 Subject: [scikit-image] color.lab2rgb output differs from colormine.org In-Reply-To: References: Message-ID: What illuminant standard is colormine.org using? Looks like scikit-image is using D65. https://github.com/scikit-image/scikit-image/blob/1c4646c25c9e1158bf7134973119705b2ee29a8b/skimage/color/colorconv.py On Mon, Mar 27, 2017 at 9:01 AM, Michael O'Brien wrote: > Hi all, > > > If I use the following array of LAB values > array([[[ 48.07851346, -14.69400135, 25.2170507 ], > [ 63.21232753, -3.65444198, 6.67734193], > [ 45.80027308, -2.47952304, 11.5073341 ], > [ 46.84900559, -10.37025167, 19.92527996], > [ 44.92476952, 19.36861848, 2.97238555], > [ 35.50132805, 5.89086564, 1.95259827]]]) > and use the following code to pass the array to lab2rgb > rgbcolours =color.lab2rgb(ClusterColours.values[np.newaxis]) > I get the array > array([[[ 0.40929448, 0.47071505, 0.27701891], > [ 0.59383913, 0.60611158, 0.55329837], > [ 0.4393785 , 0.4276561 , 0.34999225], > [ 0.4159481 , 0.4516056 , 0.3026519 ], > [ 0.54449997, 0.36963636, 0.4001209 ], > [ 0.36970012, 0.3145826 , 0.315974 ]]]) > but on colormine.org if I enter the 1st of the LAB values I get 105,119,70 for RGB and not colours so close to black > > Where am I going wrong? > > > _______________________________________________ > scikit-image mailing list > scikit-image at python.org > https://mail.python.org/mailman/listinfo/scikit-image > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randerson at resonon.com Mon Mar 27 09:22:57 2017 From: randerson at resonon.com (Ryan Anderson) Date: Mon, 27 Mar 2017 07:22:57 -0600 Subject: [scikit-image] color.lab2rgb output differs from colormine.org In-Reply-To: References: Message-ID: It looks to me as if lab2rgb is returning colors scaled as floats between 0 and 1 while colormine.org is returning 8 bit integers scaled 0-255. Try multiplying by 255 and comparing the outputs. On Mar 27, 2017 7:02 AM, "Michael O'Brien" wrote: Hi all, If I use the following array of LAB values array([[[ 48.07851346, -14.69400135, 25.2170507 ], [ 63.21232753, -3.65444198, 6.67734193], [ 45.80027308, -2.47952304, 11.5073341 ], [ 46.84900559, -10.37025167, 19.92527996], [ 44.92476952, 19.36861848, 2.97238555], [ 35.50132805, 5.89086564, 1.95259827]]]) and use the following code to pass the array to lab2rgb rgbcolours =color.lab2rgb(ClusterColours.values[np.newaxis]) I get the array array([[[ 0.40929448, 0.47071505, 0.27701891], [ 0.59383913, 0.60611158, 0.55329837], [ 0.4393785 , 0.4276561 , 0.34999225], [ 0.4159481 , 0.4516056 , 0.3026519 ], [ 0.54449997, 0.36963636, 0.4001209 ], [ 0.36970012, 0.3145826 , 0.315974 ]]]) but on colormine.org if I enter the 1st of the LAB values I get 105,119,70 for RGB and not colours so close to black Where am I going wrong? _______________________________________________ scikit-image mailing list scikit-image at python.org https://mail.python.org/mailman/listinfo/scikit-image -------------- next part -------------- An HTML attachment was scrubbed... URL: From mob.irl at gmail.com Mon Mar 27 09:36:08 2017 From: mob.irl at gmail.com (Michael O'Brien) Date: Mon, 27 Mar 2017 13:36:08 +0000 Subject: [scikit-image] color.lab2rgb output differs from colormine.org In-Reply-To: References: Message-ID: I'm not sure what illuminant colormine uses but if you multiple by 255 you get 151,154,141 which it getting closer to what I expect (greenish colour) with 105,119,70 still being much closer On Mon, 27 Mar 2017, 14:22 Ryan Anderson, wrote: > It looks to me as if lab2rgb is returning colors scaled as floats between > 0 and 1 while colormine.org is returning 8 bit integers scaled 0-255. > > Try multiplying by 255 and comparing the outputs. > > On Mar 27, 2017 7:02 AM, "Michael O'Brien" wrote: > > Hi all, > > > If I use the following array of LAB values > array([[[ 48.07851346, -14.69400135, 25.2170507 ], > [ 63.21232753, -3.65444198, 6.67734193], > [ 45.80027308, -2.47952304, 11.5073341 ], > [ 46.84900559, -10.37025167, 19.92527996], > [ 44.92476952, 19.36861848, 2.97238555], > [ 35.50132805, 5.89086564, 1.95259827]]]) > and use the following code to pass the array to lab2rgb > rgbcolours =color.lab2rgb(ClusterColours.values[np.newaxis]) > I get the array > array([[[ 0.40929448, 0.47071505, 0.27701891], > [ 0.59383913, 0.60611158, 0.55329837], > [ 0.4393785 , 0.4276561 , 0.34999225], > [ 0.4159481 , 0.4516056 , 0.3026519 ], > [ 0.54449997, 0.36963636, 0.4001209 ], > [ 0.36970012, 0.3145826 , 0.315974 ]]]) > but on colormine.org if I enter the 1st of the LAB values I get 105,119,70 for RGB and not colours so close to black > > Where am I going wrong? > > > _______________________________________________ > scikit-image mailing list > scikit-image at python.org > https://mail.python.org/mailman/listinfo/scikit-image > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mob.irl at gmail.com Mon Mar 27 10:45:53 2017 From: mob.irl at gmail.com (Michael O'Brien) Date: Mon, 27 Mar 2017 14:45:53 +0000 Subject: [scikit-image] color.lab2rgb output differs from colormine.org In-Reply-To: References: Message-ID: Using http://www.easyrgb.com/index.php *CIE-L*ab = 48.000 -14.000 25.000* *equals* *RGB 0-255 = 105.30 119.53 70.87* *RGB 0-0.1 = 0.41293 0.46875 0.27791* XYZ = 13.654 16.794 8.461 Illuminant = D65 Observer = 2? (1931) So Ryan was correct to say the values are scaled between 0 and 1 (I was using the wrong row in my re-conversion to 0 to 255 scale) This is the 1st time I've come across RGB scaled to 0 and 1. Is its common in python and does the other scikit-image functions handle the 0 -1 scaled values or should I work with 0 to 255 values to be safe? On Mon, 27 Mar 2017 at 14:36 Michael O'Brien wrote: > I'm not sure what illuminant colormine uses but if you multiple by 255 you > get 151,154,141 which it getting closer to what I expect (greenish colour) > with 105,119,70 still being much closer > > On Mon, 27 Mar 2017, 14:22 Ryan Anderson, wrote: > > It looks to me as if lab2rgb is returning colors scaled as floats between > 0 and 1 while colormine.org is returning 8 bit integers scaled 0-255. > > Try multiplying by 255 and comparing the outputs. > > On Mar 27, 2017 7:02 AM, "Michael O'Brien" wrote: > > Hi all, > > > If I use the following array of LAB values > array([[[ 48.07851346, -14.69400135, 25.2170507 ], > [ 63.21232753, -3.65444198, 6.67734193], > [ 45.80027308, -2.47952304, 11.5073341 ], > [ 46.84900559, -10.37025167, 19.92527996], > [ 44.92476952, 19.36861848, 2.97238555], > [ 35.50132805, 5.89086564, 1.95259827]]]) > and use the following code to pass the array to lab2rgb > rgbcolours =color.lab2rgb(ClusterColours.values[np.newaxis]) > I get the array > array([[[ 0.40929448, 0.47071505, 0.27701891], > [ 0.59383913, 0.60611158, 0.55329837], > [ 0.4393785 , 0.4276561 , 0.34999225], > [ 0.4159481 , 0.4516056 , 0.3026519 ], > [ 0.54449997, 0.36963636, 0.4001209 ], > [ 0.36970012, 0.3145826 , 0.315974 ]]]) > but on colormine.org if I enter the 1st of the LAB values I get 105,119,70 for RGB and not colours so close to black > > Where am I going wrong? > > > _______________________________________________ > scikit-image mailing list > scikit-image at python.org > https://mail.python.org/mailman/listinfo/scikit-image > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jni.soma at gmail.com Mon Mar 27 10:50:13 2017 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Mon, 27 Mar 2017 10:50:13 -0400 Subject: [scikit-image] color.lab2rgb output differs from colormine.org In-Reply-To: References: Message-ID: Hi Michael, Yes, it?s common in Python and you should generally work in floating point until the very final step of processing. This will help avoid accumulation of rounding errors. See our documentation on this here: http://scikit-image.org/docs/dev/user_guide/data_types.html Happy coding! Juan. On 27 Mar 2017, 10:46 AM -0400, Michael O'Brien , wrote: > Using?http://www.easyrgb.com/index.php > > CIE-L*ab = 48.000 -14.000 25.000 > > equals > > RGB 0-255 = 105.30 119.53 70.87 > RGB 0-0.1 = 0.41293 0.46875 0.27791 > > XYZ = 13.654 16.794 8.461 > > Illuminant = D65 > Observer = 2? (1931) > > So Ryan was correct to say the values are scaled between 0 and 1 (I was using the wrong row in my re-conversion to 0 to 255 scale) > This is the 1st time I've come across RGB scaled to 0 and 1. Is its common in python and does the other scikit-image functions handle the 0 -1 scaled values or should I work with 0 to 255 values to be safe? > > > > > > On Mon, 27 Mar 2017 at 14:36 Michael O'Brien wrote: > > > I'm not sure what illuminant colormine uses but if you multiple by 255 you get 151,154,141 which it getting closer to what I expect (greenish colour) with 105,119,70 still being much closer > > > > > > On Mon, 27 Mar 2017, 14:22 Ryan Anderson, wrote: > > > > It looks to me as if lab2rgb is returning colors scaled as floats between 0 and 1 while colormine.org is returning 8 bit integers scaled 0-255. > > > > > > > > Try multiplying by 255 and comparing the outputs. > > > > > > > > On Mar 27, 2017 7:02 AM, "Michael O'Brien" wrote: > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > If I use the following array of LAB values > > > > > array([[[ 48.07851346, -14.69400135, 25.2170507 ], > > > > > [ 63.21232753, -3.65444198, 6.67734193], > > > > > [ 45.80027308, -2.47952304, 11.5073341 ], > > > > > [ 46.84900559, -10.37025167, 19.92527996], > > > > > [ 44.92476952, 19.36861848, 2.97238555], > > > > > [ 35.50132805, 5.89086564, 1.95259827]]]) > > > > > and use the following code to pass the array to lab2rgb > > > > > rgbcolours =color.lab2rgb(ClusterColours.values[np.newaxis]) > > > > > I get the array > > > > > array([[[ 0.40929448, 0.47071505, 0.27701891], > > > > > [ 0.59383913, 0.60611158, 0.55329837], > > > > > [ 0.4393785 , 0.4276561 , 0.34999225], > > > > > [ 0.4159481 , 0.4516056 , 0.3026519 ], > > > > > [ 0.54449997, 0.36963636, 0.4001209 ], > > > > > [ 0.36970012, 0.3145826 , 0.315974 ]]]) > > > > > but on colormine.org if I enter the 1st of the LAB values I get 105,119,70 for RGB and not colours so close to black > > > > > > > > > > Where am I going wrong? > > > > > > > > > > _______________________________________________ > > > > > scikit-image mailing list > > > > > scikit-image at python.org > > > > > https://mail.python.org/mailman/listinfo/scikit-image > > > > > > _______________________________________________ > scikit-image mailing list > scikit-image at python.org > https://mail.python.org/mailman/listinfo/scikit-image -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Tue Mar 28 23:29:22 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Tue, 28 Mar 2017 20:29:22 -0700 Subject: [scikit-image] Sprint at SciPy2017 Message-ID: <1490758162.2662918.926899293.4F5F88C2@webmail.messagingengine.com> Hi, everyone If you are interested in hosting a sprint with me at SciPy2017, please get in touch directly. Thanks! St?fan From jni.soma at gmail.com Wed Mar 29 14:22:10 2017 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Wed, 29 Mar 2017 18:22:10 +0000 Subject: [scikit-image] Announcement: scikit-image 0.13.0 Message-ID: We're happy to (finally) announce the release of scikit-image v0.13.0! Special thanks to our many contributors for making it possible! This release is the result of over a year of work, with over 200 pull requests by 82 contributors. Linux and macOS wheels are available now on PyPI , together with a source distribution. Use "pip install -U scikit-image" to get the latest version! Packages on conda-forge, Windows wheels, and Debian packages should be available within the next few days. scikit-image is an image processing toolbox for SciPy that includes algorithms for segmentation, geometric transformations, color space manipulation, analysis, filtering, morphology, feature detection, and more. For more information, examples, and documentation, please visit our website: http://scikit-image.org and our gallery of examples http://scikit-image.org/docs/dev/auto_examples/ Highlights ---------- - Improved n-dimensional image support. This release adds nD support to: * ``regionprops`` computation for centroids (#2083) * ``segmentation.clear_border`` (#2087) * Hessian matrix (#2194) - In addition, the following new functions support nD images: * new wavelet denoising function, ``restoration.denoise_wavelet`` (#1833, #2190, #2238, #2240, #2241, #2242, #2462) * new thresholding functions, ``filters.threshold_sauvola`` and ``filters.threshold_niblack`` (#2266, #2441) * new local maximum, local minimum, hmaxima, hminima functions (#2449) - Grey level co-occurrence matrix (GLCM) now works with uint16 images - ``filters.try_all_threshold`` to rapidly see output of various thresholding methods - Frangi and Hessian filters (2D only) (#2153) - New *compact watershed* algorithm in ``segmentation.watershed`` (#2211) - New *shape index* algorithm in ``feature.shape_index`` (#2312) New functions and features -------------------------- - Add threshold minimum algorithm (#2104) - Implement mean and triangle thresholding (#2126) - Add Frangi and Hessian filters (#2153) - add bbox_area to region properties (#2187) - colorconv: Add rgba2rgb() (#2181) - Lewiner marching cubes algorithm (#2052) - image inversion (#2199) - wavelet denoising (from #1833) (#2190) - routine to estimate the noise standard deviation from an image (#1837) - Add compact watershed and clean up existing watershed (#2211) - Added the missing 'grey2rgb' function. (#2316) - Shape index (#2312) - Fundamental and essential matrix 8-point algorithm (#1357) - Add YUV, YIQ, YPbPr, YCbCr colorspaces - Detection of local extrema from morphology (#2449) - shannon entropy (#2416) Documentation improvements -------------------------- - add details about github SSH keys in contributing page (#2073) - Add example for felzenszwalb image segmentation (#2096) - Sphinx gallery for example gallery (#2078) - Improved region boundary RAG docs (#2106) - Add gallery Lucy-Richardson deconvolution algorithm (#2376) - Gallery: Use Horse to illustrate Convex Hull (#2431) - Add working with OpenCV in user guide (#2519) Code improvements ----------------- - Remove lena image from test suite (#1985) - Remove duplicate mean calculation in skimage.feature.match_template (#1980) - Add nD support to clear_border (#2087) - Add uint16 images support for co-occurrence matrix (#2095) - Add default parameters for Gaussian and median filters (#2151) - try_all to choose the best threshold algorithm (#2110) - Add support for multichannel in Felzenszwalb segmentation (#2134) - Improved SimilarityTransform, new EuclideanTransform class (#2044) - ENH: Speed up Hessian matrix computation (#2194) - add n-dimensional support to denoise_wavelet (#2242) - Speedup ``inpaint_biharmonic`` (#2234) - Update hessian matrix code to include order kwarg (#2327) - Handle cases for label2rgb where input labels are negative and/or nonconsecutive (#2370) - Added watershed_line parameter (#2393) API Changes ----------- - Remove deprecated ``filter`` module. Use ``filters`` instead. (#2023) - Remove ``skimage.filters.canny`` links. Use ``feature.canny`` instead. (#2024) - Removed Python 2.6 support and related checks (#2033) - Remove deprecated {h/v}sobel, {h/v}prewitt, {h/v}scharr, roberts_{positive/negative} filters (#2159) - Remove deprecated ``_mode_deprecations`` (#2156) - Remove deprecated None defaults in ``rescale_intensity`` (#2161) - Parameters ``ntiles_x`` and ``ntiles_y`` have been removed from ``exposure.equalize_adapthist`` - The minimum NumPy version is now 1.11, and the minimum SciPy version is now 0.17 Deprecations ------------ - clip_negative will be set to false by default in version 0.15 (func: dtype_limits) (#2228) - Deprecate "dynamic_range" in favor of "data_range" (#2384) - The default value of the ``circle`` argument to ``radon`` and ``iradon`` transforms will be ``True`` in 0.15 (#2235) - The default value of ``multichannel`` for ``denoise_bilateral`` and ``denoise_nl_means`` will be ``False`` in 0.15 - The default value of ``block_norm`` in ``feature.hog`` will be L2-Hysteresis in 0.15. - The ``threshold_adaptive`` function is deprecated. Use ``threshold_local`` instead. - The default value of ``mode`` in ``transform.swirl``, ``resize``, and ``rescale`` will be "reflect" in 0.15. For a complete list of contributors and pull requests merged in this release, please see our release notes online: https://github.com/scikit-image/scikit-image/blob/master/doc/release/release_0.13.rst Please spread the word, including on Twitter ! Enjoy! Juan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Wed Mar 29 14:36:36 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Wed, 29 Mar 2017 11:36:36 -0700 Subject: [scikit-image] Announcement: scikit-image 0.13.0 In-Reply-To: References: Message-ID: <1490812596.1890400.927722232.31AD8CF4@webmail.messagingengine.com> On Wed, Mar 29, 2017, at 11:22, Juan Nunez-Iglesias wrote: > We're happy to (finally) announce the release of scikit-image v0.13.0! > Special thanks to our many contributors for making it possible! This > release is the result of over a year of work, with over 200 pull > requests by 82 contributors. I want to send a huge shout-out to Juan for the great job he did on this release. v0.13.0 was big, and he took great care in sorting out various technical issues along the way. Thanks, Juan! Enjoy, everyone, and please let us know if you run into any issues! St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From fboulogne at sciunto.org Wed Mar 29 15:12:27 2017 From: fboulogne at sciunto.org (=?UTF-8?Q?Fran=c3=a7ois_Boulogne?=) Date: Wed, 29 Mar 2017 21:12:27 +0200 Subject: [scikit-image] Announcement: scikit-image 0.13.0 In-Reply-To: References: Message-ID: <99c737a1-36b0-b9c2-8d6f-e7f4c4b62851@sciunto.org> Thank you Juan for making it possible and congrats to the contributors, especially the new ones who made their first contributions. Best, -- Fran?ois Boulogne. http://www.sciunto.org GPG: 32D5F22F From jni.soma at gmail.com Wed Mar 29 13:44:19 2017 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Wed, 29 Mar 2017 13:44:19 -0400 Subject: [scikit-image] Announcement: scikit-image 0.13.0 Message-ID: <5302d3ae-73b4-4458-a61f-b36a37d1792a@Spark> We're happy to (finally) announce the release of scikit-image v0.13.0! Special thanks to all our contributors who made this possible. Linux and macOS wheels are available now on PyPI, as well as a source distribution. A conda-forge package, Windows wheels, and Debian packages should arrive in the coming days. scikit-image is an image processing toolbox for SciPy that includes algorithms for segmentation, geometric transformations, color space manipulation, analysis, filtering, morphology, feature detection, and more. For more information, examples, and documentation, please visit our website: http://scikit-image.org and our gallery of examples http://scikit-image.org/docs/dev/auto_examples/ Highlights ---------- This release is the result of a year of work, with over 200 pull requests by 82 contributors. Highlights include: - Improved n-dimensional image support. This release adds nD support to: ? * ``regionprops`` computation for centroids (#2083) ? * ``segmentation.clear_border`` (#2087) ? * Hessian matrix (#2194, #2327) - In addition, the following new functions support nD images: ? * new wavelet denoising function, ``restoration.denoise_wavelet`` (#1833, #2190, #2238, #2240, #2241, #2242, #2462) ? * new thresholding functions, ``filters.threshold_sauvola`` and ``filters.threshold_niblack`` (#2266, #2441) ? * new local maximum, local minimum, hmaxima, hminima functions (#2449) - Grey level co-occurrence matrix (GLCM) now works with uint16 images - ``filters.try_all_threshold`` to rapidly see output of various thresholding methods - Frangi and Hessian filters (2D only) (#2153) - New *compact watershed* algorithm in ``segmentation.watershed`` (#2211) - New *shape index* algorithm in ``feature.shape_index`` (#2312) New functions and features -------------------------- - Add threshold minimum algorithm (#2104) - Implement mean and triangle thresholding (#2126) - Add Frangi and Hessian filters (#2153) - add bbox_area to region properties (#2187) - colorconv: Add rgba2rgb() (#2181) - Lewiner marching cubes algorithm (#2052) - image inversion (#2199) - wavelet denoising (from #1833) (#2190) - routine to estimate the noise standard deviation from an image (#1837) - Add compact watershed and clean up existing watershed (#2211) - Added the missing 'grey2rgb' function. (#2316) - Shape index (#2312) - Fundamental and essential matrix 8-point algorithm (#1357) - Add YUV, YIQ, YPbPr, YCbCr colorspaces - Detection of local extrema from morphology (#2449) - shannon entropy (#2416) Documentation improvements -------------------------- - add details about github SSH keys in contributing page (#2073) - Add example for felzenszwalb image segmentation (#2096) - Sphinx gallery for example gallery (#2078) - Improved region boundary RAG docs (#2106) - Add gallery Lucy-Richardson deconvolution algorithm (#2376) - Gallery: Use Horse to illustrate Convex Hull (#2431) - Add working with OpenCV in user guide (#2519) Code improvements ----------------- - Remove lena image from test suite (#1985) - Remove duplicate mean calculation in skimage.feature.match_template (#1980) - Add nD support to clear_border (#2087) - Add uint16 images support for co-occurrence matrix (#2095) - Add default parameters for Gaussian and median filters (#2151) - try_all to choose the best threshold algorithm (#2110) - Add support for multichannel in Felzenszwalb segmentation (#2134) - Improved SimilarityTransform, new EuclideanTransform class (#2044) - ENH: Speed up Hessian matrix computation (#2194) - add n-dimensional support to denoise_wavelet (#2242) - Speedup ``inpaint_biharmonic`` (#2234) - Update hessian matrix code to include order kwarg (#2327) - Handle cases for label2rgb where input labels are negative and/or ? nonconsecutive (#2370) - Added watershed_line parameter (#2393) API Changes ----------- - Remove deprecated ``filter`` module. Use ``filters`` instead. (#2023) - Remove ``skimage.filters.canny`` links. Use ``feature.canny`` instead. (#2024) - Removed Python 2.6 support and related checks (#2033) - Remove deprecated {h/v}sobel, {h/v}prewitt, {h/v}scharr, roberts_{positive/negative} filters (#2159) - Remove deprecated ``_mode_deprecations`` (#2156) - Remove deprecated None defaults in ``rescale_intensity`` (#2161) - Parameters ``ntiles_x`` and ``ntiles_y`` have been removed from ``exposure.equalize_adapthist`` - The minimum NumPy version is now 1.11, and the minimum SciPy version is now 0.17 Deprecations ------------ - clip_negative will be set to false by default in version 0.15 ? (func: dtype_limits) (#2228) - Deprecate "dynamic_range" in favor of "data_range" (#2384) - The default value of the ``circle`` argument to ``radon`` and ``iradon`` transforms will be ``True`` in 0.15 (#2235) - The default value of ``multichannel`` for ``denoise_bilateral`` and ``denoise_nl_means`` will be ``False`` in 0.15 - The default value of ``block_norm`` in ``feature.hog`` will be L2-Hysteresis in 0.15. - The ``threshold_adaptive`` function is deprecated. Use ``threshold_local`` instead. - The default value of ``mode`` in ``transform.swirl``, ``resize``, and ``rescale`` will be "reflect" in 0.15. For a complete list of contributors to this release, and PRs merged, please see the online release notes: https://github.com/scikit-image/scikit-image/blob/master/doc/release/release_0.13.rst Enjoy! -------------- next part -------------- An HTML attachment was scrubbed... URL: