Mailman 3 December 2011 - scikit-image

Re: Asymmetric behavior in dtype conversion
by Christoph Gohlke Dec. 21, 2011

Dec. 21, 2011

On 12/21/2011 8:41 AM, StÃ¯Â¿Â½fan van der Walt wrote: > On Wed, Dec 21, 2011 at 1:30 AM, Tony Yu<tsyu80(a)gmail.com> wrote: >> I think one of two things should happen: >> >> 1) >> [uint -> int]: expand uint to *full* range of int. >> [int -> uint]: unchanged (squeeze into range of uint) >> >> 2) >> [uint -> int]: unchanged (fill *positive* range of int) >> [int -> uint]: clip negative values from int > People very often represent images in signed integers, even though > they only manipulate positive values, e.g. storing 0-255 in int8. So > the conversion to signed should not spread those values over the > entire range. However, I think you're right that we should add the > clipping in 2 to avoid the conversion bias, along with a nice big > warning. > > Regards > StÃ¯Â¿Â½fan > At this point it might be worth considering other cases that are currently not well handled by skimage dtype conversions. For example: 1) float images in the range 0.0 - 255.0 2) 1 bit images stored as (u)int 3) 10 and 12 bit images stored as uint16 Christoph

2 1

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

Dec. 21, 2011

On Wed, Dec 21, 2011 at 1:30 AM, Tony Yu <tsyu80(a)gmail.com> wrote: > I think one of two things should happen: > > 1) > [uint -> int]: expand uint to *full* range of int. > [int -> uint]: unchanged (squeeze into range of uint) > > 2) > [uint -> int]: unchanged (fill *positive* range of int) > [int -> uint]: clip negative values from int People very often represent images in signed integers, even though they only manipulate positive values, e.g. storing 0-255 in int8. So the conversion to signed should not spread those values over the entire range. However, I think you're right that we should add the clipping in 2 to avoid the conversion bias, along with a nice big warning. Regards Stéfan

1 0

Re: Asymmetric behavior in dtype conversion
by Christoph Gohlke Dec. 21, 2011

Dec. 21, 2011

On 12/21/2011 1:30 AM, Tony Yu wrote: > I noticed that---when converting unsigned integers to (signed) > integers---the values of the uint are simply scaled to fit into the > positive range of the int array. On the other hand, when converting > from int to uint, the *full range* (i.e. negative and positive) values > of the int array get scaled to fit into the uint. The result is > asymmetric, and it can lead to drift when converting between types; e.g.: > > #~~~ > In [55]: skimage.img_as_ubyte(skimage.img_as_int(np.uint8([0]))) > WARNING:dtype_converter:Possible sign loss when converting negative > image of type int16 to positive image of type uint8. > WARNING:dtype_converter:Possible precision loss when converting from > int16 to uint8 > Out[55]: array([128], dtype=uint8) > #~~~ > > I think one of two things should happen: > > 1) > [uint -> int]: expand uint to *full* range of int. > [int -> uint]: unchanged (squeeze into range of uint) > > 2) > [uint -> int]: unchanged (fill *positive* range of int) > [int -> uint]: clip negative values from int > > Thoughts? > -Tony > > P.S. This change would either have to wait for PR 99 > <https://github.com/scikits-image/scikits-image/pull/99>, or it could > be integrated into that pull request. (I haven't yet looked at what it > would take to make this change.) My original implementation of PR99 had 1) implemented but skimage tests failed. Christoph

1 0

Asymmetric behavior in dtype conversion
by Tony Yu Dec. 21, 2011

Dec. 21, 2011

I noticed that---when converting unsigned integers to (signed) integers---the values of the uint are simply scaled to fit into the positive range of the int array. On the other hand, when converting from int to uint, the *full range* (i.e. negative and positive) values of the int array get scaled to fit into the uint. The result is asymmetric, and it can lead to drift when converting between types; e.g.: #~~~ In [55]: skimage.img_as_ubyte(skimage.img_as_int(np.uint8([0]))) WARNING:dtype_converter:Possible sign loss when converting negative image of type int16 to positive image of type uint8. WARNING:dtype_converter:Possible precision loss when converting from int16 to uint8 Out[55]: array([128], dtype=uint8) #~~~ I think one of two things should happen: 1) [uint -> int]: expand uint to *full* range of int. [int -> uint]: unchanged (squeeze into range of uint) 2) [uint -> int]: unchanged (fill *positive* range of int) [int -> uint]: clip negative values from int Thoughts? -Tony P.S. This change would either have to wait for PR 99<https://github.com/scikits-image/scikits-image/pull/99>, or it could be integrated into that pull request. (I haven't yet looked at what it would take to make this change.)

1 0

Re: A bug in skimage.io
by Nadav Horesh Dec. 21, 2011

