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
>