Mailman 3 April 2015 - scikit-image

Object detection in images (HOG)
by Snowflake 23 Apr '15

23 Apr '15

Hi! I am new to machine learning and I need some help. I want to detect objects inside cells of microscopy images. I have a lot of annotated images (app. 50.000 images with an object and 500.000 without an object). So far I tried to extract features using HOG and classifying using logistic regression and LinearSVC. I have tried several parameters for HOG or color spaces (RGB, HSV, LAB) but I don't see a big difference, the predication rate is about 70 %. I have several questions. How many images should I use to train the descriptor? How many images should I use to test the prediction? I have tried with about 1000 images for training, which gives me 55 % positive and 5000, which gives me about 72 % positive. However, it also depends a lot on the test set, sometimes a test set can reach 80-90 % positive detected images. Here are two examples containing an object and two images without an object: Object01 <http://labtools.ipk-gatersleben.de/ML/with_object01.jpg> object02 <http://labtools.ipk-gatersleben.de/ML/with_object03.jpg> cell01 <http://labtools.ipk-gatersleben.de/ML/cell01.jpg> cell02 <http://labtools.ipk-gatersleben.de/ML/cell02.jpg> Another problem is, sometimes the images contain several objects: objects <http://labtools.ipk-gatersleben.de/ML/with_object02.jpg> Should I try to increase the examples of the learning set? How should I choose the images for the training set, just random? What else could I try? Any help or tips would be very appreciated, thank you very much in advance!

2 2

Re: Website designer volunteer
by Stefan van der Walt 22 Apr '15

22 Apr '15

Hi Tony On 2015-03-27 23:01:01, Tony Yu <tsyu80(a)gmail.com> wrote: > Do you have some ideas for what improvements you're looking for? Sorry, I seem to have missed your reply! Yes, I am looking for someone to work on the readability of the docs (stylesheet + font design) and to look at the structure of the site overall (making sure important information is easily accessible, etc.). If you know of someone, or if you are interested yourself, please let me know! Thanks Stéfan > On Wed, Mar 25, 2015 at 9:09 PM, Stéfan van der Walt > <stefanv(a)berkeley.edu> > wrote: > >> Hi folks, >> >> I know it's a bit of a long shot, but I'd like to find a >> volunteer to work on the layout and readability of our website. >> >> If you know of anyone interested in doing design work the same >> way we do software development, please let me know. They will >> have to be able to work with our current workflow, so good >> technical chops are a must. >> >> Thanks, Stéfan

1 0

speed of iradon transform
by Matthew Newville 20 Apr '15

20 Apr '15

Hi, Some time ago, I raised Issue #929 on github about the interpolation step in skimage.transforms.radon_transform.iradon being too slow. After some on-and-off investigation, I found two opportunities to speed this up. First, numpy's linear interpolation routine interp() was very slow for repeated interpolations of well-ordered input -- this is now fixed in the github master repo for numy, and gives roughly a 3x to 4x speed-up. Second, the trigonometric calculations can be cached when doing repeated calls to iradon() for the same geometry (image size, number of angles). This can give another factor of 1.5 to 2.0x speed-up. This is PR #1474. Some preliminary timing results: Python2.7.8 (linux), with an image shape of (500, 500), and sinogram shape of (500, 361). I used iradon() options of dict(filter='shepp-logan', interpolation='linear') and tried both circle=True and False. The "workspace?" column here indicates whether the iradon_workspace() function introduced in PR1474 was used. with circle=True: numpy skimage workspace? Best, Worst of 5 (s) |---------+-----------+------------+---------------------| 1.9.2 master N/A 6.085 6.132 master master N/A 1.784, 1.813 master PR1474 No 1.788, 1.809 master PR1474 Yes 1.103, 1.160 |---------+-----------+------------+---------------------| with circle=False: numpy skimage workspace? Best, Worst of 5 (s) |---------+-----------+------------+---------------------| 1.9.2 master N/A 2.736, 2.767 master master N/A 0.820, 0.831 master PR1474 No 0.802, 0.814 master PR1474 Yes 0.535, 0.540 |---------+-----------+------------+---------------------| That is, the cumulative improvement is about 5x. Also note that not using the workspace reverts to the older behavior, and that using he workspace for 1 run of iradon() has basically no improvement over not using the workspace. Oddly, iradon() is now faster than radon() on this machine/image size (radon() takes about 3.5 sec). I don't understand why that would be. Anybody understand why radon() is so slow? Cheers, --Matt Newville

2 1

reconstruct image after preprocessing
by souZou 13 Apr '15

13 Apr '15

Hello, Im beginner, I have an image which i done a preprocessing with sklearn img_scaled = preprocessing.scale(img) my question how can reconstrcut my original image just from img_scaled?? is it possible or no?? is there a function that ensures the reverse of preprocessing.scale??? Thx for replay.

2 1

Fast(er) Radon Transform
by Ross McKinney 13 Apr '15

13 Apr '15

Hello All, Does anyone know of a more efficient way to implement the skimage.transform.radon() function? Here are some comparisons of computation times for an image that is 384 x 512 pixels: Python (scikit_image-0.10.1-py2.7-macosx-10.5-x86_64): skimage.transform.radon(image) -- 4.295662 sec MATLAB (R2014a): radon(image) -- 0.204158 sec I am trying to rotationally align a large series of images (>10,000) by taking their radon projections and then converting them into the frequency domain. Unfortunately, this is going to take a really long time using the current implementation of the radon() function. I've started to take a look at the code myself, but I'm not an expert on the subject. Also, if there are any alternative methods of rotational alignment (that are computationally efficient), I'd love to hear them! Thanks for the help/input, -Ross

2 1

Multiple peaks with peak_local_max
by Forest Applied Remote Sensing RG (FARS) 10 Apr '15

10 Apr '15

Hi, I'm trying to use peak_local_max for tree detection. The only problem is that I keep getting multiple peaks (image attached). I tried already a combination of different filters but no success. Can anyone help me out? Thank you

3 6

regionprops - displaying region properties
by ciaran.robb＠googlemail.com 07 Apr '15

07 Apr '15

Hello everyone, I have recently been attempting to modify some existing skimage code to display regionprops for a labeled image (e.g. area or eccentricity) I initially tried to translate a vectorized bit of old matlab code I had, but gave up on that and decided to alter the existing label2rgb skimage function I am attempting to change each label value to it's area property value similar to the label2rgb "avg" function. so I have: labels = a labeled image out = np.zeros_like(labels) #a blank array labels2 = np.unique(labels) #a vector of label vals out = np.zeros_like(labels) Props = regionprops(labels, ['Area']) bg_label=0 bg = (labels2 == bg_label) if bg.any(): labels2 = labels2[labels2 != bg_label] out[bg] = 0 for label in labels2: mask = (labels == label).nonzero() color = Props[label].area out[mask] = color but the "out" props image does not correspond to the correct area values? Can anyone help me with this? It also throws the following error: "list index out of range" It would certainly be useful to have a way to view the spatial distribution of label properties in this way - perhaps in a future skimage version?

3 7

Re: GSoC: Rewriting scipy.ndimage in Cython
by AMAN singh 04 Apr '15

04 Apr '15

Hi everyone @Jaime Thanks for the suggestion. This is really a great idea I will follow this excellent strategy while rewriting the module. @Stefanv I was not able to add the suggestions of Jaime since my proposal was locked . Can you please allow me revise my proposal? I want to include Jaime's suggestion in it. Regards, Aman Singh > That sounds about right. I think that breaking down the schedule to what > function will be ported what week is little more than wishful thinking, and > that keeping things at the file level would make more sense. But I think > you are getting your proposal there. > > One idea that just crossed my mind: checking your implementation of the > iterators and other stuff in support.c for correctness and performance is > going to be an important part of the project. Perhaps it is a good idea to > identify, either now or very early on the project, a few current ndimage > top level functions that use each of those objects, if possible without > interaction with the others, and build a sequence that could look something > like (I am making this up in a hurry, so don't take the actual function > names proposed too seriously, although they may actually make sense): > > Port NI_PointIterator -> Port NI_CenterOfMass, benchmark and test > Port NI_LineBuffer -> Port NI_UniformFilter1D, benchmark and test > ... > > This would very likely extend the time you will need to implement all the > items in support.c. But by the time you were finished with that we would > both have high confidence that things were going well, plus a "Rosetta > Stone" that should make it a breeze to finish the job, both for you and > anyone else. We would also have an intermediate milestone (everything in > support ported plus a working example of each being used, with correctness > and performance verified), that would be a worthy deliverable on its own: > if we are terribly miscalculating task duration, and everything slips and > is delayed, getting there could still be considered a success, since it > would make finishing the job for others much, much simpler. > > One little concern of mine, and the questions don't really go to Aman, but > to the scipy devs: the Cython docs on fused types have a big fat warning at > the top on support still being experimental. Also, this is going to bump > the version requirements for Cython to a very recent one. Are we OK with > this? > > Similarly, you suggest using Cython's prange to parallelize computations. > I haven't seen OpenMP used anywhere in NumPy or SciPy, and have the feeling > that parallel implementations are left out on purpose. Am I right, or would > parallelizing were possible be OK? > > Jaime > > -- > (\__/) > ( O.o) > ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes > de dominación mundial. >

1 0

Re: Range of beta values in segmentation algorithm?
by Yuta Sato 04 Apr '15

04 Apr '15

Thanks Emmanuelle Gouillart for describing me all the hack! On Sat, Apr 4, 2015 at 10:22 PM, Emmanuelle Gouillart < emmanuelle.gouillart(a)normalesup.org> wrote: > Hi Yuta, > > beta has to take a positive value. In the algorithm, the weight on a graph > edge is given by exp(- beta * diff) where diff is the absolute value of > pixels differences on both sides of the edge. Furthermore, the value of > beta you give is normalized by ten times the standard deviation of the > image, so that you don't have to worry about the image range (I know this > sounds a bit weird, but that's how it's coded. I might even be responsible > for this hack :-). > > Therefore, if you put a large value of beta there will be a very small > weight on edges for which pixels have different values, and diffusion will > be difficult. On the other hand, for small values diffusion will be easy > and regions will be "flooded" for markers, no matter the gradients. A > larger value of beta means that boundaries are more likely to lie on pixels > with a strong gradient. I would advise that you start with a small value of > beta (1 for example) and look at the result. If you feel like boudaries are > "leaky" it means that diffusion is too fast and you should increase beta. > > Hope this helps > Emma > > > > 2015-04-04 14:58 GMT+02:00 Juan Nunez-Iglesias <jni.soma(a)gmail.com>: > >> Hi Yuta, >> >> Sorry, this slipped through the cracks. I haven't used random walker >> segmentation so I can't give you advice here... You might want to read the >> original publication [1], or, more practically, try out different betas on >> a logarithmic scale. >> >> Juan. >> >> [1] http://webdocs.cs.ualberta.ca/~nray1/CMPUT615/MRF/grady2006random.pdf >> >> >> >> >> On Sat, Apr 4, 2015 at 12:56 AM, Yuta Sato <yutaxsato(a)gmail.com> wrote: >> >>> >>> Dear skimage developers: >>> I would really appreciate to hear the answer on my question if it does >>> worth. >>> >>> Thanks >>> >>> On Thu, Mar 12, 2015 at 4:04 PM, Yuta Sato <yutaxsato(a)gmail.com> wrote: >>> >>>> In the following skimage.segmentation.random_walker algorithm: >>>> What is the range of 'beta' values that can be supplied? >>>> I am working with a single band 8bit unsigned image. >>>> >>>> Is it 0 to 255? >>>> >>>> >>>> skimage.segmentation.random_walker(data, labels, beta=130, mode='bf', >>>> tol=0.001, copy=True,multichannel=False, return_full_prob=False, >>>> spacing=None) >>>> >>>> beta : float [Penalization coefficient for the random walker motion >>>> (the greater beta, the more difficult the diffusion)] >>>> >>>> Thanks for your support. >>>> >>> >>> -- >>> 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/d/optout. >>> >> >> -- >> 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/d/optout. >> > > -- > 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/d/optout. >

