Mailman 3 April 2018 - scikit-image

local maxima improvements
by Yann GAVET 12 Apr '18

12 Apr '18

Dear all, I have been playing around with the watershed segmentation by markers with the code proposed as example: http://scikit-image.org/docs/dev/auto_examples/segmentation/plot_watershed.… Unfortunately, if we use for example floating values for the radii of the circles (like r1, r2 = 20.7, 24.7), the separation is not perfect, as it gives 4 labels. If we use the chamfer distance transform instead of the Euclidean distance transform, it is even worse. It appears that the markers detection by regional maximum (peak_local_max) fails in the presence of plateaus. Its algorithm is basically D(I)==I, where D is the morphological dilation. A better algorithm would be to use morphological reconstruction (see SOILLE, Pierre. /Morphological image analysis: principles and applications/. Springer Science & Business Media, 2003, p202, Eq 6.13). A proposition of the code can be the following (it should deal with float values): import numpy as np from skimage import morphology def rmax(I): """ This avoids plateaus problems of peak_local_max I: original image, float values returns: binary array, with True for the maxima """ I = I.astype('float'); I = I / np.max(I) * 2**31; I = I.astype('int32'); rec = morphology.reconstruction(I-1, I); maxima = I - rec; return maxima>0 This code is relatively fast. Notice that the matlab function imregionalmax seem to work the same way (the help is not explicit, but the results on a few tests seem to be similar). I am afraid I do not have time to integrate it on gitlab, but this should be a good start if someone wants to work on it. If you see any problem with this code, please correct it. thank you best regards -- Yann

4 7

Specify rotation centre to iradon?
by David Mills 12 Apr '18

12 Apr '18

Hello I’m trying to use skimage to reconstruct some projections from a demo optical CT system. Due to wobble in the rotation stage, the rotation centre isn’t at (image_width/2,image_height/2) but at some offset. Is there a way to specify offsets to the iradon transform? I’ve had a hunt though the mailing list and docs, but can’t see anything obvious. I’m pretty new to python, so there could well be something I’ve missed. Regards, David -- Dr. David Mills Queen Mary, University of London Dental Biophysics Section Oral Growth and Development Institute of Dentistry Francis Bancroft Building London E1 4NS UK

1 0

回复：Re: local maxima improvements
by imagepy＠sina.com 11 Apr '18

11 Apr '18

Hi，everyone I think we should not use peak_local_max for find watershed's seeds. why not use h_maxima? which can give a h tolerance.I think if we should replace it in the official demo? It would cause a misunderstanding. And scikit-image's h_maxima, h_minima is very slow. here I implements one with numba, https://github.com/Image-Py/imagepy/blob/master/imagepy/ipyalg/hydrology/fi…. you can see if it is useful. yxdragon----- 原始邮件 ----- 发件人：Stefan van der Walt <stefanv(a)berkeley.edu> 收件人："Mailing list for scikit-image (http://scikit-image.org)" <scikit-image(a)python.org> 主题：Re: [scikit-image] local maxima improvements 日期：2018年04月12日 03点08分 On Wed, 11 Apr 2018 12:44:45 +1000, Juan Nunez-Iglesias wrote: > In [7]: image > Out[7]: > array([[ 0., 0., 0., 0., 0., 0.], > [ 0., 1., 0., 0., 0., 0.], > [ 0., 0., 0., 0., 0., 0.], > [ 2., 2., 2., 4., 4., 2.], > [ 2., 2., 2., 4., 4., 2.], > [ 2., 2., 2., 2., 2., 2.]]) > > In [15]: feature.peak_local_max(image) > In [17]: image_peak[tuple(feature.peak_local_max(image).T)] = 1 > > In [18]: image_peak > Out[18]: > array([[ 0., 0., 0., 0., 0., 0.], > [ 0., 1., 0., 0., 0., 0.], > [ 0., 0., 0., 0., 0., 0.], > [ 0., 1., 0., 1., 1., 0.], > [ 0., 1., 0., 1., 1., 0.], > [ 0., 0., 0., 0., 0., 0.]]) That output in column 1 looks highly suspect! This is a great example for a regression test, thanks Yann. Stéfan _______________________________________________ scikit-image mailing list scikit-image(a)python.org https://mail.python.org/mailman/listinfo/scikit-image

1 0

Re: [scikit-image] scikit-image Digest, Vol 19, Issue 5
by Alexandre de Siqueira 10 Apr '18

10 Apr '18

Dear Yann, thank you for that. This looks really interesting; I think I faced this issue myself these months in [1]. I solved it using a terrible workaround... Could you please submit a new issue in https://github.com/scikit-image/scikit-image/issues? Meanwhile, I'll try to find Soille's book and read it, ok? Then we can start to investigate it. Thank you again. Kind regards, Alex [1] https://arxiv.org/abs/1706.03282v1 -------------------------------------------------- Dr. Alexandre 'Jaguar' Fioravante de Siqueira Grupo de Cronologia - Sala S13 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 ORCID: http://orcid.org/0000-0003-1320-4347 Personal site: http://programmingscience.org Github: http://github.com/alexandrejaguar Skype: alexandrejaguar -------------------------------------------------- Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On April 10, 2018 1:00 PM, <scikit-image-request(a)python.org> wrote: > Dear all, > > I have been playing around with the watershed segmentation by markers with the code proposed as example: > > http://scikit-image.org/docs/dev/auto_examples/segmentation/plot_watershed.… > > Unfortunately, if we use for example floating values for the radii of the circles (like r1, r2 = 20.7, 24.7), the separation is not perfect, as it gives 4 labels. > > If we use the chamfer distance transform instead of the Euclidean distance transform, it is even worse. > > It appears that the markers detection by regional maximum (peak_local_max) fails in the presence of plateaus. Its algorithm is basically D(I)==I, where D is the morphological dilation. > > A better algorithm would be to use morphological reconstruction (see SOILLE, Pierre. Morphological image analysis: principles and applications. Springer Science & Business Media, 2003, p202, Eq 6.13). A proposition of the code can be the following (it should deal with float values): > > import numpy as np > > from skimage import morphology > > def rmax(I): > > """ > > This avoids plateaus problems of peak_local_max > > I: original image, float values > > returns: binary array, with True for the maxima > > """ > > I = I.astype('float'); > > I = I / np.max(I) * 2**31; > > I = I.astype('int32'); > > rec = morphology.reconstruction(I-1, I); > > maxima = I - rec; > > return maxima>0 > > This code is relatively fast. Notice that the matlab function imregionalmax seem to work the same way (the help is not explicit, but the results on a few tests seem to be similar). > > I am afraid I do not have time to integrate it on gitlab, but this should be a good start if someone wants to work on it. If you see any problem with this code, please correct it. > > thank you > > best regards > > -- > Yann > > First mistake, this should work, but the discretization of the 'continuous' values should be handled with care. > > def rmax(I): > > """ > > Own version of regional maximum > > This avoids plateaus problems of peak_local_max > > I: original image, int values > > returns: binary array, with 1 for the maxima > > """ > > I = I.astype('float'); > > I = I / np.max(I) * (2**31 -2); > > I = I.astype('int32'); > > h = 1; > > rec = morphology.reconstruction(I, I+h); > > maxima = I + h - rec; > > return maxima > > Le 10/04/2018 à 15:35, Yann GAVET a écrit : > >> Dear all, >> >> I have been playing around with the watershed segmentation by markers with the code proposed as example: >> >> http://scikit-image.org/docs/dev/auto_examples/segmentation/plot_watershed.… >> >> Unfortunately, if we use for example floating values for the radii of the circles (like r1, r2 = 20.7, 24.7), the separation is not perfect, as it gives 4 labels. >> >> If we use the chamfer distance transform instead of the Euclidean distance transform, it is even worse. >> >> It appears that the markers detection by regional maximum (peak_local_max) fails in the presence of plateaus. Its algorithm is basically D(I)==I, where D is the morphological dilation. >> >> A better algorithm would be to use morphological reconstruction (see SOILLE, Pierre. Morphological image analysis: principles and applications. Springer Science & Business Media, 2003, p202, Eq 6.13). A proposition of the code can be the following (it should deal with float values): >> >> import numpy as np >> >> from skimage import morphology >> >> def rmax(I): >> >> """ >> >> This avoids plateaus problems of peak_local_max >> >> I: original image, float values >> >> returns: binary array, with True for the maxima >> >> """ >> >> I = I.astype('float'); >> >> I = I / np.max(I) * 2**31; >> >> I = I.astype('int32'); >> >> rec = morphology.reconstruction(I-1, I); >> >> maxima = I - rec; >> >> return maxima>0 >> >> This code is relatively fast. Notice that the matlab function imregionalmax seem to work the same way (the help is not explicit, but the results on a few tests seem to be similar). >> >> I am afraid I do not have time to integrate it on gitlab, but this should be a good start if someone wants to work on it. If you see any problem with this code, please correct it. >> >> thank you >> >> best regards >> >> -- >> Yann >> >> _______________________________________________ >> scikit-image mailing list >> scikit-image(a)python.org >> >> https://mail.python.org/mailman/listinfo/scikit-image > > -- > Yann GAVET > Assistant Professor - Ecole Nationale Supérieure des Mines de Saint-Etienne > 158 Cours Fauriel, CS 62362, 42023 SAINT-ETIENNE cedex 2 > Tel: (33) - 4 7742 0170

