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