Mailman 3 June 2013 - scikit-image

how to highlight/shade a segment in an image.
by Brickle Macho June 29, 2013

June 29, 2013

I over segment an image using a superpixel algorithm. I region grow using the superpixels to end up with a segmented image, a label-image. I overlay the label boundaries using mark_boundaries(). I can click on a segment/region and indicate it as either foreground or background. This foreground/background information is maintained in a python dict. How can I provide visual feedback, say tinting the clicked segment, in the image. Short version, given a label, a lable-image and a image, how do I shade/tint the label area. Thanks, Michael. --

3 2

Re: how to highlight/shade a segment in an image.
by Andreas Mueller June 29, 2013

June 29, 2013

On 06/21/2013 06:44 AM, Tony Yu wrote: > > > > On Thu, Jun 20, 2013 at 10:44 PM, Brickle Macho > <bricklemacho(a)gmail.com <mailto:bricklemacho@gmail.com>> wrote: > > On 21/06/13 7:03 AM, Tony Yu wrote: >> >> Short version, given a label, a lable-image and a image, how do I >> shade/tint the label area. >> >> >> You could try out the label2rgb PR: >> >> https://github.com/scikit-image/scikit-image/pull/485 > > Thanks. Look interesting. How do I try/pull/incorporate > label2rgb code? > > I know this reply is a bit late, still, I thought it might be useful. I usually do it using matplotlib and the alpha setting of imshow. I just plot an image and then plot the segments using some alpha value. That works quite well. Hth, Andy

1 0

Re: Algorithm to 'walk' along a line from an endpoint by N pixels
by Anders Klint June 28, 2013

June 28, 2013

Hi all, Just some thoughts and a question: On 28 jun 2013, at 18:51, Stéfan van der Walt <stefan(a)sun.ac.za> wrote: > Hi Robin > > On Fri, Jun 28, 2013 at 11:26 AM, Robin Wilson > <r.t.wilson.bak(a)googlemail.com> wrote: >> Thanks for the really quick reply. I'm not sure how I can use the label >> function to do what I want. I have the image shown in the numpy array below: >> >> array([[0, 0, 1, 1, 0], >> [0, 0, 1, 0, 0], >> [0, 1, 1, 0, 0], >> [0, X, 0, 0, 0], >> [0, 0, 0, 0, 0]]) > > Right, so the label function will just identify the pixels, and then > perhaps you can do something like this: > > http://stackoverflow.com/questions/8686926/python-image-processing-help-nee… > Could it help to use the endpoints identified as suggested above as background, calculate a distance transform and mask that with the initial line? That should give you lines with values corresponding to the distance from the endpoints, right? Locate the wanted distance values and you should have your pixels. In practice, you may have to do that on a line at a time to avoid "interference" from other lines, it may not be efficient, but in general I think this could work. Or? However, the only mention of distance transform I find in the docs is an optional parameter to morphology.medial_axis... Is there no distance transform in skimage, or is this the one in a (for me, at least) unexpected place? /Anders > Stéfan > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > >

2 1

Re: Algorithm to 'walk' along a line from an endpoint by N pixels
by Robin Wilson June 28, 2013

June 28, 2013