1 0

Re: [scikit-image] data types
by Juan Nunez-Iglesias 09 Apr '18

09 Apr '18

Thanks everyone! I've made a "master issue" to track progress on this: https://github.com/scikit-image/scikit-image/issues/3009 Let's continue the discussion there. If anyone wants to tackle anything in the to-do list, we would be very grateful! skimage will be a much nicer package when all those tick-boxes are ticked. =) Juan. On Sun, Apr 8, 2018, at 9:48 PM, David Sarma wrote: > In compositing in visual effects, dealing with many widely varying > image and data formats used to be a common problematic issue, but for > the most part it is not much of an issue anymore. Maybe the > resolution in that domain can give you some ideas for how to deal > with this issue:> > Guessing about the intent of the user was common at one point, but > generally led to a lot of frustration, particularly so when the > operation that the user needs to perform is different from what s/he > needs to view in order to judge the correctness of the outcome. "Data > images" need to remain untouched, and it is very frustrating to have > any mysterious conversions taking place behind the scenes (automatic > gamma correction in particular was the key issue that caused so many > problems). On the other hand, it is also frustrating to get black > images, and not know what is happening.> > The resolution of this issue took the form of the split of viewer from > operation. If you have a clear separation of operations that are > intended to assist the user in making visual judgement, then you are > at liberty to guess at "magic" transformations. Meanwhile, you lend > clarity to the idea that, wrt the actual image data, nothing will > happen unless the user explicitly asks for it. It's easy to lose trust > in tools when magic operations start taking place behind the scenes, > even if they are well-documented.> > It may also be worth considering that, presenting things as error > messages or warnings when they are just information that's necessary > to do legitimate work, can wind up being somewhat off-putting. It is > common, for example, to drastically exaggerate a correction that will > later be brought back into range at a different stage in the > computation. In compositing packages (like Nuke for example), there's > a lot of information that's persistently displayed to you, that you > need available to do the basic work of building up a computation. I > tried a while ago to see if it might be possible to use the Orange > Data Mining interface to get something resembling an image processing > setup. I set it aside, but it did at least seem to have the right mix > of components such that a working setup would be imaginable with some > effort. Having immediate feedback on what are not actually errors but > rather necessary steps in understanding and building up a computation > might reduce the need to rely on documentation, which in this case > might be standing in for the information that you would get from a > tighter feedback loop.> > -David > > On Fri, Apr 6, 2018 at 9:44 PM, Juan Nunez-Iglesias > <jni(a)fastmail.com> wrote:>> On Sat, Apr 7, 2018, at 10:36 AM, Stefan van der Walt wrote: >> > Agreed, I don't think anyone ever uses uint32 for images. >> > Typically 16, but perhaps also 64? >> >> What I'm arguing is that if anyone takes a 64-bit image and converts >> it to float, they are *not* after their image divided by 2**64.>> >> _______________________________________________ >> scikit-image mailing list >> scikit-image(a)python.org >> https://mail.python.org/mailman/listinfo/scikit-image > > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Phone 917 375 8730 > Email david(a)davidsarma.org > Web http://www.davidsarma.org > _________________________________________________ > scikit-image mailing list > scikit-image(a)python.org > https://mail.python.org/mailman/listinfo/scikit-image

1 0

Re: [scikit-image] data types
by David Sarma 08 Apr '18

08 Apr '18

In compositing in visual effects, dealing with many widely varying image and data formats used to be a common problematic issue, but for the most part it is not much of an issue anymore. Maybe the resolution in that domain can give you some ideas for how to deal with this issue: Guessing about the intent of the user was common at one point, but generally led to a lot of frustration, particularly so when the operation that the user needs to perform is different from what s/he needs to view in order to judge the correctness of the outcome. "Data images" need to remain untouched, and it is very frustrating to have any mysterious conversions taking place behind the scenes (automatic gamma correction in particular was the key issue that caused so many problems). On the other hand, it is also frustrating to get black images, and not know what is happening. The resolution of this issue took the form of the split of viewer from operation. If you have a clear separation of operations that are intended to assist the user in making visual judgement, then you are at liberty to guess at "magic" transformations. Meanwhile, you lend clarity to the idea that, wrt the actual image data, nothing will happen unless the user explicitly asks for it. It's easy to lose trust in tools when magic operations start taking place behind the scenes, even if they are well-documented. It may also be worth considering that, presenting things as error messages or warnings when they are just information that's necessary to do legitimate work, can wind up being somewhat off-putting. It is common, for example, to drastically exaggerate a correction that will later be brought back into range at a different stage in the computation. In compositing packages (like Nuke for example), there's a lot of information that's persistently displayed to you, that you need available to do the basic work of building up a computation. I tried a while ago to see if it might be possible to use the Orange Data Mining interface to get something resembling an image processing setup. I set it aside, but it did at least seem to have the right mix of components such that a working setup would be imaginable with some effort. Having immediate feedback on what are not actually errors but rather necessary steps in understanding and building up a computation might reduce the need to rely on documentation, which in this case might be standing in for the information that you would get from a tighter feedback loop. -David On Fri, Apr 6, 2018 at 9:44 PM, Juan Nunez-Iglesias <jni(a)fastmail.com> wrote: > On Sat, Apr 7, 2018, at 10:36 AM, Stefan van der Walt wrote: > > Agreed, I don't think anyone ever uses uint32 for images. Typically 16, > > but perhaps also 64? > > What I'm arguing is that if anyone takes a 64-bit image and converts it to > float, they are *not* after their image divided by 2**64. > _______________________________________________ > scikit-image mailing list > scikit-image(a)python.org > https://mail.python.org/mailman/listinfo/scikit-image > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Phone 917 375 8730 Email david(a)davidsarma.org Web http://www.davidsarma.org

1 0

Re: [scikit-image] data types
by Juan Nunez-Iglesias 06 Apr '18

06 Apr '18

On Sat, Apr 7, 2018, at 10:36 AM, Stefan van der Walt wrote: > Agreed, I don't think anyone ever uses uint32 for images. Typically 16, > but perhaps also 64? What I'm arguing is that if anyone takes a 64-bit image and converts it to float, they are *not* after their image divided by 2**64.

1 0

Re: [scikit-image] data types
by Stefan van der Walt 06 Apr '18

06 Apr '18

On Fri, Apr 6, 2018, at 17:25, Juan Nunez-Iglesias wrote: > Stéfan, btw, one last Q: what do you think about my suggestions for the > (u)int32 and (u)int64 image types? I feel like assuming a range up to > 2**32 when converting is *never* useful. Agreed, I don't think anyone ever uses uint32 for images. Typically 16, but perhaps also 64? Stéfan

1 0

