dendrograms / astrodendro

Generate a dendrogram from a dataset
https://dendrograms.readthedocs.io/
Other
37 stars 38 forks source link

Make BasicDendrogramViewer extensible #94

Open tomr-stargazer opened 10 years ago

tomr-stargazer commented 10 years ago

I'm working on dendrogramming Tom Dame's CO datacube, which is much longer along one axis than the other two, and so the default Viewer performs poorly for imagecube slices with that aspect ratio.

As a temporary fix, I've forked astrodendro to implement my own "workaround" in the style of this gist. In the long term, it would be interesting if I could write my own Viewer classes that extend BasicDendrogramViewer and can be used in place of it.

image

As an even better "bonus", it would be wonderful if the extensibility allowed for me to put in multiple "image" panels, so that (e.g.) I could see both an (l, b) and an (l, v) slice at the same time, or even add a GUI button that let me toggle between the two.

This is something that I'd be happy to help develop over the coming weeks, and could probably submit a pull request with my own idea of how to "extensibilize" BasicDendrogramViewer, in it if that would be helpful.

astrofrog commented 10 years ago

@tomr-stargazer - I'm all for making the DendrogramViewer more flexible! To some extent, we need to make sure that we don't reinvent Glue (cc @ChrisBeaumont) so it might be worth seeing how much the code here can be extended, versus how much Glue could be used instead. If you can show what you were thinking, it might help understand how much overlap there is with Glue.

tomr-stargazer commented 10 years ago

Thanks for the quick feedback! I agree that Glue is definitely worth looking into; I haven't used it yet even though I've seen and heard lots about it.

Among the upgrades I'm hoping for:

ChrisBeaumont commented 10 years ago

Since there is ~no dendrogram support in Glue yet, I am definitely in favor of figuring out the important features for interactive analysis within this package, and then porting over to Glue (for the cross-file support and more robust UI stuff). We should keep the Glue use-case in mind when adding new features, to make it easier to port

I think multiple selections and #95 would be more straightforward to implement than the multiple image panels thing, so I would start there first. Of course, Glue will solve the multiple image panel thing automatically