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

Serialization of Viewer #117

Closed
javierbq opened this issue Aug 24, 2015 · 5 comments
Closed

Serialization of Viewer #117

javierbq opened this issue Aug 24, 2015 · 5 comments

Comments

@javierbq
Copy link

Hi Marco,

Thanks for making such beautiful, the performance is just amazing.

Is there any way to serialize a the contents of a viewer and reload them into another viewer?

I tried dumping the contents into a JSON but I get a circular reference error.

JSON.stringify( $scope.viewer.all())
VM33605:1 Uncaught TypeError: Converting circular structure to JSON
    at Object.stringify (native)
    at eval (eval at evaluate (unknown source), <anonymous>:1:6)
    at Object.InjectedScript._evaluateOn (<anonymous>:905:55)
    at Object.InjectedScript._evaluateAndWrap (<anonymous>:838:34)
    at Object.InjectedScript.evaluateOnCallFrame (<anonymous>:964:21)

Thanks!

Javier

@biasmv
Copy link
Owner

biasmv commented Aug 24, 2015

Hi Javier,

as of now, there is no support for serializing of the viewer and saving its state. I agree that this would be very useful to have. This will take a while to implement, though as there will need to be custom serialization code for many of the viewer classes. It doesn't make sense to just store the complete objects as is, as the geometries themselves are rather big and the saves state would rather quickly reach multiple megabytes. Instead, the simplest representation that can be used to recreate the geometry would need to be saved.

Depending on what your exact use-case is, a simpler approach to serialization might already work. Could you elaborate for what you would like to use the serialization?

Best,
Marco

@javierbq
Copy link
Author

Hi Marco,

I am trying to serialize the viewer so I can store the it in a DB. I really like pymol sessions because you can save models with their representation. I am thinking on implementing this by doing something like CSS that cascades through the molecule -> chain -> residue -> atom hierarchy.

@biasmv
Copy link
Owner

biasmv commented Aug 25, 2015

Depending on how complex your application is you might be able to serialize the list of commands that were used to create the session, e.g. save the original PDB file together with all the calls to pv.Viewer. A session reload then essentially reapplies all of these commands. I don't remember if that's also what's PyMOL is doing, but certainly other molecular viewers are using the command pattern to store sessions.

In the long term, the ideal solution would be for the viewer to offer a pv.Viewer.saveSession() and pv.viewer.loadSession() pair of methods that do all the magic behind the scenes.

From the top of my head the following parts of the viewer need to be serialized:

  • viewer options such as size, antialias state, background color etc. They are all contained in the options dictionary, so just serializing this should be sufficient.
  • camera parameters such as center, rotation zoom etc. Most of what's stored inside the camera is just cached properties and can be easily recalculated from a small set of properties.
  • the rendered objects. Ignoring custom meshes and labels for now, the following things would need to be serialized: The complete molecular structure they are based on and the structural subset used for displaying. If the molecular structure is used in multiple graphical objects, we need to make sure that the molecular structure is only serialized once. This reduces both size and ensures also in the reloaded session the graphical objects share the same structure.The structural subset (view) could be serialized as a list of selected chains, residues and atoms. In addition, the color (RGBA) and the selected part of the structure would need to be saved as well. Lastly, we would need to save the parameters that were used to create the object (render style, detail level etc). That's all that's needed. All other data of graphical objects can be recreated from these.

Thinking about this again, it's probably not going to be too bad to implement. I'd guess 1 day of work should be sufficient to get most of it going. But it's still going to be 1 day and I'm not sure I have the time for this right now. Depending on how quickly you need this, you will have to work on this on your own.

@javierbq
Copy link
Author

Thanks Marco,

I will try to implement it myself.

Cheers,

Javier

@biasmv
Copy link
Owner

biasmv commented Sep 1, 2015

OK, cool! I might have a little time next week to help out with some parts of it.

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

2 participants