Holoviews: Raster supports (MxNx3) clashes with docstring

[michaelaye]

Doing

img = hv.Raster(img)
img

inside a ipython notebook, I get a fine color display of the image array with dimensions (MxNx3), despite the docstring saying:

Raster is a basic 2D element type for presenting either numpy or
dask arrays as two dimensional raster images.

Arrays with a shape of (N,M) are valid inputs for Raster wheras
subclasses of Raster (e.g. RGB) may also accept 3D arrays
containing channel information.

Using latest version on conda-forge.

[jlstevens]

Thanks for reporting this and well spotted!

The docstring declares our intent for this element and it just happens the implementation supports something more general than that. As you should use the RGB element when you have three (or four with alpha) channels, I agree we should validate and suggest using RGB when the array has more dimensions than expected.

[michaelaye]

Okay. FYI, despite the API bug, I'm happy that Raster does that at the moment, because RGB again does not respect the incoming aspect of the data (which it should I think).

[jlstevens]

@philippjfr Do we agree that RGB should always respect the aspect of the incoming data?

At least with RGB this seems very sensible as RGB is going to be used for things like photographs where you definitely don't want distortion.

All these fixes regarding setting aspects are pretty easy as long as we come to a decision we can all agree upon and as long as we feel the behavior is consistent and not too confusing.

If we can decide, I'll make RGBs respect aspects properly before improving validation on Raster.

[michaelaye]

Wouldn't it be a sensible approach to always respect the aspect when the user does not specify specific x/y dimensions? Because that most likely means that the user does not have (or did not provide yet) any continuous coordinates for where the pixel data is located.
So:

1. No kdims provided: respect the incoming data aspect
2. kdims provided: create the aspect that the kdims ranges suggest

What do you think?

[jlstevens]

That is equivalent to respecting the aspect for the default (i.e 'x','y') kdims only and not otherwise. You could use redim to rename those dimensions after the fact.

This seems a little bit inconsistent to me: I would prefer to respect the aspect when the bounds are not explicitly supplied, instead of involving the key dimensions.

[michaelaye]

That might be what I mean, I'm still new to holoviews and weak on the vernacular. I'm confused on the different roles of bounds vs key dimensions.

[philippjfr]

The main issue here is that we don't have proper support for aspects, I totally agree that the default behavior should be to respect aspects. That being said I don't think it should be dependent on the way the data was defined, instead I think we should change the default bounds of images to match the shape of the image rather than the arbitrary -0.5 to 0.5 range we currently use.

I'll address the issue referenced in the title shortly.

[philippjfr]

Closing as the bug this issue is nominally about has been fixed. Aspect issues will be addressed once we actually have control over aspects in the bokeh backend.