BLAST results should display an overview graphic

[wwood]

Hi,

I seem to be more complaining than contributing code. Sorry about that.

In wwwblast, there is a graphic that comes with the BLAST results. It allows you to quickly get a sense of the number of hits, the coverage of those hits on the query sequence, and the strength of the sequence similarity.

Potentially, this might be achieved by using Bio::Graphics
https://github.com/jandot/bio-graphics
http://bio-graphics.rubyforge.org/
in conjuction with a BioRuby parser of the BLAST output.

One potential issue with this setup is that BioRuby cannot currently parse the default text output of BLAST, instead requiring XML or tab-separated outputs. Does this mean that the call to BLAST should return XML and not the default textual output? Doing so would mean that code to convert the XML into human-readable text/HTML needs to be written, but perhaps this is a good thing anyway so that the output is more suitable for web-pages? e.g. each hit has a different colour background to make them easier to tell apart.

Thanks,
ben

[yannickwurm]

Yes, please :)

A possible solution could be to use the intermediate output.
In BLAST+ they have a blast formatter script where. 1. you run blast and specify the intermediate output, 2. you use the formatter script to get your final output. That way you can get several different outputs from a single blast run (eg: text AND xml).

In 2.2.24 it didn't work as advertised (not at all if I remember correctly). But perhaps it does in newer versions. That could avoid the need for running multiple blasts for a single query...

[wwood]

Thanks for the suggestion of blast_formatter. I just ran some prototype code using blast_formatter 2.2.25+, and it seemed to work as I would have hoped. I'll try to incorporate that into a new branch now.

[wwood]

I got this working in wwood@51f66c25ff but it is far from perfect - probably not worth your time even looking at it at this stage.

bio-graphics is a bit of a pain to install. I had to install 2 different packages in Ubuntu:

sudo apt-get install libpango1.0-dev libcairo2-dev

Then install the gems

gem install pango cairo bio-graphics

Given this difficulty, which is probably too much effort for the average biologist, I suggest we make it an optional thing. That is, if we can successfully require bio-graphcs then we put the graphics in. Otherwise we do without it. Unless there's a simpler way?

Thanks,
ben

[yannickwurm]

Hi Ben,

indeed, biographics is a nightmare to install.
I have failed to succesfully get things running on my mac. Am stuck with:
/Users/yannickwurm/.rvm/gems/ruby-1.8.7-p334/gems/glib2-0.90.8/lib/glib2.bundle: [BUG] Segmentation fault

YARG!

On 29 May 2011, at 20:46, wwood wrote:

I got this working in wwood@51f66c25ff but it is far from perfect - probably not worth your time even looking at it at this stage.

bio-graphics is a bit of a pain to install. I had to install 2 different packages in Ubuntu:

sudo apt-get install libpango1.0-dev libcairo2-dev

Then install the gems

gem install pango cairo bio-graphics

Given this difficulty, which is probably too much effort for the average biologist, I suggest we make it an optional thing. That is, if we can successfully require bio-graphcs then we put the graphics in. Otherwise we do without it. Unless there's a simpler way?

Thanks,
ben

Reply to this email directly or view it on GitHub:
#21 (comment)

[yeban]

I am not very keen on using bio-graphics. I would prefer designing our own small, and simple library to do the visualization stuff.

[yannickwurm]

Hmmm..
why not?
If it stays hard to install (I was unsuccessful), its indeed difficult to justify using it.

DOn't you think that designing an alternate graphcis lib would induce just as many dependencies?

But in any case we will need to stick with bioruby's blast parser (which should remain up to date).

On 14 Jun 2011, at 22:10, yeban wrote:

I am not very keen on using bio-graphics. I would prefer designing our own small, and simple, library to do the visualization stuff.

Reply to this email directly or view it on GitHub:
#21 (comment)

[yeban]

why not?

Too many dependencies, which includes pago markup library, and cairo graphics library. I am apprehensive of getting the dependency tree big. First there are these libs, then the ruby wrapper on top of them, and then bio-graphics. Too many things can go wrong at too many levels. Besides, I am not sure of their development status. bio-graphics seems to be last updated on Apr, 2008.

I guess bio-graphics outputs images, and then you embed the image, and then you embed the images. In our case it probably will be simpler, and more useful to format blast results with proper HTML, and CSS.

DOn't you think that designing an alternate graphcis lib would induce just as many dependencies?

Doesn't need to be. Can't be sure yet though unless I understand really well what it would take to implement this. We will need to talk about this at length on IM.

Basically, depending on our needs the advantages of rolling our own lib, might outweigh the advantages of using bio-graphics.

[yannickwurm]

What do you think Ben?

Concerning what should be in an overview graphic, we have several options. One would be to copy what NCBI do. Another may be to provide more information within the blast graphic.

• perhaps a clear physical separation of ranges of e-values (yes NCBI uses colors, but users don't understand them).
• within each hit, can we provide info about the lengths of the hits, and alignment coordinates?
• what about indicating where things align very well and less well (eg: by color intensity)
• Other ideas? (is it possible to provide visual info about the targets as well as the query?)

[wwood]

Given you are having problems installing bio-graphics Yannick (and it took a bit of fiddling on my end too), I would say it is unsuitable for our purposes. However, given that we are probably going to display graphics similar to the ones bio-graphics comes up with, should we fix bio-graphics instead of just abandoning it? By fix I mean remove the dependencies on pago and libcairo.

Whether we modify bio-graphics or not, I would think a pure ruby graphics library would be best, but can't find any that are useful and still maintained by a quick google. Any ideas? RMagick is the one that jumps out at me, but that requires imagemagick to be installed separately.

I like the idea of innovating - I agree it isn't obvious to the users what the colours mean. For a start I think they should convey e-values, not bit scores. Maybe annotate the query sequence to show where it has been masked for low complexity? How about joining HSPs intuitively (that would be particularly useful for tblastx)? [yw: yes that would be wonderful. when joining HSPs we have to take care that were joining them in "possible" orders... not if they cannot be joined (eg if something is duplicated or reversed)]

[yeban]

Whether we modify bio-graphics or not, I would think a pure ruby graphics library would be best,

Since we intend the BLAST output to be viewed on a browser, I think we can totally avoid images (and a graphics library) in favor of pure HTML, and CSS.

RMagick is not very actively maintained. Last I checked they were looking for a new maintainer to take it up.

[yannickwurm]

Good ideas. There's a young ruby-only SVG (which is xml) library here: https://github.com/aseldawy/rasem ....

[yeban]

I am open to exploring SVG as an option. Just a little apprehensive about browser support.

[yeban]

And I forgot to mention Raphael, which makes it super easy to create rich, interactive UI (given that we need such functionality). I have been meaning to give it a try since ages.

[yannickwurm]

just stumbled onto an easy solution on biostar:

• apply the following stylesheet http://code.google.com/p/lindenb/source/browse/trunk/src/xsl/blast2svg.xsl

taken from: http://biostar.stackexchange.com/questions/277/how-to-convert-blast-results-to-gff

[yannickwurm]

there may be an advantage to outputting into an intermediary format (such as GFF) and then parsing and displaying from there.
Why?

1. it should represent the same amount of work.
2. it will make our code more flexible for the future (many programs output GFF)
3. genome annotation information is usually in GFF format. Coding things "around" GFF may give us the flexibility of concurrently displaying GFF information at a point in the distant future. (lets not turn 1.0 into bloatware!)