gmod-ajax

Re: [Gmod-ajax] JBrowse feature requests

[Ian H. <ih...@be...>]

Hi David, I'm ccing this discussion to the gmod-ajax list as some of it 
may be of general interest.

Fabrice David wrote:
> Hello Mitch,
> 
> Thank you very much for your quick reply!
> 
> On Jul 19, 2009, at 5:22 AM, Mitch Skinner wrote:
> 
>> Hello!  I'm always excited when people show interest in JBrowse.  Thanks
>> for being specific with your feedback; I've replied in more detail below:
>>
>> Bernhard Sonderegger wrote:
>>> A y-axis for quantitative tracks (.wig data). The absence of y-axis
>>> label and scale in the display and the absence of configuration
>>> options to select the range and to choose between logarithmic or
>>> linear scales makes it difficult to compare certain types of data.
>>
>> The JBrowse administrator can use the wiggle-processing program's --min
>> and --max command-line options to set the range of the image, and the
>> --height option to set the pixel height.  Or did you mean an option for
>> the end user to set the scale in their web browser?
> 
> Yes, --min and --max options should be sufficient to set the range.
> Zooming in/out dynamically in the web browser would require to generate 
> images for the different levels... As a suggestion, would it be possible 
> to create JSON (transformed into SVG in the browser) instead of an 
> image; like for the gene density view? Then, users could custom both the 
> resolution (bin size), scale and range dynamically. But I guess there is 
> a problem of performance doing this way?

The gene density histogram is actually built of DIV elements, not SVG 
primitives. I believe Internet Explorer cannot render SVGs without a plugin.

Since an early stage we considered implementing the WIGgle (i.e. 
quantitative) tracks in the same way as the gene density histograms. 
Probably this would have been easier... I remember a discussion between 
myself, Mitch and Lincoln Stein at CSHL in 2007...

The drawback is the resolution is not very good: if you put thousands of 
pixel-wide DIVs on the page (as you would need in order to get 
resolution comparable to the PNG images we currently use to display 
quantitative tracks) then the browser gets pretty slow, especially if 
you try to display many such tracks.

For various reasons, we also considered it an important proof of concept 
to have clientside code to display arbitrary chromosome-length images as 
tracks (broken up into managably-sized tile PNGs).

So these were the reasons that our initial implementation of 
quantitative tracks used static images, rather than dynamically 
generated content.

We want to encourage a diversity of track types and styles, however 
(just as GBrowse does), and writing up documentation (so that others can 
add track types) is high on our list.

To take your example, it would certainly be cool to have the an option 
to render quantitative tracks using DIV histograms (just like the gene 
density tracks). For one thing, this would definitely be one way to make 
it easier to implement dynamic behavior (track overlay, track 
subtraction/comparison, dynamic resizing)

I would really encourage you to put these sorts of feature requests 
straight into the lighthouse feature- and bug-tracking system. We would 
like discussions like this to be persistent, and benefit from the 
ongoing accumulation of comments, so that a feature request becomes 
finely-honed by the hive mind often before any code is written. Tracking 
systems can do that, but email is less good for it.

I don't believe you need a lighthouse account to create a ticket (though 
I haven't tried) -- in any case it's easy to get an account.

Thanks so much for your feedback -- as I hope is clear from the above, 
we value it highly.

Cheers!
Ian


