Mailman 3 December 2011 - scikit-image

plugin freeimage vs gdal on 0.5dev
by jip Dec. 22, 2011

Dec. 22, 2011

Dear all, If I try to load a 12bits TIF image: sk.io.use_plugin('freeimage', 'imread') sk.io.use_plugin('matplotlib', 'imshow') dapi=io.imread(path+CC+im) I have the following message: ** Message: pygobject_register_sinkfunc is deprecated (GstObject) Traceback (most recent call last): File "/home/claire/Applications/ProjetPython/projet particule et objet/Nuclei/QuantSpots-skimage.py", line 49, in <module> sk.io.use_plugin('freeimage', 'imread') File "/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev- py2.6-linux-i686.egg/skimage/io/_plugins/plugin.py", line 128, in use _load(name) File "/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev- py2.6-linux-i686.egg/skimage/io/_plugins/plugin.py", line 190, in _load fromlist=[modname]) File "/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev- py2.6-linux-i686.egg/skimage/io/_plugins/freeimage_plugin.py", line 6, in <module> from numpy.compat import asbytes ImportError: No module named compat What is that compat module? I have numpy 1.30 installed. Anyway,I can load the image with gdal (sk.io.use_plugin('gdal', 'imread') with some warnings: ** Message: pygobject_register_sinkfunc is deprecated (GstObject) Warning 1: TIFFReadDirectory:Unknown field with tag 34959 (0x888f) encountered Warning 1: TIFFReadDirectory:Unknown field with tag 34960 (0x8890) encountered Warning 1: TIFFReadDirectory:Unknown field with tag 34959 (0x888f) encountered Warning 1: TIFFReadDirectory:Unknown field with tag 34960 (0x8890) encountered best regards Jean-Patrick

2 1

Re: morphology.label() bug?
by Stéfan van der Walt Dec. 22, 2011

Dec. 22, 2011

On Wed, Dec 21, 2011 at 10:39 PM, karoyakani <tj.takei(a)gmail.com> wrote: >> I don't like having background == 0, but I'll settle for background == >> -1 as a default. > > Thanks! Please review the PR at: https://github.com/scikits-image/scikits-image/pull/105 > Or, len(np.unique(labels)) - 1, if we do not count the background in. Or, as Tony mentioned: labels.max() Cheers Stéfan

1 0

Re: morphology.label() bug?
by Stéfan van der Walt Dec. 22, 2011

Dec. 22, 2011

On Wed, Dec 21, 2011 at 12:36 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > Actually, I've always found the return values for `ndimage.label` to be > surprising. Every time I use it, I expect to just get the labeled array. > Isn't the number of labeled regions equal to the max value of the labeled > array? That's correct. Cheers Stéfan

1 0

Re: Video io, 'get' not working with OpenCv
by Stéfan van der Walt Dec. 22, 2011

Dec. 22, 2011

Hi Pieter On Thu, Dec 22, 2011 at 2:40 AM, Pieter Holtzhausen <holtzhau(a)gmail.com> wrote: > Seems like the python bindings disabled that functionality > https://code.ros.org/trac/opencv/changeset/6358 Could you perhaps put together a PR to address this issue? That'd be much appreciated. Stéfan

1 0

Re: Video io, 'get' not working with OpenCv
by Pieter Holtzhausen Dec. 22, 2011

Dec. 22, 2011

Seems like the python bindings disabled that functionality https://code.ros.org/trac/opencv/changeset/6358 On Thu, Dec 22, 2011 at 12:31 PM, Pieter Holtzhausen <holtzhau(a)gmail.com> wrote: > Hello > > Yeah opencv made their python bindings work a bit less well with 2.3.1 > A workaround is to use cv.fromarray(img_mat) instead of img_mat > wherever it complains in video.py. It is strange since automatic > conversion was one of the cool features of the binding system...but > I'll investigate a bit further. > > Regards > Pieter > > On Thu, Dec 22, 2011 at 10:51 AM, robbert <superslimme(a)netscape.net> wrote: >> On 17-12-11 23:55, Stéfan van der Walt wrote: >>> >>> Hi Robbert >>> >>> On Sat, Dec 17, 2011 at 7:50 AM, robbert<superslimme(a)netscape.net> wrote: >>>> >>>> I've wrote a little test program to a extract a frame of a video file >>>> (for >>>> processing), but I can't get it work. >>> >>> Thanks for the report. This works using GStreamer, so tomorrow I'll >>> compile OpenCV and determine what the problem is. >> >> >> Thanks Stéfan & Christoph for your responses. >> If this problem is solved, I've probably all the necessary toolboxes to >> leave matlab behind! >> >> In the meanwhile I tried to install the alternative back-end, GStreamer, but >> without success. >> The python demo's (of GStreamer) wont work, so there is no point in posting >> the error that scikits-image generates. >> >> kind regards, >> >> Robbert

1 0

Re: Video io, 'get' not working with OpenCv
by robbert Dec. 22, 2011

Dec. 22, 2011

On 17-12-11 23:55, StÃ¯Â¿Â½fan van der Walt wrote: > Hi Robbert > > On Sat, Dec 17, 2011 at 7:50 AM, robbert<superslimme(a)netscape.net> wrote: >> I've wrote a little test program to a extract a frame of a video file (for >> processing), but I can't get it work. > Thanks for the report. This works using GStreamer, so tomorrow I'll > compile OpenCV and determine what the problem is. Thanks StÃ¯Â¿Â½fan & Christoph for your responses. If this problem is solved, I've probably all the necessary toolboxes to leave matlab behind! In the meanwhile I tried to install the alternative back-end, GStreamer, but without success. The python demo's (of GStreamer) wont work, so there is no point in posting the error that scikits-image generates. kind regards, Robbert

2 1

Re: morphology.label() bug?
by karoyakani Dec. 22, 2011

Dec. 22, 2011

On Dec 21, 2:02 pm, Stéfan van der Walt <ste...(a)sun.ac.za> wrote: ... > I don't like having background == 0, but I'll settle for background == > -1 as a default. Thanks! > > Regarding connectedness, both matlab and ndimage have options of 8- > > connect and 4-connect. ... > > That's been added in the patch I proposed. Thanks!! > > Regarding number of labeled regions (not counting the background > > regions), again matlab and ndimage compute and return it. ... > > This is a one-liner: len(np.unique(labels)) Or, len(np.unique(labels)) - 1, if we do not count the background in. I tend to think that is a norm when we consider the background special. Yet who cares if the output does not include the number of regions. Regards, TJ

1 0

Re: Asymmetric behavior in dtype conversion
by Stéfan van der Walt Dec. 21, 2011

Dec. 21, 2011

On Wed, Dec 21, 2011 at 11:16 AM, Tony Yu <tsyu80(a)gmail.com> wrote: > I've definitely been bit by example 1 many times. > > I think we should check that float images are between 0 and 1 in > ``util.dtype._convert`` (and either warn or raise an error), but we > shouldn't have to worry about it elsewhere. That doesn't really solve the > issue, so... This check is cheap enough that we should just add it (it may save more time than it costs in the end). The rest of the examples are fairly unusual, and since there's no way to automatically detect those situations, we'll just expect the users to correctly scale their data before using it (I am not opposed to adding utility functions for that purpose, though). Stéfan

1 0

Re: morphology.label() bug?
by Stéfan van der Walt Dec. 21, 2011

Dec. 21, 2011

On Sat, Dec 17, 2011 at 7:36 PM, karoyakani <tj.takei(a)gmail.com> wrote: > It's very useful and common that we assume Background:="0"-value > pixels. > ndimage and matlab do so. > I don't know why skimage doesn't. I don't like having background == 0, but I'll settle for background == -1 as a default. > Regarding connectedness, both matlab and ndimage have options of 8- > connect and 4-connect. > Meantime skimage has only 8-connect. > Why don't we add 4-connect as an option? That's been added in the patch I proposed. > Regarding number of labeled regions (not counting the background > regions), again matlab and ndimage compute and return it. > Why don't we add it to the skimage, as it would be very useful to > users? This is a one-liner: len(np.unique(labels)) Cheers Stéfan

1 0

Re: morphology.label() bug?
by Tony Yu Dec. 21, 2011

Dec. 21, 2011

On Sat, Dec 17, 2011 at 7:36 PM, karoyakani <tj.takei(a)gmail.com> wrote: > > > On Dec 17, 3:27 am, Stéfan van der Walt <ste...(a)sun.ac.za> wrote: > > On Sat, Dec 17, 2011 at 3:13 AM, Emmanuelle Gouillart > > > > <emmanuelle.gouill...(a)nsup.org> wrote: > > >> > a = np.array([ > > >> > [0,1,1,0,0,0], > > >> > [0,1,1,0,1,0], > > >> > [0,0,0,1,1,1], > > >> > [0,0,0,0,1,0]]) > > > > >> This is the correct output, since the zero is not connected to any > > >> other region. In fact, ndimage labels it incorrectly as: > > > > >> array([[0, 1, 1, 0, 0, 0], > > >> [0, 1, 1, 0, 1, 0], > > >> [0, 0, 0, 1, 1, 1], > > >> [0, 0, 0, 0, 1, 0]]) > > > > > Well, this is not incorrect, since ndimage.label only labels connected > > > components of the foreground (True pixels). > > > > Right, so zero is a magical value. I guess it's pretty easy to get > > the same out of our implementation by simply masking out all > > uninteresting values, and calling "unique" to get the remaining > > labels? > > It's very useful and common that we assume Background:="0"-value > pixels. > ndimage and matlab do so. > I don't know why skimage doesn't. > > Regarding connectedness, both matlab and ndimage have options of 8- > connect and 4-connect. > Meantime skimage has only 8-connect. > Why don't we add 4-connect as an option? > > Regarding number of labeled regions (not counting the background > regions), again matlab and ndimage compute and return it. > Why don't we add it to the skimage, as it would be very useful to > users? > Actually, I've always found the return values for `ndimage.label` to be surprising. Every time I use it, I expect to just get the labeled array. Isn't the number of labeled regions equal to the max value of the labeled array? -Tony > I suspect the reason why the skimage doesn't is because it currently > has a vague notion on the background regions, isn't it? > > Regards, > TJ > > >

1 0