How does the GenomeBrowse genome browser from Golden Helix compare to IGV?
What are the pros and cons?
To answer the question directly, I can enumerate some of the differences between GenomeBrowse and IGV. IGV is the established player for sure and there are many features there that have grown on the product over the years that are not yet in GenomeBrowse (or that don't make sense as GenomeBrowse does things like zoom or stacking differently).
So here are pros GenomeBrowse's perspective:
Pros:
Here are some pros for IGV
I'm sure I'm missing more on the IGV side as I'm obviously more of an expert with our own tool, but someone who has more experience with IGV can feel free to edit and append.
I have tried the latest GenomeBrowse for 10 min or so. I think it can be improved. The first showstopper for me is registration. I know it is more of a personal opinion - I do not like that (usually I would stop if I were asked to fill such a long form just for trying a tool that is supposed to be easy to use). Being unable to import my own reference/annotations is another major drawback. I have seen in your tutorial the responsiveness is quite good, but on your remote exome data (as I cannot import a genome to view my local data), it is very slow. I was just scrolling up and down in a 1kb region. I would think data downloading from your server is not an issue in that case. In addition, if I zoom in/out too much in the pileup view, I will lose the entire view, leaving me a gray area. On zooming, I have not found a way to zoom into a region (I have tried double-click and ctrl/shift-click, but they are not working, at least not always in the way I would expect); I also need finer zooming scale. I think you should allow users to colorize alignments based on mapping quality (IGV highlights mapQ=0 reads, which is not enough for me but is still better than nothing). To me, that is crucial feature - mismapping is a major source of artifact. I have not found an indel, but ideally, you should display the entire inserted/deleted sequence (I know IGV is no better; this is my major complaint about IGV). This helps to see if a false SNP is caused by misalignment around indels. In all, I think GenomeBrowser looks more beautiful and has a few nice features, but overall, IGV is better and faster at my hand.
Thanks for the feedback!
For registration, I understand your personal preference. I was much in the same camp once. We have it there for similar reasons why IGV and GATK require registration. The account you create provides a login to our community site as well for example.
In my mind, we are not a full IGV competitor until we have the ability to add your own speicies reference/annotations is drawback. But we felt it was worth getting out the door as many people on human and other model organisms can immediately get value by using it. These features will come.
I'm not sure why you can't view a local BAM file though. Please just follow the prompt to download the human reference the first time you add a human BAM (or really any model organism, we've curated quite a few). I think you won't get a proper experience loading the remote Exome examples otherwise. The performance there is decent but not as good as it could be. I think what you are experience as you zoom is is just the lag while we load quite of bit of data remotely (note the "cylon" bar throbbing on the plot as it loads).
There are two zoom modes, one is click-n-drag to select a region and the other is through the scroll wheel where you can click-n-pan the view. Using the zoom slider is more of a backup to those primary zoom controls.
We do colorize alignments based on mapping quality. MQ=0 reads are grey by default. You can click on the gear in the top left of the pile-up plot and choose different colorized, stacking and filtering options (like filtering out MQ=0 alignments).
We also do display the full inserted sequence in both the coverage and pile-up view. When you hover over an insertion it shows the sequence. I would suggest going to position Chr5: 139,931,591 - 139,931,669 to see examples in the exome trio data.
In terms of speed though, comparing our network based BAM/reference sequence to IGV with local sources is not quite fair. I definitely encourage you to load local BAM files and let the built-in downloader download the reference. The reason we don't allow you to just pick a FA file is we including species meta-data and coverage (GC content) on top of that to provide a fluid experience.
Thanks again for giving it a try!
On speed, I know what I should expect. I don't think network load is the problem. I am looking at a 1kb region without moving around. Little network traffic occurs. I don't have human data on my laptop. That is why I have not imported local data.
Importing users' genomes should really be at the top top top priority. It is surprising to me that you have all the other features but without allowing users to load their own genomes - that would be one of the first features if I were to implement a viewer. Frequently I do not need fancy features. I just want to see my alignment in an informative and convenient way! By showing inserted sequences, I mean to add padding to the reference sequence instead of just showing "I". I am using Mac's trackpad. I still have not figured out how to zoom in a convenient way. You should implement a way similar to UCSC: shift/control a selected region to zoom.
Ok, I can certainly agree you of all people should know what to expect.
But thanks for letting me know you are using the track pad of a Mac to look through stuff. There are two issues that are hurting the performance there. One is we can't render as quickly on Mac. The drawing path just isn't as fast with the technology stack on Mac as it is on Windows and Linux. When trying to understand why, we quickly go down the rabbit whole of how Macs' 2D graphics libraries prefer to be called etc. I'm hopeful we might improve this in the future, but it's definitely a slower frame rate. That said, my MacBook Air still is pretty fluid when using an external mouse with a scroll wheel to zoom around. It's only slightly noticeably slower than Windows. But that gets to our second issue: our handling of the mouse track pad pinch-to-zoom events. The Mac OS X generates hundreds of events a second and we have not figured out the best way to "interpolate" the user's intentions. We can't draw at 100 or 1000 frames per second, and right now we try to sample the events as well as we can but it's definitely sub-optimal at this point.
Windows and Linux have much faster draw rates and people with mice have much more fluid zooming experience. I wish your demoing experience didn't hit all our weakest machine configuration points! But that's where it's at.
In terms of people adding their own genomes, it really is top top priority! But what we are doing now is curating and shipping genomes on request with a turn around of less than a week if you email genomebrowse@goldenhelix.com. Our current customers of SVS can curate their own genomes, but we want to improve the experience for folks doing it from GenomeBrowse. The decision was to ship and let people with many common species have the tool to start using (which we might agree is a large portion of users) or wait till we have this feature in there.
Thanks for taking the time to respond with your feedback.
Since you posted this the event handling on Mac that caused the perceived slow responsiveness has been nagging me. I spent some time last Saturday night hacking on it and came up with away to compress the input events so we can be responsive and let the Mac do it's thing with the touch pad scroll events to give the feel of "momentum" when flicking your fingers.
So in our 1.1.1 release we shipped on Friday, the responsiveness and rendering experience on Mac is 1000% better. It may even be as fast as windows but I would need identically speced hardware to know for sure.
Also, based on your comments, I added a button to the log-in screen (go to File-> Log Out if you are logged in to see it) to open a fully loaded demo project without the need to register. I hope this serves as a venue to experience the tool and gives you a sense of what you are registering to use. Also, it gets you right into a documented project that showcases some of GenomeBrowse's strength and differentiators.
Let me know if you give 1.1.1 a try and have any more comments on it.
Great responsiveness and communication! Before this exchange I never knew what to make of your tool GenomeBrowse, there was no way to see how serious and committed you all were. But I am very impressed and I can now see that it is not the typical corporate software development process. Instead you exhibit the startup mentality where people take great pride in the product and want to do the right thing.
I will investigate the product more closely and I will recommend others to do so.
I really appreciate that response. People often over-estimate our size as a company and we do operate like a startup in the ways you mentioned (necessarily, as we are bootstrapped and have to be agile enough to survive in this market).
Thanks for the feedback and keep it coming.
Thanks. Speed-wise, it is much better now, arguably better than IGV. Mac's trackpad also works. As to finer zooming, I realize that I can drag on the zooming slide bar. I was assuming IGV-like discretized zooming and was clicking "+" and "-" buttons. When I use it the proper way, zooming experience is better than with IGV.
I would change the title to request an opinion without the qualifier of "any good" that seems a little bit judgmental from the get go.
I have downloaded the tool but I found the interface confusing and did not pursue it further - but I admit that I did not spend too much time with it.
Then some time later (2-3 months) when I wanted to look at it again it denied running saying that my license expired and that I would be required to download a new version. It was then when I noticed that it also installed a hidden program something called "licensing server" that I believe was always running in the background even when the browser was not active. I found both of these practices unacceptable, first that they can revoke my access at any time as well as installing hidden programs that are not visible or known to me.
Overall this turned me off from using this tool or recommending it to others.
As it turned out later and explained by a representative of the company this has been a misunderstanding on my part. The tool was hard coded to expire and the licensing server must have been installed by some other software.
I apologize for the incorrect statements made with respect of this software.
Please please do not spread FUD about my tool that is inaccurate and uninformed. We worked very hard to build it and give it away for free in as easy to use manner as possible.
GenomeBrowse is not licensed, the message you saw was that older versions "expire" (maybe poor choice of words, more like is "deprecated") simply because we are moving the development forward quickly and can't commit to supporting all the network annotation tracks for versions that are over 3 months old. All the message was telling you was to please download the latest version. The message was just hard coded to go off at a certain date.
We ABSOLUTELY DO NOT install a license server or any other programs on your computer other than the files in the GenomeBrowse folder. We try to make the install painless to remove. We DO NOT leave any programs running in the background.
We work very hard to make the user experience very intuitive to get started and have youtube videos showing you around the interface as well as quick start guides.
If you didn't get to the point of actually experience any of the features in depth, please be specific about that so others can judge the tool on it's own merits.
If you want to see GenomeBrowse in action, you can also watch webinars that we give and record for free such as the one I gave yesterday on comparing secondary analysis pipelines between Complete Genomics, Illumina Genome Network and BWA-GATK.
My apologies.
From what you describe it must have been some other tool that was running the "licensing server". It was the message generated by your tool that the software expired that made me look for a reasons of how would it even know that. I found another program running that seemed to cause it and I have jumped to conclusions.
Having a hard coded behavior that tells users that the browser expired and then refuses to run without installing a new version is not a common behavior. It should be a simple and non intrusive message to remind users to upgrade.
But even so my statements were incorrect and I apologize for claiming the tool installs a licensing server and I will correct my statements above,
I appreciate you retracting the comment. Thanks for clearing it up.
I totally understand the behavior was not-standard. We put it in there at the last minute as we cut out scope for a better update notification/built-in updater system we were hoping to have for our 1.0 release but didn't' have time to build.
We have since change the message to be more of a friendly reminder to check for updates but still allow you to run it.
We also have added a non-obstructing notification in the bottom right of the GenomeBrowse window when an update is available (It just says "Update Available!" and takes you to the download page).
I think I'll remove the non-standard hard-coded to go off in 3 months blocking dialog entirely in the next bug fix release.
Thanks for the feedback.
I have downloaded and checked the MacOS version superficially due to Istvan's concerns. The mac package does not contain any file such as "licen[sc]e". Also, after starting the GenomeBrowser I didn't see any suspicious processes. That should not be interpreted as if mean to say the software is safe or clean, or anything. Certainly, use of a free and "open-source" model would be recommended. I would also recommend to consider the FOS approach to you, Gabe. That will easily deflect any mistrust that could possibly arise, so the "FUD" you Gabe are complaining about, is partly the result of the closed source approach, so you better get used to it.
The registration process was fairly quick, it asked for the main contact data including phone and email, in principle you have to enter them all, but it seemingly doesn't make an attempt to validate them in any way. I would have no problem to register a software with my office address and phone if it was really good and could be used in a project.
Showstopper: not being able to import my own genome and annotation. In my project, are working with sea lice, which have no public genome yet, and hence are not in the list. Otherwise I might have recommended GenomeBrowse, as one of many alternatives in a list of "free" tools, as it is now, it is unfortunately no alternative to IGV at all. So here come my 2ct for making a successful genome browser:
Thanks for checking it out.
I understand that coming from a commercial company, you convey some trust in the company and brand by running their binaries on your system. I'm not sure having a open source code base would change this. We would still be distributing binaries and need to overcome that trust threshold (I wouldn't want to wish the process of compiling GenomeBrowse from source on anyone, mostly because it requires the latest Qt 4.8.2 which even on linux is a pain to compile from source and on windows requires a full MSVC compiler).
Totally realize your own species genomes and annotations are a show stopper. GenomeBrowse isn't feature complete without them and not a replacement for IGV for users who need that. I hope when we get those features in there you'll give it another look and see if you can recommend it to colleagues.
Thanks again for the feedback.
Use of this site constitutes acceptance of our User Agreement and Privacy Policy.
version 2.3.6
Well, different users have different preferences. Why not try yourself? It is only a matter of ~10min. Two years ago, I did not like it for read alignment. Don't know now.