Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

common vis features #8

Open
volodymyrss opened this issue Feb 21, 2024 · 9 comments
Open

common vis features #8

volodymyrss opened this issue Feb 21, 2024 · 9 comments
Assignees

Comments

@volodymyrss
Copy link
Contributor

volodymyrss commented Feb 21, 2024

  • select bokeh/d3
  • Xerr Yerr
  • LC profile reader, using timedel, timeref
  • Spectrum profile reader

select file and fields to plot in a generic case

https://esg-epfl-apc.github.io/astrojsvis/

@volodymyrss volodymyrss assigned francoismg and unassigned francoismg Feb 21, 2024
@francoismg
Copy link
Contributor

francoismg commented Apr 6, 2024

Interface has 4 containers (graph, settings, header and data)

Graph container contains the generated graph

Settings container contains every options used to generate graph

Header and data container let user explore hdus data

Each containers should be retractable in width and height to account for galaxy narrow plugin space


User can choose between different libraries (?) for plotting and visualization. Right now bokeh and d3 for test purposes but more could be added in order to support different use cases. Maybe even libraries like aladin lite could be added to have an all purpose visualization tool (list of available hdus is updated to match a library capabilities e.g. only image and compressed image extension for aladin lite.....)

library library1

User can choose between data type (light curve, spectrum) or just have a generic plotting without additional options or processing

Each data type enables additional selection like second file for spectrum data (?) (list could be generated with a galaxy history api call)

Type specific variable could be linked to specific header cards value if needed (?)

type type1

User can choose the hdu from which the data will be retrieved and the rest of the settings are updated to list the available data. Will only work for BINTABLE and TABLE extension (as mentioned above that behavior could be modified to adapt to library selection) so right now the other extensions are removed from the list except primary header

hdu hdu1

User can choose which data set will be used for each axis and the type of scale (linear or log)

More options could be added : line, color, customized domain, symbols

axis axis1

User can choose which data should be used for x and y error bars

errorbar errorbar1

User can choose additional data set that should be plotted and add error bars to them

dataset

When a specific hdus is selected its data (BINTABLE and TABLE extension) and header is displayed, could be useful for data selection and header variable also it lets d3 user see the data at disposal like with the bokeh datatable

Should probably be modified so it is not tied to the selected hdus so user can more freely explore the data

data header

Graph is generated given user choices

bokeh d3

@volodymyrss
Copy link
Contributor Author

Looks interesting! Should we do a demo with you, @dsavchenko , maybe @andriineronov ? Today 15h?

@dsavchenko
Copy link
Contributor

Today 15h?

Ok for me

@francoismg
Copy link
Contributor

Looks interesting! Should we do a demo with you, @dsavchenko , maybe @andriineronov ? Today 15h?

Works for me too, like I said at the other meeting not everything is working and there's still some bugs but would be nice too know if it's going in the right direction

@andriineronov
Copy link

Ok for me as well

@francoismg
Copy link
Contributor

francoismg commented Apr 15, 2024

Changes are available on branch https://github.com/esg-epfl-apc/astrojsvis/tree/jsvis-prototype

This is still work in progress so there are still things that are not finished and I haven't tested everything.

The main parts are components, wrappers and visualizations. Most of the flow between them is handled through events that are dispatched to different elements or objects that listen to specific event that are relevant to them.

Standard flow is :

  • fitsReaderWrapper is provided with a fits file url
  • Once the file is loaded and parsed an event is emitted to the event subscribers (Settings, Header and Data components)
  • The components use the fits file to initialize different part of their interface
  • User choose a specific library to use
  • The settings component dispatch an event with the user library choice
  • The corresponding wrapper responds by dispatching a new event holding a specific configuration object
  • Settings component use the config object to adapt its interface to the library choice
  • User choose the settings and click on generation button
  • Settings are transmitted to the relevant wrappers that uses it alongside a DataProcessor to initialize a visualization object
  • Vis object instantiate the visualization in the given element

Components contains the four main interface components (Graph, Settings, Header, Data). Each component inherits from HTMLElement and is responsible for all the elements inside it. All events originating from inner elements are handled by the component that will dispatch them or use them according to the event type.

Wrappers are used to interact with different libraries (Bokeh, D3 and fits-reader right now), they communicate with components through events like 'fits-loaded' that let every event subscribing component know that a fits file has been loaded and is available.

They are responsible for providing their library with the necessary settings they need to instantiate their visualizations and they use specific DataProviders to process the data according to user choices before sending them to a vis library.

Visualizations contains the classes that are directly responsible for instantiating visualizations given a set of parameters provided by the user through their respective wrappers.

I tried to reduce the d3 code as much as possible and everything is now "encapsulated" in different functions so I hope it is more clear that way.


DataProcessors are responsible for processing data from hdus for specific data type (light curve, spectrum.....).

There was a comment about adding support for binning so I started making things but not sure if what I started makes sense. Basically user could choose between binning strategies (time based, arbitrary bin size) and provide a time frame or bin size for the binning process, user can also choose between different method to calculate the bin rate value like min, max, mean, weighted mean based on fracexp etc.....

Helpers represents various utility classes (right now only TimeHelper), I don't know if it's useful but since there could be different time format jd, mjd..... and time based binning I thought maybe it could be of use. Also in mohamed heavens project the user has the possibility to choose between different formats like decimal years.

Events contains the main events that might need more specific behavior than standard CustomEvent, they are dispatched to subscribers or different part of the dom depending on which type of object is listening to them.

Settings contains the settings object that the settings component use to communicate with the wrappers and the configuration object that is used by the wrappers to let the component know what part of its interface should change depending on the user library choice.

Containers contains different kinds of containers that are responsible for instantiating specific objects and make them available to the other classes

Registries right now only holds the registry that keeps tracks of which events components have subscribed to

Errors a few specific exceptions mostly events and fits related


Work in progress :

  • fits reader wrapper can only hold one file at the moment
  • Light curve data processor and D3 + Bokeh wrappers
  • Settings and configuration objects
  • Too much similar code, should be better encapsulated and use inheritance
  • D3 + data list bugs
  • Maybe some code to move from fits reader wrapper to fits reader library

@francoismg
Copy link
Contributor

Changes have been pushed to the branch https://github.com/esg-epfl-apc/astrojsvis/tree/jsvis-prototype

  • Light curve data processor and D3 + Bokeh wrappers (code should be improved)
  • Settings and configuration objects
  • D3 bugs + data list bugs
  • D3 + Bokeh graph objects
  • Too much similar code, should be better encapsulated and use inheritance

Everything seems ok otherwise just need to finish error bars processing for D3 and probably some small bugs here and there.

There's still the questions I mentioned about binning and time handling in the previous comment too.

Will make another comment with screenshots and snippets to illustrate

@volodymyrss
Copy link
Contributor Author

Please open PR, @francoismg

@francoismg
Copy link
Contributor

Please open PR, @francoismg

PR is available here : #12

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants