glue-viz / glue Goto Github PK
View Code? Open in Web Editor NEWLinked Data Visualizations Across Multiple Files
Home Page: http://glueviz.org
License: Other
Linked Data Visualizations Across Multiple Files
Home Page: http://glueviz.org
License: Other
The imagewidget uses right mouse gestures to adjust image bias/contrast, a la ds9. However, this conflicts with other mouse modes (namely the pan/zoom mode). The bias/contrast gestures should be moved to a mouse mode, so these gestures don't conflict
Let users do the equivalent of
subset = (subset1 & subset 2) || (ra > 5 and ra < 6 and dec > 10 and dec < 20)
Integrate into GUI
Iterate once more on GUI design, fleshing out some details (like the specific size of elements, menu navigation)
How should selections be applied across data? Automatically? Manually as done now? Should their be a visual indication of which data sets are linked? Should the visual properties of linked data sets sync up?
In other words, what is the most intuitive way to do cross-data linking?
RasterAxes are needed for interactive plotting once a catalog grows to more than ~1000 entries.
Normal axes provide more functionality at the moment, so perhaps they should be retained for small catalogs. Can the code swap out axes when needed?
the histogram client doesn't use point size or symbol, for example. It would be better to disable these columns for that widget
Should basically do what sandbox/glueapp.py does
Maybe this involves coordinate grids with AplPy? Or maybe we display the world coordinates of the mouse in the Qt Information window?
We need to better think about how to link data and subsets when we create subsets. Also, we need to think about circular references a bit harder in general.
If a subset is registered to a data set before a client is registered to a hub, the client misses that message. Upon registration to the hub, it should make sure it knows about all the subsets in the data.
The Multiple Document Interface widget in QT stores multiple moveable, resizable widgets on a canvas. It provides a tile method in an attempt to move/resize each window so they use all available space and fill the screen. However, it is buggy (it moves the entire Glue Application partially off-screen).
Perhaps we should implement our own window layout method to address the "screen real estate" problem
Let's come up with a couple of nice use-cases that show the power behind Glue's cross-data linking. We can build tutorials around them
Should be able to navigate to file-> open data to load new data
What is the easiest and fastest way to get Glue to install on new machines for .astronomy?
Goals include
Scatter client crashes when trying to plot components which aren't one dimensional.
Traceback with a 2D data set:
Traceback (most recent call last):
File "/Users/beaumont/Library/Python/2.7/lib/python/site-packages/glue/qt/scatterwidget.py", line 116, in update_xatt
self.client.set_xdata(component_id)
File "/Users/beaumont/Library/Python/2.7/lib/python/site-packages/glue/scatter_client.py", line 290, in set_xdata
self.set_xydata('x', attribute, snap=snap)
File "/Users/beaumont/Library/Python/2.7/lib/python/site-packages/glue/scatter_client.py", line 254, in set_xydata
map(self._update_layer, (l for l in self.managers))
File "/Users/beaumont/Library/Python/2.7/lib/python/site-packages/glue/scatter_client.py", line 432, in _update_layer
self.managers[layer].set_data(x, y)
File "/Users/beaumont/Library/Python/2.7/lib/python/site-packages/glue/scatter_client.py", line 59, in set_data
xy[:, 0] = x
ValueError: operands could not be broadcast together with shapes (13911267) (27767,501)
For .astronomy, we should have at a minimum:
Should use LinkManager to keep virtual / derived components in sync. Gluing/ungluing should interface with the LM.
ROIs currently defined in coordinate space. This occasionally leads to unexpected / buggy behavior due to the spherical geometry (for example, ROI's which straddle the l=360 line are incorrect). Pixel coordinates are euclidian, and thus the ROIs should always behave sensibly
after loading irdcs.fits
Traceback (most recent call last):
File "/Users/beaumont/Library/Python/2.7/lib/python/site-packages/glue/qt/widgets/layer_tree_widget.py", line 346, in
lambda: LinkEditor.update_links(self._data_collection))
File "/Users/beaumont/Library/Python/2.7/lib/python/site-packages/glue/qt/link_editor.py", line 59, in update_links
widget = cls(collection)
File "/Users/beaumont/Library/Python/2.7/lib/python/site-packages/glue/qt/link_editor.py", line 17, in init
self._init_widgets()
File "/Users/beaumont/Library/Python/2.7/lib/python/site-packages/glue/qt/link_editor.py", line 25, in _init_widgets
self._add_link(link)
File "/Users/beaumont/Library/Python/2.7/lib/python/site-packages/glue/qt/link_editor.py", line 34, in _add_link
item = QListWidgetItem(str(link))
File "/Users/beaumont/Library/Python/2.7/lib/python/site-packages/glue/core/component_link.py", line 97, in str
result = "%s <- %s(%s)" % (self._to, self._using.name, args)
AttributeError: 'int' object has no attribute 'name'
Hi!
pyqt causes trouble when I do a dumb pip install - some advice for users on the docs would be great!
Thanks,
Phil
Currently, there are several circular dependencies in the backend. One example:
I attempted to add "from client import Client" to hub.py, and "from hub import Hub" to client.py. Python doesn't like this.
What's the best way to deal with this? Put the base classes for the backend (Hub, Data, Subset, Client) in a single module?
Play with the scatter client using a couple of different data sets. Walk through a few use cases. Where are the rough edges? File issues and address the most important
the component link widget's title is 'form'. Change it to something meaningful
Glue should read data easily. Currently, Glue punts if it hits an error when parsing with atpy. Many times, these errors can be fixed by tweaking which catalog format to expect, what denotes a comment line, etc.
There should be a more fleshed out "data load wizard" that walks the user through loading data, letting him fiddle with these options until the data can be read.
When loading images, Glue currently punts if hit hits unexpected astrometric information. It should deal with this more gracefully. Probably, this means skipping the step where it creates world coordinates.
What do we want to do if we get time for a .astronomy hack session? User studies? Implementing new features?
I think the current interface for the data class is too restrictive for our future goals. The simple list of regularly-gridded, in-memory numpy arrays for each component will prove problematic for, e.g., larger-than-memory data and variable resolution data sets (perhaps backed by YT data objects).
This poses a problem for viz clients, which use the current Data interface pretty heavily (i.e. they directly access the numpy component arrays). As it stands, if we were to build support for the above data types, we'd have to either
As an alternative to this, I propose we create a higher-level API for the data class, so that viz clients can extract the information they need without knowing the low-level representation of the data. In other words, instead of an image client extracting a component numpy array directly, it would call a method like data.extract_image(image_properties). The various data types each have their own class, and override these methods.
I'm getting this idea by looking over how yt works -- yt has general methods to, e.g., created fixed resolution images from various simulations for generic visualization. If we adopt a similar approach, we can guarantee that our viz clients will continue to work with whatever data classes we dream up.
There are still downsides to this approach -- the current clients would need to be updated, of course. Also, the subsets would need some thought (how does the ElementSubset work?)
Thoughts? I can spend some time thinking about how this might work specifically, but wanted to test the water first. Maybe I'm missing something. If we go down this road, I think it would be a good idea to study yt's API, since I bet we could borrow heavily from their interface.
Default plot size for edit subsets should be bigger, for emphasis. Default colors could be made more intelligent, so that similar colors are less likely to overplot
The image client doesn't render pre-existing subsets when first initialized. It should
Subsets should be saveable. They should be readable by Glue, and easily interpreted for use in other environments.
This functionality should be connected to the GUI
The link dialog widget only shows the links defined in the current invokation of the widget. It should display all links, to let the user un-glue old links
Play with the image client using a couple of different data sets. Walk through a few use cases. Where are the rough edges? File issues and address the most important
When activating the contrast mouse mode and then the pan/zoom mouse mode in the image widget, the contrast mode stays active and responds to mouse gestures. It shouldn't
Component lists (in scatter widget, image widget, component link widget) are given in random order. This is confusing for big catalogs with many columns. Alphabetize them
The scatter widget's layer manager doesn't remove data sets when they are deleted -- this is probably intrinsic to the layer manager widget
The editable subsets should be drawn on top of other subsets, so that they can always be seen
We need a way to specify other link logic besides 1:1 in the link_dialog. The code can already handle this -- we just need a way of plugging in other options to the dialog
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.