Mailman 3 May 2012 - scikit-image

Re: Fwd: [scikits-image] FITS plugin test failures on OS X Lion (#173)
by James Turner May 29, 2012

May 29, 2012

This few-line change should fix the following PyFITS problem: https://github.com/scikits-image/scikits-image/pull/194 Cheers, James. On 18/04/12 21:39, StÃ¯Â¿Â½fan van der Walt wrote: > Hi James > > Do you know why hdu.size is an int on OSX? Or is this a version > specific problem? > > StÃ¯Â¿Â½fan > > > ---------- Forwarded message ---------- > From: Christoph Deil > <reply+i-4102551-b422c74f143608749812b80550d847f8d689a21b-45071(a)reply.github.com> > Date: Fri, Apr 13, 2012 at 5:46 AM > Subject: [scikits-image] FITS plugin test failures on OS X Lion (#173) > To: Stefan van der Walt<sjvdwalt(a)gmail.com> > > > I installed skimage cdb61f82ff2285b26be9eb1decb8fc5657fecf50 on Mac OS > X 10.7 with pyfits 3.1-0.0.dev846 . > > There are two test FITS-related test failures: > http://dl.dropbox.com/u/4923986/bug_reports/skimage-test.log > > Also there's lots of WARNINGs when building the docs: > http://dl.dropbox.com/u/4923986/bug_reports/skimage-docs.log > > --- > Reply to this email directly or view it on GitHub: > https://github.com/scikits-image/scikits-image/issues/173

1 0

Re: skimage now in Debian
by Damian Eads May 22, 2012

May 22, 2012

Congrats! This is excellent news. On Sun, May 20, 2012 at 12:24 PM, Stéfan van der Walt <stefan(a)sun.ac.za> wrote: > Hi everyone, > > I'm happy to announce that the package "python-skimage" is now > included in Debian! A special word of thanks to Yaroslav Halchenko > who worked so hard to make this happen. > > If we can release 0.6 this week, then that should be the version > included Debian, if I understand correctly. So, if you have any time > to review, document, test, please do so ASAP! > > Stéfan

1 0

Re: skimage now in Debian
by Emmanuelle Gouillart May 22, 2012

May 22, 2012

Wow, great news!! Thanks a lot, Yaroslav!! Emmanuelle On Sun, May 20, 2012 at 12:24:59PM -0700, StÃ¯Â¿Â½fan van der Walt wrote: > Hi everyone, > I'm happy to announce that the package "python-skimage" is now > included in Debian! A special word of thanks to Yaroslav Halchenko > who worked so hard to make this happen. > If we can release 0.6 this week, then that should be the version > included Debian, if I understand correctly. So, if you have any time > to review, document, test, please do so ASAP! > StÃ¯Â¿Â½fan

1 0

Standalone package for FreeImage plugin: imageio
by Almar Klein May 22, 2012

May 22, 2012

Hi, I really like Zach's code that wraps the FreeImage library and that's now a plugin of scikits-image. With more and more projects transitioning to Py3k I think there is an increased need for a *proper* replacement for PIL. I've discussed with Zach, and we believe that the code should be in a stand-alone package. Therefore we started a new project. We've called it imageio and its main page is at http://imageio.readthedocs.org. I invite all who's interested to join us in coding/testing/discussing. One particular topic of interest is how to ship the libraries to the users on Windows and Mac<https://groups.google.com/d/topic/imageio/KKIaAlXDxHw/discussion> (which I think has also been discussed in this group). I forked from the code in freeimage_plugin.py. Here are two patches that might be of interest to your plugin: https://bitbucket.org/almarklein/imageio/changeset/78eef0776ca2 - py3k compatibility https://bitbucket.org/almarklein/imageio/changeset/8c6f499aea62 - encoding/decoding However, I hope that on the long term we can work together on the stand-alone library and have the plugin as a wrapper or fallback. Regards, Almar Klein Science Applied v.o.f.

2 1

skimage now in Debian
by Stéfan van der Walt May 20, 2012

May 20, 2012

Hi everyone, I'm happy to announce that the package "python-skimage" is now included in Debian! A special word of thanks to Yaroslav Halchenko who worked so hard to make this happen. If we can release 0.6 this week, then that should be the version included Debian, if I understand correctly. So, if you have any time to review, document, test, please do so ASAP! Stéfan

1 0

Re: Remarks for transform.warp function
by Tony Yu May 17, 2012

May 17, 2012

On Wed, May 16, 2012 at 1:10 PM, Nadav Horesh <nadavh.horesh(a)gmail.com>wrote: > > > 2012/5/16 Tony Yu <tsyu80(a)gmail.com> > >> >> >> On Wed, May 16, 2012 at 1:45 AM, Nadav Horesh <nadavh.horesh(a)gmail.com>wrote: >> >>> It solves the problem. >>> What do you think about letting enabling output_shape=(m,n) even for a >>> colour image, implicitly assuming that the 3rd dimension is copied from the >>> original image. >>> >>> Nadav >>> >> >> Currently, color images work fine when no `output_shape` is >> specified. I'm not sure what you mean by "implicitly assuming that the 3rd >> dimension is copied from the original image". Are you suggesting that for >> color images setting `output_shape=(m, n)` should actually return a shape >> of `(m, n, 3)`? If that's the case, I strongly disagree because it seems >> magical---i.e. it's contradicting the user's command. >> >> Actually, I don't understand the use case for `output_shape`, so I could >> be missing something... >> >> -Tony >> >> > The warp mapping usually define an image of a different size than the > original. The common case is that the distortion corrected image is cliped > to the original image size, this is why that this is the default. However, > one may want to see the full details of the original image, and thus > specify output_shape > image.shape. > > You got me right about the implicit dimension. The logic: The image size > is the number of pixels, disregarding the colour depth. You are right if > you consider the image as an array of values, but if you consider it as an > image, the image shape is just the first 2 dimensions. Anyway it is not > that important. > > Thank you, > > Nadav. > Oh, I guess the `output_shape` parameter would be helpful for image stretching when you want to include all of the original image. Thanks, for the explanation. Hmm, your logic on the implicit dimension is somewhat convincing. I would temper my previous "strong objection" to a "moderate objection" (since it still seems magical). Maybe a compromise would allow custom warping functions to set `output_shape=(m, n, -1)`; the -1 being a special flag that adapts to grayscale and color images. Note this isn't unprecedented: you can pass -1 as a dimension to `np.reshape` and it'll figure out the dimension size that fits the data. (I suggest this as an idea for someone else to contribute :) -Tony

1 0

Re: Rewrite of extension to generate examples in documentation
by Tony Yu May 17, 2012

May 17, 2012

On Wed, May 16, 2012 at 4:59 PM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: > Hi Tony > > On Tue, May 15, 2012 at 8:15 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > > P.S. I only recently learned of an IPython project to provide similar > > functionality. I'm not sure if there are any lasting advantages to using > > `plot2rst` (compared to the IPython notebook; one disadvantage is that > > `plot2rst` doesn't capture terminal output), but the immediate advantage > is > > that it's a drop-in replacement for `gen_rst`. > > I'm glad you mentioned this; I've been using nbconvert > (https://github.com/ipython/nbconvert), and I think that would be a > good way forward: not only can it produce good looking PDFs, but it > can also do the HTML, and allows us to edit examples easily. > > However, someone has to do the work to integrate this, so I'm not sure > it's the best solution *right now* (unless you are feeling > particularly productive :-). > ... sorry, can't jump at that opportunity right now ;) > P.P.S. I noticed that we include the `plot_directive` extension, but I > don't > > believe it's used. I can remove this as part of the PR if someone > confirms. > > I thought this was for when matplotlib (sphinx?) didn't ship it, but > since we rely on matplotlib 1 and sphinx anyway, you can go ahead. > Actually, I wasn't wondering whether or not we should ship it; I was wondering if I should strip out all references to it (e.g. the sphinx extension itself, listing it as an extension, setting config parameters for the extension). A quick search suggests that we don't use the plot directive at all. > > > P.P.P.S. This PR should probably wait until after releasing 0.6, since > it's > > a pretty big change. Plus, it's just documentation so it will be > up-to-date > > on the website; it's less important that it's up-to-date in a user's > > install. > > That's probably sensible; and for now I'd also like to explore how > much effort it would be to integrate notebooks in this pipeline, so > waiting until 0.7 should give us time. > > Thanks! > Stéfan >

