Remove invalid dimension checking in axes_rgb.

[anntzer]

Just let dstack error out if dimensions don't match.

See #7810.

[codecov-io]

Current coverage is 62.10% (diff: 0.00%)

Merging #7826 into master will increase coverage by <.01%

@@             master      #7826   diff @@
==========================================
  Files           174        174          
  Lines         56052      56049     -3   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
  Hits          34809      34809          
+ Misses        21243      21240     -3   
  Partials          0          0          

Powered by Codecov. Last update 9edcb03...ab9610e

[NelleV]

I am concerned that this patch makes it harder for the user to understand where exactly the error comes from.

[tacaswell]

I agree with @NelleV This is one of the few places where we raise a non-inscrutable exception. This also replaces comparing equality of a few integers with copying all of the data an extra time. It is probably better to just fix the transposition.

[anntzer]

1. The error is not really worse than what it effectively was before, given that before, matching nonsquare shapes would be incorrectly rejected and some nonvalid nonsquare shapes would even error a bit further below (although there are certainly cases where the previous case would raise an informative message).

2. In general I'd rather push for numpy to add these clearer error messages ("cannot stack arrays of shape (12, 34) and (56, 78)"), which would benefit every call site of every project that uses numpy rather than having to rewrite it every time.

3. np.dstack([r, g, b]) certainly checks sizes before allocating the memory and starting to copy it, so there isn't a performance issue.

[tacaswell]

1. fair, but a smaller change would yield a much better warning

2. also fair, but ValueError: all the input array dimensions except for the concatenation axis must match exactly is what you currently get and given how slow both us and numpy move, it will likely be that way for a while so it is worth our effort to patch around it.

3. but in the case where everything is copacetic we have an extra set of copies (I think)

[anntzer]

I feel a bit ridiculous to have waste both of our times over this so I restored the check :) but at least I learnt a new word (copacetic)...
By the way even in that case there is no extra copy, you just trade it against the RGB=R+G+B a bit below... which was likely a bit less efficient.

[tacaswell]

ah, I missed the sum at the bottom 🐑

[QuLogic]

Backported to v2.0.x as 2da8a98.