Hi Stefan, Thanks for the really quick reply. I'm not sure how I can use the label function to do what I want. I have the image shown in the numpy array below: array([[0, 0, 1, 1, 0], [0, 0, 1, 0, 0], [0, 1, 1, 0, 0], [0, X, 0, 0, 0], [0, 0, 0, 0, 0]]) I'd like to start at the pixel that is marked with an X (it has a value of 1 really, but I've just marked it in this post as an example), and then find the pixel that is n pixels further down the line than that. So, for example, with n=3 I'd get the pixel marked with E below. array([[0, 0, 1, 1, 0], [0, 0, E, 0, 0], [0, 1, 1, 0, 0], [0, X, 0, 0, 0], [0, 0, 0, 0, 0]]) I can't see how the label function will do that (although it will let me extract just the line I want to work on - which will be handy as a first step), but I may well be entirely wrong. If the label function won't, is there any other function, or group of functions, that would help me do that? Cheers, Robin On Friday, 28 June 2013 17:08:04 UTC+1, Stefan van der Walt wrote: > > Hi Robin > > It sounds like you may be able to get away with a connected component > search. Have a look at the "skimage.morphology.label". > > Stéfan > > On Fri, Jun 28, 2013 at 11:04 AM, Robin Wilson > <r.t.wil...(a)googlemail.com <javascript:>> wrote: > > Hi, > > > > Does anyone know if an algorithm to take an endpoint of a binary line in > an > > image and 'walk' back along the line for N pixels already exists in > skimage? > > (or in any of the related projects). I'm happy to go ahead and implement > it, > > but it seems like the kind of thing that would have already been > > implemented, even though I can't find it in the documentation. > > > > Does this already exist? > > > > Cheers, > > > > Robin > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "scikit-image" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to scikit-image...(a)googlegroups.com <javascript:>. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > >

2 1

Re: Inconsistent projection centre for the Radon transform
by Jostein Bø Fløystad June 27, 2013

June 27, 2013

Dear Stefan, thanks for taking the time. I will be without internet connectivity until next Thursday, so there is no rush. I'm guessing you're at SciPy; enjoy the conference! Regards Jostein 2013/6/23 Stéfan van der Walt <stefan(a)sun.ac.za> > Dear Jostein > > On Sat, Jun 22, 2013 at 10:31 AM, <jostein.floystad(a)gmail.com> wrote: > > 2. Alert any users that have based results on this code to check them > > carefully for systematic errors. If the radon_transform module has been > used > > for tomography simulations, it is quite likely that the results are > > affected. In the case of using the module for reconstructing tomography > data > > obtained otherwise, the results may be affected and they may not; this > will > > depend on the specifics of the situation. > > Thank you for bringing this issue to everyone's attention. Rigorous > code review, which leads to the uncovering of such mistakes, is what > makes open source science so compelling to me. I'll review your PR, > so that we can get this fixed ASAP. > > Regards > Stéfan > > -- > You received this message because you are subscribed to the Google Groups > "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to scikit-image+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > >

1 0

Re: storing keypoints
by Jerome Kieffer June 27, 2013

June 27, 2013

On Thu, 27 Jun 2013 01:11:08 -0500 Stéfan van der Walt <stefan(a)sun.ac.za> wrote: > Hi Jerome > > On Thu, Jun 27, 2013 at 12:32 AM, Jérôme Kieffer > <google(a)terre-adelie.org> wrote: > > I am wondering what is the best way to store (in python) SIFT keypoints > > to exchange them (serialize, save, load-back, ...) SIFT is a keypoint > > extraction algorithm for images so it transforms a 2D image into > > n-keypoints; each keypoint being composed of 4floats > > (x, y, scale, orientation) and 128 uint8. > > Probably an array with elements of > > dtype = np.dtype([('x', float), ('y', float), ('scale', float), > ('orientation', float), ('feature', (np.uint8, 128))]) Thanks a lot, I didn't know this was possible with record-arrays. -- Jerome Kieffer <google(a)terre-adelie.org>

1 0

storing keypoints
by Jérôme Kieffer June 26, 2013

June 26, 2013

Dear pythonistas, I am wondering what is the best way to store (in python) SIFT keypoints to exchange them (serialize, save, load-back, ...) SIFT is a keypoint extraction algorithm for images so it transforms a 2D image into n-keypoints; each keypoint being composed of 4floats (x, y, scale, orientation) and 128 uint8. * I would like to use at best numpy machinery. * record array look indicated but the 128xuint8 block is likely to be tedious * I would like to be able to separate directly the float from uint8. Maybe nx36 float with 32 float being actually 128uint and use recordarrays and views ? Any idea? Thanks. -- Jérôme Kieffer <google(a)terre-adelie.org>

3 2

Issues with scaling images for canny edge detection
by Robin Wilson June 26, 2013

June 26, 2013

Hi, *Summary: *I'm fairly new to skimage, and I'm trying to replicate some work I've done in IDL using the Canny edge detector. I've imported the same image into skimage and tried running the Canny function with the same parameters, but I either get a blank image, or very different results to IDL which don't change regardless of the parameters I use. I suspect my problems may be related to how I am scaling my image to make it between 0 and 1, as the documentation for the skimage Canny function requires. *More details:* The input image I used in both IDL and skimage is available at https://www.dropbox.com/s/xaiq9kitrf1b4cf/HOT_sub.tif. In IDL I called the CANNY function (documentation available at http://www.exelisvis.com/docs/CANNY.html) as follows: result = CANNY(image, HIGH=0.95, LOW=0.3, SIGMA=2) and got the following image: <https://lh3.googleusercontent.com/-xwuyuH_mxEA/Ucm2Y2m2EyI/AAAAAAAAEnw/46Om…> I loaded the image into skimage as follows: hot = skimage.io.imread("HOT_sub.tif") And removed all negative values by adding the absolute value of the minimum: abs_hot = hot + abs(np.min(hot)) >From what I'd read in the documentation, the function img_as_float would then scale this between 0 and 1 in a sensible way, but it gave an error: C:\Python27\lib\site-packages\skimage\util\dtype.pyc in convert(image, dtype) 73 if kind_in == 'f': 74 if np.min(image) < 0 or np.max(image) > 1: ---> 75 raise ValueError("Images of type float must be between 0 and 1") 76 if kind == 'f': 77 # floating point -> floating point ValueError: Images of type float must be between 0 and 1 So I did it myself by simply dividing by the maximum value: im_hot = img_as_float(abs_hot/np.max(abs_hot) However, running the Canny edge detector on this image produces an entirely blank edge image: edges = canny(im_hot, sigma=2, low_threshold=0.3, high_threshold=0.90) np.sum(edges) # Gives 0 showing there are no edges found Regardless how I play with the parameters, I can't seem to get it to give me any edges. Interestingly, if I ignore the instructions to make sure that my input image is between 0 and 1, and just use the raw image: edges = canny(hot, sigma=2, low_threshold=0.3, high_threshold=0.90) I get a more sensible result (well, at least it isn't blank!): <https://lh5.googleusercontent.com/-Ta33pkF-pIY/Ucm4abti3lI/AAAAAAAAEoA/iyX6…> But this is very different to the result given by IDL - and furthermore, adjusting the parameters doesn't seem to change the output at all. What am I doing wrong here? I suspect it is something to do with the image scaling, but I'm not sure - it could be a conceptual problem with my image processing knowledge, or I could be using skimage improperly. Does anyone have any ideas or suggestions as to where to go from here? If I manage to solve this I will, of course, write up the solution on my blog so that others can benefit too. Best regards, Robin University of Southampton, UK

3 4

Re: SciPy sprint for scikit-image
by Emmanuelle Gouillart June 24, 2013

June 24, 2013

On Mon, Jun 24, 2013 at 02:30:43PM -0400, Juan Nunez-Iglesias wrote: > Wish I could come! Last year was awesome and it really changed my life — you > might remember I'd never done a PR before that sprint! =) > I'll be at EuroSciPy this year, anyone else? I'll be there! Anyone else? Emmanuelle

2 1

Graph Cuts implementation
by Marc de Klerk June 24, 2013

June 24, 2013

Hi Everyone, One of items on my todo list in first three weeks of my GSOC is to implement a CPU Graph-cuts. I've made a couple points from a preliminary literature survey and would like to get some feedback / recommendations / advice. Graph cut algorithms can generally be regarded as either begin push-relabel (PR) or augmenting paths (AP) style. - The goto algorithm has typically been the Boykov and Kolmogorov algorithm (AP) [1] - The current state-of-art graph-cut is packaged as GridCut, product of [2] - Based on [1] - Multi core (from [3]) - Cache efficient memory layout (from [2]) - For grid-like topologies - A push relabel variant exists from [4] - Multi core (from [3]) - Not bound by memory constraints - For grid-like topologies - From what I can gather BK typically outperforms other approaches such as the push-relabel algorithm, but to what extent I'm can't tell from the literature… - [4] describes memory layout strategies to optimize caching for both AP and PR style algorithms, but that choose the implement their strategies on BK. - PR style algorithms are not limited by memory constraints, whereas AP style algorithms are, however doing graph cuts on a coarse to fine scale seem to be an answer. - PR is the only feasible way to do graph cuts on the GPU. So I'm suggestions to implement the PR style algorithm of [4] using the strategies described in [2] to speed things up. This then let's us make a fairer comparison between CPU and GPU versions of the graph cut Does this sound like a good way forward? It does require some multi-core programming which I'm not familiar with - are there any examples of something similar in scikit-image? [1] Boykov, Y., & Kolmogorov, V. (2004). An experimental comparison of min-cut/max- flow algorithms for energy minimization in vision. Pattern Analysis and Machine Intelligence, IEEE Transactions on, 26(9), 1124–1137. doi:10.1109/TPAMI.2004.60 [2] Jamriska, O., Sykora, D., & Hornung, A. (2012). Cache-efficient graph cuts on structured grids (pp. 3673–3680). Presented at the Computer Vision and Pattern Recognition (CVPR), 2012 IEEE Conference on. doi:10.1109/CVPR.2012.6248113 [3] Liu, J., & Sun, J. (2010). Parallel graph-cuts by adaptive bottom-up merging (pp. 2181–2188). Presented at the Computer Vision and Pattern Recognition (CVPR), 2010 IEEE Conference on. doi:10.1109/CVPR.2010.5539898 [4] Delong, A., & Boykov, Y. (2008). A Scalable graph-cut algorithm for N-D grids (pp. 1–8). Presented at the Computer Vision and Pattern Recognition, 2008. CVPR 2008. IEEE Conference on. doi:10.1109/CVPR.2008.4587464

3 3