1 0

Re: Rewrite of extension to generate examples in documentation
by Stéfan van der Walt May 16, 2012

May 16, 2012

Hi Tony On Tue, May 15, 2012 at 8:15 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > P.S. I only recently learned of an IPython project to provide similar > functionality. I'm not sure if there are any lasting advantages to using > `plot2rst` (compared to the IPython notebook; one disadvantage is that > `plot2rst` doesn't capture terminal output), but the immediate advantage is > that it's a drop-in replacement for `gen_rst`. I'm glad you mentioned this; I've been using nbconvert (https://github.com/ipython/nbconvert), and I think that would be a good way forward: not only can it produce good looking PDFs, but it can also do the HTML, and allows us to edit examples easily. However, someone has to do the work to integrate this, so I'm not sure it's the best solution *right now* (unless you are feeling particularly productive :-). > P.P.S. I noticed that we include the `plot_directive` extension, but I don't > believe it's used. I can remove this as part of the PR if someone confirms. I thought this was for when matplotlib (sphinx?) didn't ship it, but since we rely on matplotlib 1 and sphinx anyway, you can go ahead. > P.P.P.S. This PR should probably wait until after releasing 0.6, since it's > a pretty big change. Plus, it's just documentation so it will be up-to-date > on the website; it's less important that it's up-to-date in a user's > install. That's probably sensible; and for now I'd also like to explore how much effort it would be to integrate notebooks in this pipeline, so waiting until 0.7 should give us time. Thanks! Stéfan

