Mailman 3 January 2017 - scikit-image

IO documentation
by Michal Romaniuk Jan. 5, 2017

Jan. 5, 2017

Hi everyone, The IO documentation doesn't seem to be very good. It explains how plugins work but it's scarce on examples e.g. on how to export jpeg image with a specified compression level. The IO API docs don't give much detail either. Some details can be found in the docs for external.tifffile but it takes some searching to find it. For PIL the only way to figure out how to use it seems to be looking at the source code - no modern docs as far as I can tell (did I fail to use Google properly?). Any thoughts? Best wishes, Michal

1 0

Re: [scikit-image] pixel value changes during reading image and showing images using skimage and matplotlib
by Thomas Caswell Jan. 5, 2017

Jan. 5, 2017

plt.imread falls back to PIL/pillow for tiff reading which does not always handle high-bit depth tiffs well. I (as a lead mpl dev) would discourage `plt.imread` for 'production' use, there are many better options out there (ex skimage, http://imageio.github.io/ , http://soft-matter.github.io/pims/v0.3.3/ , http://imread.readthedocs.io/en/latest/ ). Tom On Sun, Dec 11, 2016 at 2:04 PM wine lover <winecoding(a)gmail.com> wrote: > Hi Imanol, > > It works fine now, thanks for your suggestions. > > Regarding the second part of my question. If I read the image using > matlibplot instead of skimage, > i.e., output=plt.imread(os.path.join(image_path,raw_image_name)) > > I found that the pixel values of output were all changed, and they becomes > either 255. or 0. which causes the image shown as all black. What are the > possible reasons for plt.imread. Thanks. > > Yuanyuan > > On Sun, Dec 11, 2016 at 4:54 AM, Imanol Luengo < > imanol.luengo(a)nottingham.ac.uk> wrote: > > Dear Yuanyuan, > > The reason why you are looking at a *color* image is due to the colormaps: > > http://matplotlib.org/users/colormaps.html > > The default colormap (to map from numbers to colors) is not grayscale, as > matplotlib is not primarly focus on images, and grayscale is not an > *adequate* colormap to represent other types of plots. > > To properly visualize your image specify a colormap to the plot function: > > plt.imshow(output, 'gray') > > Cheers, > > Imanol > > On 11/12/16 06:46, wine lover wrote: > > Dear All, > > I have a tif images, its type is float32, shape is (128*128) (a grayscale > image). All the pixel values are of range [0.0, 1.0] > > I am trying to read it using skimage and show it on screen using > matplotlib. > > from skimage import ioimport matplotlib.pyplot as plt > output=io.imread(os.path.join(image_path,raw_image_name))print(output.dtype)print(output.shape)print(output.max())print(output.min()) > plt.imshow(output) > plt.show() > > The output image looks like color image instead of gray image as shown > originally. I attached the screenshot as the capture-1.jpg. > > However, when I read the image using matplotlib instead,i.e., > output=plt.imread(os.path.join(image_path,raw_image_name)). I found that > pixel value will become 255 and 0. The dtype is still float32. But when I > print output, the pixel values are either 0. or 255. > > The output image will become black as shown in the second image > (capture-2.jpg). I am confused how does this work? My guess is that there > are some dtype changes happening during the reading image and showing > image, > > > Thanks, > > Yuanyuan > > > _______________________________________________ > scikit-image mailing listscikit-image@python.orghttps://mail.python.org/mailman/listinfo/scikit-image > > > > > This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this > message in error, please send it back to me, and immediately delete it. > > Please do not use, copy or disclose the information contained in this > message or in any attachment. Any views or opinions expressed by the > author of this email do not necessarily reflect the views of the > University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > > > _______________________________________________ > 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 >

1 0

Re: [scikit-image] GLCM and angles
by Stefan van der Walt Jan. 4, 2017

Jan. 4, 2017

Hi Igor On Thu, Dec 8, 2016, at 22:43, Igor Karlovits wrote: > I would have a question regarding the results of graycoprops which is > giving me the same results for all attributes (energy, ASM etc...) in > angles of rotation of 135 and 90. Angles 0, 45 and 90 are ok (with an > offset of 1) but the angle 135 is giving the same results as 90? Apologies for the delay: can you give an example of the problem you see? If you believe this to be a bug, would you mind filing an issue on GitHub? Thanks! Stéfan

1 0

Re: [scikit-image] Future of nose and issues for scikit-image
by Juan Nunez-Iglesias Jan. 3, 2017

Jan. 3, 2017

+1 for pytest. Nelle, can you comment a bit on why scikit-learn effectively decided to roll their own test library? ;) Is it part of their general (and well-justified) aversion to new dependencies, or were there specific objections to pytest? Pytest mostly works out of the box with tests written for nose. As far as I know the exceptions are: - all the nose imports that Stéfan pointed out (btw how did an import * make its way into our codebase???) - it seems that yielding tests is deprecated, so that will require a few rewrites. It's not a trivial effort to fix these, but I don't think it'll be any bigger than any other move. Juan. On 1 Jan 2017, 10:26 AM +1100, Stefan van der Walt <stefanv(a)berkeley.edu>, wrote: > On Sat, Dec 31, 2016, at 15:05, Steven Silvester wrote: > > I agree with Stéfan that a forward-looking clean break would be best. It looks like a rather large undertaking though, judging from https://github.com/matplotlib/matplotlib/pull/5405. > > Perhaps we are better off than matplotlib: > > $ git grep "from nose" > skimage/_shared/testing.py: from nose.tools import assert_less > skimage/_shared/testing.py: from nose.tools import assert_greater > skimage/_shared/tests/test_testing.py:from nose.tools import (assert_true, assert_raises, assert_equal) > skimage/draw/tests/test_draw3d.py:from nose.tools import raises > skimage/io/tests/test_sift.py:from nose.tools import * > skimage/novice/tests/test_novice.py:from nose.tools import assert_true > skimage/segmentation/tests/test_quickshift.py:from nose.tools import assert_true > skimage/util/tests/test_montage.py:from nose.tools import assert_equal, raises > skimage/util/tests/test_shape.py:from nose.tools import raises > > Stéfan > > _______________________________________________ > scikit-image mailing list > scikit-image(a)python.org > https://mail.python.org/mailman/listinfo/scikit-image

2 1