[Gmod-gbrowse] [Gmod-help] Re: wiggle_xyplot smoothing
Timothy Parnell
Timothy.Parnell at hci.utah.edu
Thu Oct 7 15:06:27 EDT 2010
Hi Dan,
I'm not sure I understand whether you're trying to compare the bigwig data to data stored in a wig file (referenced in a B:D:SF:Store database) or stored directly in the B:D:SF:Store database (as GFF features with scores).
If you're trying to get the bigwig data to look identical to B:D:SF:Store source data, then you'll need to convince the bigwig db adaptor to return features (used by the xyplot glyph), and not the statistical summary that wiggle_xyplot glyph expects. Set the following
database = bigwig_source_database
feature = region
glyph = xyplot
graph_type = line
group_on = type
If you're instead trying to get the bigwig source data to look like wig source data, then I'm stumped as to why they look different. You're using wiggle_xyplot glyph for both, then, right? The arguments should be identical for both, with the exception of database and feature.
Tim
On 10/7/10 10:04 AM, "Dan Bolser" <dan.bolser at gmail.com> wrote:
On 2 June 2010 21:31, Lincoln Stein <lincoln.stein at gmail.com> wrote:
> Sorry you've had such a miserable time of it. I am hoping to throw out
> Bio::Graphics::Wiggle entirely and replace it with a pure-perl
> implementation of Bio::DB::BigWig. The naive storage system used in BGW just
> doesn't work well across large regions. I recommend Bio::DB::BigWig if at
> all possible.
I didn't immediately find information on how to configure GBrowse to
use Bio::DB::BigWig, so here is my config (I came here because I was
seeing a similar smoothing problem, which is not yet fully resolved):
Under the [GENERAL] section:
database = basic
# see '[basic:database]' below
#db_adaptor = Bio::DB::SeqFeature::Store
#
#db_args = -adaptor DBI::mysql
# -dsn www-potato:my.mysql.host
## -namespace gb_pot_agp
# -user me
# -pass secret
Just before the [TRACK DEFAULTS] section:
[basic:database]
db_adaptor = Bio::DB::SeqFeature::Store
db_args = -adaptor DBI::mysql
-dsn www-potato:my.mysql.host
# -namespace gb_pot_agp
-user me
-pass secret
[bigwig:database]
db_adaptor = Bio::DB::BigWig
db_args = -bigwig '/path/to/my/bigwig_file.bw'
[clonesLink_bigwig]
database = bigwig
feature = summary
glyph = wiggle_xyplot
graph_type = line
bgcolor = black
fgcolor = black
height = 50
min_score = 0
max_score = 10
scale = right
category = Link
key = finally
I think the feature has to be 'summary', so I'm not sure if you can
have more than one track per database.
I'm still seeing differences between the track produced by the BigWig
database adaptor and the track produced using the SeqFeature::Store
database adaptor, unlike the situation reported above. For this
reason, I'm not sure if I set the step and span options correctly...
here is a sample of the GFF / WIG:
chr04 dundee link intensity 1 1000 0 . . Name=Exhaust
chr04 dundee link intensity 1001 2000 1 . . Name=Exhaust
chr04 dundee link intensity 2001 3000 1 . . Name=Exhaust
track type=wiggle_0 name='link intensity' description='Exhaust'
fixedStep chrom=chr04 start=1 step=1000 span=1000
Attached is an image to confirm the (slight) difference in smoothing
behaviour of the two resulting tracks.
Cheers,
Dan.
# fun for everyone!
irc://irc.perl.org/#gmod
#also good!
irc://irc.freenode.net/#bioperl
> Lincoln
>
> On Wed, Jun 2, 2010 at 3:26 PM, Timothy Parnell
> <Timothy.Parnell at hci.utah.edu> wrote:
>>
>> Hi Dave,
>>
>> I identified the source of the problem and possible workarounds/fixes.
>>
>> The problem stems from the formatting of my wig file. The wig file I am
>> using is a variable step wig file that contains the microarray data value
>> recorded at just the probe's midpoint. However, when it is converted to the
>> binary file, it apparently is converted to a 1 bp fixed step, where all the
>> intervening positions are undef. If I use a custom script to pull data out
>> of the wib file, it is in 1 bp increments, with undef values at all
>> positions intervening the real values.
>>
>> The problem comes when the zoom level (in bp) exceeds the pixel resolution
>> of the track png. The image renderer apparently pulls out a data value at
>> every n'th position from the wig file across the region. If the value at
>> that position is undef, it simply extends the value from the previously
>> found position. This essentially gives the appearance of smoothed data, as
>> it may only come across a real value every so often across the region.
>>
>> There are two workarounds, which I have confirmed works for me. The first
>> is to generate a new wig file at 1 bp fixed step by interpolating the values
>> between the real number positions. The second is to use Lincoln's new
>> adaptor, Bio::DB::BigWig, which fundamentally works differently by pulling
>> out features with scores, rather than assuming a fixed 1 bp step interval.
>> The BigWig adaptor produces a track indistinguishable from a track produced
>> using the SeqFeature::Store database adaptor.
>>
>> The fix would be in the appropriate Graphics adaptor
>> (wiggle_xyplot.pm????) to first toss out all the undef values prior to down
>> sampling for rendering the track.
>>
>> I hope this helps.
>> Tim
>>
>>
>> On 6/1/10 5:35 PM, "Dave Clements, GMOD Help Desk" <help at gmod.org> wrote:
>>
>> Hi Timothy,
>>
>> I submitted a bug on this. See
>>
>>
>> https://sourceforge.net/tracker/?func=detail&aid=3010143&group_id=27707&atid=391291
>>
>> Dave C.
>>
>> On Tue, May 25, 2010 at 3:10 PM, Timothy Parnell
>> <Timothy.Parnell at hci.utah.edu> wrote:
>> Hi Dave,
>> Yes, I forgot to mention this in my first email. I'm using the latest
>> relevant distributions available from CPAN.
>>
>> GBrowse-2.08
>> Bio-Graphics-2.09
>> BioPerl-1.6.1
>>
>> I have not tried checking anything out from the live developer versions.
>> Should I try those?
>>
>> Tim
>>
>>
>>
>>
>> On 5/25/10 3:54 PM, "Dave Clements, GMOD Help Desk" <help at gmod.org> wrote:
>>
>> Hi Timothy,
>>
>> I'm pretty sure this is a a bug. I know the wig rendering code has been
>> touched in the last year or so. What version of GBrowse is this happening
>> in? I'm hopeful that upgrading will solve this problem.
>>
>> Dave C.
>>
>> On Mon, May 24, 2010 at 9:02 AM, Timothy Parnell
>> <Timothy.Parnell at hci.utah.edu> wrote:
>> Hello,
>>
>> I'm having issues with the smoothing of wiggle data when rendering a track
>> in GBrowse. Specifically, turning smoothing off.
>>
>> I have the same high resolution microarray data loaded both into a
>> SeqFeature::Store database as well as binary wiggle files (via the
>> wiggle2gff3.pl <http://wiggle2gff3.pl> <http://wiggle2gff3.pl> script).
>> Viewing tracks from each data source gives vastly different graphs (see
>> attached image). It's most apparent with the histogram plot. It appears that
>> the wiggle track is automatically binning the data to smooth it. However, I
>> anticipate the "noisy" data as seen in the database track, and it would be
>> nice to see it in the wiggle track.
>>
>> I have set the smoothing option to "none" in the wiggle track
>> configuration, but GBrowse appears to be ignoring this line. The smoothing
>> occurs at zoom levels above 2 kb, whereas at 1 kb or below the tracks are
>> the same. I can pull the data back out of the database and wiggle files
>> (using either custom scripts or downloading track data from GBrowse) and the
>> data is identical (within expectations of converting the data to 8-bit
>> dynamic range).
>>
>> Is there a way to control the semantic automatic smoothing of wiggle data?
>> Is my configuration set incorrectly? Or is this a bug?
>>
>> My track conf is below:
>>
>> [sample_chip_wig1]
>> feature = deg_con_ratio_mono1_wig
>> glyph = wiggle_xyplot
>> graph_type = histogram
>> height = 50
>> scale = left
>> label = 0
>> autoscale = global
>> bicolor_pivot = zero
>> pos_color = blue
>> neg_color = red
>> smoothing = none
>> smoothing_window = 1
>> key = sample_chip_wig1
>>
>> [sample_chip_db1]
>> feature = deg_con_ratio_mono1_244k
>> glyph = xyplot
>> graph_type = histogram
>> height = 50
>> scale = left
>> fgcolor = black
>> min_score = -2
>> max_score = 2
>> label = 0
>> group_on = display_name
>> key = sample_chip_db1
>>
>> Thanks for any assistance
>>
>> --
>>
>> Timothy J Parnell, PhD.
>> Research Associate
>> Howard Hughes Medical Institute
>> Department of Oncology
>> Huntsman Cancer Institute
>> University of Utah
>> Salt Lake City, UT 84112
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Gmod-gbrowse mailing list
>> Gmod-gbrowse at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Gmod-gbrowse mailing list
>> Gmod-gbrowse at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse
>>
>>
>>
>
>
>
> --
> Lincoln D. Stein
> Director, Informatics and Biocomputing Platform
> Ontario Institute for Cancer Research
> 101 College St., Suite 800
> Toronto, ON, Canada M5G0A3
> 416 673-8514
> Assistant: Renata Musa <Renata.Musa at oicr.on.ca>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Gmod-gbrowse mailing list
> Gmod-gbrowse at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse
>
>
More information about the Gmod-help
mailing list