1 0

Re: Remarks for transform.warp function
by Nadav Horesh May 16, 2012

May 16, 2012

2012/5/16 Tony Yu <tsyu80(a)gmail.com> > > > On Wed, May 16, 2012 at 1:45 AM, Nadav Horesh <nadavh.horesh(a)gmail.com>wrote: > >> It solves the problem. >> What do you think about letting enabling output_shape=(m,n) even for a >> colour image, implicitly assuming that the 3rd dimension is copied from the >> original image. >> >> Nadav >> > > Currently, color images work fine when no `output_shape` is specified. I'm > not sure what you mean by "implicitly assuming that the 3rd dimension is > copied from the original image". Are you suggesting that for color images > setting `output_shape=(m, n)` should actually return a shape of `(m, n, > 3)`? If that's the case, I strongly disagree because it seems > magical---i.e. it's contradicting the user's command. > > Actually, I don't understand the use case for `output_shape`, so I could > be missing something... > > -Tony > > Nadav: could you bottom-post or interleave posts<http://en.wikipedia.org/wiki/Posting_style> to > the list---it helps when following long conversations. > > >> >> 2012/5/15 Tony Yu <tsyu80(a)gmail.com> >> >>> >>> >>> On Tue, May 15, 2012 at 2:28 PM, Nadav Horesh <nadavh.horesh(a)gmail.com>wrote: >>> >>>> def shift(xy): >>>> return xy+10 >>>> >>>> from skimage.transform import warp >>>> from skimage.transform import warp >>>> >>>> camera = samples.camera() >>>> warp(camera, shift, output_shape=camera.shape) >>>> >>>> >>>> --------------------------------------------------------------------------- >>>> ValueError Traceback (most recent call >>>> last)/home/nadav/pyscripts/<ipython-input-11-ce1e92562ac8> in <module>() >>>> ----> 1 warp(camera, shift, output_shape=camera.shape) >>>> /usr/lib64/python3.2/site-packages/scikits_image-0.6dev-py3.2-linux-x86_64.egg/skimage/transform/_warp.py >>>> in warp(image, reverse_map, map_args, output_shape, order, mode, cval) >>>> 92 >>>> 93 # Place the y-coordinate mapping >>>> >>>> ---> 94 _stackcopy(coords[1, ...], tf_coords[0, ...]) >>>> 95 >>>> 96 # Place the x-coordinate mapping >>>> >>>> /usr/lib64/python3.2/site-packages/scikits_image-0.6dev-py3.2-linux-x86_64.egg/skimage/transform/_warp.py >>>> in _stackcopy(a, b) >>>> 23 >>>> 24 """ >>>> ---> 25 a[:] = b[:, :, np.newaxis] >>>> 26 >>>> 27 def warp(image, reverse_map, map_args={}, >>>> ValueError: output operand requires a reduction, but reduction is not >>>> enabled >>>> >>>> >>>> Nadav >>>> >>> >>> >>> Hi Nadav, >>> >>> Could you check to see if the fix in my fix-stack-copy solves your >>> issues (it should fix the example you gave above, but it sounds like you >>> might have other uses). You can either make changes<https://github.com/tonysyu/scikits-image/commit/048c6c06ebe9935aa6844a09ed8…>to your local copy, or you can create a new branch based off of mine. I >>> think you mentioned that you're new to git so... >>> >>> Add my repo as a remote: >>> $ git remote add tonysyu git@github.com:tonysyu/scikits-image.git >>> Fetch my branches: >>> $ git fetch tonysyu >>> Create and checkout a new branch based off of my branch: >>> $ git checkout -b fix-stack-copy tonysyu/fix-stack-copy >>> >>> (Let me know if you have issues with the above---I'm working from >>> memory, so it may be flawed) >>> >>> Best, >>> -Tony >>> >>> >>>> >>>> >>>> >>>> >>>> 2012/5/15 Stéfan van der Walt <stefan(a)sun.ac.za> >>>> >>>>> Hi Nadav >>>>> >>>>> On Tue, May 15, 2012 at 7:24 AM, Nadav Horesh <nadavh.horesh(a)gmail.com> >>>>> wrote: >>>>> > Remarks for today's skimage snaphot: >>>>> > >>>>> > The documentation state that the input image is a 2D array. In >>>>> practice it >>>>> > can be a colour image. >>>>> > I got failures whenever I used the output_shape parameter >>>>> >>>>> What code are you referring to? >>>>> >>>>> Stéfan >>>>> >>>> >>> > The warp mapping usually define an image of a different size than the original. The common case is that the distortion corrected image is cliped to the original image size, this is why that this is the default. However, one may want to see the full details of the original image, and thus specify output_shape > image.shape. You got me right about the implicit dimension. The logic: The image size is the number of pixels, disregarding the colour depth. You are right if you consider the image as an array of values, but if you consider it as an image, the image shape is just the first 2 dimensions. Anyway it is not that important. Thank you, Nadav.

1 0

Re: Remarks for transform.warp function
by Tony Yu May 16, 2012

May 16, 2012

On Wed, May 16, 2012 at 1:45 AM, Nadav Horesh <nadavh.horesh(a)gmail.com>wrote: > It solves the problem. > What do you think about letting enabling output_shape=(m,n) even for a > colour image, implicitly assuming that the 3rd dimension is copied from the > original image. > > Nadav > Currently, color images work fine when no `output_shape` is specified. I'm not sure what you mean by "implicitly assuming that the 3rd dimension is copied from the original image". Are you suggesting that for color images setting `output_shape=(m, n)` should actually return a shape of `(m, n, 3)`? If that's the case, I strongly disagree because it seems magical---i.e. it's contradicting the user's command. Actually, I don't understand the use case for `output_shape`, so I could be missing something... -Tony Nadav: could you bottom-post or interleave posts<http://en.wikipedia.org/wiki/Posting_style> to the list---it helps when following long conversations. > > 2012/5/15 Tony Yu <tsyu80(a)gmail.com> > >> >> >> On Tue, May 15, 2012 at 2:28 PM, Nadav Horesh <nadavh.horesh(a)gmail.com>wrote: >> >>> def shift(xy): >>> return xy+10 >>> >>> from skimage.transform import warp >>> from skimage.transform import warp >>> >>> camera = samples.camera() >>> warp(camera, shift, output_shape=camera.shape) >>> >>> >>> --------------------------------------------------------------------------- >>> ValueError Traceback (most recent call >>> last)/home/nadav/pyscripts/<ipython-input-11-ce1e92562ac8> in <module>() >>> ----> 1 warp(camera, shift, output_shape=camera.shape) >>> /usr/lib64/python3.2/site-packages/scikits_image-0.6dev-py3.2-linux-x86_64.egg/skimage/transform/_warp.py >>> in warp(image, reverse_map, map_args, output_shape, order, mode, cval) >>> 92 >>> 93 # Place the y-coordinate mapping >>> >>> ---> 94 _stackcopy(coords[1, ...], tf_coords[0, ...]) >>> 95 >>> 96 # Place the x-coordinate mapping >>> >>> /usr/lib64/python3.2/site-packages/scikits_image-0.6dev-py3.2-linux-x86_64.egg/skimage/transform/_warp.py >>> in _stackcopy(a, b) >>> 23 >>> 24 """ >>> ---> 25 a[:] = b[:, :, np.newaxis] >>> 26 >>> 27 def warp(image, reverse_map, map_args={}, >>> ValueError: output operand requires a reduction, but reduction is not >>> enabled >>> >>> >>> Nadav >>> >> >> >> Hi Nadav, >> >> Could you check to see if the fix in my fix-stack-copy solves your issues >> (it should fix the example you gave above, but it sounds like you might >> have other uses). You can either make changes<https://github.com/tonysyu/scikits-image/commit/048c6c06ebe9935aa6844a09ed8…>to your local copy, or you can create a new branch based off of mine. I >> think you mentioned that you're new to git so... >> >> Add my repo as a remote: >> $ git remote add tonysyu git@github.com:tonysyu/scikits-image.git >> Fetch my branches: >> $ git fetch tonysyu >> Create and checkout a new branch based off of my branch: >> $ git checkout -b fix-stack-copy tonysyu/fix-stack-copy >> >> (Let me know if you have issues with the above---I'm working from memory, >> so it may be flawed) >> >> Best, >> -Tony >> >> >>> >>> >>> >>> >>> 2012/5/15 Stéfan van der Walt <stefan(a)sun.ac.za> >>> >>>> Hi Nadav >>>> >>>> On Tue, May 15, 2012 at 7:24 AM, Nadav Horesh <nadavh.horesh(a)gmail.com> >>>> wrote: >>>> > Remarks for today's skimage snaphot: >>>> > >>>> > The documentation state that the input image is a 2D array. In >>>> practice it >>>> > can be a colour image. >>>> > I got failures whenever I used the output_shape parameter >>>> >>>> What code are you referring to? >>>> >>>> Stéfan >>>> >>> >>

1 0