Remarks for transform.warp function

25 views
Skip to first unread message

Nadav Horesh

unread,
May 15, 2012, 10:24:38 AM5/15/12
to scikit...@googlegroups.com
Remarks for today's skimage snaphot:

  1. The documentation state that the input image is a 2D array. In practice it can be a colour image.
  2. I got failures whenever I used the output_shape parameter


Nadav.

Stéfan van der Walt

unread,
May 15, 2012, 1:12:17 PM5/15/12
to scikit...@googlegroups.com
Hi Nadav
What code are you referring to?

Stéfan

Nadav Horesh

unread,
May 15, 2012, 2:28:32 PM5/15/12
to scikit...@googlegroups.com
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




2012/5/15 Stéfan van der Walt <ste...@sun.ac.za>

Tony Yu

unread,
May 15, 2012, 4:05:49 PM5/15/12
to scikit...@googlegroups.com
On Tue, May 15, 2012 at 2:28 PM, Nadav Horesh <nadavh...@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 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 g...@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

Nadav Horesh

unread,
May 16, 2012, 1:45:52 AM5/16/12
to scikit...@googlegroups.com
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

2012/5/15 Tony Yu <tsy...@gmail.com>

Tony Yu

unread,
May 16, 2012, 10:10:43 AM5/16/12
to scikit...@googlegroups.com
On Wed, May 16, 2012 at 1:45 AM, Nadav Horesh <nadavh...@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 to the list---it helps when following long conversations.

Nadav Horesh

unread,
May 16, 2012, 1:10:51 PM5/16/12
to scikit...@googlegroups.com


2012/5/16 Tony Yu <tsy...@gmail.com>

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.

Tony Yu

unread,
May 17, 2012, 12:57:11 AM5/17/12
to scikit...@googlegroups.com
On Wed, May 16, 2012 at 1:10 PM, Nadav Horesh <nadavh...@gmail.com> wrote:
2012/5/16 Tony Yu <tsy...@gmail.com>


On Wed, May 16, 2012 at 1:45 AM, Nadav Horesh <nadavh...@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
Reply all
Reply to author
Forward
0 new messages