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.<div>
<br></div><div>Lincoln<br><br><div class="gmail_quote">On Wed, Jun 2, 2010 at 3:26 PM, Timothy Parnell <span dir="ltr"><<a href="mailto:Timothy.Parnell@hci.utah.edu">Timothy.Parnell@hci.utah.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi Dave,<br>
<br>
I identified the source of the problem and possible workarounds/fixes.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
The fix would be in the appropriate Graphics adaptor (<a href="http://wiggle_xyplot.pm???" target="_blank">wiggle_xyplot.pm???</a>?) to first toss out all the undef values prior to down sampling for rendering the track.<br>
<br>
I hope this helps.<br>
Tim<br>
<div class="im"><br>
<br>
On 6/1/10 5:35 PM, "Dave Clements, GMOD Help Desk" <<a href="mailto:help@gmod.org">help@gmod.org</a>> wrote:<br>
<br>
Hi Timothy,<br>
<br>
I submitted a bug on this. See<br>
<br>
<a href="https://sourceforge.net/tracker/?func=detail&aid=3010143&group_id=27707&atid=391291" target="_blank">https://sourceforge.net/tracker/?func=detail&aid=3010143&group_id=27707&atid=391291</a><br>
<br>
Dave C.<br>
<br>
On Tue, May 25, 2010 at 3:10 PM, Timothy Parnell <<a href="mailto:Timothy.Parnell@hci.utah.edu">Timothy.Parnell@hci.utah.edu</a>> wrote:<br>
Hi Dave,<br>
Yes, I forgot to mention this in my first email. I'm using the latest relevant distributions available from CPAN.<br>
<br>
GBrowse-2.08<br>
Bio-Graphics-2.09<br>
BioPerl-1.6.1<br>
<br>
I have not tried checking anything out from the live developer versions. Should I try those?<br>
<br>
Tim<br>
<br>
<br>
<br>
<br>
On 5/25/10 3:54 PM, "Dave Clements, GMOD Help Desk" <<a href="mailto:help@gmod.org">help@gmod.org</a>> wrote:<br>
<br>
Hi Timothy,<br>
<br>
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.<br>
<br>
Dave C.<br>
<br>
On Mon, May 24, 2010 at 9:02 AM, Timothy Parnell <<a href="mailto:Timothy.Parnell@hci.utah.edu">Timothy.Parnell@hci.utah.edu</a>> wrote:<br>
Hello,<br>
<br>
I'm having issues with the smoothing of wiggle data when rendering a track in GBrowse. Specifically, turning smoothing off.<br>
<br>
</div>I have the same high resolution microarray data loaded both into a SeqFeature::Store database as well as binary wiggle files (via the <a href="http://wiggle2gff3.pl" target="_blank">wiggle2gff3.pl</a> <<a href="http://wiggle2gff3.pl" target="_blank">http://wiggle2gff3.pl</a>> <<a href="http://wiggle2gff3.pl" target="_blank">http://wiggle2gff3.pl</a>> 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.<br>
<div><div></div><div class="h5"><br>
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).<br>
<br>
Is there a way to control the semantic automatic smoothing of wiggle data? Is my configuration set incorrectly? Or is this a bug?<br>
<br>
My track conf is below:<br>
<br>
[sample_chip_wig1]<br>
feature = deg_con_ratio_mono1_wig<br>
glyph = wiggle_xyplot<br>
graph_type = histogram<br>
height = 50<br>
scale = left<br>
label = 0<br>
autoscale = global<br>
bicolor_pivot = zero<br>
pos_color = blue<br>
neg_color = red<br>
smoothing = none<br>
smoothing_window = 1<br>
key = sample_chip_wig1<br>
<br>
[sample_chip_db1]<br>
feature = deg_con_ratio_mono1_244k<br>
glyph = xyplot<br>
graph_type = histogram<br>
height = 50<br>
scale = left<br>
fgcolor = black<br>
min_score = -2<br>
max_score = 2<br>
label = 0<br>
group_on = display_name<br>
key = sample_chip_db1<br>
<br>
Thanks for any assistance<br>
<br>
--<br>
<br>
Timothy J Parnell, PhD.<br>
Research Associate<br>
Howard Hughes Medical Institute<br>
Department of Oncology<br>
Huntsman Cancer Institute<br>
University of Utah<br>
Salt Lake City, UT 84112<br>
<br>
<br>
------------------------------------------------------------------------------<br>
<br>
<br>
_______________________________________________<br>
Gmod-gbrowse mailing list<br>
<a href="mailto:Gmod-gbrowse@lists.sourceforge.net">Gmod-gbrowse@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse" target="_blank">https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse</a><br>
<br>
<br>
<br>
<br>
------------------------------------------------------------------------------<br>
<br>
_______________________________________________<br>
Gmod-gbrowse mailing list<br>
<a href="mailto:Gmod-gbrowse@lists.sourceforge.net">Gmod-gbrowse@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse" target="_blank">https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse</a><br>
<br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Lincoln D. Stein<br>Director, Informatics and Biocomputing Platform<br>Ontario Institute for Cancer Research<br>101 College St., Suite 800<br>Toronto, ON, Canada M5G0A3<br>
416 673-8514<br>Assistant: Renata Musa <<a href="mailto:Renata.Musa@oicr.on.ca">Renata.Musa@oicr.on.ca</a>><br>
</div>