Re: [scikit-image] data types
by Juan Nunez-Iglesias 06 Apr '18

06 Apr '18

Thanks everyone for your comments. Ralf’s comment in particular gives me pause again about my magical proposal. Changing that behaviour could indeed be simply trading one class of common error for another, even more annoying class. Warnings *should* be the right answer, but the truth is that essentially no one reads them, *and* once you’ve figured out the issue, they are a nuisance. However perhaps we can make more of an effort to make our warnings more “full-bodied”, including plain english explanations and links to the relevant documentation page. @Tom, I think actually adding a 12-bit option to rescale intensity, (rather than currently having to define `in_range=(0, 4096)`) would be very useful. There’s some room for lots of utility functions, maybe even in their own top-level `skimage.data_types` submodule. Two other proposals: - put a big warning on the project homepage: “black images? out of range errors? See this page!” The page would be the data types page, to which we must add a “troubleshooting common data type errors” section. - add a poll on a GitHub issue or on the site: “Did you spend 2h debugging something related to the image data type and range? Please vote on what you think would have helped!” Then we can link to that every time someone stumbles on this. Juan. On 30 Mar 2018, 4:19 PM -0400, Thomas Caswell <tcaswell(a)gmail.com>, wrote: > Automatically picking bit-depth based on value seems dangerous, but a `guess_best_dtype(input_data: np.array) -> dtype` helper function would be useful. > > Tom > > > On Fri, Mar 30, 2018 at 10:10 AM Gregory Lee <grlee77(a)gmail.com> wrote: > > > > On Thu, Mar 29, 2018 at 1:46 PM, Juan Nunez-Iglesias <jni.soma(a)gmail.com> wrote: > > > > > I think maybe 50% of our bug reports/help requests have to do with image data types. Does anyone want to express an opinion about how we can fix things? > > > > > > > > > > My humble (really) suggestions, *to start* (ie more needs to be done than this): > > > > > > > > > > * If a 16-bit or higher image has no values above 4096 or below 0, treat the image as 12 bit. This is a very common image type for some reason. > > > > > > > > > > > > One common source for 12-bit is the DICOM standard used by industry for medical imaging. > > > > > > > > > > > > > * If an integer image has no values above 255, treat it as an 8-bit image. This also happens a lot. > > > > > > > > > > * If a floating point image has values outside [0, 1], don’t croak, just accept it. (This might have already happened?) If it has values only in [0, 1/255], and the user wants to convert to uint8, use the input range as the range. > > > > > > > > > > > > > I am in favor of accepting arbitrarily scaled floats unless the algorithm depends on values being within a particular range (not sure if we have many of these?). We do already allow unscaled floats in some places (e.g. compare_nrmse, etc), but it is not very consistent. For example, I recently noticed that denoise_wavelet enforces floats to be in [0, 1] (or [-1, 1]), but it would work equally well for unscaled data. > > > > > > > > > > > > > Some of these, especially the last one, may appear too magical, and in some ways I think they are, but honestly, given the frequency of problems that we get because of this, I think it’s time to suck it up and really work on doing what most of our users want most of the time. We don’t need to coddle the power users — they can be annoyed and micromanage the image range properly. To paraphrase a tweet I saw once (sorry, couldn’t find attribution): “edge cases should be used to check the design, not drive it.” > > > > > > > > > > Applied to this case, we shouldn’t scale a uint32 image by 2**(-32) just because we can come up with a test case where this is useful. > > > > > > > > > > Some of these problems would be alleviated by some consistent metadata conventions. > > > > > > > > > > Juan. > > > > > > > > > > > > > > > _______________________________________________ > > > > > scikit-image mailing list > > > > > scikit-image(a)python.org > > > > > https://mail.python.org/mailman/listinfo/scikit-image > > > > > > > > _______________________________________________ > > > scikit-image mailing list > > > scikit-image(a)python.org > > > https://mail.python.org/mailman/listinfo/scikit-image > _______________________________________________ > scikit-image mailing list > scikit-image(a)python.org > https://mail.python.org/mailman/listinfo/scikit-image

3 2