>> I've also added some new tickets to our  bug tracking system:
>>
>> * log scale rendering option is now ticket #33
>> * y-axis display is now ticket #34
>>
>>> When zooming out, narrow peaks sometimes shrink in height. It appears
>>> that the algorithm used to generate the track images takes the average
>>> value across a bin of genomic positions to calculate the hight of each
>>> (1 pixel wide) bar in the display instead of using the maximum. It
>>> would be nice to have an option to select the max.
>>
>> I agree; this is ticket #35.  I intend to add both min and max, and
>> possibly display all three at the same time.
>>
>>
>>> Comparing tracks by displaying them side-by-side is not always
>>> sufficient to reveal differences between highly similar tracks. An
>>> additional action to allow superposition of two pre-calculated tracks
>>> would be helpful. This would of course require the background of the
>>> pre-calculated images to be fully transparent and the foreground to be
>>> partially transparent. Transparency is supported by the .png format so
>>> the substance of implementing this feature would involve the drag-and
>>> drop action to superpose tracks.
>>
>> This is ticket #36.  So far, I've avoided using transparency because it
>> slowed down panning and zooming (significantly, on some platforms), but
>> if transparency only occurs in specific situations and the user can turn
>> it off (by un-superposing the tracks) that should be fine.  Or, web
>> browser technology may advance enough that my speed concerns will go
>> away.  Either way, this functionality clearly serves a need by helping
>> users compare tracks to each other.
>>
>> Do you think it's okay to superpose two tracks that have different
>> scales?  We could certainly just superpose the tracks as-is and call it
>> done, possibly including displaying more than one axis.  But it would be
>> difficult to try and match the axes of the two tracks (e.g., by scaling
>> and offsetting them), especially if one of them was logarithmic and the
>> other linear.
> 
> In the case of superposed tracks, we should probably avoid confusion 
> having multiple scales; and assume that values in the different tracks 
> are directly comparable. Then, indeed, if the different tracks have not 
> the same scale/range, we should notice it easily having superimposed and 
> unreadable scales. But, this is less true for the type of display (if we 
> use the min or the max to display the histogram - ticket #35). Then we 
> could be comparing tracks that are actually not comparable. Thus, it 
> should be probably useful to set constraints about which tracks can be 
> superposed in TrackInfo.js. Following these constraints people could 
> superimpose or not tracks by drag-and-drop.
> However, there is still a problem about superimposing several images: 
> the z-index matters. As Bernhard proposed, you could use 
> semi-transparency for the foreground, and/or maybe also add another 
> option to render the tracks as single lines instead of histograms; 
> allowing the comparison of more than 2 tracks. What do you think about 
> this?
> 
>>
>>
>>> Thanks for your feed-back on my suggestions, and keep up the good work
>>> developing JBrowse.
>>
>> Thanks!
>>
>> Mitch
> 
> 
> Thanks again to have added these tickets!
> Have a nice week-end,
> 
> Fabrice

Re: [Gmod-ajax] JBrowse feature requests

[Mitch S. <mi...@ar...>]

To add a little bit to what Ian said:

Fabrice David wrote:
> Zooming in/out dynamically in the web browser would require to 
> generate images for the different levels... As a suggestion, would it 
> be possible to create JSON (transformed into SVG in the browser) 
> instead of an image; like for the gene density view? Then, users could 
> custom both the resolution (bin size), scale and range dynamically. 
> But I guess there is a problem of performance doing this way?

Yes, the reason we're using pre-rendered images is for performance, and 
also to support Internet Explorer (which doesn't have SVG).  The web 
browser is able to scale (and offset) pre-rendered images on the client 
side though, which is something I'd like to implement at some point.  
But that scaling couldn't switch between log and linear scales.

> In the case of superposed tracks, we should probably avoid confusion 
> having multiple scales; and assume that values in the different tracks 
> are directly comparable. Then, indeed, if the different tracks have 
> not the same scale/range, we should notice it easily having 
> superimposed and unreadable scales. But, this is less true for the 
> type of display (if we use the min or the max to display the histogram 
> - ticket #35). Then we could be comparing tracks that are actually not 
> comparable. Thus, it should be probably useful to set constraints 
> about which tracks can be superposed in TrackInfo.js. Following these 
> constraints people could superimpose or not tracks by drag-and-drop.

Well, I could imagine data sources with different scales that you might 
want to compare.  Say, comparing microarray expression data with RNA-seq 
expression data, maybe.  I don't know if people would really want to do 
that, but I do think that people might want to compare tracks with 
different scales.  My main concern is about how those differences ought 
to be reflected in the user interface.

I think we can wait until we start implementing this functionality to 
make some of these decisions, though.

> However, there is still a problem about superimposing several images: 
> the z-index matters. As Bernhard proposed, you could use 
> semi-transparency for the foreground, and/or maybe also add another 
> option to render the tracks as single lines instead of histograms; 
> allowing the comparison of more than 2 tracks. What do you think about 
> this?

Yes, the z-index matters, but setting the z-index should be do-able, 
although it might require some changes to the way ImageTrack.js.  Or 
maybe I'm misunderstanding the problem you're talking about?

One issue will be semi-transparency support in IE 6; we'll have to do 
some experiments to see what (if anything) works there.

By "render the tracks as single lines instead of histograms", you mean 
using color to indicate the quantitative value?  That's definitely high 
on the to-do list (ticket #7).  That will probably get done before 
superimposing tracks.

Mitch

Re: [Gmod-ajax] JBrowse feature requests

[Bernhard S. <Ber...@ep...>]

I have signed up for a lighthouse account and am watching the tickets of 
interest to me. Should we move these comments/discussions there? For the 
moment, I've inserted a few comments in the cited text below.

Bernhard

On 07/23/2009 07:42 AM, Mitch Skinner wrote:
> To add a little bit to what Ian said:
>
> Fabrice David wrote:
>    
>> Zooming in/out dynamically in the web browser would require to
>> generate images for the different levels... As a suggestion, would it
>> be possible to create JSON (transformed into SVG in the browser)
>> instead of an image; like for the gene density view? Then, users could
>> custom both the resolution (bin size), scale and range dynamically.
>> But I guess there is a problem of performance doing this way?
>>      
>
> Yes, the reason we're using pre-rendered images is for performance, and
> also to support Internet Explorer (which doesn't have SVG).  The web
> browser is able to scale (and offset) pre-rendered images on the client
> side though, which is something I'd like to implement at some point.
> But that scaling couldn't switch between log and linear scales.
>
>    
>> In the case of superposed tracks, we should probably avoid confusion
>> having multiple scales; and assume that values in the different tracks
>> are directly comparable. Then, indeed, if the different tracks have
>> not the same scale/range, we should notice it easily having
>> superimposed and unreadable scales. But, this is less true for the
>> type of display (if we use the min or the max to display the histogram
>> - ticket #35). Then we could be comparing tracks that are actually not
>> comparable. Thus, it should be probably useful to set constraints
>> about which tracks can be superposed in TrackInfo.js. Following these
>> constraints people could superimpose or not tracks by drag-and-drop.
>>      
>
> Well, I could imagine data sources with different scales that you might
> want to compare.  Say, comparing microarray expression data with RNA-seq
> expression data, maybe.  I don't know if people would really want to do
> that, but I do think that people might want to compare tracks with
> different scales.  My main concern is about how those differences ought
> to be reflected in the user interface.
>
> I think we can wait until we start implementing this functionality to
> make some of these decisions, though.
>
>    

I actually have someone doing exactly what you mention here -- comparing 
rna-seq to expression data from tiling arrays.
As you say, the important thing is that the user notices the differences 
in scales. However, brings up an additional problem. Should the user be 
able to apply different y-axis zoom factors to different superimposed 
tracks? In the rna-seq/tilin array example, this would be useful.

>> However, there is still a problem about superimposing several images:
>> the z-index matters. As Bernhard proposed, you could use
>> semi-transparency for the foreground, and/or maybe also add another
>> option to render the tracks as single lines instead of histograms;
>> allowing the comparison of more than 2 tracks. What do you think about
>> this?
>>      
>
> Yes, the z-index matters, but setting the z-index should be do-able,
> although it might require some changes to the way ImageTrack.js.  Or
> maybe I'm misunderstanding the problem you're talking about?
>
> One issue will be semi-transparency support in IE 6; we'll have to do
> some experiments to see what (if anything) works there.
>
> By "render the tracks as single lines instead of histograms", you mean
> using color to indicate the quantitative value?  That's definitely high
> on the to-do list (ticket #7).  That will probably get done before
> superimposing tracks.
>    

What is meant here is to have a line plot instead of a bar plot. (i.e. 
just the upper border of the current solid surface in each plot)

> Mitch
>