Hi Philip,
Yes I would propose something which is swappable i.e. the plotting is well separated from the algorithm/data. So plotting details do not leak into eclipse parts,
instead they interact with an interface. Any design we choose should have to be abstract – including from underlying plot objects (draw2d figures, javafx scene graphs, jogl objects etc. are all not in the interface!).
At Diamond, we have had several plotting engines (3) in the past, so we have learned this over a hard earned period of time. It would mean that anyone could
contribute a plotting system (by extension point) and that any user from the group can swap plotting whenever they need – providing there is an implementation. I can imagine that we would want to swap the javafx 1D plotting into the interface fairly soon!
– tying ourselves to any particular plotting engine would be a bad idea. Although I am a fan (most of the time) and would-be contributor to xy-graph.
I would be willing to send around the interfaces with examples how to use them later this month if people want that. I suggest that the package be org.eclipse.scisoft.xxx
where scisoft stands for scientific software.
Nomenclature: Can we name the plotting type after the dimensionality of the data? This gives room in the nomenclature to have a name for images which cannot
be called 3D – so they must be 2D!
Xy-graphs, scatter, pie, area -
1D (e.g. XY-Graphs are1D data shown with two axes)
Images, surfaces, contours, vector plots -
2D (Note surfaces are 2D data shown with 3 axes and using 3D scene graph)
Iso-surface, other volume rendering -
3D? (They are slices from 3D data)
Best Regards,
Matt
From: science-iwg-bounces@xxxxxxxxxxx
[mailto:science-iwg-bounces@xxxxxxxxxxx] On Behalf Of Philip Wenig
Sent: 02 November 2013 11:45
To: science-iwg@xxxxxxxxxxx
Subject: Re: [science-iwg] Review BoF EclipseCon
Hi Matt,
I think that's a great idea to have APIs and abstract respectively generalized methods and views for 2D and 3D data. Attached are two screenshots of DAWN and OpenChrom. Both screenshots show profiles, despite the fact that both have completely different data
models (XRD and GC/MS). Hence, it would be great to have an unified and flexible API. Moreover, it would be great use the existing knowledge and to build upon the interfaces and methods that are already available in DAWN, Bioclipse, OpenChrom and others.
----------------------------------
Profile Views
----------------------------------
2D / 3D
Variable measurement units and descriptions for each Axis
1st Derivative
2nd Derivative
...
Overlay
----------------------------------
Profile Methods
----------------------------------
Smoothing Algorithms (Savitzky-Golay, ...)
Peak Detektion (1st Derivative, ..., Deconvolution, ...)
Peak Integration (Gaussian model, ...)
Peak Fitting (Correlation Optimized Warping, Dynamic Time Warping, ...)
...
In my opinion, such abstract handling of profile data would make it much more easier for others (students, post-docs, scientists, ...) to implement additional algorithms. Furthermore, data from different detectors like XRD, NMR, GC/FID, GC/MS MS/MS could be
handled in an unified way as long as it produces profile data. In addition, all specific calculations can still be executed by specialized frameworks for e.g. XRD (DAWN) or GC/MS (OpenChrom). Wouldn't that be great?
“As long as your going to be thinking anyway, think big.” Donald Trump
Cheers,
Philip
Hi Philip,
Yes it was a very positive step, well done in getting it organised. I am willing to write the documents and circulate these for agreement as we agreed.
Diamond are able and, subject to review, interested in providing interfaces and a reference implementation for all of the features mentioned in the meeting, including everything in Jans recent email. I have a concrete idea of how this could happen and we can detail this in the documents. We would obviously start gradually so that the searches of license agreement can be performed on each API provided. In fact even more gradual than that - we should agree on interfaces of each module, I can provide the starting point for these too including examples of how to use the API. The APIs are elegant and powerful to use and I hope you will like them.
Since the talk I did at eclipse con was not busily attended, I am looking forward to the video of the demonstration being available on the youtube channel. Then people can see how cool the features the team here has worked on are, and decide if they are interested in working with us.
Best Regards,
Matt
-----Original Message-----
From: science-iwg-bounces@xxxxxxxxxxx [mailto:science-iwg-bounces@xxxxxxxxxxx] On Behalf Of Philip Wenig
Sent: 01 November 2013 13:17
To: science-iwg@xxxxxxxxxxx
Subject: [science-iwg] Review BoF EclipseCon
Hi folks,
the BoF was fantastic, wasn't it!
I really feel that the time has come to bring our idea of a scientific working group to reality :-).
Best
Philip
--
~~~~~~~~~~~~~~~~~~~~~~~~
Dr. Philip Wenig
http://www.openchrom.net
https://www.xing.com/profile/Philip_Wenig
http://de.linkedin.com/pub/philip-wenig/2a/4a8/877
~~~~~~~~~~~~~~~~~~~~~~~~
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
