Tool:Big Browser : a new genom browser in development

Question

[sacha]

Hi,

With student from the University of Rennes in France (Master 2 BIG) we are building a new standalone genom browser similar to IGV. This one is made using the excellent framework Qt5. That means everything is writted in C++ and compiled under windows, linux and mac. ( Troll: and it's faster and prettier than any java app). The main objective of this application is : "Fast and Cute". We focus on a simple user interface and a powerfull data access based on tabix and bedtools. Me (DrIDK) and ikit , are guiding this project. I am a Qt expert and ikit is an IHM expert from industry. The project is under GPL license hosted on github: https://github.com/BIG-Tools/BigBrowser

The project has just started, this is just the beginning. Be free to join us ! You can code, propose suggestion, find bug, translate. If you want to start right now, You can install QtSDK , clone the project and run it from qtcreator by opening src/BigBrowser.pro.

We also have a mailling list : https://groups.google.com/forum/#!forum/bigbrowser if you want to register.

To conclude, Here is a preview of the current state of BigBrowser

[ablanchetcohen]

Great idea! I was thinking exactly the same thing. IGV is slow ... IGV is an excellent genome browser, but I've always wondered how much faster a browser with equivalent functions would be in C++. I even considered writing it myself, but quickly realized the scale of the project.

I'm really curious to see if it's possible to build a faster, and portable, version of IGV in C++.

[sacha]

Actually we are cloning igv file type. That means BB and IGV will be compatible

[John]

Awesome! :)

[sacha]

C++ versus java.. you already have the answer :)

[John]

meh. It depends on who codes it... I don't use Java, in fact I don't like it -- but it can be very fast. I wouldnt assume writing it in C will make things faster. Innovation will make it faster. Time, effort and energy will make it faster. I am confident you can do it though :)

[sacha]

Your are right.. I just like to troll java ! We will do our best !

[John]

I would seriously consider an Canvas/WebGL interface in addition to (or instead of) the Qt interface. I know you're an expert in Qt, but if I can't run it on a server and visualize it locally, then I can't use it! :( Can this be done with Qt? (I honestly don't know, not trying to be rude)

[sacha]

I wonder why do you want to run from a server and use webGL. Do you mean a non-gui server app which provide data for a web browser?

BB will be able to communicate with Rest API. That's mean it will behave like a web browser gettings his data from a server.

[pmarijon]

Maybe we can use asm.js for build a web version but isn't the main goal of project.

[John]

Yup, exactly that. A restful API and an in-browser viz so we can look at alignment across the network easily :)

[sacha]

It's same. Exept you are using BB instead of firefox.

[John]

OK, that works too then :)

[Zev.Kronenberg]

sacha How long until bam support? IGV freezes of my 16GB MBP when viewing segmental duplications.

Answer 1

[Ann]

Suggestion:

Make sure to do due diligence - learn from other genome browsers.

IGV is only one of many that have been developed by many groups - starting in 1988 with ACeDB.

Genome browsers are essential tools in genomics. Anyone that deals with genomic data needs to visualize it. Developers in this space now know a lot about which features matter most to users.

Places to start:

• Integrated Genome Browser (developed by my group): http://www.bioviz.org http://biorxiv.org/content/early/2015/09/15/026351 http://biorxiv.org/content/early/2015/11/26/025924
• ACeDB and its successor Zmap, a fast genome browser implemented in C http://www.sanger.ac.uk/science/tools/zmap
• Savant, introduced arcs to indicate connections between different sites, no longer being developed

Web-based, using Scala, JavaScript:

• Mango, aims to handle big data, https://github.com/bigdatagenomics/mango
• Trackster, part of the Galaxy system; lets users visualize how changing parameters affect analysis results
• JBrowse, very mature project, lots of users

There are many more.

Good luck!

Also, this review article (I wrote it) may be helpful:

http://bmcbioinformatics.biomedcentral.com/articles/10.1186/1471-2105-3-19

[Ann]

And of course, handling chromosome synonyms, as Istvan mentioned in his comment, is one such key feature that is important to users.

Handling chromosome and also genome version synonyms was one of the first features IGB users requested, back when it was developed at Affymetrix.

To handle genome synonyms, best thing is to build a curated list and package it with the software, while also enabling users to add their own custom synonyms.

The Galaxy project includes a curated list and so does IGB. I'm sure there are more. Ideally there would be a REST Web service that software can use to retrieve all known synonyms of a genome version or chromosome name. Maybe there is one already?

Answer 2

[Istvan Albert]

Two suggestions (things that annoy me the most with IGV):

• easy remapping chromosome names (time and again I have to jump over hoops just because datasources name the same sequences differently)
• reading and visualizing GenBank and EMBL files

Answer 3

[sacha]

There is also a IRC channel on irc.freenode.net , chan : #bigbrowser

Answer 4

[sacha]

Here is a first video showing the progression of development . This is not a release video ! Only a preview of what actually has been done.

https://www.youtube.com/watch?v=Y7ouuS8Ooo0

[Ann]

Looks like you are using overview-plus-detail to implement jump-zooming to a new location.

I think this is nice. UCSC, IGB, and many other genome browsers implement this same type of interaction. It's a great idea to re-use these conventions because then your interface will feel familiar to users who have already learned these same interaction modes with other tools. When they come to your tool, they will already have a sense of how it works.

It think it's a good idea for developers to design software so that users do not have to think about the interface. Ideally, users will spend all their mental energy thinking about science and data, not the mechanics of how to use the software.

One potential pitfall however is that some genomes don't have a cytological map. Or, if they do, it may not precisely map onto the sequence map. At this level of resolution, it may not matter too much.