From rideamus at yahoo.com Sun Apr 2 18:30:57 2017 From: rideamus at yahoo.com (Serge Shakhov) Date: Sun, 2 Apr 2017 22:30:57 +0000 (UTC) Subject: [scikit-image] How to see full image after transformation not the cropped one References: <500002450.8647029.1491172257517.ref@mail.yahoo.com> Message-ID: <500002450.8647029.1491172257517@mail.yahoo.com> Hello everybody This question was raised here:?Google Grup | | | Google Grup Google Grup memungkinkan Anda untuk membuat dan berpartisipasi dalam forum online serta grup berbasis email deng... | | | ? ? ? But I didn't find an answer.I'm doing?2D piecewise affine transformation with??skimage.transform.PiecewiseAffineTransformResult image is heavily cropped.I tried to play with?output_shape, mode and clip parameters but without any effect, image is still cropped.Could anyone point me what am I doing wrong?Thanks Best regards, Serge Shakhov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From egor.v.panfilov at gmail.com Mon Apr 3 03:04:58 2017 From: egor.v.panfilov at gmail.com (Egor Panfilov) Date: Mon, 3 Apr 2017 10:04:58 +0300 Subject: [scikit-image] How to see full image after transformation not the cropped one In-Reply-To: <500002450.8647029.1491172257517@mail.yahoo.com> References: <500002450.8647029.1491172257517.ref@mail.yahoo.com> <500002450.8647029.1491172257517@mail.yahoo.com> Message-ID: Hi Serge, Could you provide an example of the code you are running. This will help us to better understand the issue, and solve it faster. Thanks! Regards, Egor 2017-04-03 1:30 GMT+03:00 Serge Shakhov via scikit-image < scikit-image at python.org>: > Hello everybody > > This question was raised here: Google Grup > > > Google Grup > Google Grup memungkinkan Anda untuk membuat dan berpartisipasi dalam forum > online serta grup berbasis email deng... > > ? > ? > ? > > But I didn't find an answer. > I'm doing 2D piecewise affine transformation with skimage.transform. > PiecewiseAffineTransform > Result image is heavily cropped. > I tried to play with output_shape, mode and clip parameters but without > any effect, image is still cropped. > Could anyone point me what am I doing wrong? > Thanks > > Best regards, > Serge Shakhov. > > _______________________________________________ > 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 Mon Apr 3 11:55:55 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Mon, 03 Apr 2017 08:55:55 -0700 Subject: [scikit-image] How to see full image after transformation not the cropped one In-Reply-To: <500002450.8647029.1491172257517@mail.yahoo.com> References: <500002450.8647029.1491172257517.ref@mail.yahoo.com> <500002450.8647029.1491172257517@mail.yahoo.com> Message-ID: <1491234955.3580357.932609936.02982F66@webmail.messagingengine.com> Hi Serge On Sun, Apr 2, 2017, at 15:30, Serge Shakhov via scikit-image wrote: > But I didn't find an answer. > I'm doing 2D piecewise affine transformation with > skimage.transform.PiecewiseAffineTransform > Result image is heavily cropped. > I tried to play with output_shape, mode and clip parameters but > without any effect, image is still cropped. > Could anyone point me what am I doing wrong? I thought we had this implemented, but I guess not yet. You can see how here: https://github.com/scikit-image/skimage-tutorials/blob/master/lectures/adv3_panorama-stitching.ipynb Specifically: *from* *skimage.transform* *import* SimilarityTransform *# Shape of middle image, our registration target* r, c = image.shape *# Note that transformations take coordinates in (x, y) format,* *# not (row, column), in order to be consistent with most literature* corners = np.array([[, ], [, r], [c, ], [c, r]]) *# Warp the image corners to their new positions* warped_corners = my_tf(corners) *# The overall output shape will be max - min* corner_min = np.min(corners, axis=0) corner_max = np.max(corners, axis=0) output_shape = (corner_max - corner_min) *# Ensure integer shape with np.ceil and dtype conversion* output_shape = np.ceil(output_shape[::-1]).astype(int) That calculates the shape you want. You now need to modify the transform to output an image inside of this shape: *from* *skimage.transform* *import* warp * # This in-plane offset is the only necessary transformation for the # middle image* offset = SimilarityTransform(translation=-corner_min) shifted_transform = (my_tf + offset).inverse pano0_warped = warp(image, shifted_transform, order=3, output_shape=output_shape, cval=-1) Let us know how that goes! St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From msaunders83 at gmail.com Mon Apr 3 15:00:51 2017 From: msaunders83 at gmail.com (mat saunders) Date: Mon, 3 Apr 2017 15:00:51 -0400 Subject: [scikit-image] Fwd: SSIM with tolerances In-Reply-To: References: Message-ID: I sent this to scikit-learn by accident, so forwarding to image. Hi, I am using SSIM to compare 2 video streams\sets of images and I find it to be almost too accurate. I would like some fudge factor like other image comparison tools have. I used to do it in an automated test suite but due to file sizes and amounts I turned to scikit. I do quality assurance on a render engine and we just want to make sure the images are meaningfully identical build to build. Currently with SSIM I am seeing things as small as 4 pixels across a 1920x1080 image different. I personally would like to ignore those 4 pixels but still catch meaningful items. Say if 8 pixels near each other were off keep those but if they are 8 pixels randomly through the image ignore them. Does this sound like something logical, say using an adjacency of pixels with a tolerance value for color and number of pixels as arguments? See attached image for example of how little is different in the entire image. It is a GIF zoomed in to the exact spot of 3 different pixels so hopefully it works. I also attached the comparison image to show how little changed. Another issue that we had is we had to turn off AA to get rid of noise, it is amazing how accurate this library is!! Regards, Mathew Saunders -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 3dots-again.gif Type: image/gif Size: 101041 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Pasted image at 2017_03_28 12_51 PM.png Type: image/png Size: 409206 bytes Desc: not available URL: From stefanv at berkeley.edu Mon Apr 3 15:47:03 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Mon, 03 Apr 2017 12:47:03 -0700 Subject: [scikit-image] Fwd: SSIM with tolerances In-Reply-To: References: Message-ID: <1491248823.1975796.932894232.1CB169EF@webmail.messagingengine.com> Hi Mat You'll probably have to come up with some heuristics for the kinds of errors you wish to identify. As a very crude first attempt, you may try to downscale the images before comparison to reduce sensitivity. Perhaps also take a look at what Matplotlib does in their test suite to compare different renderings of plots (I know they do image comparison too). Best regards St?fan On Mon, Apr 3, 2017, at 12:00, mat saunders wrote: > I sent this to scikit-learn by accident, so forwarding to image. > > Hi, > > I am using SSIM to compare 2 video streams\sets of images and I find > it to be almost too accurate. I would like some fudge factor like > other image comparison tools have. I used to do it in an automated > test suite but due to file sizes and amounts I turned to scikit. > > I do quality assurance on a render engine and we just want to make > sure the images are meaningfully identical build to build. Currently > with SSIM I am seeing things as small as 4 pixels across a 1920x1080 > image different. I personally would like to ignore those 4 pixels but > still catch meaningful items. Say if 8 pixels near each other were > off keep those but if they are 8 pixels randomly through the image > ignore them. > > Does this sound like something logical, say using an adjacency of > pixels with a tolerance value for color and number of pixels as > arguments? > > See attached image for example of how little is different in the > entire image. It is a GIF zoomed in to the exact spot of 3 different > pixels so hopefully it works. I also attached the comparison image to > show how little changed. > > Another issue that we had is we had to turn off AA to get rid of > noise, it is amazing how accurate this library is!! > > Regards, > Mathew Saunders > _________________________________________________ > scikit-image mailing list > scikit-image at python.org > https://mail.python.org/mailman/listinfo/scikit-image > Email had 2 attachments: > * 3dots-again.gif 138k (image/gif) > * Pasted image at 2017_03_28 12_51 PM.png 560k (image/png) -------------- next part -------------- An HTML attachment was scrubbed... URL: From msaunders83 at gmail.com Mon Apr 3 15:51:03 2017 From: msaunders83 at gmail.com (mat saunders) Date: Mon, 3 Apr 2017 15:51:03 -0400 Subject: [scikit-image] Fwd: SSIM with tolerances In-Reply-To: <1491248823.1975796.932894232.1CB169EF@webmail.messagingengine.com> References: <1491248823.1975796.932894232.1CB169EF@webmail.messagingengine.com> Message-ID: Hi Stefan, Thank you for feedback I will look at it more closely and see what I can come up with. I did not know about the matplotlib comparison so I will see what they do. I did come across this the other day and wondered about down scaling. http://tech.jetsetter.com/2017/03/21/duplicate-image-detection/ Thanks, Mat Saunders On Mon, Apr 3, 2017 at 3:47 PM, Stefan van der Walt wrote: > Hi Mat > > You'll probably have to come up with some heuristics for the kinds of > errors you wish to identify. As a very crude first attempt, you may try to > downscale the images before comparison to reduce sensitivity. Perhaps also > take a look at what Matplotlib does in their test suite to compare > different renderings of plots (I know they do image comparison too). > > Best regards > St?fan > > > On Mon, Apr 3, 2017, at 12:00, mat saunders wrote: > > I sent this to scikit-learn by accident, so forwarding to image. > > Hi, > > I am using SSIM to compare 2 video streams\sets of images and I find it to > be almost too accurate. I would like some fudge factor like other image > comparison tools have. I used to do it in an automated test suite but due > to file sizes and amounts I turned to scikit. > > I do quality assurance on a render engine and we just want to make sure > the images are meaningfully identical build to build. Currently with SSIM I > am seeing things as small as 4 pixels across a 1920x1080 image different. I > personally would like to ignore those 4 pixels but still catch meaningful > items. Say if 8 pixels near each other were off keep those but if they are > 8 pixels randomly through the image ignore them. > > Does this sound like something logical, say using an adjacency of pixels > with a tolerance value for color and number of pixels as arguments? > > See attached image for example of how little is different in the entire > image. It is a GIF zoomed in to the exact spot of 3 different pixels so > hopefully it works. I also attached the comparison image to show how little > changed. > > Another issue that we had is we had to turn off AA to get rid of noise, it > is amazing how accurate this library is!! > > Regards, > Mathew Saunders > *_______________________________________________* > scikit-image mailing list > scikit-image at python.org > https://mail.python.org/mailman/listinfo/scikit-image > > Email had 2 attachments: > > - 3dots-again.gif > 138k (image/gif) > - Pasted image at 2017_03_28 12_51 PM.png > 560k (image/png) > > > > _______________________________________________ > 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 Mon Apr 3 16:03:53 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Mon, 03 Apr 2017 13:03:53 -0700 Subject: [scikit-image] Fwd: SSIM with tolerances In-Reply-To: References: <1491248823.1975796.932894232.1CB169EF@webmail.messagingengine.com> Message-ID: <1491249833.1979860.932908920.148223E1@webmail.messagingengine.com> Hi Mat On Mon, Apr 3, 2017, at 12:51, mat saunders wrote: > Thank you for feedback I will look at it more closely and see what I > can come up with. I did not know about the matplotlib comparison so I > will see what they do. I did come across this the other day and > wondered about down scaling. > http://tech.jetsetter.com/2017/03/21/duplicate-image-detection/ I suspect this mechanism is too crude for what you want---videos often have small codec artifacts, and you want to be insensitive to those. E.g., you may not care much about introducing blocking / smudging, but very much about color changes. Or, since you are working with video, perhaps you only care about key-frames, or only about sliding window (over time) averages. Feel free to give me a call sometime if you want to brainstorm ideas. Best regards St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rideamus at yahoo.com Mon Apr 3 18:14:31 2017 From: rideamus at yahoo.com (Serge Shakhov) Date: Mon, 3 Apr 2017 22:14:31 +0000 (UTC) Subject: [scikit-image] How to see full image after transformation not the cropped one In-Reply-To: <1491234955.3580357.932609936.02982F66@webmail.messagingengine.com> References: <500002450.8647029.1491172257517.ref@mail.yahoo.com> <500002450.8647029.1491172257517@mail.yahoo.com> <1491234955.3580357.932609936.02982F66@webmail.messagingengine.com> Message-ID: <1302668839.10115410.1491257671866@mail.yahoo.com> Hi Stefan, Thanks for your reply.My experience with scikit-image just started with this script, I'm not experienced at all.Here is the test script:import skimage.transform import matplotlib.pyplot as plt from PIL import Image from skimage import data from skimage.transform import resize from skimage.transform import rescale import numpy as np import os from skimage import io srcIm = data.checkerboard() src = np.array([[(0,0),(100,0),(110,0)],[(0,110),(100,110),(110,110)]]) dst = np.array([[(0,0),(50,0),(70,0)],[(0,20),(60,50),(100,100)]]) src = src.astype(float) dst = dst.astype(float) #revert to 1D list src = src.reshape(((src.shape[0]*src.shape[1]),2), order='F') dst = dst.reshape(((dst.shape[0]*dst.shape[1]),2), order='F') #Perform transform piecewiseAffine = skimage.transform.PiecewiseAffineTransform() piecewiseAffine.estimate(src,dst) dstArr = skimage.transform.warp(srcIm, piecewiseAffine, order=1, mode='constant', cval=0, clip=False, preserve_range=False) #Visualise result dstArr = np.array(dstArr * 255., dtype=np.uint8) dstIm = Image.fromarray(dstArr) dstIm.show()Could you help me and point to what I have to modify here?? If I reverse the?piecewiseAffine.estimate(src,dst) -->>?piecewiseAffine.estimate(dst, src)I can get the opposite transformation and it's not cropped, but not the one I need. Thanks. Best regards, Serge Shakhov. On Tuesday, 4 April 2017, 3:56, Stefan van der Walt wrote: Hi Serge On Sun, Apr 2, 2017, at 15:30, Serge Shakhov via scikit-image wrote: But I didn't find an answer. I'm doing?2D piecewise affine transformation with??skimage.transform.PiecewiseAffineTransform Result image is heavily cropped. I tried to play with?output_shape, mode and clip parameters but without any effect, image is still cropped. Could anyone point me what am I doing wrong? I thought we had this implemented, but I guess not yet. ?You can see how here: https://github.com/scikit-image/skimage-tutorials/blob/master/lectures/adv3_panorama-stitching.ipynb Specifically: from skimage.transform import SimilarityTransform # Shape of middle image, our registration target r, c = image.shape # Note that transformations take coordinates in (x, y) format, # not (row, column), in order to be consistent with most literature corners = np.array([[0, 0], [0, r], [c, 0], [c, r]]) # Warp the image corners to their new positions warped_corners = my_tf(corners) # The overall output shape will be max - min corner_min = np.min(corners, axis=0) corner_max = np.max(corners, axis=0) output_shape = (corner_max - corner_min) # Ensure integer shape with np.ceil and dtype conversion output_shape = np.ceil(output_shape[::-1]).astype(int) That calculates the shape you want. ?You now need to modify the transform to output an image inside of this shape: from skimage.transform import warp # This in-plane offset is the only necessary transformation for the middle image offset = SimilarityTransform(translation=-corner_min) shifted_transform = (my_tf + offset).inverse pano0_warped = warp(image, shifted_transform, order=3, output_shape=output_shape, cval=-1) Let us know how that goes! 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 johnjenkinson1 at gmail.com Mon Apr 3 19:49:22 2017 From: johnjenkinson1 at gmail.com (John Jenkinson) Date: Mon, 3 Apr 2017 18:49:22 -0500 Subject: [scikit-image] How to see full image after transformation not the cropped one In-Reply-To: <1302668839.10115410.1491257671866@mail.yahoo.com> References: <500002450.8647029.1491172257517.ref@mail.yahoo.com> <500002450.8647029.1491172257517@mail.yahoo.com> <1491234955.3580357.932609936.02982F66@webmail.messagingengine.com> <1302668839.10115410.1491257671866@mail.yahoo.com> Message-ID: Hi guys, Please remove me from this mailing list. On Apr 3, 2017 5:18 PM, "Serge Shakhov via scikit-image" < scikit-image at python.org> wrote: > Hi Stefan, > > Thanks for your reply. > My experience with scikit-image just started with this script, I'm not > experienced at all. > Here is the test script: > > import skimage.transform > import matplotlib.pyplot as plt > from PIL import Image > from skimage import data > from skimage.transform import resize > from skimage.transform import rescale > import numpy as np > import os > from skimage import io > > srcIm = data.checkerboard() > src = np.array([[(0,0),(100,0),(110,0)],[(0,110),(100,110),(110,110)]]) > dst = np.array([[(0,0),(50,0),(70,0)],[(0,20),(60,50),(100,100)]]) > > src = src.astype(float) > dst = dst.astype(float) > > #revert to 1D list > src = src.reshape(((src.shape[0]*src.shape[1]),2), order='F') > dst = dst.reshape(((dst.shape[0]*dst.shape[1]),2), order='F') > > #Perform transform > piecewiseAffine = skimage.transform.PiecewiseAffineTransform() > piecewiseAffine.estimate(src,dst) > dstArr = skimage.transform.warp(srcIm, piecewiseAffine, order=1, mode='constant', cval=0, clip=False, preserve_range=False) > > #Visualise result > dstArr = np.array(dstArr * 255., dtype=np.uint8) > > dstIm = Image.fromarray(dstArr) > dstIm.show() > > Could you help me and point to what I have to modify here? > > If I reverse the piecewiseAffine.estimate(src,dst) > -->> piecewiseAffine.estimate(dst, src) > I can get the opposite transformation and it's not cropped, but not the > one I need. > > Thanks. > > > Best regards, > Serge Shakhov. > > > On Tuesday, 4 April 2017, 3:56, Stefan van der Walt > wrote: > > > Hi Serge > > On Sun, Apr 2, 2017, at 15:30, Serge Shakhov via scikit-image wrote: > > But I didn't find an answer. > I'm doing 2D piecewise affine transformation with skimage.transform. > PiecewiseAffineTransform > Result image is heavily cropped. > I tried to play with output_shape, mode and clip parameters but without > any effect, image is still cropped. > Could anyone point me what am I doing wrong? > > > I thought we had this implemented, but I guess not yet. You can see how > here: > > https://github.com/scikit-image/skimage-tutorials/blob/ > master/lectures/adv3_panorama-stitching.ipynb > > Specifically: > > *from* *skimage.transform* *import* SimilarityTransform > *# Shape of middle image, our registration target*r, c = image.shape > *# Note that transformations take coordinates in (x, y) format,**# not (row, column), in order to be consistent with most literature*corners = np.array([[0, 0], > [0, r], > [c, 0], > [c, r]]) > *# Warp the image corners to their new positions*warped_corners = my_tf(corners) > *# The overall output shape will be max - min*corner_min = np.min(corners, axis=0)corner_max = np.max(corners, axis=0)output_shape = (corner_max - corner_min) > *# Ensure integer shape with np.ceil and dtype conversion*output_shape = np.ceil(output_shape[::-1]).astype(int) > > > That calculates the shape you want. You now need to modify the transform > to output an image inside of this shape: > > *from* *skimage.transform* *import* warp > *# This in-plane offset is the only necessary transformation for the middle image*offset = SimilarityTransform(translation=-corner_min) > > shifted_transform = (my_tf + offset).inversepano0_warped = warp(image, shifted_transform, order=3, > output_shape=output_shape, cval=-1) > > > Let us know how that goes! > > 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 stefanv at berkeley.edu Tue Apr 4 02:58:56 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Mon, 03 Apr 2017 23:58:56 -0700 Subject: [scikit-image] How to see full image after transformation not the cropped one In-Reply-To: <1302668839.10115410.1491257671866@mail.yahoo.com> References: <500002450.8647029.1491172257517.ref@mail.yahoo.com> <500002450.8647029.1491172257517@mail.yahoo.com> <1491234955.3580357.932609936.02982F66@webmail.messagingengine.com> <1302668839.10115410.1491257671866@mail.yahoo.com> Message-ID: <1491289136.469290.933390496.1DCF3869@webmail.messagingengine.com> Hi Serge Have a look at the attached version. St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: warp_to_extents.py Type: text/x-python Size: 1735 bytes Desc: not available URL: From rideamus at yahoo.com Tue Apr 4 18:28:54 2017 From: rideamus at yahoo.com (Serge Shakhov) Date: Tue, 4 Apr 2017 22:28:54 +0000 (UTC) Subject: [scikit-image] How to see full image after transformation not the cropped one In-Reply-To: <1491289136.469290.933390496.1DCF3869@webmail.messagingengine.com> References: <500002450.8647029.1491172257517.ref@mail.yahoo.com> <500002450.8647029.1491172257517@mail.yahoo.com> <1491234955.3580357.932609936.02982F66@webmail.messagingengine.com> <1302668839.10115410.1491257671866@mail.yahoo.com> <1491289136.469290.933390496.1DCF3869@webmail.messagingengine.com> Message-ID: <1089429596.11304229.1491344934813@mail.yahoo.com> Hi Stefan. Noticed that you changed my?PiecewiseAffineTransform?to?AffineTransform.Is it applicable to?PiecewiseAffineTransform??When I tried to revert it back to?PiecewiseAffineTransformGot error:?Traceback (most recent call last): ? File "C:/Users/Serge/Downloads/warp_to_extents.py", line 45, in ? ? shifted_transform = (affine + offset).inverse? File "C:\Users\Serge\Software\lib\site-packages\skimage\transform\_geometric.py", line 208, in __add__? ? raise NotImplementedError()NotImplementedError Thanks??Best regards, Serge Shakhov. On Tuesday, 4 April 2017, 18:58, Stefan van der Walt wrote: Hi Serge Have a look at the attached version. St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Tue Apr 4 18:35:33 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Tue, 04 Apr 2017 15:35:33 -0700 Subject: [scikit-image] How to see full image after transformation not the cropped one In-Reply-To: <1089429596.11304229.1491344934813@mail.yahoo.com> References: <500002450.8647029.1491172257517.ref@mail.yahoo.com> <500002450.8647029.1491172257517@mail.yahoo.com> <1491234955.3580357.932609936.02982F66@webmail.messagingengine.com> <1302668839.10115410.1491257671866@mail.yahoo.com> <1491289136.469290.933390496.1DCF3869@webmail.messagingengine.com> <1089429596.11304229.1491344934813@mail.yahoo.com> Message-ID: <1491345333.2491491.934355592.15FE86FF@webmail.messagingengine.com> Hi Serge There is no inverse defined for the piecewise affine, hence the change I made. St?fan On Tue, Apr 4, 2017, at 15:28, Serge Shakhov wrote: > Hi Stefan. > > Noticed that you changed my PiecewiseAffineTransform to > AffineTransform. > Is it applicable to PiecewiseAffineTransform? > When I tried to revert it back to PiecewiseAffineTransform > Got error: > Traceback (most recent call last): > File "C:/Users/Serge/Downloads/warp_to_extents.py", line 45, in > > shifted_transform = (affine + offset).inverse > File "C:\Users\Serge\Software\lib\site- > packages\skimage\transform\_geometric.py", line 208, in __add__ > raise NotImplementedError() > NotImplementedError > > > Thanks > > Best regards, > Serge Shakhov. > > On Tuesday, 4 April 2017, 18:58, Stefan van der Walt > wrote: > > > Hi Serge > > Have a look at the attached version. > > > St?fan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rideamus at yahoo.com Tue Apr 4 18:43:14 2017 From: rideamus at yahoo.com (Serge Shakhov) Date: Tue, 4 Apr 2017 22:43:14 +0000 (UTC) Subject: [scikit-image] How to see full image after transformation not the cropped one In-Reply-To: <1491345333.2491491.934355592.15FE86FF@webmail.messagingengine.com> References: <500002450.8647029.1491172257517.ref@mail.yahoo.com> <500002450.8647029.1491172257517@mail.yahoo.com> <1491234955.3580357.932609936.02982F66@webmail.messagingengine.com> <1302668839.10115410.1491257671866@mail.yahoo.com> <1491289136.469290.933390496.1DCF3869@webmail.messagingengine.com> <1089429596.11304229.1491344934813@mail.yahoo.com> <1491345333.2491491.934355592.15FE86FF@webmail.messagingengine.com> Message-ID: <53560559.10427575.1491345794676@mail.yahoo.com> okay, but I don't need Affine.Does it mean that there is no solution for my problem??Best regards, Serge Shakhov. On Wednesday, 5 April 2017, 10:35, Stefan van der Walt wrote: Hi Serge There is no inverse defined for the piecewise affine, hence the change I made. St?fan On Tue, Apr 4, 2017, at 15:28, Serge Shakhov wrote: Hi Stefan. Noticed that you changed my?PiecewiseAffineTransform?to?AffineTransform. Is it applicable to?PiecewiseAffineTransform?? When I tried to revert it back to?PiecewiseAffineTransform Got error:? Traceback (most recent call last): ? File "C:/Users/Serge/Downloads/warp_to_extents.py", line 45, in ? ? shifted_transform = (affine + offset).inverse ? File "C:\Users\Serge\Software\lib\site-packages\skimage\transform\_geometric.py", line 208, in __add__ ? ? raise NotImplementedError() NotImplementedError Thanks? ? Best regards, Serge Shakhov. On Tuesday, 4 April 2017, 18:58, Stefan van der Walt wrote: Hi Serge Have a look at the attached version. St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.shrawankumar at gmail.com Tue Apr 4 19:48:23 2017 From: m.shrawankumar at gmail.com (Shrawan) Date: Tue, 4 Apr 2017 16:48:23 -0700 Subject: [scikit-image] 3D to 2D projective transformation Message-ID: Dear scikit-image developers, Could any one help me with a problem that involves finding registration parameters between a 3D volume data and a 2D perspective projection? The 3D data is from light microscopy and 2D data is from scanning electron microscopy and I can provide more details if needed. If such a tool doesn't exist already in scikit-image, would anyone be interested in creating one? Of course, the person would be recognized for his/her work in the peer-reviewed article that develops from this collaboration. Thank you in advance Best, Shrawan -- Shrawan Kumar Mageswaran Postdoctoral Scholar Jensen Lab California Institute of Technology -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Wed Apr 5 02:32:48 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Tue, 04 Apr 2017 23:32:48 -0700 Subject: [scikit-image] 3D to 2D projective transformation In-Reply-To: References: Message-ID: <1491373968.3493584.934667968.4ED0C9FC@webmail.messagingengine.com> On Tue, Apr 4, 2017, at 16:48, Shrawan wrote: > Could any one help me with a problem that involves finding > registration parameters between a 3D volume data and a 2D perspective > projection? The 3D data is from light microscopy and 2D data is from > scanning electron microscopy and I can provide more details if needed. > If such a tool doesn't exist already in scikit-image, would anyone be > interested in creating one? Of course, the person would be recognized > for his/her work in the peer-reviewed article that develops from this > collaboration. Thank you in advance You may want to direct this question to the nipy list: https://mail.python.org/mailman/listinfo/neuroimaging At least two of their packages do registration on volumetric data. scikit-image does not currently have this implemented. St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From vighneshbirodkar at gmail.com Wed Apr 5 12:29:53 2017 From: vighneshbirodkar at gmail.com (Vighnesh Birodkar) Date: Wed, 5 Apr 2017 12:29:53 -0400 Subject: [scikit-image] Tools for 3D segmentation ? Message-ID: Hello guys I was wondering if anyone on the list knew about software to do 3d segmentation. Thanks Vighnesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From imagepy at sina.com Wed Apr 5 13:02:54 2017 From: imagepy at sina.com (imagepy at sina.com) Date: Thu, 06 Apr 2017 01:02:54 +0800 Subject: [scikit-image] =?gbk?q?=BB=D8=B8=B4=3A_Tools_for_3D_segmentation_?= =?gbk?q?=3F?= Message-ID: <20170405170254.A70E22E00CF@webmail.sinamail.sina.com.cn> -------------------------------- I known itk has many 2d,3d segment raster algrism, and cgal has some vector algrism. but it is not a independent work, you must do some pretreatment and use the right method, then the segment work will be esaier. -------- ???? -------- ???:Vighnesh Birodkar ??????:2017?4?6? 00:30(???) ???:scikit-image at python.org ??:[scikit-image] Tools for 3D segmentation ? Hello guys I was wondering if anyone on the list knew about software to do 3d segmentation. ThanksVighnesh _______________________________________________ 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 graham.kosiba at gmail.com Wed Apr 5 13:44:53 2017 From: graham.kosiba at gmail.com (Graham Kosiba) Date: Wed, 5 Apr 2017 13:44:53 -0400 Subject: [scikit-image] Tools for 3D segmentation ? In-Reply-To: References: Message-ID: I have also done 3D segmentation in the past with imageJ and specifically the 3Dviewer and boneJ plugins. Graham On Wed, Apr 5, 2017 at 12:29 PM, Vighnesh Birodkar < vighneshbirodkar at gmail.com> wrote: > Hello guys > > I was wondering if anyone on the list knew about software to do 3d > segmentation. > > Thanks > Vighnesh > > _______________________________________________ > 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 joferkington at gmail.com Wed Apr 5 14:14:42 2017 From: joferkington at gmail.com (Joe Kington) Date: Wed, 5 Apr 2017 13:14:42 -0500 Subject: [scikit-image] Tools for 3D segmentation ? In-Reply-To: References: Message-ID: For basic segmentation, scipy.ndimage has what you're looking for. For more specalized/advanced methods, you'll need to go beyond it (e.g. itk), but scipy.ndimage is sufficient for most tasks. On Wed, Apr 5, 2017 at 12:44 PM, Graham Kosiba wrote: > I have also done 3D segmentation in the past with imageJ and specifically > the 3Dviewer and boneJ plugins. > > Graham > > On Wed, Apr 5, 2017 at 12:29 PM, Vighnesh Birodkar < > vighneshbirodkar at gmail.com> wrote: > >> Hello guys >> >> I was wondering if anyone on the list knew about software to do 3d >> segmentation. >> >> Thanks >> Vighnesh >> >> _______________________________________________ >> 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 Wed Apr 5 14:22:29 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Wed, 05 Apr 2017 11:22:29 -0700 Subject: [scikit-image] Tools for 3D segmentation ? In-Reply-To: References: Message-ID: <1491416549.650886.935383736.1C144930@webmail.messagingengine.com> On Wed, Apr 5, 2017, at 09:29, Vighnesh Birodkar wrote: > I was wondering if anyone on the list knew about software to do 3d > segmentation. There's so much going on in that space that I wouldn't even know where to start without understanding your problem in more detail. But here's a place to start, a blog post by Emmanuelle, one of our core devs: http://emmanuelle.github.io/segmentation-of-3-d-tomography-images-with-python-and-scikit-image.html St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From matteo.niccoli at gmail.com Wed Apr 5 16:38:46 2017 From: matteo.niccoli at gmail.com (Matteo Niccoli) Date: Wed, 5 Apr 2017 14:38:46 -0600 Subject: [scikit-image] Tools for 3D segmentation ? In-Reply-To: <1491416549.650886.935383736.1C144930@webmail.messagingengine.com> References: <1491416549.650886.935383736.1C144930@webmail.messagingengine.com> Message-ID: I love Emmanuelle's posts. I think snakes might also work for 3D segmentation: https://github.com/pmneila/morphsnakes Matteo Niccoli P. Geo., M.sc. Geophysics and data science [image: WordPress] [image: LinkedIn] [image: Twitter] [image: Custom link] [image: Custom link] On Wed, Apr 5, 2017 at 12:22 PM, Stefan van der Walt wrote: > On Wed, Apr 5, 2017, at 09:29, Vighnesh Birodkar wrote: > > I was wondering if anyone on the list knew about software to do 3d > segmentation. > > > There's so much going on in that space that I wouldn't even know where to > start without understanding your problem in more detail. But here's a > place to start, a blog post by Emmanuelle, one of our core devs: > > http://emmanuelle.github.io/segmentation-of-3-d- > tomography-images-with-python-and-scikit-image.html > > 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 grlee77 at gmail.com Wed Apr 5 19:42:36 2017 From: grlee77 at gmail.com (Gregory Lee) Date: Wed, 5 Apr 2017 19:42:36 -0400 Subject: [scikit-image] Tools for 3D segmentation ? In-Reply-To: References: Message-ID: > I was wondering if anyone on the list knew about software to do 3d > segmentation. > > Thanks > Vighnesh > > A nice, free GUI-based tool for interactive 3D segmentation is itk-snap http://www.itksnap.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jni.soma at gmail.com Wed Apr 5 21:50:01 2017 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Wed, 5 Apr 2017 21:50:01 -0400 Subject: [scikit-image] Tools for 3D segmentation ? In-Reply-To: References: Message-ID: <8c856705-ad4b-4238-8fbf-34a112f1d96d@Spark> Well, almost three years ago we had a GSoC student work on it? =P Assuming you mean manual 3D segmentation, I second Greg?s recommendation of ITK-SNAP for fully manual segmentation. For semi-automated work, I recommend Ilastik (ilastik.org). Juan. On 5 Apr 2017, 7:43 PM -0400, Gregory Lee , wrote: > > > > I was wondering if anyone on the list knew about software to do 3d segmentation. > > > > > > Thanks > > > Vighnesh > > > > > > > A nice, free GUI-based tool for interactive 3D segmentation is itk-snap > > http://www.itksnap.org/ > > > _______________________________________________ > 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 vighneshbirodkar at gmail.com Wed Apr 5 21:57:46 2017 From: vighneshbirodkar at gmail.com (Vighnesh Birodkar) Date: Wed, 5 Apr 2017 21:57:46 -0400 Subject: [scikit-image] Tools for 3D segmentation ? In-Reply-To: <8c856705-ad4b-4238-8fbf-34a112f1d96d@Spark> References: <8c856705-ad4b-4238-8fbf-34a112f1d96d@Spark> Message-ID: Hey guys Sorry for not being clear about this. What I meant is manual labelling of 3D volumes. I cannot reveal all the details, but it's basically a foreground ?Vs background labelling task. On 5 Apr 2017 9:52 pm, "Juan Nunez-Iglesias" wrote: > Well, almost three years ago we had a GSoC student work on it? =P > > Assuming you mean manual 3D segmentation, I second Greg?s recommendation > of ITK-SNAP for fully manual segmentation. For semi-automated work, I > recommend Ilastik (ilastik.org). > > Juan. > > On 5 Apr 2017, 7:43 PM -0400, Gregory Lee , wrote: > > > I was wondering if anyone on the list knew about software to do 3d >> segmentation. >> >> Thanks >> Vighnesh >> >> > A nice, free GUI-based tool for interactive 3D segmentation is itk-snap > http://www.itksnap.org/ > > _______________________________________________ > 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 rideamus at yahoo.com Wed Apr 5 22:02:54 2017 From: rideamus at yahoo.com (Serge Shakhov) Date: Thu, 6 Apr 2017 02:02:54 +0000 (UTC) Subject: [scikit-image] How to see full image after transformation not the cropped one In-Reply-To: <53560559.10427575.1491345794676@mail.yahoo.com> References: <500002450.8647029.1491172257517.ref@mail.yahoo.com> <500002450.8647029.1491172257517@mail.yahoo.com> <1491234955.3580357.932609936.02982F66@webmail.messagingengine.com> <1302668839.10115410.1491257671866@mail.yahoo.com> <1491289136.469290.933390496.1DCF3869@webmail.messagingengine.com> <1089429596.11304229.1491344934813@mail.yahoo.com> <1491345333.2491491.934355592.15FE86FF@webmail.messagingengine.com> <53560559.10427575.1491345794676@mail.yahoo.com> Message-ID: <461015233.319123.1491444174930@mail.yahoo.com> Hello Stefan, ?Just want to clarify. Am I right that your solution isn't applicable to?PiecewiseAffineTransform at all?Do you think it may be possible to find a workaround?Thanks.?Best regards, Serge Shakhov. On Wednesday, 5 April 2017, 10:46, Serge Shakhov via scikit-image wrote: okay, but I don't need Affine.Does it mean that there is no solution for my problem??Best regards, Serge Shakhov. On Wednesday, 5 April 2017, 10:35, Stefan van der Walt wrote: Hi Serge There is no inverse defined for the piecewise affine, hence the change I made. St?fan On Tue, Apr 4, 2017, at 15:28, Serge Shakhov wrote: Hi Stefan. Noticed that you changed my?PiecewiseAffineTransform?to?AffineTransform. Is it applicable to?PiecewiseAffineTransform?? When I tried to revert it back to?PiecewiseAffineTransform Got error:? Traceback (most recent call last): ? File "C:/Users/Serge/Downloads/warp_to_extents.py", line 45, in ? ? shifted_transform = (affine + offset).inverse ? File "C:\Users\Serge\Software\lib\site-packages\skimage\transform\_geometric.py", line 208, in __add__ ? ? raise NotImplementedError() NotImplementedError Thanks? ? Best regards, Serge Shakhov. On Tuesday, 4 April 2017, 18:58, Stefan van der Walt wrote: Hi Serge Have a look at the attached version. 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 stefanv at berkeley.edu Thu Apr 6 12:57:04 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Thu, 06 Apr 2017 09:57:04 -0700 Subject: [scikit-image] How to see full image after transformation not the cropped one In-Reply-To: <461015233.319123.1491444174930@mail.yahoo.com> References: <500002450.8647029.1491172257517.ref@mail.yahoo.com> <500002450.8647029.1491172257517@mail.yahoo.com> <1491234955.3580357.932609936.02982F66@webmail.messagingengine.com> <1302668839.10115410.1491257671866@mail.yahoo.com> <1491289136.469290.933390496.1DCF3869@webmail.messagingengine.com> <1089429596.11304229.1491344934813@mail.yahoo.com> <1491345333.2491491.934355592.15FE86FF@webmail.messagingengine.com> <53560559.10427575.1491345794676@mail.yahoo.com> <461015233.319123.1491444174930@mail.yahoo.com> Message-ID: <1491497824.2621784.936523896.09B4D093@webmail.messagingengine.com> On Wed, Apr 5, 2017, at 19:02, Serge Shakhov wrote: > Just want to clarify. Am I right that your solution isn't applicable > to PiecewiseAffineTransform at all? > Do you think it may be possible to find a workaround? Sorry, I should have been clearer. With "defined" I meant implemented. To invert a piecewise affine transform, you'll have to use SciPy KD-tree to find the nearest quad coordinates, and then invert the matching affine. This is not necessarily hard, but it's not trivial to implement. St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Thu Apr 6 15:14:25 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Thu, 06 Apr 2017 12:14:25 -0700 Subject: [scikit-image] Tools for 3D segmentation ? In-Reply-To: References: <8c856705-ad4b-4238-8fbf-34a112f1d96d@Spark> Message-ID: <1491506065.2653071.936672632.5F4FE016@webmail.messagingengine.com> If anyone is willing to write an overview of how to do this with screenshots, that'd make a great addition to the website. St?fan On Wed, Apr 5, 2017, at 18:57, Vighnesh Birodkar wrote: > Hey guys > > Sorry for not being clear about this. What I meant is manual labelling > of 3D volumes. I cannot reveal all the details, but it's basically a > foreground Vs background labelling task. > > On 5 Apr 2017 9:52 pm, "Juan Nunez-Iglesias" > wrote: >> Well, almost three years ago we had a GSoC student work on it? =P >> >> Assuming you mean manual 3D segmentation, I second Greg?s >> recommendation of ITK-SNAP for fully manual segmentation. For semi- >> automated work, I recommend Ilastik (ilastik.org). >> >> Juan. >> >> On 5 Apr 2017, 7:43 PM -0400, Gregory Lee , wrote: >> >>> >>>> I was wondering if anyone on the list knew about software to do 3d >>>> segmentation. >>>> >>>> Thanks >>>> Vighnesh >>>> >>> >>> A nice, free GUI-based tool for interactive 3D segmentation is >>> itk-snap >>> http://www.itksnap.org/ >>> >>> _______________________________________________ >>> 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 rideamus at yahoo.com Thu Apr 6 17:42:04 2017 From: rideamus at yahoo.com (Serge Shakhov) Date: Thu, 6 Apr 2017 21:42:04 +0000 (UTC) Subject: [scikit-image] How to see full image after transformation not the cropped one In-Reply-To: <1491497824.2621784.936523896.09B4D093@webmail.messagingengine.com> References: <500002450.8647029.1491172257517.ref@mail.yahoo.com> <500002450.8647029.1491172257517@mail.yahoo.com> <1491234955.3580357.932609936.02982F66@webmail.messagingengine.com> <1302668839.10115410.1491257671866@mail.yahoo.com> <1491289136.469290.933390496.1DCF3869@webmail.messagingengine.com> <1089429596.11304229.1491344934813@mail.yahoo.com> <1491345333.2491491.934355592.15FE86FF@webmail.messagingengine.com> <53560559.10427575.1491345794676@mail.yahoo.com> <461015233.319123.1491444174930@mail.yahoo.com> <1491497824.2621784.936523896.09B4D093@webmail.messagingengine.com> Message-ID: <958886490.1819122.1491514924752@mail.yahoo.com> >>To invert a piecewise affine transform, you'll have to use SciPy KD-tree to find the nearest quad coordinates, and then invert the matching affine. ?This is not necessarily hard, but it's not trivial to implement. ?Definitely too hard for a beginner :-)?Probably I should just increase image canvas size to have empty area cropped and the picture to remain full.?Thanks. Best regards, Serge Shakhov. On Friday, 7 April 2017, 4:57, Stefan van der Walt wrote: On Wed, Apr 5, 2017, at 19:02, Serge Shakhov wrote: ?Just want to clarify. Am I right that your solution isn't applicable to?PiecewiseAffineTransform at all? Do you think it may be possible to find a workaround? Sorry, I should have been clearer. ?With "defined" I meant implemented. To invert a piecewise affine transform, you'll have to use SciPy KD-tree to find the nearest quad coordinates, and then invert the matching affine. ?This is not necessarily hard, but it's not trivial to implement. St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Thu Apr 6 18:50:42 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Thu, 06 Apr 2017 15:50:42 -0700 Subject: [scikit-image] How to see full image after transformation not the cropped one In-Reply-To: <1491497824.2621784.936523896.09B4D093@webmail.messagingengine.com> References: <500002450.8647029.1491172257517.ref@mail.yahoo.com> <500002450.8647029.1491172257517@mail.yahoo.com> <1491234955.3580357.932609936.02982F66@webmail.messagingengine.com> <1302668839.10115410.1491257671866@mail.yahoo.com> <1491289136.469290.933390496.1DCF3869@webmail.messagingengine.com> <1089429596.11304229.1491344934813@mail.yahoo.com> <1491345333.2491491.934355592.15FE86FF@webmail.messagingengine.com> <53560559.10427575.1491345794676@mail.yahoo.com> <461015233.319123.1491444174930@mail.yahoo.com> <1491497824.2621784.936523896.09B4D093@webmail.messagingengine.com> Message-ID: <1491519042.845824.936874320.3345C7C7@webmail.messagingengine.com> On Thu, Apr 6, 2017, at 09:57, Stefan van der Walt wrote: > On Wed, Apr 5, 2017, at 19:02, Serge Shakhov wrote: >> Just want to clarify. Am I right that your solution isn't applicable >> to PiecewiseAffineTransform at all? >> Do you think it may be possible to find a workaround? > > Sorry, I should have been clearer. With "defined" I meant > implemented. Upon closer inspection, it turns out that the PiecewiseAffineTransform *does* have an inverse implemented. It was the "+" operator causing the problem. Still, I have found cases now where I get invalid answers for valid- seeming sets of coordinates. I'm investigating further, but I think I have a solution to your problem. St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Thu Apr 6 19:02:25 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Thu, 06 Apr 2017 16:02:25 -0700 Subject: [scikit-image] How to see full image after transformation not the cropped one In-Reply-To: <1491519042.845824.936874320.3345C7C7@webmail.messagingengine.com> References: <500002450.8647029.1491172257517.ref@mail.yahoo.com> <500002450.8647029.1491172257517@mail.yahoo.com> <1491234955.3580357.932609936.02982F66@webmail.messagingengine.com> <1302668839.10115410.1491257671866@mail.yahoo.com> <1491289136.469290.933390496.1DCF3869@webmail.messagingengine.com> <1089429596.11304229.1491344934813@mail.yahoo.com> <1491345333.2491491.934355592.15FE86FF@webmail.messagingengine.com> <53560559.10427575.1491345794676@mail.yahoo.com> <461015233.319123.1491444174930@mail.yahoo.com> <1491497824.2621784.936523896.09B4D093@webmail.messagingengine.com> <1491519042.845824.936874320.3345C7C7@webmail.messagingengine.com> Message-ID: <1491519745.848327.936880320.3CCA5484@webmail.messagingengine.com> Hi Serge Hhere you go (attached). Notes: - The transform is very sensitive *outside of any coordinates specified in the source coordinates*, so make sure it covers your whole image - The process I follow here is as follows: estimate the transform, calculate where the corners of the image will go, then estimate a new transform that includes a shift that positions the result on a new, larger output image - Estimate `affine` (forward) and warp on `affine.inverse` (because warp expects an inverse transformation to be provided) I hope that helps! St?fan On Thu, Apr 6, 2017, at 15:50, Stefan van der Walt wrote: > On Thu, Apr 6, 2017, at 09:57, Stefan van der Walt wrote: >> On Wed, Apr 5, 2017, at 19:02, Serge Shakhov wrote: >>> Just want to clarify. Am I right that your solution isn't >>> applicable to PiecewiseAffineTransform at all? >>> Do you think it may be possible to find a workaround? >> >> Sorry, I should have been clearer. With "defined" I meant >> implemented. > > Upon closer inspection, it turns out that the PiecewiseAffineTransform > *does* have an inverse implemented. It was the "+" operator causing > the problem. > > Still, I have found cases now where I get invalid answers for valid- > seeming sets of coordinates. I'm investigating further, but I think I > have a solution to your problem. > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: warp_to_extents.py Type: text/x-python-script Size: 1708 bytes Desc: not available URL: From stefanv at berkeley.edu Thu Apr 6 20:32:29 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Thu, 06 Apr 2017 17:32:29 -0700 Subject: [scikit-image] How to move pull requests forward (devs, please read) Message-ID: <1491525149.1891706.936906712.3C8FA86A@webmail.messagingengine.com> Hi everyone, and especially devs This afternoon, Nelle Varoquaux gave a short presentation at BIDS on optimistic merging, a workflow suggested by the late Pieter Hintjens. In optimistic merging, all PRs are merged into a project, and fixes happen via additional patches or reverts. While, in my mind, this is not a viable model for scikit-image, it made me think of our PR review process. A failure mode I observe often is the following: - user submits patch - review happens, often either a) nitpicking on minor things or b) asking for technically difficult tasks to be performed (rebasing, can be tricky) This introduces several problems, including discouraging new contributors, and wasting a lot of time (many PRs are left hanging for months, while waiting for a one-line fix from the original author). I'd like to request the following: - Ask contributors to open their branches for collaboration (this is on by default already, probably). - While reviewing a PR, pull down the branch, look at the diff, and fix any trivial errors you see. Push the results back up or, if collaboration is switched off, make a PR against theirs. - Keep review comments to bigger picture changes, and avoid getting bogged down in trivial fixes and stylistic changes. Let's keep it collaborative and friendly, grow our team of contributors, and get going on 0.14 :) Thanks! St?fan P.S. A question for the git experts: I've been looking for ways of making the above process easier. I found that I can easily download pull requests: - In my ~/.gitconfig, I add the following alias (replace 'upstream' with whatever you normally call the scikit-image main repository): [alias] pullpr = "!f() { git fetch upstream pull/$1/head:pr$1 ;}; f" I can now grab a PR with: git pullpr 2447 and it will appear in the branch pr2447. Unfortunately, I don't have a similarly easy way of pushing back, other than adding the contributor's remote, and pushing back to the PR branch. Any ideas? From jni.soma at gmail.com Fri Apr 7 03:16:08 2017 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Fri, 7 Apr 2017 17:16:08 +1000 Subject: [scikit-image] Help with making moments nD Message-ID: <334b7705-39c5-41ea-b920-a27cedb8e374@Spark> Hi everyone, I?ve started work on getting image moments working in nD. I have two working alternative implementations: one with NumPy broadcasting and one with Numba JIT. Both are consistent with each other and with the existing Cython implementation, with to caveats: 1- my results are the *transpose* of the reference results. I suspected this might be because the reference uses x/y coordinates but that doesn?t seem to be the case. (see code below). 2- each of my implementations is ~10x slower than the Cython implementation. Of these, problem 1 is the most pressing. (Problem 2 can be solved by special-casing 2D.) Can someone familiar with moments compare my implementations and the reference and tell me where I might have gone wrong? I?ve included all the code below for reference. Ideas about speedups are also welcome! To that end, I?ve marked the slow lines in the broadcasting code. (I don?t know how to line profile in Numba; I think it?s currently impossible, in fact.) Juan. ????????? Reference results ???????????? Values (Notice the .T for `moments_central`, which is the existing Cython implementation) In [189]: m.moments_central_nb(horse.astype(float), central_coords, 3) Out[189]: array([[ ?8.779e+04, ?-1.621e-07, ? 1.301e+09, ?-6.370e+09], ? ? ? ?[ -8.245e-07, ? 9.275e+07, ?-3.430e+09, ? 1.938e+12], ? ? ? ?[ ?9.873e+08, ?-1.363e+10, ? 1.349e+13, ?-3.604e+14], ? ? ? ?[ -2.218e+10, ? 1.552e+12, ?-2.849e+14, ? 3.245e+16]]) In [190]: moments_central(horse.astype(float), *central_coords, 3).T Out[190]: array([[ ?8.779e+04, ?-1.621e-07, ? 1.301e+09, ?-6.370e+09], ? ? ? ?[ -8.245e-07, ? 9.275e+07, ?-3.430e+09, ? 1.938e+12], ? ? ? ?[ ?9.873e+08, ?-1.363e+10, ? 1.349e+13, ?-3.604e+14], ? ? ? ?[ -2.218e+10, ? 1.552e+12, ?-2.849e+14, ? 3.245e+16]]) In [191]: m.moments_central(horse.astype(float), central_coords, 3) Out[191]: array([[ ?8.779e+04, ?-1.037e-09, ? 1.301e+09, ?-6.370e+09], ? ? ? ?[ -1.979e-09, ? 9.275e+07, ?-3.430e+09, ? 1.938e+12], ? ? ? ?[ ?9.873e+08, ?-1.363e+10, ? 1.349e+13, ?-3.604e+14], ? ? ? ?[ -2.218e+10, ? 1.552e+12, ?-2.849e+14, ? 3.245e+16]]) ???????????? Timings In [185]: %timeit moments_central(horse.astype(float), *central_coords, 3) 100 loops, best of 3: 3.14 ms per loop In [187]: %timeit m.moments_central_nb(horse.astype(float), central_coords, 3) 10 loops, best of 3: 35.7 ms per loop In [188]: %timeit m.moments_central(horse.astype(float), central_coords, 3) 10 loops, best of 3: 39.4 ms per loop ????????? Implementations ???????????? Existing Cython cpdef moments_central(image_t image, double cr, double cc, Py_ssize_t order): ? ? cdef Py_ssize_t p, q, r, c ? ? cdef double[:, ::1] mu = np.zeros((order + 1, order + 1), dtype=np.double) ? ? cdef double val, dr, dc, dcp, drq ? ? for r in range(image.shape[0]): ? ? ? ? dr = r - cr ? ? ? ? for c in range(image.shape[1]): ? ? ? ? ? ? dc = c - cc ? ? ? ? ? ? val = image[r, c] ? ? ? ? ? ? dcp = 1 ? ? ? ? ? ? for p in range(order + 1): ? ? ? ? ? ? ? ? drq = 1 ? ? ? ? ? ? ? ? for q in range(order + 1): ? ? ? ? ? ? ? ? ? ? mu[p, q] += val * drq * dcp ? ? ? ? ? ? ? ? ? ? drq *= dr ? ? ? ? ? ? ? ? dcp *= dc ? ? return np.asarray(mu) ???????????? Broadcasting import numpy as np import numba from functools import reduce def moments_central(image, center=None, order=3): ? ? coords = np.nonzero(image) ? ? values = image[coords] ? ? coords_stack = np.column_stack(np.nonzero(image)) ? ? if center is None: ? ? ? ? center = np.mean(coords_stack, axis=0) ? ? ccoords = coords_stack - center ? ? powers = np.arange(order + 1) ? ? result_shape = (order + 1,) * image.ndim + (coords_stack.shape[0],) ? ? coords_pow = [] ? ? for dim in range(image.ndim): ? ? ? ? power_shape = [1,] * (image.ndim + 1) ? ? ? ? power_shape[dim] = order + 1 ? ? ? ? powers = np.reshape(powers, power_shape) ? ? ? ? ccoords_pow = ccoords[:, dim] ** powers ?# SLOW, 50% of time ? ? ? ? bcast_coords_pow = np.broadcast_to(ccoords_pow, result_shape) ? ? ? ? coords_pow.append(bcast_coords_pow) ? ? result = np.sum(reduce(np.multiply, coords_pow + [values]), axis=-1) ?# SLOW, 30% of time ? ? return result ???????????? Numba def moments_central_nb(image, center=None, order=3): ? ? mu = np.zeros((order + 1,) * image.ndim) ? ? if center is None: ? ? ? ? center = np.mean(np.column_stack(np.nonzero(image)), axis=0) ? ? _moments_central_nb_loop(image, center, mu) ? ? return mu @numba.njit def _moments_central_nb_loop(image, center, mu): ? ? for coord, val in np.ndenumerate(image): ? ? ? ? if val > 0: ? ? ? ? ? ? for powers in np.ndindex(mu.shape): ? ? ? ? ? ? ? ? curval = val ? ? ? ? ? ? ? ? for c, ctr, p in zip(coord, center, powers): ? ? ? ? ? ? ? ? ? ? dc = c - ctr ? ? ? ? ? ? ? ? ? ? cr = 1 ? ? ? ? ? ? ? ? ? ? for pcount in range(p): ? ? ? ? ? ? ? ? ? ? ? ? cr *= dc ? ? ? ? ? ? ? ? ? ? curval *= cr ? ? ? ? ? ? ? ? mu[powers] += curval -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaime.frio at gmail.com Fri Apr 7 07:22:22 2017 From: jaime.frio at gmail.com (=?UTF-8?Q?Jaime_Fern=C3=A1ndez_del_R=C3=ADo?=) Date: Fri, 7 Apr 2017 13:22:22 +0200 Subject: [scikit-image] Help with making moments nD In-Reply-To: <334b7705-39c5-41ea-b920-a27cedb8e374@Spark> References: <334b7705-39c5-41ea-b920-a27cedb8e374@Spark> Message-ID: Hi Juan, The transposition is almost certainly due to the fact that in the Cython implementation the p loop, which loops rows of the moments array, uses the dc multiplier, which comes from the image columns, while the q loop, which loops columns of the moments array, uses the dr multiplier, which comes from the image rows. Your other code chooses the multiplier corresponding to the same axes in both the image and the moments arrays. It is not obvious to me how to extend the current behavior to higher dimensions. As for your implementation, using np.nonzero is probably not going to pay off unless your image is very sparse, because you basically go from having to handle a single value per image pixel, to add an extra coordinate value for each dimension. And you don't really need to compute an offset for each pixel, since many pixels share the offsets along some dimensions, e.g. for a 100 x 100 x 100 3D image, this code is 2-3x faster: import itertools def moments_central(image, center=None, order=3): image = np.asarray(image) if center is None: center = np.array(image.shape, dtype=float) / 2 center = np.asarray(center) assert center.ndim == 1 and center.size == image.ndim # deltas is a list of arrays holding the deltas from the center along each # dimension of the image. deltas = [np.arange(image.shape[dim], dtype=float) - center[dim] for dim in range(image.ndim)] # Reshape each delta so that it can properly broadcast against image. deltas = [delta.reshape((1,) * dim + (-1,) + (1,) * (image.ndim - dim - 1)) for dim, delta in enumerate(deltas)] moments = np.empty((order + 1,) * image.ndim, dtype=float) reusable_buffer = np.empty_like(image, dtype=float) for powers in itertools.product(range(order + 1), repeat=image.ndim): reusable_buffer[:] = image for power, delta in zip(powers, deltas): reusable_buffer *= delta ** power moments[tuple(powers)] = reusable_buffer.sum() return moments Notice that this just iterates over the moments items. Broadcasting in this type of problems is dangerous, because you basically replace an N item loop with creating an arrays N times larger than your original data. And Python loops are slow, but not THAT slow. You can actually make the above idea run even faster, almost 2x, by reducing the dimensionality of your result as soon as possible earlier: import itertools def moments_central_faster(image, center=None, order=3): image = np.asarray(image) if center is None: center = np.array(image.shape, dtype=float) / 2 center = np.asarray(center) assert center.ndim == 1 and center.size == image.ndim # deltas is a list of arrays holding the deltas from the center along each # dimension of the image. deltas = [np.arange(image.shape[dim], dtype=float) - center[dim] for dim in range(image.ndim)] # Reshape each delta so that it can properly broadcast against image. deltas = [delta.reshape((1,) * dim + (-1,) + (1,) * (image.ndim - dim - 1)) for dim, delta in enumerate(deltas)] moments = np.empty((order + 1,) * image.ndim, dtype=float) for powers in itertools.product(range(order + 1), repeat=image.ndim): calc = image.copy() for dim, (power, delta) in enumerate(zip(powers, deltas)): calc *= delta ** power calc = np.add.reduce(calc, axis=dim, keepdims=True) moments[tuple(powers)] = calc.sum() return moments This idea of reducing dimensionality can be given a twist in the form of stacked matrix multiplication: one can think of the whole calculation as reducing each dimension of size D to O, where O is the order plus one, by multiplying by a DXO matrix, holding the powers of the deltas along that dimension. In code it could look something like this: def moments_central_even_faster(image, center=None, order=3): image = np.asarray(image) if center is None: center = np.array(image.shape, dtype=float) / 2 center = np.asarray(center) assert center.ndim == 1 and center.size == image.ndim # deltas is a list of arrays holding the deltas from the center along each # dimension of the image. deltas = [np.arange(image.shape[dim], dtype=float) - center[dim] for dim in range(image.ndim)] calc = image for dim, delta in enumerate(deltas): powers_of_delta = delta[:, None] ** np.arange(order + 1) calc = np.rollaxis(calc, dim, image.ndim) calc = np.dot(calc, powers_of_delta) calc = np.rollaxis(calc, -1, dim) return calc This turns out to be ridiculously fast for the 100 x 100 x 100 image case (1.41 s vs 520 ms vs 258 ms vs 10.5 ms), so over 100x (!!!) faster than your implementation. On a 1000 x 1000 2D image it's fast, but not the fastest (571 ms vs 122 ms vs 92.8 ms vs 113 ms), but the fastest version is probably in the same ballpark as the current Cython implementation. Let me know how do your timings compare. Jaime On Fri, Apr 7, 2017 at 9:16 AM, Juan Nunez-Iglesias wrote: > Hi everyone, > > I?ve started work on getting image moments working in nD. I have two > working alternative implementations: one with NumPy broadcasting and one > with Numba JIT. Both are consistent with each other and with the existing > Cython implementation, with to caveats: > > 1- my results are the *transpose* of the reference results. I suspected > this might be because the reference uses x/y coordinates but that doesn?t > seem to be the case. (see code below). > > 2- each of my implementations is ~10x slower than the Cython > implementation. > > Of these, problem 1 is the most pressing. (Problem 2 can be solved by > special-casing 2D.) Can someone familiar with moments compare my > implementations and the reference and tell me where I might have gone > wrong? I?ve included all the code below for reference. > > Ideas about speedups are also welcome! To that end, I?ve marked the slow > lines in the broadcasting code. (I don?t know how to line profile in Numba; > I think it?s currently impossible, in fact.) > > Juan. > > *????????? Reference results* > > ???????????? Values > > (Notice the .T for `moments_central`, which is the existing Cython > implementation) > > In [189]: m.moments_central_nb(horse.astype(float), central_coords, 3) > Out[189]: > array([[ 8.779e+04, -1.621e-07, 1.301e+09, -6.370e+09], > [ -8.245e-07, 9.275e+07, -3.430e+09, 1.938e+12], > [ 9.873e+08, -1.363e+10, 1.349e+13, -3.604e+14], > [ -2.218e+10, 1.552e+12, -2.849e+14, 3.245e+16]]) > > In [190]: moments_central(horse.astype(float), *central_coords, 3).T > Out[190]: > array([[ 8.779e+04, -1.621e-07, 1.301e+09, -6.370e+09], > [ -8.245e-07, 9.275e+07, -3.430e+09, 1.938e+12], > [ 9.873e+08, -1.363e+10, 1.349e+13, -3.604e+14], > [ -2.218e+10, 1.552e+12, -2.849e+14, 3.245e+16]]) > > In [191]: m.moments_central(horse.astype(float), central_coords, 3) > Out[191]: > array([[ 8.779e+04, -1.037e-09, 1.301e+09, -6.370e+09], > [ -1.979e-09, 9.275e+07, -3.430e+09, 1.938e+12], > [ 9.873e+08, -1.363e+10, 1.349e+13, -3.604e+14], > [ -2.218e+10, 1.552e+12, -2.849e+14, 3.245e+16]]) > > ???????????? Timings > > In [185]: %timeit moments_central(horse.astype(float), *central_coords, 3) > 100 loops, best of 3: 3.14 ms per loop > > In [187]: %timeit m.moments_central_nb(horse.astype(float), > central_coords, 3) > 10 loops, best of 3: 35.7 ms per loop > > In [188]: %timeit m.moments_central(horse.astype(float), central_coords, > 3) > 10 loops, best of 3: 39.4 ms per loop > > *????????? Implementations* > > ???????????? Existing Cython > cpdef moments_central(image_t image, double cr, double cc, Py_ssize_t > order): > cdef Py_ssize_t p, q, r, c > cdef double[:, ::1] mu = np.zeros((order + 1, order + 1), > dtype=np.double) > cdef double val, dr, dc, dcp, drq > for r in range(image.shape[0]): > dr = r - cr > for c in range(image.shape[1]): > dc = c - cc > val = image[r, c] > dcp = 1 > for p in range(order + 1): > drq = 1 > for q in range(order + 1): > mu[p, q] += val * drq * dcp > drq *= dr > dcp *= dc > return np.asarray(mu) > > ???????????? Broadcasting > import numpy as np > import numba > from functools import reduce > > def moments_central(image, center=None, order=3): > coords = np.nonzero(image) > values = image[coords] > coords_stack = np.column_stack(np.nonzero(image)) > if center is None: > center = np.mean(coords_stack, axis=0) > ccoords = coords_stack - center > powers = np.arange(order + 1) > result_shape = (order + 1,) * image.ndim + (coords_stack.shape[0],) > coords_pow = [] > for dim in range(image.ndim): > power_shape = [1,] * (image.ndim + 1) > power_shape[dim] = order + 1 > powers = np.reshape(powers, power_shape) > ccoords_pow = ccoords[:, dim] ** powers # SLOW, 50% of time > bcast_coords_pow = np.broadcast_to(ccoords_pow, result_shape) > coords_pow.append(bcast_coords_pow) > result = np.sum(reduce(np.multiply, coords_pow + [values]), axis=-1) > # SLOW, 30% of time > return result > > ???????????? Numba > def moments_central_nb(image, center=None, order=3): > mu = np.zeros((order + 1,) * image.ndim) > if center is None: > center = np.mean(np.column_stack(np.nonzero(image)), axis=0) > _moments_central_nb_loop(image, center, mu) > return mu > > > @numba.njit > def _moments_central_nb_loop(image, center, mu): > for coord, val in np.ndenumerate(image): > if val > 0: > for powers in np.ndindex(mu.shape): > curval = val > for c, ctr, p in zip(coord, center, powers): > dc = c - ctr > cr = 1 > for pcount in range(p): > cr *= dc > curval *= cr > mu[powers] += curval > > > > > _______________________________________________ > scikit-image mailing list > scikit-image at python.org > https://mail.python.org/mailman/listinfo/scikit-image > > -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ay?dale en sus planes de dominaci?n mundial. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jni.soma at gmail.com Fri Apr 7 23:54:01 2017 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Sat, 8 Apr 2017 13:54:01 +1000 Subject: [scikit-image] Help with making moments nD In-Reply-To: References: <334b7705-39c5-41ea-b920-a27cedb8e374@Spark> Message-ID: <7a5e2920-dd9e-4701-97d8-b119842e0005@Spark> Hi Jaime, Thanks for an outrageously thorough response! Firstly, I totally missed that the dc and dr multipliers were in a different order! Looks like we will have to do some deprecation! Second, my own timings match yours, even for the 2D horse image. I?ve renamed my function moments_central_np0 and yours _np[1-3]. Plain moments_central is the skimage implementation. In [216]: %timeit moments_central(horse, *central_coords, 3) 100 loops, best of 3: 3.11 ms per loop In [217]: %timeit m.moments_central_np0(horse, central_coords, 3) 10 loops, best of 3: 39.2 ms per loop In [218]: %timeit m.moments_central_np1(horse, central_coords, 3) 100 loops, best of 3: 6.49 ms per loop In [219]: %timeit m.moments_central_np2(horse, central_coords, 3) 100 loops, best of 3: 5.28 ms per loop In [220]: %timeit m.moments_central_np3(horse, central_coords, 3) The slowest run took 5.99 times longer than the fastest. This could mean that an intermediate result is being cached. 1000 loops, best of 3: 375 ?s per loop In [221]: %timeit m.moments_central_np3(horse, central_coords, 3) 1000 loops, best of 3: 396 ?s per loop The only thing I?m concerned about is that ?intermediate result being cached?. Any idea why that could be? It only seems to happen with the third implementation?! Either way, even the slowest time is faster than the other functions! Anyway, thanks so much for your help! Juan. On 7 Apr 2017, 9:22 PM +1000, Jaime Fern?ndez del R?o , wrote: > Hi Juan, > > The transposition is almost certainly due to the fact that in the Cython implementation the p loop, which loops rows of the moments array, uses the dc multiplier, which comes from the image columns, while the q loop, which loops columns of the moments array, uses the dr multiplier, which comes from the image rows. Your other code chooses the multiplier corresponding to the same axes in both the image and the moments arrays. It is not obvious to me how to extend the current behavior to higher dimensions. > > As for your implementation, using np.nonzero is probably not going to pay off unless your image is very sparse, because you basically go from having to handle a single value per image pixel, to add an extra coordinate value for each dimension. And you don't really need to compute an offset for each pixel, since many pixels share the offsets along some dimensions, e.g. for a 100 x 100 x 100 3D image, this code is 2-3x faster: > > import itertools > > def moments_central(image, center=None, order=3): > ? image = np.asarray(image) > ? if center is None: > ? ? center = np.array(image.shape, dtype=float) / 2 > ? center = np.asarray(center) > ? assert center.ndim == 1 and center.size == image.ndim > ? # deltas is a list of arrays holding the deltas from the center along each > ? # dimension of the image. > ? deltas = [np.arange(image.shape[dim], dtype=float) - center[dim] > ? ? ? ? ? ? for dim in range(image.ndim)] > ? # Reshape each delta so that it can properly broadcast against image. > ? deltas = [delta.reshape((1,) * dim + (-1,) + (1,) * (image.ndim - dim - 1)) > ? ? ? ? ? ? for dim, delta in enumerate(deltas)] > ? moments = np.empty((order + 1,) * image.ndim, dtype=float) > ? reusable_buffer = np.empty_like(image, dtype=float) > ? for powers in itertools.product(range(order + 1), repeat=image.ndim): > ? ? reusable_buffer[:] = image > ? ? for power, delta in zip(powers, deltas): > ? ? ? reusable_buffer *= delta ** power > ? ? moments[tuple(powers)] = reusable_buffer.sum() > > ? return moments > > Notice that this just iterates over the moments items. Broadcasting in this type of problems is dangerous, because you basically replace an N item loop with creating an arrays N times larger than your original data. And Python loops are slow, but not THAT slow. You can actually make the above idea run even faster, almost 2x, by reducing the dimensionality of your result as soon as possible earlier: > > import itertools > > def moments_central_faster(image, center=None, order=3): > ? image = np.asarray(image) > ? if center is None: > ? ? center = np.array(image.shape, dtype=float) / 2 > ? center = np.asarray(center) > ? assert center.ndim == 1 and center.size == image.ndim > ? # deltas is a list of arrays holding the deltas from the center along each > ? # dimension of the image. > ? deltas = [np.arange(image.shape[dim], dtype=float) - center[dim] > ? ? ? ? ? ? for dim in range(image.ndim)] > ? # Reshape each delta so that it can properly broadcast against image. > ? deltas = [delta.reshape((1,) * dim + (-1,) + (1,) * (image.ndim - dim - 1)) > ? ? ? ? ? ? for dim, delta in enumerate(deltas)] > ? moments = np.empty((order + 1,) * image.ndim, dtype=float) > ? for powers in itertools.product(range(order + 1), repeat=image.ndim): > ? ? calc = image.copy() > ? ? for dim, (power, delta) in enumerate(zip(powers, deltas)): > ? ? ? calc *= delta ** power > ? ? ? calc = np.add.reduce(calc, axis=dim, keepdims=True) > ? ? moments[tuple(powers)] = calc.sum() > > ? return moments > > This idea of reducing dimensionality can be given a twist in the form of stacked matrix multiplication: one can think of the whole calculation as reducing each dimension of size D to O, where O is the order plus one, by multiplying by a DXO matrix, holding the powers of the deltas along that dimension. In code it could look something like this: > > def moments_central_even_faster(image, center=None, order=3): > ? image = np.asarray(image) > ? if center is None: > ? ? center = np.array(image.shape, dtype=float) / 2 > ? center = np.asarray(center) > ? assert center.ndim == 1 and center.size == image.ndim > ? # deltas is a list of arrays holding the deltas from the center along each > ? # dimension of the image. > ? deltas = [np.arange(image.shape[dim], dtype=float) - center[dim] > ? ? ? ? ? ? for dim in range(image.ndim)] > ? calc = image > ? for dim, delta in enumerate(deltas): > ? ? powers_of_delta = delta[:, None] ** np.arange(order + 1) > ? ? calc = np.rollaxis(calc, dim, image.ndim) > ? ? calc = np.dot(calc, powers_of_delta) > ? ? calc = np.rollaxis(calc, -1, dim) > > ? return calc > > This turns out to be ridiculously fast for the 100 x 100 x 100 image case (1.41 s vs 520 ms vs 258 ms vs 10.5 ms), so over 100x (!!!) faster than your implementation. > > On a 1000 x 1000 2D image it's fast, but not the fastest (571 ms vs 122 ms vs 92.8 ms vs 113 ms), but the fastest version is probably in the same ballpark as the current Cython implementation. > > Let me know how do your timings compare. > > Jaime > > > > > On Fri, Apr 7, 2017 at 9:16 AM, Juan Nunez-Iglesias wrote: > > > Hi everyone, > > > > > > I?ve started work on getting image moments working in nD. I have two working alternative implementations: one with NumPy broadcasting and one with Numba JIT. Both are consistent with each other and with the existing Cython implementation, with to caveats: > > > > > > 1- my results are the *transpose* of the reference results. I suspected this might be because the reference uses x/y coordinates but that doesn?t seem to be the case. (see code below). > > > > > > 2- each of my implementations is ~10x slower than the Cython implementation. > > > > > > Of these, problem 1 is the most pressing. (Problem 2 can be solved by special-casing 2D.) Can someone familiar with moments compare my implementations and the reference and tell me where I might have gone wrong? I?ve included all the code below for reference. > > > > > > Ideas about speedups are also welcome! To that end, I?ve marked the slow lines in the broadcasting code. (I don?t know how to line profile in Numba; I think it?s currently impossible, in fact.) > > > > > > Juan. > > > > > > ????????? Reference results > > > > > > ???????????? Values > > > > > > (Notice the .T for `moments_central`, which is the existing Cython implementation) > > > > > > In [189]: m.moments_central_nb(horse.astype(float), central_coords, 3) > > > Out[189]: > > > array([[ ?8.779e+04, ?-1.621e-07, ? 1.301e+09, ?-6.370e+09], > > > ? ? ? ?[ -8.245e-07, ? 9.275e+07, ?-3.430e+09, ? 1.938e+12], > > > ? ? ? ?[ ?9.873e+08, ?-1.363e+10, ? 1.349e+13, ?-3.604e+14], > > > ? ? ? ?[ -2.218e+10, ? 1.552e+12, ?-2.849e+14, ? 3.245e+16]]) > > > > > > In [190]: moments_central(horse.astype(float), *central_coords, 3).T > > > Out[190]: > > > array([[ ?8.779e+04, ?-1.621e-07, ? 1.301e+09, ?-6.370e+09], > > > ? ? ? ?[ -8.245e-07, ? 9.275e+07, ?-3.430e+09, ? 1.938e+12], > > > ? ? ? ?[ ?9.873e+08, ?-1.363e+10, ? 1.349e+13, ?-3.604e+14], > > > ? ? ? ?[ -2.218e+10, ? 1.552e+12, ?-2.849e+14, ? 3.245e+16]]) > > > > > > In [191]: m.moments_central(horse.astype(float), central_coords, 3) > > > Out[191]: > > > array([[ ?8.779e+04, ?-1.037e-09, ? 1.301e+09, ?-6.370e+09], > > > ? ? ? ?[ -1.979e-09, ? 9.275e+07, ?-3.430e+09, ? 1.938e+12], > > > ? ? ? ?[ ?9.873e+08, ?-1.363e+10, ? 1.349e+13, ?-3.604e+14], > > > ? ? ? ?[ -2.218e+10, ? 1.552e+12, ?-2.849e+14, ? 3.245e+16]]) > > > > > > ???????????? Timings > > > > > > In [185]: %timeit moments_central(horse.astype(float), *central_coords, 3) > > > 100 loops, best of 3: 3.14 ms per loop > > > > > > In [187]: %timeit m.moments_central_nb(horse.astype(float), central_coords, 3) > > > 10 loops, best of 3: 35.7 ms per loop > > > > > > In [188]: %timeit m.moments_central(horse.astype(float), central_coords, 3) > > > 10 loops, best of 3: 39.4 ms per loop > > > > > > ????????? Implementations > > > > > > ???????????? Existing Cython > > > cpdef moments_central(image_t image, double cr, double cc, Py_ssize_t order): > > > ? ? cdef Py_ssize_t p, q, r, c > > > ? ? cdef double[:, ::1] mu = np.zeros((order + 1, order + 1), dtype=np.double) > > > ? ? cdef double val, dr, dc, dcp, drq > > > ? ? for r in range(image.shape[0]): > > > ? ? ? ? dr = r - cr > > > ? ? ? ? for c in range(image.shape[1]): > > > ? ? ? ? ? ? dc = c - cc > > > ? ? ? ? ? ? val = image[r, c] > > > ? ? ? ? ? ? dcp = 1 > > > ? ? ? ? ? ? for p in range(order + 1): > > > ? ? ? ? ? ? ? ? drq = 1 > > > ? ? ? ? ? ? ? ? for q in range(order + 1): > > > ? ? ? ? ? ? ? ? ? ? mu[p, q] += val * drq * dcp > > > ? ? ? ? ? ? ? ? ? ? drq *= dr > > > ? ? ? ? ? ? ? ? dcp *= dc > > > ? ? return np.asarray(mu) > > > > > > ???????????? Broadcasting > > > import numpy as np > > > import numba > > > from functools import reduce > > > > > > def moments_central(image, center=None, order=3): > > > ? ? coords = np.nonzero(image) > > > ? ? values = image[coords] > > > ? ? coords_stack = np.column_stack(np.nonzero(image)) > > > ? ? if center is None: > > > ? ? ? ? center = np.mean(coords_stack, axis=0) > > > ? ? ccoords = coords_stack - center > > > ? ? powers = np.arange(order + 1) > > > ? ? result_shape = (order + 1,) * image.ndim + (coords_stack.shape[0],) > > > ? ? coords_pow = [] > > > ? ? for dim in range(image.ndim): > > > ? ? ? ? power_shape = [1,] * (image.ndim + 1) > > > ? ? ? ? power_shape[dim] = order + 1 > > > ? ? ? ? powers = np.reshape(powers, power_shape) > > > ? ? ? ? ccoords_pow = ccoords[:, dim] ** powers ?# SLOW, 50% of time > > > ? ? ? ? bcast_coords_pow = np.broadcast_to(ccoords_pow, result_shape) > > > ? ? ? ? coords_pow.append(bcast_coords_pow) > > > ? ? result = np.sum(reduce(np.multiply, coords_pow + [values]), axis=-1) ?# SLOW, 30% of time > > > ? ? return result > > > > > > ???????????? Numba > > > def moments_central_nb(image, center=None, order=3): > > > ? ? mu = np.zeros((order + 1,) * image.ndim) > > > ? ? if center is None: > > > ? ? ? ? center = np.mean(np.column_stack(np.nonzero(image)), axis=0) > > > ? ? _moments_central_nb_loop(image, center, mu) > > > ? ? return mu > > > > > > > > > @numba.njit > > > def _moments_central_nb_loop(image, center, mu): > > > ? ? for coord, val in np.ndenumerate(image): > > > ? ? ? ? if val > 0: > > > ? ? ? ? ? ? for powers in np.ndindex(mu.shape): > > > ? ? ? ? ? ? ? ? curval = val > > > ? ? ? ? ? ? ? ? for c, ctr, p in zip(coord, center, powers): > > > ? ? ? ? ? ? ? ? ? ? dc = c - ctr > > > ? ? ? ? ? ? ? ? ? ? cr = 1 > > > ? ? ? ? ? ? ? ? ? ? for pcount in range(p): > > > ? ? ? ? ? ? ? ? ? ? ? ? cr *= dc > > > ? ? ? ? ? ? ? ? ? ? curval *= cr > > > ? ? ? ? ? ? ? ? mu[powers] += curval > > > > > > > > > > > > > > > _______________________________________________ > > > scikit-image mailing list > > > scikit-image at python.org > > > https://mail.python.org/mailman/listinfo/scikit-image > > > > > > > -- > (\__/) > ( O.o) > ( > <) Este es Conejo. Copia a Conejo en tu firma y ay?dale en sus planes de dominaci?n mundial. -------------- next part -------------- An HTML attachment was scrubbed... URL: From suryak at udel.edu Mon Apr 10 18:48:40 2017 From: suryak at udel.edu (Surya Kasturi) Date: Mon, 10 Apr 2017 18:48:40 -0400 Subject: [scikit-image] Non-rigid shape matching Message-ID: <01070AB1-2A73-4808-97B9-1149F7FB677E@udel.edu> Hey everyone, My name is Surya ? working on a project on image classification. I?m interested in identifying non-rigid shapes (close to an ellipse) in an image. Sample image below. Could anyone please point me to some references for that? Thanks Surya -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: output1.jpg Type: image/jpeg Size: 20923 bytes Desc: not available URL: From kmichael.aye at gmail.com Mon Apr 10 19:16:03 2017 From: kmichael.aye at gmail.com (K.-Michael Aye) Date: Mon, 10 Apr 2017 17:16:03 -0600 Subject: [scikit-image] Non-rigid shape matching In-Reply-To: <01070AB1-2A73-4808-97B9-1149F7FB677E@udel.edu> References: <01070AB1-2A73-4808-97B9-1149F7FB677E@udel.edu> Message-ID: How about applying a morphological closing operation until an ellipse fit converges in quality? With that fish though, maybe need a few ?erosion? operations to scrape of those fins. ;) The disadvantage of morphological erosion alone is that the size of the object will be reduced, while the combo of erosion and dilution (i.e. ?closing?) keeps the integrated object size nearly the same. Michael > On Apr 10, 2017, at 16:48, Surya Kasturi wrote: > > Hey everyone, > > My name is Surya ? working on a project on image classification. > > I?m interested in identifying non-rigid shapes (close to an ellipse) in an image. Sample image below. > > Could anyone please point me to some references for that? > > > > > Thanks > Surya > > _______________________________________________ > scikit-image mailing list > scikit-image at python.org > https://mail.python.org/mailman/listinfo/scikit-image From suryak at udel.edu Tue Apr 11 16:55:30 2017 From: suryak at udel.edu (Surya Kasturi) Date: Tue, 11 Apr 2017 16:55:30 -0400 Subject: [scikit-image] Non-rigid shape matching In-Reply-To: References: <01070AB1-2A73-4808-97B9-1149F7FB677E@udel.edu> Message-ID: <9E33DD2F-E83A-4E89-AD64-65084F955312@udel.edu> Is this correct interpretation? ? Do morphological operations and Hough Ellipse transform for ellipse detection? I?m thinking of leveraging active contours. Is it possible to place shape constraints on Energy equation in some way? For instance, perform non-rigid shape matching? Thanks, Surya > On Apr 10, 2017, at 7:16 PM, K.-Michael Aye wrote: > > How about applying a morphological closing operation until an ellipse fit converges in quality? > > With that fish though, maybe need a few ?erosion? operations to scrape of those fins. ;) > > The disadvantage of morphological erosion alone is that the size of the object will be reduced, while the combo of erosion and dilution (i.e. ?closing?) keeps the integrated object size nearly the same. > > Michael > > >> On Apr 10, 2017, at 16:48, Surya Kasturi wrote: >> >> Hey everyone, >> >> My name is Surya ? working on a project on image classification. >> >> I?m interested in identifying non-rigid shapes (close to an ellipse) in an image. Sample image below. >> >> Could anyone please point me to some references for that? >> >> >> >> >> Thanks >> Surya >> >> _______________________________________________ >> 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 Wed Apr 12 04:46:52 2017 From: egor.v.panfilov at gmail.com (Egor Panfilov) Date: Wed, 12 Apr 2017 11:46:52 +0300 Subject: [scikit-image] Important change in testing environment Message-ID: Dear contributors, We'd like to notify your that we have just finished a transition of our testing environment from `nose` to `pytest` (see https://github.com/scikit-image/scikit-image/pull/2468 for the details). We kindly ask you to revisit your open Pull Requests on GitHub, perform a rebase onto `master` branch of `scikit-image/scikit-image` repo (see http://scikit-image.org/docs/dev/contribute.html#divergence-between-upstream-master-and-your-feature-branch), and rewrite your tests using `pytest` wherever is needed. Usage of the functions from `numpy.testing` in addition to `pytest` ones is allowed, but, please, notice that some of them (such as `assert_raises`) rely on `nose` under the hood, and, therefore, should not be used. Sorry for the inconvenience. Looking forward to seeing your contributions updated and merged. Regards, Egor, scikit-image core team -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Wed Apr 12 12:14:56 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Wed, 12 Apr 2017 09:14:56 -0700 Subject: [scikit-image] Important change in testing environment In-Reply-To: References: Message-ID: <1492013696.2810545.942655632.23459333@webmail.messagingengine.com> On Wed, Apr 12, 2017, at 01:46, Egor Panfilov wrote: > We'd like to notify your that we have just finished a transition of > our testing environment from `nose` to `pytest` (see > https://github.com/scikit-image/scikit-image/pull/2468 for the > details). > > We kindly ask you to revisit your open Pull Requests on GitHub, > perform a rebase onto `master` branch of `scikit-image/scikit-image` > repo (see > http://scikit-image.org/docs/dev/contribute.html#divergence-between-upstream-master-and-your-feature-branch), > and rewrite your tests using `pytest` wherever is needed. > > Usage of the functions from `numpy.testing` in addition to `pytest` > ones is allowed, but, please, notice that some of them (such as > `assert_raises`) rely on `nose` under the hood, and, therefore, should > not be used. Thanks for the reminder, Egor. The changes will, hopefully, be minimal from the developer perspective. And we're working on another PR that exposes all of the test utilities under `skimage.util`, to simplify matters. Best regards St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jni.soma at gmail.com Thu Apr 13 02:39:29 2017 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Thu, 13 Apr 2017 16:39:29 +1000 Subject: [scikit-image] How to move pull requests forward (devs, please read) In-Reply-To: <1491525149.1891706.936906712.3C8FA86A@webmail.messagingengine.com> References: <1491525149.1891706.936906712.3C8FA86A@webmail.messagingengine.com> Message-ID: Hi St?fan, I think figuring this out is certainly a high priority when it comes to being contributor-friendly. One thing I don?t know what to do is figure out whether a contributor has turned on ?collaboration?. What am I missing? I can see when *I?ve* turned it on, but for other pull requests I can?t get any info. Is the only way to know to try to push? A related point of failure that I?ve see is where we have an API discussion on the PR, and the core members have a back and forth over it, with confusion about the final outcome for the PR author. I?m still traumatised by this comment. And the current PRs on manual segmentation?and nD rescaling risk the same fate. St?fan and I briefly discussed this off-list and we came up with the following solution (which we now request comments on): - new functions of dubious API go to skimage.future. That?s what the package was created for. *However*, RAG has languished there for several releases, so this is not a long-term solution. So, in addition: - make a note in the TODO.txt for two releases down (would be v0.15 currently), forcing an API discussion and a move out of skimage.future for that release. - For existing functions that require an API change, merge a ?good enough? API, raise an issue on GitHub for the API discussion, and tag it with the next release. For rebasing, if there is nothing left to do in the PR but the rebase, I suggest that we merge the PR manually in the command line. Incidentally, regarding optimistic merging: I do think there is a place for it in scikit-image, namely, for any PRs that pass tests and coverage checks, but need stylistic updates. Frankly, it is faster to do these oneself than to write them in the PR, *and* they inevitably feel petty to both the reviewer and the contributor. Therefore, I might suggest that we do perform optimistic merging when there are minor** style issues, and then fix those issues ourselves. However, if you merge in this situation, you *must* submit the fix immediately. Otherwise it?s certain to be lost. **: by minor, I mean not something like "class Filter: ?? "class Gaussian(Filter): ?? =P So, to summarise, my proposal when dealing with non-core contributors: - avoid massive API discussions. Settle on the simplest solution and add a to-do. If it?s new functionality, put it in skimage.future. - avoid all kinds of style nitpicking ? it?s faster and easier to fix these things ourselves. I suggest even doing optimistic merging. - don?t ask users to rebase unless it?s clear that they are git experts. Follow github?s advice and merge on the command line. Comments are very welcome! Juan. On 7 Apr 2017, 10:32 AM +1000, Stefan van der Walt , wrote: > Hi everyone, and especially devs > > This afternoon, Nelle Varoquaux gave a short presentation at BIDS on > optimistic merging, a workflow suggested by the late Pieter Hintjens. > In optimistic merging, all PRs are merged into a project, and fixes > happen via additional patches or reverts. While, in my mind, this is > not a viable model for scikit-image, it made me think of our PR review > process. > > A failure mode I observe often is the following: > > - user submits patch > - review happens, often either a) nitpicking on minor things or b) > asking for technically difficult tasks to be performed (rebasing, can be > tricky) > > This introduces several problems, including discouraging new > contributors, and wasting a lot of time (many PRs are left hanging for > months, while waiting for a one-line fix from the original author). > > I'd like to request the following: > > - Ask contributors to open their branches for collaboration (this is on > by default already, probably). > - While reviewing a PR, pull down the branch, look at the diff, and fix > any trivial errors you see. Push the results back up or, if > collaboration is switched off, make a PR against theirs. > - Keep review comments to bigger picture changes, and avoid getting > bogged down in trivial fixes and stylistic changes. > > Let's keep it collaborative and friendly, grow our team of contributors, > and get going on 0.14 :) > > Thanks! > St?fan > > > > P.S. A question for the git experts: > > I've been looking for ways of making the above process easier. I found > that I can easily download pull requests: > > - In my ~/.gitconfig, I add the following alias (replace 'upstream' > with whatever you normally call the scikit-image main repository): > > [alias] > pullpr = "!f() { git fetch upstream pull/$1/head:pr$1 ;}; f" > > I can now grab a PR with: > > git pullpr 2447 > > and it will appear in the branch pr2447. > > Unfortunately, I don't have a similarly easy way of pushing back, other > than adding the contributor's remote, and pushing back to the PR branch. > Any ideas? > > _______________________________________________ > 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 Thu Apr 13 03:41:17 2017 From: ssouravsingh12 at gmail.com (Sourav Singh) Date: Thu, 13 Apr 2017 13:11:17 +0530 Subject: [scikit-image] How to move pull requests forward (devs, please read) In-Reply-To: References: <1491525149.1891706.936906712.3C8FA86A@webmail.messagingengine.com> Message-ID: Hello, I agree with most of the points put by Juan. Here are some points that I would like to put forward- 1) If there is a PR which has a merge conflict in a single file, we can tell the contributor to fix it through Github PR through the merge conflict button. 2) If the problem of merge is severe, core devs can come forward to fix the problem if the contributor is not a git expert. 3) For long standing PRs, first-time contributors could come forward and handle the problem if they know what needs to be done. Comments are very welcome! Regards, Sourav Sent from my Phone.Excuse any mistakes and brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nelle.varoquaux at gmail.com Thu Apr 13 18:28:45 2017 From: nelle.varoquaux at gmail.com (Nelle Varoquaux) Date: Thu, 13 Apr 2017 15:28:45 -0700 Subject: [scikit-image] How to move pull requests forward (devs, please read) In-Reply-To: References: <1491525149.1891706.936906712.3C8FA86A@webmail.messagingengine.com> Message-ID: Hello, For style-changes (such as pep8/flake8) elements, I find that very often new contributors don't know they can configure their text editors to display the pep8/pyflakes violations. Very often, it is a question of mentoring them through the process of configuring their text editors. Recently, I've been either creating pull requests on people's branch or pushing to the contributor's branch just before merging. Cheers, N On 13 April 2017 at 00:41, Sourav Singh wrote: > Hello, > > I agree with most of the points put by Juan. Here are some points that I > would like to put forward- > > 1) If there is a PR which has a merge conflict in a single file, we can > tell the contributor to fix it through Github PR through the merge conflict > button. > > 2) If the problem of merge is severe, core devs can come forward to fix > the problem if the contributor is not a git expert. > > 3) For long standing PRs, first-time contributors could come forward and > handle the problem if they know what needs to be done. > > Comments are very welcome! > > Regards, > > Sourav > > Sent from my Phone.Excuse any mistakes and brevity. > > _______________________________________________ > 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 Thu Apr 13 18:36:45 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Thu, 13 Apr 2017 15:36:45 -0700 Subject: [scikit-image] How to move pull requests forward (devs, please read) In-Reply-To: References: <1491525149.1891706.936906712.3C8FA86A@webmail.messagingengine.com> Message-ID: <1492123005.1456203.944175432.2835B6BD@webmail.messagingengine.com> On Thu, Apr 13, 2017, at 15:28, Nelle Varoquaux wrote: > For style-changes (such as pep8/flake8) elements, I find that very > often new contributors don't know they can configure their text > editors to display the pep8/pyflakes violations. Very often, it is a > question of mentoring them through the process of configuring their > text editors. This seems like the kind of thing we can document in our contributor guide? http://scikit-image.org/docs/stable/contribute.html#stylistic-guidelines St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Thu Apr 13 18:35:19 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Thu, 13 Apr 2017 15:35:19 -0700 Subject: [scikit-image] How to move pull requests forward (devs, please read) In-Reply-To: References: <1491525149.1891706.936906712.3C8FA86A@webmail.messagingengine.com> Message-ID: <1492122919.1455505.944169032.09CD1900@webmail.messagingengine.com> Hi Juan On Wed, Apr 12, 2017, at 23:39, Juan Nunez-Iglesias wrote: > One thing I don?t know what to do is figure out whether a contributor > has turned on ?collaboration?. What am I missing? I can see when > *I?ve* turned it on, but for other pull requests I can?t get any info. > Is the only way to know to try to push? It's enabled by default (still, odd that they do not show it). > A related point of failure that I?ve see is where we have an API > discussion on the PR, and the core members have a back and forth over > it, with confusion about the final outcome for the PR author. I?m > still traumatised by this comment[1]. And the current PRs on manual > segmentation[2] and nD rescaling[3] risk the same fate. St?fan and I > briefly discussed this off-list and we came up with the following > solution (which we now request comments on): > > - new functions of dubious API go to skimage.future. That?s what the > package was created for. *However*, RAG has languished there for > several releases, so this is not a long-term solution. So, in > addition: > - make a note in the TODO.txt for two releases down (would be v0.15 > currently), forcing an API discussion and a move out of > skimage.future for that release. > - For existing functions that require an API change, merge a ?good > enough? API, raise an issue on GitHub for the API discussion, and > tag it with the next release. The one concern I have is that we're going to run into the situation where each release is blocked by a bunch of hard-to-make API decisions. So perhaps raise an issue for API review of that function, tagged with next release? That way, we can start gathering feedback, and even close before the next release comes along. > For rebasing, if there is nothing left to do in the PR but the rebase, > I suggest that we merge the PR manually in the command line. Why don't we make the following simple rule: . Never request rebases---instruct contributor to merge, or do that for them 1. Always squash merges This is easy for the contributor, and does not pollute the master branch history. I know this goes against the original decision to retain all patches in a PR, but the problem of engaging contributors is much larger than my somewhat anal preference for well groomed patch-sets. If a squashed PR generates an overly large patch, it probably should be broken up anyway. > Incidentally, regarding optimistic merging: I do think there is a > place for it in scikit-image, namely, for any PRs that pass tests and > coverage checks, but need stylistic updates. Frankly, it is faster to > do these oneself than to write them in the PR, *and* they inevitably > feel petty to both the reviewer and the contributor. Therefore, I > might suggest that we do perform optimistic merging when there are > minor** style issues, and then fix those issues ourselves. However, if > you merge in this situation, you *must* submit the fix immediately. > Otherwise it?s certain to be lost. Whenever you have a queuing system that grows more quickly than you can consume (e.g., the number of emails in your INBOX), you have to make an adjustment. And I think this is a very reasonable compromise. St?fan Links: 1. https://github.com/scikit-image/scikit-image/pull/953#issuecomment-43598826 2. https://github.com/scikit-image/scikit-image/pull/2584 3. https://github.com/scikit-image/scikit-image/pull/1522 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nelle.varoquaux at gmail.com Thu Apr 13 18:45:21 2017 From: nelle.varoquaux at gmail.com (Nelle Varoquaux) Date: Thu, 13 Apr 2017 15:45:21 -0700 Subject: [scikit-image] How to move pull requests forward (devs, please read) In-Reply-To: <1492123005.1456203.944175432.2835B6BD@webmail.messagingengine.com> References: <1491525149.1891706.936906712.3C8FA86A@webmail.messagingengine.com> <1492123005.1456203.944175432.2835B6BD@webmail.messagingengine.com> Message-ID: On 13 April 2017 at 15:36, Stefan van der Walt wrote: > On Thu, Apr 13, 2017, at 15:28, Nelle Varoquaux wrote: > > For style-changes (such as pep8/flake8) elements, I find that very often > new contributors don't know they can configure their text editors to > display the pep8/pyflakes violations. Very often, it is a question of > mentoring them through the process of configuring their text editors. > > > This seems like the kind of thing we can document in our contributor guide? > > http://scikit-image.org/docs/stable/contribute.html#stylistic-guidelines > That seems a fairly sensible place to document this :) But considering this affect many projects in the scipy community, I am wondering if we should not try to combine efforts and link to a common page somewhere on the web (maybe hosted on the scipy-lecture notes website?) I am happy to work on this, either for scikit-image specifically or to create the webpage somewhere else then edit the scikit-image contribution guidelines to link to this document. Cheers, N > > > 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 stefanv at berkeley.edu Thu Apr 13 18:49:45 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Thu, 13 Apr 2017 15:49:45 -0700 Subject: [scikit-image] How to move pull requests forward (devs, please read) In-Reply-To: References: <1491525149.1891706.936906712.3C8FA86A@webmail.messagingengine.com> <1492123005.1456203.944175432.2835B6BD@webmail.messagingengine.com> Message-ID: <1492123785.1458261.944185272.2922CEDF@webmail.messagingengine.com> On Thu, Apr 13, 2017, at 15:45, Nelle Varoquaux wrote: > On 13 April 2017 at 15:36, Stefan van der Walt > wrote: >> __ >> >> On Thu, Apr 13, 2017, at 15:28, Nelle Varoquaux wrote: >>> For style-changes (such as pep8/flake8) elements, I find that very >>> often new contributors don't know they can configure their text >>> editors to display the pep8/pyflakes violations. Very often, it is a >>> question of mentoring them through the process of configuring their >>> text editors. >> >> >> This seems like the kind of thing we can document in our >> contributor guide? >> >> http://scikit-image.org/docs/stable/contribute.html#stylistic-guidelines > > That seems a fairly sensible place to document this :) > But considering this affect many projects in the scipy community, I am > wondering if we should not try to combine efforts and link to a common > page somewhere on the web (maybe hosted on the scipy-lecture notes > website?) > I am happy to work on this, either for scikit-image specifically or to > create the webpage somewhere else then edit the scikit-image > contribution guidelines to link to this document. Good idea; and thanks! St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nelle.varoquaux at gmail.com Thu Apr 13 18:57:18 2017 From: nelle.varoquaux at gmail.com (Nelle Varoquaux) Date: Thu, 13 Apr 2017 15:57:18 -0700 Subject: [scikit-image] How to move pull requests forward (devs, please read) In-Reply-To: <1492123785.1458261.944185272.2922CEDF@webmail.messagingengine.com> References: <1491525149.1891706.936906712.3C8FA86A@webmail.messagingengine.com> <1492123005.1456203.944175432.2835B6BD@webmail.messagingengine.com> <1492123785.1458261.944185272.2922CEDF@webmail.messagingengine.com> Message-ID: > > For style-changes (such as pep8/flake8) elements, I find that very often > new contributors don't know they can configure their text editors to > display the pep8/pyflakes violations. Very often, it is a question of > mentoring them through the process of configuring their text editors. > > > > This seems like the kind of thing we can document in our contributor guide? > > http://scikit-image.org/docs/stable/contribute.html#stylistic-guidelines > > > That seems a fairly sensible place to document this :) > But considering this affect many projects in the scipy community, I am > wondering if we should not try to combine efforts and link to a common page > somewhere on the web (maybe hosted on the scipy-lecture notes website?) > I am happy to work on this, either for scikit-image specifically or to > create the webpage somewhere else then edit the scikit-image contribution > guidelines to link to this document. > > > Good idea; and thanks! > I just got the approval from Gael to add a chapter "Best development practices" to scipy lecture notes. That should cover setting up text editors and other elements. If you have any other ideas on what should be in that chapter, just email me. Cheers, N > > St?fan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vighneshbirodkar at gmail.com Fri Apr 14 00:30:14 2017 From: vighneshbirodkar at gmail.com (Vighnesh Birodkar) Date: Fri, 14 Apr 2017 00:30:14 -0400 Subject: [scikit-image] How to move pull requests forward (devs, please read) In-Reply-To: References: <1491525149.1891706.936906712.3C8FA86A@webmail.messagingengine.com> Message-ID: Hello I wonder if the scope of optimistic merging can be broader. Let's say we have a working implementation of an algorithm which is not the best for one or more of the following reasons. - Suboptimal data structure choice (linear instead of logarithmic complexity) which results in a minor speed delay during invocation. - Not having type checks or conversions. - Duplicate code which might be refactored out. - Lack of or no documentation But apart from this the PR does what the algorithm it implements correctly. Can we merge such a PR in master and keep it as a private unexposed function while raising an issue to address it's shortcomings ? The function can de decorated to exclude it from the main docs and maybe raise a warning when invoked. I believe the flaws I mentioned can be taken up by someone else in the community. Like a user might contribute documentation or a newcomer might do the refactoring. Then later down the line core Devs can agree and make the function public. It really sucks when there is a working patch for a feature you might want to use but you cannot use it because the PR isn't merged. For example, I don't care if a function takes more time to execute if all I want to do is use it to generate a few statistics or figures while writing a publication. Thanks Vighnesh On 13 Apr 2017 3:17 am, "Juan Nunez-Iglesias" wrote: > Hi St?fan, > > I think figuring this out is certainly a high priority when it comes to > being contributor-friendly. > > One thing I don?t know what to do is figure out whether a contributor has > turned on ?collaboration?. What am I missing? I can see when *I?ve* turned > it on, but for other pull requests I can?t get any info. Is the only way to > know to try to push? > > A related point of failure that I?ve see is where we have an API > discussion on the PR, and the core members have a back and forth over it, > with confusion about the final outcome for the PR author. I?m still > traumatised by this comment > . > And the current PRs on manual segmentation > and nD rescaling > risk the same > fate. St?fan and I briefly discussed this off-list and we came up with the > following solution (which we now request comments on): > > - new functions of dubious API go to skimage.future. That?s what the > package was created for. *However*, RAG has languished there for several > releases, so this is not a long-term solution. So, in addition: > - make a note in the TODO.txt for two releases down (would be v0.15 > currently), forcing an API discussion and a move out of skimage.future for > that release. > - For existing functions that require an API change, merge a ?good enough? > API, raise an issue on GitHub for the API discussion, and tag it with the > next release. > > For rebasing, if there is nothing left to do in the PR but the rebase, I > suggest that we merge the PR manually in the command line. > > Incidentally, regarding optimistic merging: I do think there is a place > for it in scikit-image, namely, for any PRs that pass tests and coverage > checks, but need stylistic updates. Frankly, it is faster to do these > oneself than to write them in the PR, *and* they inevitably feel petty to > both the reviewer and the contributor. Therefore, I might suggest that we > do perform optimistic merging when there are minor** style issues, and then > fix those issues ourselves. However, if you merge in this situation, you > *must* submit the fix immediately. Otherwise it?s certain to be lost. > > **: by minor, I mean not something like "class Filter: ?? "class > Gaussian(Filter): ?? =P > > So, to summarise, my proposal when dealing with non-core contributors: > > - avoid massive API discussions. Settle on the simplest solution and add a > to-do. If it?s new functionality, put it in skimage.future. > - avoid all kinds of style nitpicking ? it?s faster and easier to fix > these things ourselves. I suggest even doing optimistic merging. > - don?t ask users to rebase unless it?s clear that they are git experts. > Follow github?s advice and merge on the command line. > > Comments are very welcome! > > Juan. > > On 7 Apr 2017, 10:32 AM +1000, Stefan van der Walt , > wrote: > > Hi everyone, and especially devs > > This afternoon, Nelle Varoquaux gave a short presentation at BIDS on > optimistic merging, a workflow suggested by the late Pieter Hintjens. > In optimistic merging, all PRs are merged into a project, and fixes > happen via additional patches or reverts. While, in my mind, this is > not a viable model for scikit-image, it made me think of our PR review > process. > > A failure mode I observe often is the following: > > - user submits patch > - review happens, often either a) nitpicking on minor things or b) > asking for technically difficult tasks to be performed (rebasing, can be > tricky) > > This introduces several problems, including discouraging new > contributors, and wasting a lot of time (many PRs are left hanging for > months, while waiting for a one-line fix from the original author). > > I'd like to request the following: > > - Ask contributors to open their branches for collaboration (this is on > by default already, probably). > - While reviewing a PR, pull down the branch, look at the diff, and fix > any trivial errors you see. Push the results back up or, if > collaboration is switched off, make a PR against theirs. > - Keep review comments to bigger picture changes, and avoid getting > bogged down in trivial fixes and stylistic changes. > > Let's keep it collaborative and friendly, grow our team of contributors, > and get going on 0.14 :) > > Thanks! > St?fan > > > > P.S. A question for the git experts: > > I've been looking for ways of making the above process easier. I found > that I can easily download pull requests: > > - In my ~/.gitconfig, I add the following alias (replace 'upstream' > with whatever you normally call the scikit-image main repository): > > [alias] > pullpr = "!f() { git fetch upstream pull/$1/head:pr$1 ;}; f" > > I can now grab a PR with: > > git pullpr 2447 > > and it will appear in the branch pr2447. > > Unfortunately, I don't have a similarly easy way of pushing back, other > than adding the contributor's remote, and pushing back to the PR branch. > Any ideas? > > _______________________________________________ > 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 jni.soma at gmail.com Fri Apr 14 02:06:23 2017 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Fri, 14 Apr 2017 16:06:23 +1000 Subject: [scikit-image] How to move pull requests forward (devs, please read) In-Reply-To: References: <1491525149.1891706.936906712.3C8FA86A@webmail.messagingengine.com> Message-ID: <12f50761-f720-4060-a06f-126b85a99e27@Spark> Hey Vighnesh, I'm -1 on this level of optimism. =P I think code in master should reflect with probability 1 the best that we can make it. What that means is that "quick fix" PRs can get merged because the maintainer who merges it can issue a fix instantly. For large fixes, the most likely scenario is that it stays in the code for a long time, and then come release time there is a huge burden for the maintainers. Regarding new contributors pitching in, my take is that most new contributors are using the stable release, and so are unlikely to have even encountered the "dirty" function. Finally, for "single use" functions, it is straightforward enough for one to grab them off the contributor's fork, I think. Juan. On 14 Apr 2017, 2:30 PM +1000, Vighnesh Birodkar , wrote: > Hello > > I wonder if the scope of optimistic merging can be broader. Let's say we have a working implementation of an algorithm which is not the best for one or more of the following reasons. > > - Suboptimal data structure choice (linear instead of logarithmic complexity) which results in a minor speed delay during invocation. > - Not having type checks or conversions. > - Duplicate code which might be refactored out. > - Lack of or no documentation > > But apart from this the PR does what the algorithm it implements correctly. Can we merge such a PR in master and keep it as a private unexposed function while raising an issue to address it's shortcomings ? The function can de decorated to exclude it from the main docs and maybe raise a warning when invoked. I believe the flaws I mentioned can be taken up by someone else in the community. Like a user might contribute documentation or a newcomer might do the refactoring. Then later down the line core Devs can agree and make the function public. > > It really sucks when there is a working patch for a feature you might want to use but you cannot use it because the PR isn't merged. For example, I don't care if a function takes more time to execute if all I want to do is use it to generate a few statistics or figures while writing a publication. > > Thanks > Vighnesh > > > On 13 Apr 2017 3:17 am, "Juan Nunez-Iglesias" wrote: > > > Hi St?fan, > > > > > > I think figuring this out is certainly a high priority when it comes to being contributor-friendly. > > > > > > One thing I don?t know what to do is figure out whether a contributor has turned on ?collaboration?. What am I missing? I can see when *I?ve* turned it on, but for other pull requests I can?t get any info. Is the only way to know to try to push? > > > > > > A related point of failure that I?ve see is where we have an API discussion on the PR, and the core members have a back and forth over it, with confusion about the final outcome for the PR author. I?m still traumatised by this comment. And the current PRs on manual segmentation?and nD rescaling risk the same fate. St?fan and I briefly discussed this off-list and we came up with the following solution (which we now request comments on): > > > > > > - new functions of dubious API go to skimage.future. That?s what the package was created for. *However*, RAG has languished there for several releases, so this is not a long-term solution. So, in addition: > > > - make a note in the TODO.txt for two releases down (would be v0.15 currently), forcing an API discussion and a move out of skimage.future for that release. > > > - For existing functions that require an API change, merge a ?good enough? API, raise an issue on GitHub for the API discussion, and tag it with the next release. > > > > > > For rebasing, if there is nothing left to do in the PR but the rebase, I suggest that we merge the PR manually in the command line. > > > > > > Incidentally, regarding optimistic merging: I do think there is a place for it in scikit-image, namely, for any PRs that pass tests and coverage checks, but need stylistic updates. Frankly, it is faster to do these oneself than to write them in the PR, *and* they inevitably feel petty to both the reviewer and the contributor. Therefore, I might suggest that we do perform optimistic merging when there are minor** style issues, and then fix those issues ourselves. However, if you merge in this situation, you *must* submit the fix immediately. Otherwise it?s certain to be lost. > > > > > > **: by minor, I mean not something like "class Filter: ?? "class Gaussian(Filter): ?? =P > > > > > > So, to summarise, my proposal when dealing with non-core contributors: > > > > > > - avoid massive API discussions. Settle on the simplest solution and add a to-do. If it?s new functionality, put it in skimage.future. > > > - avoid all kinds of style nitpicking ? it?s faster and easier to fix these things ourselves. I suggest even doing optimistic merging. > > > - don?t ask users to rebase unless it?s clear that they are git experts. Follow github?s advice and merge on the command line. > > > > > > Comments are very welcome! > > > > > > Juan. > > > > > > On 7 Apr 2017, 10:32 AM +1000, Stefan van der Walt , wrote: > > > > Hi everyone, and especially devs > > > > > > > > This afternoon, Nelle Varoquaux gave a short presentation at BIDS on > > > > optimistic merging, a workflow suggested by the late Pieter Hintjens. > > > > In optimistic merging, all PRs are merged into a project, and fixes > > > > happen via additional patches or reverts. While, in my mind, this is > > > > not a viable model for scikit-image, it made me think of our PR review > > > > process. > > > > > > > > A failure mode I observe often is the following: > > > > > > > > - user submits patch > > > > - review happens, often either a) nitpicking on minor things or b) > > > > asking for technically difficult tasks to be performed (rebasing, can be > > > > tricky) > > > > > > > > This introduces several problems, including discouraging new > > > > contributors, and wasting a lot of time (many PRs are left hanging for > > > > months, while waiting for a one-line fix from the original author). > > > > > > > > I'd like to request the following: > > > > > > > > - Ask contributors to open their branches for collaboration (this is on > > > > by default already, probably). > > > > - While reviewing a PR, pull down the branch, look at the diff, and fix > > > > any trivial errors you see. Push the results back up or, if > > > > collaboration is switched off, make a PR against theirs. > > > > - Keep review comments to bigger picture changes, and avoid getting > > > > bogged down in trivial fixes and stylistic changes. > > > > > > > > Let's keep it collaborative and friendly, grow our team of contributors, > > > > and get going on 0.14 :) > > > > > > > > Thanks! > > > > St?fan > > > > > > > > > > > > > > > > P.S. A question for the git experts: > > > > > > > > I've been looking for ways of making the above process easier. I found > > > > that I can easily download pull requests: > > > > > > > > - In my ~/.gitconfig, I add the following alias (replace 'upstream' > > > > with whatever you normally call the scikit-image main repository): > > > > > > > > [alias] > > > > pullpr = "!f() { git fetch upstream pull/$1/head:pr$1 ;}; f" > > > > > > > > I can now grab a PR with: > > > > > > > > git pullpr 2447 > > > > > > > > and it will appear in the branch pr2447. > > > > > > > > Unfortunately, I don't have a similarly easy way of pushing back, other > > > > than adding the contributor's remote, and pushing back to the PR branch. > > > > Any ideas? > > > > > > > > _______________________________________________ > > > > 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 vighneshbirodkar at gmail.com Fri Apr 14 02:34:31 2017 From: vighneshbirodkar at gmail.com (Vighnesh Birodkar) Date: Fri, 14 Apr 2017 02:34:31 -0400 Subject: [scikit-image] How to move pull requests forward (devs, please read) In-Reply-To: <12f50761-f720-4060-a06f-126b85a99e27@Spark> References: <1491525149.1891706.936906712.3C8FA86A@webmail.messagingengine.com> <12f50761-f720-4060-a06f-126b85a99e27@Spark> Message-ID: Hey Juan I understand where you are coming from. But don't you think there are instances when a contributor , after working on a new feature or function, does not have the time or energy to drive their work towards completion. The pending work might be too much for a single developer but it may be something that multiple developers working together might be able to complete. These features need not have to be part of the next release. But my assumption is that if one these features is useful, it will quickly get polished and be good enough to be exposable. If a feature works and is kept isolated from the public API, its tests/docs/optimizations can come from different other developers at different points of time. On 14 Apr 2017 2:12 am, "Juan Nunez-Iglesias" wrote: > Hey Vighnesh, > > I'm -1 on this level of optimism. =P I think code in master should reflect > with probability 1 the best that we can make it. What that means is that > "quick fix" PRs can get merged because the maintainer who merges it can > issue a fix instantly. For large fixes, the most likely scenario is that it > stays in the code for a long time, and then come release time there is a > huge burden for the maintainers. > > Regarding new contributors pitching in, my take is that most new > contributors are using the stable release, and so are unlikely to have even > encountered the "dirty" function. > > Finally, for "single use" functions, it is straightforward enough for one > to grab them off the contributor's fork, I think. > > Juan. > > On 14 Apr 2017, 2:30 PM +1000, Vighnesh Birodkar < > vighneshbirodkar at gmail.com>, wrote: > > Hello > > I wonder if the scope of optimistic merging can be broader. Let's say we > have a working implementation of an algorithm which is not the best for one > or more of the following reasons. > > - Suboptimal data structure choice (linear instead of logarithmic > complexity) which results in a minor speed delay during invocation. > - Not having type checks or conversions. > - Duplicate code which might be refactored out. > - Lack of or no documentation > > But apart from this the PR does what the algorithm it implements > correctly. Can we merge such a PR in master and keep it as a private > unexposed function while raising an issue to address it's shortcomings ? > The function can de decorated to exclude it from the main docs and maybe > raise a warning when invoked. I believe the flaws I mentioned can be taken > up by someone else in the community. Like a user might contribute > documentation or a newcomer might do the refactoring. Then later down the > line core Devs can agree and make the function public. > > It really sucks when there is a working patch for a feature you might want > to use but you cannot use it because the PR isn't merged. For example, I > don't care if a function takes more time to execute if all I want to do is > use it to generate a few statistics or figures while writing a publication. > > Thanks > Vighnesh > > On 13 Apr 2017 3:17 am, "Juan Nunez-Iglesias" wrote: > >> Hi St?fan, >> >> I think figuring this out is certainly a high priority when it comes to >> being contributor-friendly. >> >> One thing I don?t know what to do is figure out whether a contributor has >> turned on ?collaboration?. What am I missing? I can see when *I?ve* turned >> it on, but for other pull requests I can?t get any info. Is the only way to >> know to try to push? >> >> A related point of failure that I?ve see is where we have an API >> discussion on the PR, and the core members have a back and forth over it, >> with confusion about the final outcome for the PR author. I?m still >> traumatised by this comment >> . >> And the current PRs on manual segmentation >> and nD rescaling >> risk the same >> fate. St?fan and I briefly discussed this off-list and we came up with the >> following solution (which we now request comments on): >> >> - new functions of dubious API go to skimage.future. That?s what the >> package was created for. *However*, RAG has languished there for several >> releases, so this is not a long-term solution. So, in addition: >> - make a note in the TODO.txt for two releases down (would be v0.15 >> currently), forcing an API discussion and a move out of skimage.future for >> that release. >> - For existing functions that require an API change, merge a ?good >> enough? API, raise an issue on GitHub for the API discussion, and tag it >> with the next release. >> >> For rebasing, if there is nothing left to do in the PR but the rebase, I >> suggest that we merge the PR manually in the command line. >> >> Incidentally, regarding optimistic merging: I do think there is a place >> for it in scikit-image, namely, for any PRs that pass tests and coverage >> checks, but need stylistic updates. Frankly, it is faster to do these >> oneself than to write them in the PR, *and* they inevitably feel petty to >> both the reviewer and the contributor. Therefore, I might suggest that we >> do perform optimistic merging when there are minor** style issues, and then >> fix those issues ourselves. However, if you merge in this situation, you >> *must* submit the fix immediately. Otherwise it?s certain to be lost. >> >> **: by minor, I mean not something like "class Filter: ?? "class >> Gaussian(Filter): ?? =P >> >> So, to summarise, my proposal when dealing with non-core contributors: >> >> - avoid massive API discussions. Settle on the simplest solution and add >> a to-do. If it?s new functionality, put it in skimage.future. >> - avoid all kinds of style nitpicking ? it?s faster and easier to fix >> these things ourselves. I suggest even doing optimistic merging. >> - don?t ask users to rebase unless it?s clear that they are git experts. >> Follow github?s advice and merge on the command line. >> >> Comments are very welcome! >> >> Juan. >> >> On 7 Apr 2017, 10:32 AM +1000, Stefan van der Walt , >> wrote: >> >> Hi everyone, and especially devs >> >> This afternoon, Nelle Varoquaux gave a short presentation at BIDS on >> optimistic merging, a workflow suggested by the late Pieter Hintjens. >> In optimistic merging, all PRs are merged into a project, and fixes >> happen via additional patches or reverts. While, in my mind, this is >> not a viable model for scikit-image, it made me think of our PR review >> process. >> >> A failure mode I observe often is the following: >> >> - user submits patch >> - review happens, often either a) nitpicking on minor things or b) >> asking for technically difficult tasks to be performed (rebasing, can be >> tricky) >> >> This introduces several problems, including discouraging new >> contributors, and wasting a lot of time (many PRs are left hanging for >> months, while waiting for a one-line fix from the original author). >> >> I'd like to request the following: >> >> - Ask contributors to open their branches for collaboration (this is on >> by default already, probably). >> - While reviewing a PR, pull down the branch, look at the diff, and fix >> any trivial errors you see. Push the results back up or, if >> collaboration is switched off, make a PR against theirs. >> - Keep review comments to bigger picture changes, and avoid getting >> bogged down in trivial fixes and stylistic changes. >> >> Let's keep it collaborative and friendly, grow our team of contributors, >> and get going on 0.14 :) >> >> Thanks! >> St?fan >> >> >> >> P.S. A question for the git experts: >> >> I've been looking for ways of making the above process easier. I found >> that I can easily download pull requests: >> >> - In my ~/.gitconfig, I add the following alias (replace 'upstream' >> with whatever you normally call the scikit-image main repository): >> >> [alias] >> pullpr = "!f() { git fetch upstream pull/$1/head:pr$1 ;}; f" >> >> I can now grab a PR with: >> >> git pullpr 2447 >> >> and it will appear in the branch pr2447. >> >> Unfortunately, I don't have a similarly easy way of pushing back, other >> than adding the contributor's remote, and pushing back to the PR branch. >> Any ideas? >> >> _______________________________________________ >> 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 fboulogne at sciunto.org Fri Apr 14 02:56:03 2017 From: fboulogne at sciunto.org (=?UTF-8?Q?Fran=c3=a7ois_Boulogne?=) Date: Fri, 14 Apr 2017 08:56:03 +0200 Subject: [scikit-image] How to move pull requests forward (devs, please read) In-Reply-To: References: <1491525149.1891706.936906712.3C8FA86A@webmail.messagingengine.com> <12f50761-f720-4060-a06f-126b85a99e27@Spark> Message-ID: <1f4a33cf-e4b1-7c6b-4405-2f439139b7e6@sciunto.org> Dear all, As Juan, I believe that merging unpolished features is just displacing the problem. Like a messy desk tidy up by dumping everything in the drawers. Side remarks, It seems to me that the magic box is not ticked for our oldest PR. So we need to ask the contributor sometimes to do it. I tried to submit PR to contributors branches a couple of time and I always failed with a awkward diff. I probably miss something stupid in the procedure. Any guidance would be appreciated. It sounds quite difficult to me to define rigid rules. Most of the things I learned is with you guys because you pushed me beyond my borders. Education is also a benefit. Whatever the final decision, it's urgent to care about all the PRs we have so far. We have few years old PRs, that we must either decide to close or move forward by ourself. our objective must be to keep the number of open PRs at a low level. In addition, standard rules for our API would help (standard names of variables, standard checks, typical default values etc), even just for the reviewers. It will shortcut debates. Perhaps we can multiply these discussions: https://github.com/scikit-image/scikit-image/issues?q=is%3Aissue+is%3Aopen+label%3Adiscussion and agree that it should end up with a note in the documentation. All the best, -- Fran?ois Boulogne. http://www.sciunto.org GPG: 32D5F22F From njs at pobox.com Fri Apr 14 03:14:04 2017 From: njs at pobox.com (Nathaniel Smith) Date: Fri, 14 Apr 2017 00:14:04 -0700 Subject: [scikit-image] How to move pull requests forward (devs, please read) In-Reply-To: References: <1491525149.1891706.936906712.3C8FA86A@webmail.messagingengine.com> Message-ID: On Thu, Apr 13, 2017 at 3:28 PM, Nelle Varoquaux wrote: > Hello, > > For style-changes (such as pep8/flake8) elements, I find that very often new > contributors don't know they can configure their text editors to display the > pep8/pyflakes violations. Very often, it is a question of mentoring them > through the process of configuring their text editors. > Recently, I've been either creating pull requests on people's branch or > pushing to the contributor's branch just before merging. I wonder if it would be worthwhile to have a bot that automatically pushes formatting fixes to submitted PRs (using autopep8 or yapf). -n -- Nathaniel J. Smith -- https://vorpus.org From jni.soma at gmail.com Fri Apr 14 04:52:17 2017 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Fri, 14 Apr 2017 18:52:17 +1000 Subject: [scikit-image] Turning mailing list reply-to-list on by default Message-ID: Hi all, There is general debate about whether mailing list messages should reply to the list or to the author by default. My view is that replies to list messages should go to the list, and replies only to the author are the exception. This would also be consistent behaviour with the lists of Numba, NumPy, SciPy, and scikit-learn. I intend to update the list settings in a couple of days unless I get some very strenuous opposition to this message. And even then I might do it anyway. =P Just a heads-up! Juan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Fri Apr 14 05:27:53 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Fri, 14 Apr 2017 10:27:53 +0100 Subject: [scikit-image] Turning mailing list reply-to-list on by default In-Reply-To: References: Message-ID: Hi, On Fri, Apr 14, 2017 at 9:52 AM, Juan Nunez-Iglesias wrote: > Hi all, > > There is general debate about whether mailing list messages should reply to > the list or to the author by default. My view is that replies to list > messages should go to the list, and replies only to the author are the > exception. This would also be consistent behaviour with the lists of Numba, > NumPy, SciPy, and scikit-learn. > > I intend to update the list settings in a couple of days unless I get some > very strenuous opposition to this message. For what it's worth, I completely agree. I believe the counter-argument is here: http://www.unicom.com/pw/reply-to-harmful but the argument seems pretty weak to me, it's main strength being the use of the famous phrase 'considered harmful' [1] Cheers, Matthew [1] https://en.wikipedia.org/wiki/Considered_harmful From stefanv at berkeley.edu Fri Apr 14 11:56:47 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Fri, 14 Apr 2017 08:56:47 -0700 Subject: [scikit-image] Turning mailing list reply-to-list on by default In-Reply-To: References: Message-ID: <1492185407.2176316.944769048.3B8DA659@webmail.messagingengine.com> On Fri, Apr 14, 2017, at 02:27, Matthew Brett wrote: > For what it's worth, I completely agree. I believe the > counter-argument is here: > > http://www.unicom.com/pw/reply-to-harmful > > but the argument seems pretty weak to me, it's main strength being the > use of the famous phrase 'considered harmful' [1] It's funny how often we see the argument: "put power in the hands of the user/coder"; but the counter-argument of "do the right thing most of the time" is more compelling. This is also driving the discussion behind making the contribution process easier; having each contributor rebase and polish perfect patches is great in theory, but 98% of the time you just want things to work and be easy. St?fan From stefanv at berkeley.edu Fri Apr 14 12:11:06 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Fri, 14 Apr 2017 09:11:06 -0700 Subject: [scikit-image] How to move pull requests forward (devs, please read) In-Reply-To: References: <1491525149.1891706.936906712.3C8FA86A@webmail.messagingengine.com> Message-ID: <1492186266.2178778.944785656.1F685C75@webmail.messagingengine.com> On Fri, Apr 14, 2017, at 00:14, Nathaniel Smith wrote: > On Thu, Apr 13, 2017 at 3:28 PM, Nelle Varoquaux > wrote: > > Hello, > > > > For style-changes (such as pep8/flake8) elements, I find that very often new > > contributors don't know they can configure their text editors to display the > > pep8/pyflakes violations. Very often, it is a question of mentoring them > > through the process of configuring their text editors. > > Recently, I've been either creating pull requests on people's branch or > > pushing to the contributor's branch just before merging. > > I wonder if it would be worthwhile to have a bot that automatically > pushes formatting fixes to submitted PRs (using autopep8 or yapf). That'd be great; do you know if such a thing exists? St?fan From stefanv at berkeley.edu Fri Apr 14 12:14:49 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Fri, 14 Apr 2017 09:14:49 -0700 Subject: [scikit-image] How to move pull requests forward (devs, please read) In-Reply-To: References: <1491525149.1891706.936906712.3C8FA86A@webmail.messagingengine.com> <12f50761-f720-4060-a06f-126b85a99e27@Spark> Message-ID: <1492186489.2179585.944785944.6622EA2F@webmail.messagingengine.com> Hi Vighnesh On Thu, Apr 13, 2017, at 23:34, Vighnesh Birodkar wrote: > I understand where you are coming from. But don't you think there are > instances when a contributor , after working on a new feature or > function, does not have the time or energy to drive their work towards > completion. The pending work might be too much for a single developer > but it may be something that multiple developers working together > might be able to complete. > > These features need not have to be part of the next release. But my > assumption is that if one these features is useful, it will quickly > get polished and be good enough to be exposable. If a feature works > and is kept isolated from the public API, its tests/docs/optimizations > can come from different other developers at different points of time. Importantly, each piece of contributed code needs to be maintained. I am not encouraged, when a contributer is unwilling to go through the necessary care to figure out API etc., that they will stick around to fix bugs and update documentation later. In fact, that increases my hesitance to merge, because now not only will they be gone, but we'll be stuck having to fix up their code later. So, while I am all in favor of lowering barriers to entry?mostly arround annoying grunt work?certain other barriers remain useful. My preference is for a smaller but higher quality library, with a lower maintenance burden (especially since we rely on volunteer effort for now). St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Fri Apr 14 12:17:35 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Fri, 14 Apr 2017 09:17:35 -0700 Subject: [scikit-image] How to move pull requests forward (devs, please read) In-Reply-To: <1f4a33cf-e4b1-7c6b-4405-2f439139b7e6@sciunto.org> References: <1491525149.1891706.936906712.3C8FA86A@webmail.messagingengine.com> <12f50761-f720-4060-a06f-126b85a99e27@Spark> <1f4a33cf-e4b1-7c6b-4405-2f439139b7e6@sciunto.org> Message-ID: <1492186655.2180323.944789176.01AF9F9E@webmail.messagingengine.com> On Thu, Apr 13, 2017, at 23:56, Fran?ois Boulogne wrote: > In addition, standard rules for our API would help (standard names of > variables, standard checks, typical default values etc), even just for > the reviewers. It will shortcut debates. Perhaps we can multiply these > discussions: > https://github.com/scikit-image/scikit-image/issues?q=is%3Aissue+is%3Aopen+label%3Adiscussion > and agree that it should end up with a note in the documentation. This should be added to the contributor guidelines, potentially as a separate doc linked in. Would you mind taking lead on that? A first step trying to distill what needs to be in that document is the list of model PRs here: https://github.com/scikit-image/scikit-image/wiki One entry so far ;) St?fan From stefanv at berkeley.edu Fri Apr 14 12:19:21 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Fri, 14 Apr 2017 09:19:21 -0700 Subject: [scikit-image] How to move pull requests forward (devs, please read) In-Reply-To: References: <1491525149.1891706.936906712.3C8FA86A@webmail.messagingengine.com> Message-ID: <1492186761.2180469.944791488.1F274B10@webmail.messagingengine.com> On Thu, Apr 13, 2017, at 21:30, Vighnesh Birodkar wrote: > But apart from this the PR does what the algorithm it implements > correctly. Can we merge such a PR in master and keep it as a private > unexposed function while raising an issue to address it's shortcomings > ? The function can de decorated to exclude it from the main docs and > maybe raise a warning when invoked. I believe the flaws I mentioned > can be taken up by someone else in the community. Like a user might > contribute documentation or a newcomer might do the refactoring. Then > later down the line core Devs can agree and make the function public. What you're describing above sounds a lot like skimage.future. Experimental, but with the intent to mature for full inclusion. St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From fboulogne at sciunto.org Fri Apr 14 16:27:25 2017 From: fboulogne at sciunto.org (=?UTF-8?Q?Fran=c3=a7ois_Boulogne?=) Date: Fri, 14 Apr 2017 22:27:25 +0200 Subject: [scikit-image] How to move pull requests forward (devs, please read) In-Reply-To: <1492186655.2180323.944789176.01AF9F9E@webmail.messagingengine.com> References: <1491525149.1891706.936906712.3C8FA86A@webmail.messagingengine.com> <12f50761-f720-4060-a06f-126b85a99e27@Spark> <1f4a33cf-e4b1-7c6b-4405-2f439139b7e6@sciunto.org> <1492186655.2180323.944789176.01AF9F9E@webmail.messagingengine.com> Message-ID: <3fd48733-75a1-9634-0a15-2227cbc949bf@sciunto.org> > This should be added to the contributor guidelines, potentially as a > separate doc linked in. Would you mind taking lead on that? > I started a PR with a blank file to get a place for comments. I'll start to throw few ideas in it soon. https://github.com/scikit-image/scikit-image/pull/2616 -- Fran?ois Boulogne. http://www.sciunto.org GPG: 32D5F22F From njs at pobox.com Fri Apr 14 18:23:01 2017 From: njs at pobox.com (Nathaniel Smith) Date: Fri, 14 Apr 2017 15:23:01 -0700 Subject: [scikit-image] How to move pull requests forward (devs, please read) In-Reply-To: <1492186266.2178778.944785656.1F685C75@webmail.messagingengine.com> References: <1491525149.1891706.936906712.3C8FA86A@webmail.messagingengine.com> <1492186266.2178778.944785656.1F685C75@webmail.messagingengine.com> Message-ID: On Apr 14, 2017 9:12 AM, "Stefan van der Walt" wrote: On Fri, Apr 14, 2017, at 00:14, Nathaniel Smith wrote: > On Thu, Apr 13, 2017 at 3:28 PM, Nelle Varoquaux > wrote: > > Hello, > > > > For style-changes (such as pep8/flake8) elements, I find that very often new > > contributors don't know they can configure their text editors to display the > > pep8/pyflakes violations. Very often, it is a question of mentoring them > > through the process of configuring their text editors. > > Recently, I've been either creating pull requests on people's branch or > > pushing to the contributor's branch just before merging. > > I wonder if it would be worthwhile to have a bot that automatically > pushes formatting fixes to submitted PRs (using autopep8 or yapf). That'd be great; do you know if such a thing exists? I don't know of any off the shelf implementation of this, no. -n -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Fri Apr 14 19:39:38 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Fri, 14 Apr 2017 16:39:38 -0700 Subject: [scikit-image] How to move pull requests forward (devs, please read) In-Reply-To: References: <1491525149.1891706.936906712.3C8FA86A@webmail.messagingengine.com> <1492186266.2178778.944785656.1F685C75@webmail.messagingengine.com> Message-ID: <1492213178.4003623.945107888.1E209C62@webmail.messagingengine.com> On Fri, Apr 14, 2017, at 15:23, Nathaniel Smith wrote: > On Apr 14, 2017 9:12 AM, "Stefan van der Walt" > wrote: >> On Fri, Apr 14, 2017, at 00:14, Nathaniel Smith wrote: >> > I wonder if it would be worthwhile to have a bot that >> > automatically >> > pushes formatting fixes to submitted PRs (using autopep8 or yapf). >> >> That'd be great; do you know if such a thing exists? > > I don't know of any off the shelf implementation of this, no. Oh, we already have it! https://github.com/OrkoHunter/pep8speaks Just type @pep8speaks pep8ify as a comment, and you get a PR back. St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jni.soma at gmail.com Fri Apr 14 19:43:13 2017 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Sat, 15 Apr 2017 09:43:13 +1000 Subject: [scikit-image] How to move pull requests forward (devs, please read) In-Reply-To: <1492213178.4003623.945107888.1E209C62@webmail.messagingengine.com> References: <1491525149.1891706.936906712.3C8FA86A@webmail.messagingengine.com> <1492186266.2178778.944785656.1F685C75@webmail.messagingengine.com> <1492213178.4003623.945107888.1E209C62@webmail.messagingengine.com> Message-ID: <85dd41d2-8592-40d1-ab8d-f46e60874b49@Spark> My concern with fully automated tools is that they tend to be overly stringent. There's many places where we violate PEP8 for valid stylistic reasons, e.g. to align the values of an array literal. btw St?fan, how's the PR for using PEP8speaks only for the diff? On 15 Apr 2017, 9:40 AM +1000, Stefan van der Walt , wrote: > On Fri, Apr 14, 2017, at 15:23, Nathaniel Smith wrote: > > On Apr 14, 2017 9:12 AM, "Stefan van der Walt" wrote: > > > On Fri, Apr 14, 2017, at 00:14, Nathaniel Smith wrote: > > > > I wonder if it would be worthwhile to have a bot that automatically > > > > pushes formatting fixes to submitted PRs (using autopep8 or yapf). > > > > > > That'd be great; do you know if such a thing exists? > > > > I don't know of any off the shelf implementation of this, no. > > Oh, we already have it! > > https://github.com/OrkoHunter/pep8speaks > > Just type > > @pep8speaks pep8ify > > as a comment, and you get a PR back. > > 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 suryak at udel.edu Thu Apr 20 19:10:58 2017 From: suryak at udel.edu (Surya Kasturi) Date: Thu, 20 Apr 2017 19:10:58 -0400 Subject: [scikit-image] Absolute difference of images: OpenCV vs Numpy Message-ID: <05B8FEF1-386C-4F14-A490-14EC3915649E@udel.edu> Hey, I?m doing absolute difference between two images and found that the results from opencv and scikit-image are different >> im1 = imread(?file1.jpg?) >> im2 = imread(?file2.jpg?) >> >> cv2.absdiff(im1, im2) >> np.abs(im1, im2) I was expecting exactly same result.. could anyone please let me know why I?m observing slightly different results. (I could post images if you?d like) Thanks Surya -------------- next part -------------- An HTML attachment was scrubbed... URL: From suryak at udel.edu Thu Apr 20 19:11:48 2017 From: suryak at udel.edu (Surya Kasturi) Date: Thu, 20 Apr 2017 19:11:48 -0400 Subject: [scikit-image] Absolute difference of images: OpenCV vs Numpy In-Reply-To: <05B8FEF1-386C-4F14-A490-14EC3915649E@udel.edu> References: <05B8FEF1-386C-4F14-A490-14EC3915649E@udel.edu> Message-ID: <623DB5C8-DEA1-4570-A216-162F6777B9A7@udel.edu> I?m sorry, Its >> np.abs(im1 - im2) Surya > On Apr 20, 2017, at 7:10 PM, Surya Kasturi wrote: > > Hey, > > I?m doing absolute difference between two images and found that the results from opencv and scikit-image are different > > >> im1 = imread(?file1.jpg?) > >> im2 = imread(?file2.jpg?) > >> > >> cv2.absdiff(im1, im2) > >> np.abs(im1, im2) > > I was expecting exactly same result.. could anyone please let me know why I?m observing slightly different results. > > (I could post images if you?d like) > > Thanks > Surya > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jni.soma at gmail.com Thu Apr 20 23:52:12 2017 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Fri, 21 Apr 2017 13:52:12 +1000 Subject: [scikit-image] Absolute difference of images: OpenCV vs Numpy In-Reply-To: <623DB5C8-DEA1-4570-A216-162F6777B9A7@udel.edu> References: <05B8FEF1-386C-4F14-A490-14EC3915649E@udel.edu> <623DB5C8-DEA1-4570-A216-162F6777B9A7@udel.edu> Message-ID: Hi Surya, Yes, test images would be helpful. My intuition without having test data is that you have some underflow errors in the numpy call, which cv2 avoids with some preprocessing: In [1]: im0 = np.array([64], dtype=np.uint8) In [2]: im1 = np.array([65], dtype=np.uint8) In [3]: np.abs(im0 - im1) Out[3]: array([255], dtype=uint8) This is the correct implementation in NumPy: In [6]: np.maximum(im0, im1) - np.minimum(im0, im1) Out[6]: array([1], dtype=uint8) Juan. On 21 Apr 2017, 9:12 AM +1000, Surya Kasturi , wrote: > I?m sorry, > > Its > > >> np.abs(im1 - im2) > > > Surya > > > > > > > > On Apr 20, 2017, at 7:10 PM, Surya Kasturi wrote: > > > > Hey, > > > > I?m doing absolute difference between two images and found that the results from opencv and scikit-image are different > > > > >> im1 = imread(?file1.jpg?) > > >> im2 = imread(?file2.jpg?) > > >> > > >> cv2.absdiff(im1, im2) > > >> np.abs(im1, im2) > > > > I was expecting exactly same result.. could anyone please let me know why I?m observing slightly different results. > > > > (I could post images if you?d like) > > > > Thanks > > Surya > > > > _______________________________________________ > 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 Fri Apr 21 00:03:07 2017 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Fri, 21 Apr 2017 14:03:07 +1000 Subject: [scikit-image] Reply-to now goes to list Message-ID: Hi all, As I warned last week [1], I have now turned on reply-to-list for the scikit-image mailing list. So it should go without saying but, be nice! =) Juan. ..[1]:?https://mail.python.org/pipermail/scikit-image/2017-April/005189.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Fri Apr 21 23:49:10 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Fri, 21 Apr 2017 20:49:10 -0700 Subject: [scikit-image] Website updates Message-ID: <1492832950.1184511.952446144.27087BE3@webmail.messagingengine.com> Hi, everyone I worked with a student to clean up the website a bit. Because it's hard to review a website via diff, I made the plunge and uploaded the new pages. I'd be grateful for feedback, especially on: http://scikit-image.org/ http://scikit-image.org/docs/dev/auto_examples/ (notice sidebar, notice boxes) http://scikit-image.org/docs/dev/ and http://scikit-image.org/docs/dev/api/api.html Thanks! St?fan From suryak at udel.edu Sat Apr 22 00:06:36 2017 From: suryak at udel.edu (Surya Kasturi) Date: Sat, 22 Apr 2017 00:06:36 -0400 Subject: [scikit-image] Website updates In-Reply-To: <1492832950.1184511.952446144.27087BE3@webmail.messagingengine.com> References: <1492832950.1184511.952446144.27087BE3@webmail.messagingengine.com> Message-ID: <39A3CEA8-B0ED-4FD1-A66F-B1494999C7CE@udel.edu> I think having a quick way to go through all functions would be useful. Similar to what OpenCV offers: Thank you, Surya > On Apr 21, 2017, at 11:49 PM, Stefan van der Walt wrote: > > Hi, everyone > > I worked with a student to clean up the website a bit. Because it's > hard to review a website via diff, I made the plunge and uploaded the > new pages. > > I'd be grateful for feedback, especially on: > > http://scikit-image.org/ > http://scikit-image.org/docs/dev/auto_examples/ (notice sidebar, notice > boxes) > http://scikit-image.org/docs/dev/ > > and > > http://scikit-image.org/docs/dev/api/api.html > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2017-04-22 at 12.04.08 AM.png Type: image/png Size: 39397 bytes Desc: not available URL: From stefanv at berkeley.edu Sat Apr 22 00:07:58 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Fri, 21 Apr 2017 21:07:58 -0700 Subject: [scikit-image] Website updates In-Reply-To: <39A3CEA8-B0ED-4FD1-A66F-B1494999C7CE@udel.edu> References: <1492832950.1184511.952446144.27087BE3@webmail.messagingengine.com> <39A3CEA8-B0ED-4FD1-A66F-B1494999C7CE@udel.edu> Message-ID: <1492834078.1189411.952457400.5C3B10ED@webmail.messagingengine.com> Hi Surya On Fri, Apr 21, 2017, at 21:06, Surya Kasturi wrote: > I think having a quick way to go through all functions would be > useful. Similar to what OpenCV offers: Did you have a look at: http://scikit-image.org/docs/stable/api/api.html ? St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From suryak at udel.edu Sat Apr 22 00:43:18 2017 From: suryak at udel.edu (Surya Kasturi) Date: Sat, 22 Apr 2017 00:43:18 -0400 Subject: [scikit-image] Website updates In-Reply-To: <1492834078.1189411.952457400.5C3B10ED@webmail.messagingengine.com> References: <1492832950.1184511.952446144.27087BE3@webmail.messagingengine.com> <39A3CEA8-B0ED-4FD1-A66F-B1494999C7CE@udel.edu> <1492834078.1189411.952457400.5C3B10ED@webmail.messagingengine.com> Message-ID: <06FE601E-5704-4AEE-AD79-B2B5503C8EF8@udel.edu> I am thinking whether its useful to have an API index where I don?t have to scroll many a times. For instance, something like this? Best, Surya > On Apr 22, 2017, at 12:07 AM, Stefan van der Walt wrote: > > Hi Surya > > On Fri, Apr 21, 2017, at 21:06, Surya Kasturi wrote: >> I think having a quick way to go through all functions would be useful. Similar to what OpenCV offers: > > Did you have a look at: > > http://scikit-image.org/docs/stable/api/api.html > > ? > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2017-04-22 at 12.40.23 AM.png Type: image/png Size: 157064 bytes Desc: not available URL: From fboulogne at sciunto.org Sat Apr 22 01:25:48 2017 From: fboulogne at sciunto.org (=?UTF-8?Q?Fran=c3=a7ois_Boulogne?=) Date: Sat, 22 Apr 2017 07:25:48 +0200 Subject: [scikit-image] Website updates In-Reply-To: <1492832950.1184511.952446144.27087BE3@webmail.messagingengine.com> References: <1492832950.1184511.952446144.27087BE3@webmail.messagingengine.com> Message-ID: Hi Stefan, I like the box on the left. To me, the version number looks more visible. I noticed that the doc for 0.13 is missing. What happened to that one? :) Best, -- Fran?ois Boulogne. http://www.sciunto.org GPG: 32D5F22F From egor.v.panfilov at gmail.com Sat Apr 22 03:53:25 2017 From: egor.v.panfilov at gmail.com (Egor Panfilov) Date: Sat, 22 Apr 2017 10:53:25 +0300 Subject: [scikit-image] Website updates In-Reply-To: References: <1492832950.1184511.952446144.27087BE3@webmail.messagingengine.com> Message-ID: Hi Stefan, I like the new layout. Especially, the gallery looks much better now. Some remarks: 1. As Francois mentioned, 0.13 is missing from the version selector on the left; 2. Should we consider moving the `Search documentation` textbox to the header for all the pages, not just the main one? 3. As long as we have a complicated navigation ( https://github.com/scikit-image/scikit-image-web/issues/40), I'd suggest to push the changes also for the pages with documentation version 0.13. This way we'll have a single design for both stable and dev versions, and will avoid users confusion. Regards, Egor 2017-04-22 8:25 GMT+03:00 Fran?ois Boulogne : > Hi Stefan, > > I like the box on the left. To me, the version number looks more visible. > > I noticed that the doc for 0.13 is missing. What happened to that one? :) > > Best, > > -- > Fran?ois Boulogne. > http://www.sciunto.org > GPG: 32D5F22F > > > _______________________________________________ > 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 Apr 22 13:28:23 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Sat, 22 Apr 2017 10:28:23 -0700 Subject: [scikit-image] New core team member Message-ID: <1492882103.2308273.952828088.6527B7CE@webmail.messagingengine.com> Hi everyone, I'd like to welcome Greg Lee to the scikit-image core team. Greg has been a contributor to scikit-image since September 2014, and has been doing some great work on improving N-dimensional support. Greg, we're glad to have you on board, and look forward to our future collaboration! Best regards St?fan From stefanv at berkeley.edu Sat Apr 22 13:28:21 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Sat, 22 Apr 2017 10:28:21 -0700 Subject: [scikit-image] New core team member Message-ID: <1492882101.2308299.952828088.644B80B0@webmail.messagingengine.com> Hi everyone, I'd like to welcome Greg Lee to the scikit-image core team. Greg has been a contributor to scikit-image since September 2014, and has been doing some great work on improving N-dimensional support. Greg, we're glad to have you on board, and look forward to our future collaboration! Best regards St?fan From stefanv at berkeley.edu Sat Apr 22 13:28:25 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Sat, 22 Apr 2017 10:28:25 -0700 Subject: [scikit-image] New core team member Message-ID: <1492882105.2308273.952828088.5F499AAD@webmail.messagingengine.com> Hi everyone, I'd like to welcome Greg Lee to the scikit-image core team. Greg has been a contributor to scikit-image since September 2014, and has been doing some great work on improving N-dimensional support. Greg, we're glad to have you on board, and look forward to our future collaboration! Best regards St?fan From stefanv at berkeley.edu Sat Apr 22 13:33:00 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Sat, 22 Apr 2017 10:33:00 -0700 Subject: [scikit-image] Website updates In-Reply-To: References: <1492832950.1184511.952446144.27087BE3@webmail.messagingengine.com> Message-ID: <1492882380.2309122.952830312.536FA6A6@webmail.messagingengine.com> On Fri, Apr 21, 2017, at 22:25, Fran?ois Boulogne wrote: > I noticed that the doc for 0.13 is missing. What happened to that one? :) Woops, we forgot to update that with the release; done! St?fan From stefanv at berkeley.edu Sat Apr 22 13:33:53 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Sat, 22 Apr 2017 10:33:53 -0700 Subject: [scikit-image] Website updates In-Reply-To: References: <1492832950.1184511.952446144.27087BE3@webmail.messagingengine.com> Message-ID: <1492882433.2309179.952831032.67C6F1D6@webmail.messagingengine.com> On Sat, Apr 22, 2017, at 00:53, Egor Panfilov wrote: > 2. Should we consider moving the `Search documentation` textbox to the > header for all the pages, not just the main one? I'm fine with that; any objections? > 3. As long as we have a complicated navigation > (https://github.com/scikit-image/scikit-image-web/issues/40), I'd > suggest to push the changes also for the pages with documentation > version 0.13. This way we'll have a single design for both stable > and dev versions, and will avoid users confusion Agreed, I'll do that now. St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From egor.v.panfilov at gmail.com Sat Apr 22 14:36:23 2017 From: egor.v.panfilov at gmail.com (Egor Panfilov) Date: Sat, 22 Apr 2017 21:36:23 +0300 Subject: [scikit-image] New core team member In-Reply-To: <1492882105.2308273.952828088.5F499AAD@webmail.messagingengine.com> References: <1492882105.2308273.952828088.5F499AAD@webmail.messagingengine.com> Message-ID: Warm welcome to you, Gregory! Regards, Egor 2017-04-22 20:28 GMT+03:00 Stefan van der Walt : > Hi everyone, > > I'd like to welcome Greg Lee to the scikit-image core team. > > Greg has been a contributor to scikit-image since September 2014, and > has been doing some great work on improving N-dimensional support. > > Greg, we're glad to have you on board, and look forward to our future > collaboration! > > Best regards > 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 fboulogne at sciunto.org Sun Apr 23 01:41:45 2017 From: fboulogne at sciunto.org (=?UTF-8?Q?Fran=c3=a7ois_Boulogne?=) Date: Sun, 23 Apr 2017 07:41:45 +0200 Subject: [scikit-image] New core team member In-Reply-To: <1492882105.2308273.952828088.5F499AAD@webmail.messagingengine.com> References: <1492882105.2308273.952828088.5F499AAD@webmail.messagingengine.com> Message-ID: Welcome on board Greg! :) I'm looking forward working with you in the future. -- Fran?ois Boulogne. http://www.sciunto.org GPG: 32D5F22F From siqueiraaf at gmail.com Mon Apr 24 12:45:39 2017 From: siqueiraaf at gmail.com (Alexandre Fioravante de Siqueira) Date: Mon, 24 Apr 2017 13:45:39 -0300 Subject: [scikit-image] New core team member In-Reply-To: <1492882103.2308273.952828088.6527B7CE@webmail.messagingengine.com> References: <1492882103.2308273.952828088.6527B7CE@webmail.messagingengine.com> Message-ID: <1493052339.3142.1.camel@gmail.com> Hi all, welcome Greg! It's nice to have the opportunity to work with you. I'm very fond of your work in PyWavelets and wavelets in general. Thanks for that! Kind regards, Alex On Sat, 2017-04-22 at 10:28 -0700, Stefan van der Walt wrote: > Hi everyone, > > I'd like to welcome Greg Lee to the scikit-image core team. > > Greg has been a contributor to scikit-image since September 2014, and > has been doing some great work on improving N-dimensional support. > > Greg, we're glad to have you on board, and look forward to our future > collaboration! > > Best regards > St?fan > -- ----------------------------------------------------------------------- Dr. Alexandre 'Jaguar' Fioravante de Siqueira Grupo de Cronologia - Sala 12 Departamento de Raios C?smicos e Cronologia - DRCC Instituto de F?sica "Gleb Wataghin" - IFGW Unicamp - Universidade Estadual de Campinas Rua S?rgio Buarque de Holanda, 777 Cidade Universit?ria Zeferino Vaz - CEP 13083-859 Campinas - SP - Brazil Phone: +55(19)3521-5362 Lattes curriculum: http://lattes.cnpq.br/3936721630855880/ Personal site: http://www.programmingscience.org/ Github: http://www.github.com/alexandrejaguar/ Skype: alexandrejaguar Twitter: http://www.twitter.com/alexdesiqueira/ ----------------------------------------------------------------------- From siqueiraaf at gmail.com Mon Apr 24 12:58:02 2017 From: siqueiraaf at gmail.com (Alexandre Fioravante de Siqueira) Date: Mon, 24 Apr 2017 13:58:02 -0300 Subject: [scikit-image] Image Processing short course in IAMG 2017 Message-ID: <1493053082.3142.3.camel@gmail.com> Dear all, I'll present a short course in the International Association for Mathematical Geosciences (IAMG) [1] meeting, on Sep 03 [2]. This course will be given using scikit-image for processing microscopy images. If you're close, please check it out! Also, the materials will be available in [3]. Kind regards and have a nice week, Alex [1] IAMG's website: https://iamg.org/ [2] Short Course 8 in: http://iamg2017.com/courses/. [3] github's dedicated folder: https://github.com/alexandrejaguar/lectu res/tree/master/2017/iamg2017 -- ----------------------------------------------------------------------- Dr. Alexandre 'Jaguar' Fioravante de Siqueira Grupo de Cronologia - Sala 12 Departamento de Raios C?smicos e Cronologia - DRCC Instituto de F?sica "Gleb Wataghin" - IFGW Unicamp - Universidade Estadual de Campinas Rua S?rgio Buarque de Holanda, 777 Cidade Universit?ria Zeferino Vaz - CEP 13083-859 Campinas - SP - Brazil Phone: +55(19)3521-5362 Lattes curriculum: http://lattes.cnpq.br/3936721630855880/ Personal site: http://www.programmingscience.org/ Github: http://www.github.com/alexandrejaguar/ Skype: alexandrejaguar Twitter: http://www.twitter.com/alexdesiqueira/ ----------------------------------------------------------------------- From stefanv at berkeley.edu Mon Apr 24 13:48:10 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Mon, 24 Apr 2017 10:48:10 -0700 Subject: [scikit-image] Image Processing short course in IAMG 2017 In-Reply-To: <1493053082.3142.3.camel@gmail.com> References: <1493053082.3142.3.camel@gmail.com> Message-ID: <1493056090.1258046.954623584.4704A956@webmail.messagingengine.com> On Mon, Apr 24, 2017, at 09:58, Alexandre Fioravante de Siqueira wrote: > I'll present a short course in the International Association for > Mathematical Geosciences (IAMG) [1] meeting, on Sep 03 [2]. This course > will be given using scikit-image for processing microscopy images. > If you're close, please check it out! Also, the materials will be > available in [3]. Great, thanks for doing that! We'll be building up material for SciPy2017 at the usual location: https://github.com/scikit-image/skimage-tutorials Use whatever seems useful. Best regards St?fan From jni.soma at gmail.com Mon Apr 24 19:35:24 2017 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Tue, 25 Apr 2017 09:35:24 +1000 Subject: [scikit-image] Image Processing short course in IAMG 2017 In-Reply-To: <1493056090.1258046.954623584.4704A956@webmail.messagingengine.com> References: <1493053082.3142.3.camel@gmail.com> <1493056090.1258046.954623584.4704A956@webmail.messagingengine.com> Message-ID: <34906fde-b2eb-4844-8f05-8c496ab4b794@Spark> Cool! Are you stopping in Melbourne? =D On 25 Apr 2017, 3:49 AM +1000, Stefan van der Walt , wrote: > On Mon, Apr 24, 2017, at 09:58, Alexandre Fioravante de Siqueira wrote: > > I'll present a short course in the International Association for > > Mathematical Geosciences (IAMG) [1] meeting, on Sep 03 [2]. This course > > will be given using scikit-image for processing microscopy images. > > If you're close, please check it out! Also, the materials will be > > available in [3]. > > Great, thanks for doing that! > > We'll be building up material for SciPy2017 at the usual location: > > https://github.com/scikit-image/skimage-tutorials > > Use whatever seems useful. > > Best regards > 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 cedric.espenel at gmail.com Tue Apr 25 15:31:58 2017 From: cedric.espenel at gmail.com (Cedric Espenel) Date: Tue, 25 Apr 2017 12:31:58 -0700 Subject: [scikit-image] Segmentation Message-ID: Hi everyone, I work on a project where I try to track cell and cell division over-time. If cells are well separated, a simple watershed is fine, however, if cells start to overlap it doesn't work anymore. If I had another step using random walker followed by a "join_segmentations" I can split touching cells as in follow: ? ?So my foreground (the cells) were split in 3 which is what I want, but my background is also split. I might be missing something, but is there an easy way to "unify" my background, while keeping the foreground segmentation? Best, Cedric -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cell_to_segment.png Type: image/png Size: 66099 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cell_to_segment_denoised_ws.png Type: image/png Size: 9665 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cell_to_segment_denoised_join.png Type: image/png Size: 9092 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cell_to_segment_denoised_rw.png Type: image/png Size: 10122 bytes Desc: not available URL: From espenel at stanford.edu Tue Apr 25 17:10:02 2017 From: espenel at stanford.edu (Cedric Espenel) Date: Tue, 25 Apr 2017 21:10:02 +0000 Subject: [scikit-image] Segmentation Message-ID: Hi, Sorry, I guess I can just mask the result with the watershed segmentation. I guess I wonder if it is the proper way to do it? And also, from your point of view, if it's the way to go to segment these cells or if you think of a better way? Cedric From brian.perea at berkeley.edu Tue Apr 25 15:58:16 2017 From: brian.perea at berkeley.edu (Brian Perea) Date: Tue, 25 Apr 2017 19:58:16 +0000 Subject: [scikit-image] Segmentation In-Reply-To: References: Message-ID: Hey Cedric, Have you thought of applying the background mask from the simple watershed to the final split mask? It seems that you should expect your foreground and background areas to be constant, so you should be able to create a boolean background mask (in code: > boolean_mask = watershed_mask == bg_label) from the first segmentation step and multiply the boolean mask by your split mask (> final_mask = boolean_mask * split_mask). This should preserve the foreground labels and set the background to zero uniformly. Best wishes, Brian On Tue, Apr 25, 2017 at 12:37 PM Cedric Espenel wrote: > Hi everyone, > > I work on a project where I try to track cell and cell division over-time. > If cells are well separated, a simple watershed is fine, however, if cells > start to overlap it doesn't work anymore. > > If I had another step using random walker followed by a > "join_segmentations" I can split touching cells as in follow: > > > > > > ? > ?So my foreground (the cells) were split in 3 which is what I want, but my > background is also split. I might be missing something, but is there an > easy way to "unify" my background, while keeping the foreground > segmentation? > > Best, > > Cedric > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: cell_to_segment.png Type: image/png Size: 66099 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cell_to_segment_denoised_ws.png Type: image/png Size: 9665 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cell_to_segment_denoised_join.png Type: image/png Size: 9092 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cell_to_segment_denoised_rw.png Type: image/png Size: 10122 bytes Desc: not available URL: From noflaco at gmail.com Wed Apr 26 23:14:03 2017 From: noflaco at gmail.com (Carlton Banks) Date: Thu, 27 Apr 2017 05:14:03 +0200 Subject: [scikit-image] Convert data to image and then image to numpy.ndarray Message-ID: <83E74183-6B6F-41BF-A834-31875D6E9606@gmail.com> Is it possible to convert a data set stored as a numpy.ndarray -> plot the data with a colormap , possibly cm.jet. -> and then store the image pixels to a numpy.ndarray. The data array of the image should have the same shape of the data array used to make the array. The image conversion is only used for getting a visual representation of the data, and normalise it using the cm.jet. So I actually just interested in the RGB values of the colormap normalised input data. IS this possible? From stefanv at berkeley.edu Thu Apr 27 15:38:15 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Thu, 27 Apr 2017 12:38:15 -0700 Subject: [scikit-image] Convert data to image and then image to numpy.ndarray In-Reply-To: <83E74183-6B6F-41BF-A834-31875D6E9606@gmail.com> References: <83E74183-6B6F-41BF-A834-31875D6E9606@gmail.com> Message-ID: <1493321895.2950589.958572800.76610932@webmail.messagingengine.com> Hi Carlton On Wed, Apr 26, 2017, at 20:14, Carlton Banks wrote: > Is it possible to convert a data set stored as a numpy.ndarray -> plot > the data with a colormap , possibly cm.jet. -> and then store the image > pixels to a numpy.ndarray. I hope you're not using jet ;) But here's an example: In [8]: from matplotlib.cm import viridis In [9]: import numpy as np In [10]: image = np.random.random((10, 10)) In [11]: image_mapped = viridis(image) In [12]: image_mapped.min(), image_mapped.max(), image_mapped.shape Out[12]: (0.031496999999999997, 1.0, (10, 10, 4)) Best regards St?fan From Sofiia.Kosovan at reicofil.com Fri Apr 28 04:03:01 2017 From: Sofiia.Kosovan at reicofil.com (Kosovan,Sofiia) Date: Fri, 28 Apr 2017 08:03:01 +0000 Subject: [scikit-image] GLCM with scikit-image Message-ID: <0C3F834BAA52B34DB8415DEF6077BA053FAC4581@VM-Server78.local.reifenhauser.com> Dear Neil, I have found your post from 2013 about the graycomatrix implementation differences in Matlab and Python. I would ask you few questions. Please reply. Best regards, Sofiia Kosovan Reifenh?user Reicofil GmbH & Co. KG Spicher Stra?e 46, 53844 Troisdorf, Germany Registergericht Siegburg, Reg.Nr. HR A 4534 USt-IdNr. DE 814359351, Steuer-Nr. 5220/5760/0426 Reifenh?user Reicofil Verwaltungs-GmbH Registergericht Siegburg, Reg.Nr. HR B 788 Gesch?ftsf?hrer: Dr.-Ing. Bernd Kunze Please note: This message may contain information which is privileged, confidential and proprietary. -------------- next part -------------- An HTML attachment was scrubbed... URL: From suryak at udel.edu Fri Apr 28 14:02:35 2017 From: suryak at udel.edu (Surya Kasturi) Date: Fri, 28 Apr 2017 14:02:35 -0400 Subject: [scikit-image] Using EllipseModel Message-ID: Hi, I?m trying to use skimage.measure.EllipseModel to estimate an ellipse around a contour. The results seems to be not so satisfying. I am wondering if I am using ?orientation? parameter correctly. Could anyone please let me know whether ?theta? is in radians or degrees? / I am doing anything wrong? from skimage.measure import EllipseModel # create ellipse model ellipse = EllipseModel() ellipse.estimate(cnt) xc, yc, a, b, theta = np.array(ellipse.params, dtype=int) # find perimeter rr, cc = draw.ellipse_perimeter(xc, yc, a, b, orientation=theta) # plot ax.scatter(cc, rr, s=5, label="EllipseModel?) Thank you, Surya -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: plt.png Type: image/png Size: 56396 bytes Desc: not available URL: From stefanv at berkeley.edu Fri Apr 28 15:39:54 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Fri, 28 Apr 2017 12:39:54 -0700 Subject: [scikit-image] Using EllipseModel In-Reply-To: References: Message-ID: <1493408394.1910667.959749680.43B38704@webmail.messagingengine.com> It may well be that those two functions use opposite directions for theta. Do you mind filing an issue? Thanks St?fan On Fri, Apr 28, 2017, at 11:02, Surya Kasturi wrote: > Hi, > > I?m trying to use skimage.measure.EllipseModel to estimate an ellipse > around a contour. The results seems to be not so satisfying. I am > wondering if I am using ?orientation? parameter correctly.> > Could anyone please let me know whether ?theta? is in radians or > degrees? / I am doing anything wrong?> > from skimage.measure import EllipseModel > > # create ellipse model > ellipse = EllipseModel() > ellipse.estimate(*cnt*) > > xc, yc, a, b, theta = np.array(ellipse.params, dtype=int) > > # find perimeter > rr, cc = draw.ellipse_perimeter(xc, yc, a, b, *orientation=theta)* > > # plot > ax.scatter(cc, rr, s=5, label="EllipseModel?) > > > > > > Thank you, > Surya > > _________________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: plt.png Type: image/png Size: 56396 bytes Desc: not available URL: