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. 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. Cheers, Ralf > The `pos` argument is the current solution to this, but maybe is a > better way [2]? Meshgrid for example defaults to `indexing='xy'` and > has `indexing='ij'` for a similar purpose [1]. > > Of course, if `atleast_3d` is common enough, I guess that argument > could also swing to adding a keyword-only argument to `atleast_3d` > (that way we can/will never change the default). > > - Sebastian > > > [1] Not sure the purposes are comparable, but in both cases, they > provide information about the "context" in which meshgrid/atleast_3d > are used. > > [2] It feels a bit like you may have to think about what `pos=3` will > actually do (in the sense, that we will all just end up doing trial and > error :)). At which point I am not sure there is too much gained over > the surprise of `atleast_3d`. > > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion@python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
