On Fri, Feb 12, 2021 at 1:47 PM Ralf Gommers <ralf.gomm...@gmail.com> wrote:
> > On Fri, Feb 12, 2021 at 7:25 PM Sebastian Berg <sebast...@sipsolutions.net> > wrote: > >> On Fri, 2021-02-12 at 10:08 -0500, Robert Kern wrote: >> > 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. >> >> Right, my initial feeling it that without such context `atleast_3d` is >> pretty surprising. So I wonder if we can design `atleast_nd` in a way >> that it is explicit about this context. >> > > Agreed. I think such a use case is probably too specific to design a > single function for, at least in such a hardcoded way. > That might be an argument for not designing a new one (or at least not giving it such a name). Not sure it's a good argument for removing a long-standing one. Broadcasting is a very powerful convention that makes coding with arrays tolerable. It makes some choices (namely, prepending 1s to the shape) to make some common operations with mixed-dimension arrays work "by default". But it doesn't cover all of the desired operations conveniently. atleast_3d() bridges the gap to an important convention for a major use-case of arrays. There's also "channels first" and "channels last" versions of RGB images as > 3-D arrays, and "channels first" is the default in most deep learning > frameworks - so the choice atleast_3d makes is a little outdated by now. > DL frameworks do not constitute the majority of image processing code, which has a very strong channels-last contingent. But nonetheless, the very popular Tensorflow defaults to channels-last. -- Robert Kern
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
