Handling coefficients equivalent for swt

[zaccharieramzi]

I noticed that there is no utility like coeffs_to_array or ravel_coeffs for the swt. It could be quite helpful for plotting for example (or the other reasons we have them for wavedec).

[grlee77]

Although not apparent from the PR title, the ability to set trim_approx=True as proposed in #476 allows the existing ravel_coeffs and unravel_coeffs to work with the swt functions. This is even tested as part of that PR. The only changes to the internals of those functions are the ability to specify the names swt, swt2 and swtn in addition to the wavedec ones.

I didn't look into adding support to coeffs_to_array, Unlike the decimated case, all coefficients have the same shape (neglecting boundary extension) so there is not any way to pack them into an array of approximately the same dimensions as the original input as was done for the wavedec functions. My impression was that coeffs_to_array is mainly useful to compactly visualize the coefficients, but I'm not sure if it provides any benefit over having ravel_coeffs for applications? I suppose some sort of equivalent could be conceived, but the form of tiling would have to be different.

[zaccharieramzi]

Well in the case of coeffs_to_array you can still have n_level images of size (2 * im_shape, 2 * im_shape) where you would have in the top left corner the approximation coeffs at that level of decomposition, at the top right the horizontal detail coefficients, etc...
That would be if you had trim_approx=False.

I see how it is maybe a little bit too specific, but I was actually more interested in ravel_coeffs and was giving coeffs_to_array more as an example.

[grlee77]

#476 added swt support to ravel_coeffs and unravel_coeffs when swt is called with trim_approx=True