Dec. 21, 2011

That is it. Nadav 2011/12/20 Stéfan van der Walt <stefan(a)sun.ac.za> > On Mon, Dec 19, 2011 at 11:00 PM, Nadav Horesh <nadavh.horesh(a)gmail.com> > wrote: > > the for loop should be changed to > > > > for i in range(len(self.chunks)): > > Good catch, thanks Nadav. Please verify that I made the correct change: > > > https://github.com/scikits-image/scikits-image/commit/4df36631f64285b88bdfd… > > Cheers > Stéfan >

1 0

Re: New Doodle poll: "Scientific Python packages: Popularity check" (fwd)
by Stéfan van der Walt Dec. 20, 2011

Dec. 20, 2011

Oops, sorry about the double posting. I didn't see Emmanuelle had already forwarded it! 2011/12/20 Stéfan van der Walt <stefan(a)sun.ac.za>: > ----- Forwarded message from Pierre Raybaut <> ----- > > Date: Tue, 20 Dec 2011 11:17:50 +0100 > Subject: [SciPy-User] New Doodle poll: "Scientific Python packages: > Popularity check" > > Hi all, > > Three years ago (day for day... that's weird!), I made a Doodle poll > for estimating ~scientific Python packages popularity. > > Things have changed since then and I propose a new poll here: > http://www.doodle.com/rzssq2dbnus4a34r > > This poll is intended to identify the most popular scientific Python > packages to be included in the Python(x,y) distribution. However, even > if the package list is *not* exhaustive, I'm sure that people who are > not interested in Python(x,y) will find the poll results interesting > anyway. > > Thank you for your participation, and please spread the word! > > -Pierre

1 0

New Doodle poll: "Scientific Python packages: Popularity check" (fwd)
by Stéfan van der Walt Dec. 20, 2011

Dec. 20, 2011

----- Forwarded message from Pierre Raybaut <> ----- Date: Tue, 20 Dec 2011 11:17:50 +0100 Subject: [SciPy-User] New Doodle poll: "Scientific Python packages: Popularity check" Hi all, Three years ago (day for day... that's weird!), I made a Doodle poll for estimating ~scientific Python packages popularity. Things have changed since then and I propose a new poll here: http://www.doodle.com/rzssq2dbnus4a34r This poll is intended to identify the most popular scientific Python packages to be included in the Python(x,y) distribution. However, even if the package list is *not* exhaustive, I'm sure that people who are not interested in Python(x,y) will find the poll results interesting anyway. Thank you for your participation, and please spread the word! -Pierre

1 0

[SciPy-User] New Doodle poll: "Scientific Python packages: Popularity check" (fwd)
by Emmanuelle Gouillart Dec. 20, 2011

Dec. 20, 2011

----- Forwarded message from Pierre Raybaut <pierre.raybaut(a)gmail.com> ----- Date: Tue, 20 Dec 2011 11:17:50 +0100 From: Pierre Raybaut <pierre.raybaut(a)gmail.com> To: pythonxy(a)googlegroups.com, scipy-user <scipy-user(a)scipy.org> Subject: [SciPy-User] New Doodle poll: "Scientific Python packages: Popularity check" Reply-To: SciPy Users List <scipy-user(a)scipy.org> Hi all, Three years ago (day for day... that's weird!), I made a Doodle poll for estimating ~scientific Python packages popularity. Things have changed since then and I propose a new poll here: http://www.doodle.com/rzssq2dbnus4a34r This poll is intended to identify the most popular scientific Python packages to be included in the Python(x,y) distribution. However, even if the package list is *not* exhaustive, I'm sure that people who are not interested in Python(x,y) will find the poll results interesting anyway. Thank you for your participation, and please spread the word! -Pierre _______________________________________________ SciPy-User mailing list SciPy-User(a)scipy.org http://mail.scipy.org/mailman/listinfo/scipy-user ----- End forwarded message -----

1 0

Re: A bug in skimage.io
by Stéfan van der Walt Dec. 20, 2011

Dec. 20, 2011

On Mon, Dec 19, 2011 at 11:00 PM, Nadav Horesh <nadavh.horesh(a)gmail.com> wrote: > the for loop should be changed to > > for i in range(len(self.chunks)): Good catch, thanks Nadav. Please verify that I made the correct change: https://github.com/scikits-image/scikits-image/commit/4df36631f64285b88bdfd… Cheers Stéfan

1 0

A bug in skimage.io
by Nadav Horesh Dec. 20, 2011

Dec. 20, 2011

In the file skimage/io/_plugins/util.py line 215 the for loop should be changed to for i in range(len(self.chunks)): this change let it work on my PC (linux, 4 real core + 4 virtual (with hyperthreading)), since there there self.cores == 8 and len(self(chunks)) == 4 Nadav

1 0