1 0

Re: Apply segmentation to a large binary image
by Juan Nunez-Iglesias 04 Apr '15

04 Apr '15

Hey Yuta, I'm not sure how much h5py mirrors the numpy array interface, but I suspect not sufficiently to allow C/Cython functions to work. I think you'll need to find a clever way to partition your image to get the right result, because although you can use numpy.memmap [1] to use an on-disk array, I think that might be far too slow (since binary fill holes uses quite a few iterations... Juan. [1] http://docs.scipy.org/doc/numpy/reference/generated/numpy.memmap.html On Sat, Apr 4, 2015 at 12:54 AM, Yuta Sato <yutaxsato(a)gmail.com> wrote: > Dear Juan Nunez-Iglesias and Josh Warner: > Thanks for your kind responses. > Lets take a more simpler case, e.g., binary_fill_holes. > I want to apply to the WHOLE image at once, because if I apply it in the > parts of image and later combine, the result differs. > Does putting the image into hdf5 and applying the binary_fill_holes solve > my problem? > Can I really apply binary_fill_holes to hdf5 file? > Thanks for your helps. > Yuta > On Sun, Mar 15, 2015 at 10:18 AM, Juan Nunez-Iglesias <jni.soma(a)gmail.com> > wrote: >> Josh, you might be thinking of morphology.remove_small_objects, but that >> is O(image.size), rather than O(sum(image == label)), which is what you are >> after. In fact we would need a flood-fill algorithm, which we don't have... >> That would be a fantastic addition. >> >> >> >> >> On Sun, Mar 15, 2015 at 10:24 AM, Josh Warner <silvertrumpet999(a)gmail.com> >> wrote: >> >>> Would it be possible to generalize / refactor `clear_border` to a >>> function which removes all points connected to a specific pixel/voxel? That >>> would greatly simplify the work needed here. >>> >>> I thought we had some sort of `remove_object` functionality like this, >>> but I don't see it. >>> >>> Josh >>> >>> On Friday, March 13, 2015 at 9:04:12 PM UTC-5, Juan Nunez-Iglesias wrote: >>>> >>>> Hey Yuta, >>>> >>>> You'll need to do some stitching out-of-core. That's a really tricky >>>> problem and I don't have any ready-made solutions for you. The solution >>>> will depend on the nature of your segments. The only thing I would >>>> recommend is that you use a format such as HDF5 (you can use the excellent >>>> h5py library) that allows random access into the underlying disk data. >>>> >>>> Other than that, as I said, to my knowledge you'll have to develop your >>>> own stitching: segment *overlapping* tiles independently in memory, and >>>> when it comes time to write to disk, load the tile and overlapping tiles >>>> that have already been segmented, and resolve label mapping then... >>>> >>>> Generally, think of it this way: tile i has already been segmented and >>>> written out. We now want to write out tile j, which overlaps tile i. Labels >>>> from tile i that intersect labels from tile j in the overlap region should >>>> be matched. labels in tile j that *don't* intersect tile i should be >>>> relabelled to ensure they are unique with respect to tile i. >>>> >>>> Of course this gets a bit more complicated in 2D or 3D... >>>> >>>> Juan. >>>> >>>> >>>> >>>> >>>> On Fri, Mar 13, 2015 at 7:20 PM, Yuta Sato <yutaxsato(a)gmail.com> wrote: >>>> >>>>> Dear SKIMAGE Developers and Users: >>>>> >>>>> I want to use the following algorithm in a large binary image that does >>>>> not fit into my PC memory. So, I am thinking to split my large image into >>>>> tiles and apply algorithm one by one. However, the original border >>>>> definition change when I do it in parts. I need the result as applied in >>>>> original full image. How can I do it efficiently? >>>>> >>>>> skimage.segmentation.clear_border(image, buffer_size=0, bgval=0) >>>>> >>>>> Thanks for your ideas. >>>>> >>>>> -- >>>>> 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/d/optout. >>>>> >>>> >>>> -- >>> 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/d/optout. >>> >> >> -- >> 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/d/optout. >> > -- > 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/d/optout.

2 1