On Fri, Feb 12, 2021 at 9:45 AM Joseph Fox-Rabinovitz < jfoxrabinov...@gmail.com> wrote:
> > > On Fri, Feb 12, 2021, 09:32 Robert Kern <robert.k...@gmail.com> wrote: > >> On Fri, Feb 12, 2021 at 5:15 AM Eric Wieser <wieser.eric+nu...@gmail.com> >> wrote: >> >>> > There might be some linear algebraic reason why those axis positions >>> make sense, but I’m not aware of it... >>> >>> My guess is that the historical motivation was to allow grayscale `(H, >>> W)` images to be converted into `(H, W, 1)` images so that they can be >>> broadcast against `(H, W, 3)` RGB images. >>> >> >> Correct. If you do introduce atleast_nd(), I'm not sure why you'd >> deprecate and remove the one existing function that *isn't* made redundant >> thereby. >> > > `atleast_nd` handles the promotion of 2D to 3D correctly. The `pos` > argument lets you tell it where to put the new axes. What's unintuitive to > my is that the 1D case gets promoted to from shape `(x,)` to shape `(1, x, > 1)`. It takes two calls to `atleast_nd` to replicate that behavior. > When thinking about channeled images, the channel axis is not of the same kind as the H and W axes. Really, you tend to want to think about an RGB image as a (H, W) array of colors rather than an (H, W, 3) ndarray of intensity values. As much as possible, you want to treat RGB images similar to (H, W)-shaped grayscale images. Let's say I want to make a separable filter to convolve with my image, that is, we have a 1D filter for each of the H and W axes, and they are repeated for each channel, if RGB. Setting up a separable filter for (H, W) grayscale is straightforward with broadcasting semantics. I can use (ntaps,)-shaped vector for the W axis and (ntaps, 1)-shaped filter for the H axis. Now, when I go to the RGB case, I want the same thing. atleast_3d() adapts those correctly for the (H, W, nchannels) case. -- Robert Kern
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
