bigwig track rendering failure with sparse data

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

bigwig track rendering failure with sparse data

Timothy Parnell
Hi,

I have a lab mate who is trying to visualize her genomic data with a bigwig file. The data happens to be pretty sparse, for example, maybe a dozen positions or less with a recorded value in a 10 kb window. These tend to fail to render. If you zoom out to 50 or 100 kb, then the track renders properly, presumably because there are now enough data points? If there are no data points in the requested region, then we get an empty track, as expected (no scale bars, only vertical grid lines).

So far, this seems to happen regardless whether the source file was a variableStep wig or bedGraph file.

I hadn't seen this before, but then all my data was fixedStep. I converted her sparse data to a fixedStep wig (assigning 0 to the empty positions, of course), and the track renders beautifully as expected, regardless of zoom level.

Is this a bug, or an unintentional side effect of the data formatting? Has anyone else seen this phenomenon?

Tim


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse
Reply | Threaded
Open this post in threaded view
|

Re: bigwig track rendering failure with sparse data

Timothy Parnell
Just as a followup, I'm including some sample files which should load into
the example Yeast database provided with GBrowse. If you have
Bio::DB::BigFile installed, you should be able to load these files using
the Custom Tracks upload file function. You can confirm the track000.bw
file is generated in the appropriate userdata temp folder. (I have not
tried these in GBrowse without BigFile support installed).

File chrI_sparse is a variableStep wig file with 25 random data points
across chrI.

File chrI_step10 is essentially the same data as fixedStep in 10 bp steps,
with 0 recorded at intervening positions.

Playing with these samples, I've noticed a couple of "rules".

Loading 20 Kb from chrI:141,500..161,499 yields rendered tracks for both.
Zooming in to 5 kb and the chrI_sparse cannot render (only one datapoint
available), while chrI_step10 can (500 datapoints with one non-zero).

Loading any region with two or more datapoints seems to be fine for either
file.

Loading a region with zero datapoints results in an opposite effect. Go to
chrI:161,850..211,849 with a 50 kb region. Both tracks are rendered fine.
Zoom in to 5 kb, where there are no datapoints. Now chrI_sparse correctly
renders an empty track (no datapoints) but chrI_step10 fails to render
(500 datapoints, all zero).

I admit these situations may be relatively rare, but not contrived.

On 3/21/11 11:48 AM, "Timothy Parnell" <[hidden email]>
wrote:

>Hi,
>
>I have a lab mate who is trying to visualize her genomic data with a
>bigwig file. The data happens to be pretty sparse, for example, maybe a
>dozen positions or less with a recorded value in a 10 kb window. These
>tend to fail to render. If you zoom out to 50 or 100 kb, then the track
>renders properly, presumably because there are now enough data points? If
>there are no data points in the requested region, then we get an empty
>track, as expected (no scale bars, only vertical grid lines).
>
>So far, this seems to happen regardless whether the source file was a
>variableStep wig or bedGraph file.
>
>I hadn't seen this before, but then all my data was fixedStep. I
>converted her sparse data to a fixedStep wig (assigning 0 to the empty
>positions, of course), and the track renders beautifully as expected,
>regardless of zoom level.
>
>Is this a bug, or an unintentional side effect of the data formatting?
>Has anyone else seen this phenomenon?
>
>Tim
>
>
>--------------------------------------------------------------------------
>----
>Colocation vs. Managed Hosting
>A question and answer guide to determining the best fit
>for your organization - today and in the future.
>http://p.sf.net/sfu/internap-sfd2d
>_______________________________________________
>Gmod-gbrowse mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse

chrI_sparse.wig.gz (370 bytes) Download Attachment
chrI_step10.wig.gz (744 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: bigwig track rendering failure with sparse data

Lincoln Stein
I'll take a look. Thanks for taking the effort to make the test files.

Lincoln

On Tue, Mar 22, 2011 at 1:44 AM, Timothy Parnell <[hidden email]> wrote:
Just as a followup, I'm including some sample files which should load into
the example Yeast database provided with GBrowse. If you have
Bio::DB::BigFile installed, you should be able to load these files using
the Custom Tracks upload file function. You can confirm the track000.bw
file is generated in the appropriate userdata temp folder. (I have not
tried these in GBrowse without BigFile support installed).

File chrI_sparse is a variableStep wig file with 25 random data points
across chrI.

File chrI_step10 is essentially the same data as fixedStep in 10 bp steps,
with 0 recorded at intervening positions.

Playing with these samples, I've noticed a couple of "rules".

Loading 20 Kb from chrI:141,500..161,499 yields rendered tracks for both.
Zooming in to 5 kb and the chrI_sparse cannot render (only one datapoint
available), while chrI_step10 can (500 datapoints with one non-zero).

Loading any region with two or more datapoints seems to be fine for either
file.

Loading a region with zero datapoints results in an opposite effect. Go to
chrI:161,850..211,849 with a 50 kb region. Both tracks are rendered fine.
Zoom in to 5 kb, where there are no datapoints. Now chrI_sparse correctly
renders an empty track (no datapoints) but chrI_step10 fails to render
(500 datapoints, all zero).

I admit these situations may be relatively rare, but not contrived.

On 3/21/11 11:48 AM, "Timothy Parnell" <[hidden email]>
wrote:

>Hi,
>
>I have a lab mate who is trying to visualize her genomic data with a
>bigwig file. The data happens to be pretty sparse, for example, maybe a
>dozen positions or less with a recorded value in a 10 kb window. These
>tend to fail to render. If you zoom out to 50 or 100 kb, then the track
>renders properly, presumably because there are now enough data points? If
>there are no data points in the requested region, then we get an empty
>track, as expected (no scale bars, only vertical grid lines).
>
>So far, this seems to happen regardless whether the source file was a
>variableStep wig or bedGraph file.
>
>I hadn't seen this before, but then all my data was fixedStep. I
>converted her sparse data to a fixedStep wig (assigning 0 to the empty
>positions, of course), and the track renders beautifully as expected,
>regardless of zoom level.
>
>Is this a bug, or an unintentional side effect of the data formatting?
>Has anyone else seen this phenomenon?
>
>Tim
>
>
>--------------------------------------------------------------------------
>----
>Colocation vs. Managed Hosting
>A question and answer guide to determining the best fit
>for your organization - today and in the future.
>http://p.sf.net/sfu/internap-sfd2d
>_______________________________________________
>Gmod-gbrowse mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse


------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]
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 <[hidden email]>

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse
Reply | Threaded
Open this post in threaded view
|

Re: bigwig track rendering failure with sparse data

Lincoln Stein
In reply to this post by Timothy Parnell
Hi,

Looking into this now. There seem to be inconsistencies in handling "zero" vs "missing" data.

Lincoln

On Tue, Mar 22, 2011 at 1:44 AM, Timothy Parnell <[hidden email]> wrote:
Just as a followup, I'm including some sample files which should load into
the example Yeast database provided with GBrowse. If you have
Bio::DB::BigFile installed, you should be able to load these files using
the Custom Tracks upload file function. You can confirm the track000.bw
file is generated in the appropriate userdata temp folder. (I have not
tried these in GBrowse without BigFile support installed).

File chrI_sparse is a variableStep wig file with 25 random data points
across chrI.

File chrI_step10 is essentially the same data as fixedStep in 10 bp steps,
with 0 recorded at intervening positions.

Playing with these samples, I've noticed a couple of "rules".

Loading 20 Kb from chrI:141,500..161,499 yields rendered tracks for both.
Zooming in to 5 kb and the chrI_sparse cannot render (only one datapoint
available), while chrI_step10 can (500 datapoints with one non-zero).

Loading any region with two or more datapoints seems to be fine for either
file.

Loading a region with zero datapoints results in an opposite effect. Go to
chrI:161,850..211,849 with a 50 kb region. Both tracks are rendered fine.
Zoom in to 5 kb, where there are no datapoints. Now chrI_sparse correctly
renders an empty track (no datapoints) but chrI_step10 fails to render
(500 datapoints, all zero).

I admit these situations may be relatively rare, but not contrived.

On 3/21/11 11:48 AM, "Timothy Parnell" <[hidden email]>
wrote:

>Hi,
>
>I have a lab mate who is trying to visualize her genomic data with a
>bigwig file. The data happens to be pretty sparse, for example, maybe a
>dozen positions or less with a recorded value in a 10 kb window. These
>tend to fail to render. If you zoom out to 50 or 100 kb, then the track
>renders properly, presumably because there are now enough data points? If
>there are no data points in the requested region, then we get an empty
>track, as expected (no scale bars, only vertical grid lines).
>
>So far, this seems to happen regardless whether the source file was a
>variableStep wig or bedGraph file.
>
>I hadn't seen this before, but then all my data was fixedStep. I
>converted her sparse data to a fixedStep wig (assigning 0 to the empty
>positions, of course), and the track renders beautifully as expected,
>regardless of zoom level.
>
>Is this a bug, or an unintentional side effect of the data formatting?
>Has anyone else seen this phenomenon?
>
>Tim
>
>
>--------------------------------------------------------------------------
>----
>Colocation vs. Managed Hosting
>A question and answer guide to determining the best fit
>for your organization - today and in the future.
>http://p.sf.net/sfu/internap-sfd2d
>_______________________________________________
>Gmod-gbrowse mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse


------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]
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 <[hidden email]>

------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf

_______________________________________________
Gmod-gbrowse mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse
Reply | Threaded
Open this post in threaded view
|

Re: bigwig track rendering failure with sparse data

Lincoln Stein
In reply to this post by Timothy Parnell
Hi Tim,

The difference in representation between variable and fixed stepped data is that in the former case regions that fall between annotated regions are "missing", whereas in the latter case you must give them an explicit value, even if it is zero.

I have changed the implementation of the wiggle_xyplot and wiggle_whiskers glyphs in Bio::Graphics so that the scale always gets drawn. This will be released in version 2.20, which I will release as soon as I'm sure this change doesn't introduce any new bugs.

Lincoln
 

On Mon, Mar 21, 2011 at 1:48 PM, Timothy Parnell <[hidden email]> wrote:
Hi,

I have a lab mate who is trying to visualize her genomic data with a bigwig file. The data happens to be pretty sparse, for example, maybe a dozen positions or less with a recorded value in a 10 kb window. These tend to fail to render. If you zoom out to 50 or 100 kb, then the track renders properly, presumably because there are now enough data points? If there are no data points in the requested region, then we get an empty track, as expected (no scale bars, only vertical grid lines).

So far, this seems to happen regardless whether the source file was a variableStep wig or bedGraph file.

I hadn't seen this before, but then all my data was fixedStep. I converted her sparse data to a fixedStep wig (assigning 0 to the empty positions, of course), and the track renders beautifully as expected, regardless of zoom level.

Is this a bug, or an unintentional side effect of the data formatting? Has anyone else seen this phenomenon?

Tim


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]
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 <[hidden email]>

------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf

_______________________________________________
Gmod-gbrowse mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse
Reply | Threaded
Open this post in threaded view
|

Re: bigwig track rendering failure with sparse data

Timothy Parnell
OK, that sounds good. An empty track is better than a scary message about failing to render for most users.

Thanks for looking into it.

From: Lincoln Stein <[hidden email]<mailto:[hidden email]>>
Date: Fri, 1 Apr 2011 08:38:49 -0600
To: Timothy Parnell <[hidden email]<mailto:[hidden email]>>
Cc: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Subject: Re: [Gmod-gbrowse] bigwig track rendering failure with sparse data

Hi Tim,

The difference in representation between variable and fixed stepped data is that in the former case regions that fall between annotated regions are "missing", whereas in the latter case you must give them an explicit value, even if it is zero.

I have changed the implementation of the wiggle_xyplot and wiggle_whiskers glyphs in Bio::Graphics so that the scale always gets drawn. This will be released in version 2.20, which I will release as soon as I'm sure this change doesn't introduce any new bugs.

Lincoln


On Mon, Mar 21, 2011 at 1:48 PM, Timothy Parnell <[hidden email]<mailto:[hidden email]>> wrote:
Hi,

I have a lab mate who is trying to visualize her genomic data with a bigwig file. The data happens to be pretty sparse, for example, maybe a dozen positions or less with a recorded value in a 10 kb window. These tend to fail to render. If you zoom out to 50 or 100 kb, then the track renders properly, presumably because there are now enough data points? If there are no data points in the requested region, then we get an empty track, as expected (no scale bars, only vertical grid lines).

So far, this seems to happen regardless whether the source file was a variableStep wig or bedGraph file.

I hadn't seen this before, but then all my data was fixedStep. I converted her sparse data to a fixedStep wig (assigning 0 to the empty positions, of course), and the track renders beautifully as expected, regardless of zoom level.

Is this a bug, or an unintentional side effect of the data formatting? Has anyone else seen this phenomenon?

Tim


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]<mailto:[hidden email]>
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 <[hidden email]<mailto:[hidden email]>>

------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse
Reply | Threaded
Open this post in threaded view
|

Re: bigwig track rendering failure with sparse data

Lincoln Stein
Were you seeing the failing to render message? I encountered it and tracked it down to a divide-by-zero error, but it wasn't in your bug report.

Lincoln

On Fri, Apr 1, 2011 at 11:36 AM, Timothy Parnell <[hidden email]> wrote:
OK, that sounds good. An empty track is better than a scary message about failing to render for most users.

Thanks for looking into it.

From: Lincoln Stein <[hidden email]<mailto:[hidden email]>>
Date: Fri, 1 Apr 2011 08:38:49 -0600
To: Timothy Parnell <[hidden email]<mailto:[hidden email]>>
Cc: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Subject: Re: [Gmod-gbrowse] bigwig track rendering failure with sparse data

Hi Tim,

The difference in representation between variable and fixed stepped data is that in the former case regions that fall between annotated regions are "missing", whereas in the latter case you must give them an explicit value, even if it is zero.

I have changed the implementation of the wiggle_xyplot and wiggle_whiskers glyphs in Bio::Graphics so that the scale always gets drawn. This will be released in version 2.20, which I will release as soon as I'm sure this change doesn't introduce any new bugs.

Lincoln


On Mon, Mar 21, 2011 at 1:48 PM, Timothy Parnell <[hidden email]<mailto:[hidden email]>> wrote:
Hi,

I have a lab mate who is trying to visualize her genomic data with a bigwig file. The data happens to be pretty sparse, for example, maybe a dozen positions or less with a recorded value in a 10 kb window. These tend to fail to render. If you zoom out to 50 or 100 kb, then the track renders properly, presumably because there are now enough data points? If there are no data points in the requested region, then we get an empty track, as expected (no scale bars, only vertical grid lines).

So far, this seems to happen regardless whether the source file was a variableStep wig or bedGraph file.

I hadn't seen this before, but then all my data was fixedStep. I converted her sparse data to a fixedStep wig (assigning 0 to the empty positions, of course), and the track renders beautifully as expected, regardless of zoom level.

Is this a bug, or an unintentional side effect of the data formatting? Has anyone else seen this phenomenon?

Tim


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]<mailto:[hidden email]>
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
<a href="tel:416%20673-8514">416 673-8514
Assistant: Renata Musa <[hidden email]<mailto:[hidden email]>>



--
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 <[hidden email]>

------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf

_______________________________________________
Gmod-gbrowse mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse
Reply | Threaded
Open this post in threaded view
|

Re: bigwig track rendering failure with sparse data

Timothy Parnell
Actually, the error was
"Track rendering error: Timeout; Try turning off tracks or looking at a smaller region."

I see this using the chr1_step10 wig file I included earlier (uploaded and converted to bigwig), at coordinates chrI:184,350..189,349. The chrI_Randomized file shows an empty track.

Note that I've set the details multiplier to 1. Otherwise, you could include data points outside of your view and preclude seeing the error.

I am using GBrowse 2.26, Bio::Graphics 2.18, and BigFile 1.04. I just noticed I was a little out of date, and updated to Bio::Graphics 2.19 and BigFile 1.06. Still the same error.

From: Lincoln Stein <[hidden email]<mailto:[hidden email]>>
Date: Fri, 1 Apr 2011 09:44:29 -0600
To: Timothy Parnell <[hidden email]<mailto:[hidden email]>>
Cc: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Subject: Re: [Gmod-gbrowse] bigwig track rendering failure with sparse data

Were you seeing the failing to render message? I encountered it and tracked it down to a divide-by-zero error, but it wasn't in your bug report.

Lincoln

On Fri, Apr 1, 2011 at 11:36 AM, Timothy Parnell <[hidden email]<mailto:[hidden email]>> wrote:
OK, that sounds good. An empty track is better than a scary message about failing to render for most users.

Thanks for looking into it.

From: Lincoln Stein <[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>>
Date: Fri, 1 Apr 2011 08:38:49 -0600
To: Timothy Parnell <[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>>
Cc: "[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>" <[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>>
Subject: Re: [Gmod-gbrowse] bigwig track rendering failure with sparse data

Hi Tim,

The difference in representation between variable and fixed stepped data is that in the former case regions that fall between annotated regions are "missing", whereas in the latter case you must give them an explicit value, even if it is zero.

I have changed the implementation of the wiggle_xyplot and wiggle_whiskers glyphs in Bio::Graphics so that the scale always gets drawn. This will be released in version 2.20, which I will release as soon as I'm sure this change doesn't introduce any new bugs.

Lincoln


On Mon, Mar 21, 2011 at 1:48 PM, Timothy Parnell <[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>> wrote:
Hi,

I have a lab mate who is trying to visualize her genomic data with a bigwig file. The data happens to be pretty sparse, for example, maybe a dozen positions or less with a recorded value in a 10 kb window. These tend to fail to render. If you zoom out to 50 or 100 kb, then the track renders properly, presumably because there are now enough data points? If there are no data points in the requested region, then we get an empty track, as expected (no scale bars, only vertical grid lines).

So far, this seems to happen regardless whether the source file was a variableStep wig or bedGraph file.

I hadn't seen this before, but then all my data was fixedStep. I converted her sparse data to a fixedStep wig (assigning 0 to the empty positions, of course), and the track renders beautifully as expected, regardless of zoom level.

Is this a bug, or an unintentional side effect of the data formatting? Has anyone else seen this phenomenon?

Tim


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>
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<tel:416%20673-8514>
Assistant: Renata Musa <[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>>



--
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 <[hidden email]<mailto:[hidden email]>>

------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse
Reply | Threaded
Open this post in threaded view
|

Re: bigwig track rendering failure with sparse data

Lincoln Stein
The bug is fixed in Bio::Graphics 2.20. It may not have propagated to all CPAN mirrors yet.

Lincoln

On Fri, Apr 1, 2011 at 12:26 PM, Timothy Parnell <[hidden email]> wrote:
Actually, the error was
"Track rendering error: Timeout; Try turning off tracks or looking at a smaller region."

I see this using the chr1_step10 wig file I included earlier (uploaded and converted to bigwig), at coordinates chrI:184,350..189,349. The chrI_Randomized file shows an empty track.

Note that I've set the details multiplier to 1. Otherwise, you could include data points outside of your view and preclude seeing the error.

I am using GBrowse 2.26, Bio::Graphics 2.18, and BigFile 1.04. I just noticed I was a little out of date, and updated to Bio::Graphics 2.19 and BigFile 1.06. Still the same error.

From: Lincoln Stein <[hidden email]<mailto:[hidden email]>>
Date: Fri, 1 Apr 2011 09:44:29 -0600
To: Timothy Parnell <[hidden email]<mailto:[hidden email]>>
Cc: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Subject: Re: [Gmod-gbrowse] bigwig track rendering failure with sparse data

Were you seeing the failing to render message? I encountered it and tracked it down to a divide-by-zero error, but it wasn't in your bug report.

Lincoln

On Fri, Apr 1, 2011 at 11:36 AM, Timothy Parnell <[hidden email]<mailto:[hidden email]>> wrote:
OK, that sounds good. An empty track is better than a scary message about failing to render for most users.

Thanks for looking into it.

From: Lincoln Stein <[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>>
Date: Fri, 1 Apr 2011 08:38:49 -0600
To: Timothy Parnell <[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>>
Cc: "[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>" <[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>>
Subject: Re: [Gmod-gbrowse] bigwig track rendering failure with sparse data

Hi Tim,

The difference in representation between variable and fixed stepped data is that in the former case regions that fall between annotated regions are "missing", whereas in the latter case you must give them an explicit value, even if it is zero.

I have changed the implementation of the wiggle_xyplot and wiggle_whiskers glyphs in Bio::Graphics so that the scale always gets drawn. This will be released in version 2.20, which I will release as soon as I'm sure this change doesn't introduce any new bugs.

Lincoln


On Mon, Mar 21, 2011 at 1:48 PM, Timothy Parnell <[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>> wrote:
Hi,

I have a lab mate who is trying to visualize her genomic data with a bigwig file. The data happens to be pretty sparse, for example, maybe a dozen positions or less with a recorded value in a 10 kb window. These tend to fail to render. If you zoom out to 50 or 100 kb, then the track renders properly, presumably because there are now enough data points? If there are no data points in the requested region, then we get an empty track, as expected (no scale bars, only vertical grid lines).

So far, this seems to happen regardless whether the source file was a variableStep wig or bedGraph file.

I hadn't seen this before, but then all my data was fixedStep. I converted her sparse data to a fixedStep wig (assigning 0 to the empty positions, of course), and the track renders beautifully as expected, regardless of zoom level.

Is this a bug, or an unintentional side effect of the data formatting? Has anyone else seen this phenomenon?

Tim


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>
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
<a href="tel:416%20673-8514">416 673-8514<tel:416%20673-8514>
Assistant: Renata Musa <[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>>



--
Lincoln D. Stein
Director, Informatics and Biocomputing Platform
Ontario Institute for Cancer Research
101 College St., Suite 800
Toronto, ON, Canada M5G0A3
<a href="tel:416%20673-8514">416 673-8514
Assistant: Renata Musa <[hidden email]<mailto:[hidden email]>>



--
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 <[hidden email]>

------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf

_______________________________________________
Gmod-gbrowse mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse
Reply | Threaded
Open this post in threaded view
|

Re: bigwig track rendering failure with sparse data

Keiran Raine
Hi Lincoln,

The 2.20 release is still not available on CPAN.  Do you know if there is a problem?


Regards,

Keiran Raine
Senior Computer Biologist
The Cancer Genome Project
Ext: 7703





On 1 Apr 2011, at 22:15, Lincoln Stein wrote:

The bug is fixed in Bio::Graphics 2.20. It may not have propagated to all CPAN mirrors yet.

Lincoln

On Fri, Apr 1, 2011 at 12:26 PM, Timothy Parnell <[hidden email]> wrote:
Actually, the error was
"Track rendering error: Timeout; Try turning off tracks or looking at a smaller region."

I see this using the chr1_step10 wig file I included earlier (uploaded and converted to bigwig), at coordinates chrI:184,350..189,349. The chrI_Randomized file shows an empty track.

Note that I've set the details multiplier to 1. Otherwise, you could include data points outside of your view and preclude seeing the error.

I am using GBrowse 2.26, Bio::Graphics 2.18, and BigFile 1.04. I just noticed I was a little out of date, and updated to Bio::Graphics 2.19 and BigFile 1.06. Still the same error.

From: Lincoln Stein <[hidden email]<mailto:[hidden email]>>
Date: Fri, 1 Apr 2011 09:44:29 -0600
To: Timothy Parnell <[hidden email]<mailto:[hidden email]>>
Cc: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Subject: Re: [Gmod-gbrowse] bigwig track rendering failure with sparse data

Were you seeing the failing to render message? I encountered it and tracked it down to a divide-by-zero error, but it wasn't in your bug report.

Lincoln

On Fri, Apr 1, 2011 at 11:36 AM, Timothy Parnell <[hidden email]<mailto:[hidden email]>> wrote:
OK, that sounds good. An empty track is better than a scary message about failing to render for most users.

Thanks for looking into it.

From: Lincoln Stein <[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>>
Date: Fri, 1 Apr 2011 08:38:49 -0600
To: Timothy Parnell <[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>>
Cc: "[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>" <[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>>
Subject: Re: [Gmod-gbrowse] bigwig track rendering failure with sparse data

Hi Tim,

The difference in representation between variable and fixed stepped data is that in the former case regions that fall between annotated regions are "missing", whereas in the latter case you must give them an explicit value, even if it is zero.

I have changed the implementation of the wiggle_xyplot and wiggle_whiskers glyphs in Bio::Graphics so that the scale always gets drawn. This will be released in version 2.20, which I will release as soon as I'm sure this change doesn't introduce any new bugs.

Lincoln


On Mon, Mar 21, 2011 at 1:48 PM, Timothy Parnell <[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>> wrote:
Hi,

I have a lab mate who is trying to visualize her genomic data with a bigwig file. The data happens to be pretty sparse, for example, maybe a dozen positions or less with a recorded value in a 10 kb window. These tend to fail to render. If you zoom out to 50 or 100 kb, then the track renders properly, presumably because there are now enough data points? If there are no data points in the requested region, then we get an empty track, as expected (no scale bars, only vertical grid lines).

So far, this seems to happen regardless whether the source file was a variableStep wig or bedGraph file.

I hadn't seen this before, but then all my data was fixedStep. I converted her sparse data to a fixedStep wig (assigning 0 to the empty positions, of course), and the track renders beautifully as expected, regardless of zoom level.

Is this a bug, or an unintentional side effect of the data formatting? Has anyone else seen this phenomenon?

Tim


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>
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
<a href="tel:416%20673-8514">416 673-8514<tel:416%20673-8514>
Assistant: Renata Musa <[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>>



--
Lincoln D. Stein
Director, Informatics and Biocomputing Platform
Ontario Institute for Cancer Research
101 College St., Suite 800
Toronto, ON, Canada M5G0A3
<a href="tel:416%20673-8514">416 673-8514
Assistant: Renata Musa <[hidden email]<mailto:[hidden email]>>



--
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 <[hidden email]>
------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse


-- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a compa ny registered in England with number 2742969, whose registered office is 2 15 Euston Road, London, NW1 2BE.

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse
Reply | Threaded
Open this post in threaded view
|

Re: bigwig track rendering failure with sparse data

Lincoln Stein
You're right. It isn't showing up in my uploads directory. I have just uploaded it again.

Lincoln

On Thu, Apr 7, 2011 at 5:26 AM, Keiran Raine <[hidden email]> wrote:
Hi Lincoln,

The 2.20 release is still not available on CPAN.  Do you know if there is a problem?


Regards,

Keiran Raine
Senior Computer Biologist
The Cancer Genome Project
Ext: 7703





On 1 Apr 2011, at 22:15, Lincoln Stein wrote:

The bug is fixed in Bio::Graphics 2.20. It may not have propagated to all CPAN mirrors yet.

Lincoln

On Fri, Apr 1, 2011 at 12:26 PM, Timothy Parnell <[hidden email]> wrote:
Actually, the error was
"Track rendering error: Timeout; Try turning off tracks or looking at a smaller region."

I see this using the chr1_step10 wig file I included earlier (uploaded and converted to bigwig), at coordinates chrI:184,350..189,349. The chrI_Randomized file shows an empty track.

Note that I've set the details multiplier to 1. Otherwise, you could include data points outside of your view and preclude seeing the error.

I am using GBrowse 2.26, Bio::Graphics 2.18, and BigFile 1.04. I just noticed I was a little out of date, and updated to Bio::Graphics 2.19 and BigFile 1.06. Still the same error.

From: Lincoln Stein <[hidden email]<mailto:[hidden email]>>
Date: Fri, 1 Apr 2011 09:44:29 -0600
To: Timothy Parnell <[hidden email]<mailto:[hidden email]>>
Cc: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Subject: Re: [Gmod-gbrowse] bigwig track rendering failure with sparse data

Were you seeing the failing to render message? I encountered it and tracked it down to a divide-by-zero error, but it wasn't in your bug report.

Lincoln

On Fri, Apr 1, 2011 at 11:36 AM, Timothy Parnell <[hidden email]<mailto:[hidden email]>> wrote:
OK, that sounds good. An empty track is better than a scary message about failing to render for most users.

Thanks for looking into it.

From: Lincoln Stein <[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>>
Date: Fri, 1 Apr 2011 08:38:49 -0600
To: Timothy Parnell <[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>>
Cc: "[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>" <[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>>
Subject: Re: [Gmod-gbrowse] bigwig track rendering failure with sparse data

Hi Tim,

The difference in representation between variable and fixed stepped data is that in the former case regions that fall between annotated regions are "missing", whereas in the latter case you must give them an explicit value, even if it is zero.

I have changed the implementation of the wiggle_xyplot and wiggle_whiskers glyphs in Bio::Graphics so that the scale always gets drawn. This will be released in version 2.20, which I will release as soon as I'm sure this change doesn't introduce any new bugs.

Lincoln


On Mon, Mar 21, 2011 at 1:48 PM, Timothy Parnell <[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>> wrote:
Hi,

I have a lab mate who is trying to visualize her genomic data with a bigwig file. The data happens to be pretty sparse, for example, maybe a dozen positions or less with a recorded value in a 10 kb window. These tend to fail to render. If you zoom out to 50 or 100 kb, then the track renders properly, presumably because there are now enough data points? If there are no data points in the requested region, then we get an empty track, as expected (no scale bars, only vertical grid lines).

So far, this seems to happen regardless whether the source file was a variableStep wig or bedGraph file.

I hadn't seen this before, but then all my data was fixedStep. I converted her sparse data to a fixedStep wig (assigning 0 to the empty positions, of course), and the track renders beautifully as expected, regardless of zoom level.

Is this a bug, or an unintentional side effect of the data formatting? Has anyone else seen this phenomenon?

Tim


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>
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
<a href="tel:416%20673-8514" target="_blank">416 673-8514<tel:416%20673-8514>
Assistant: Renata Musa <[hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]>>>



--
Lincoln D. Stein
Director, Informatics and Biocomputing Platform
Ontario Institute for Cancer Research
101 College St., Suite 800
Toronto, ON, Canada M5G0A3
<a href="tel:416%20673-8514" target="_blank">416 673-8514
Assistant: Renata Musa <[hidden email]<mailto:[hidden email]>>



--
Lincoln D. Stein
Director, Informatics and Biocomputing Platform
Ontario Institute for Cancer Research
101 College St., Suite 800
Toronto, ON, Canada M5G0A3
<a href="tel:416%20673-8514" value="+14166738514" target="_blank">416 673-8514
Assistant: Renata Musa <[hidden email]>
------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf

_______________________________________________
Gmod-gbrowse mailing list
[hidden email]


-- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.



--
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 <[hidden email]>

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse
Reply | Threaded
Open this post in threaded view
|

Re: bigwig track rendering failure with sparse data

Keiran Raine
Hi Lincoln,

I thought I was looking at the same bug, but perhaps not.  Was this  
happening when the tracks were not sparse?

I'm getting behaviour as show in the 2 attached images.  I start from  
the view which shows the wiggle plot correctly then use the '+' zoom  
to move in by 10%.  By my eye I should still have plenty of data but I  
get an empty track.

Regards,

Keiran Raine
Senior Computer Biologist
The Cancer Genome Project
Ext: 7703
[hidden email]




--
 The Wellcome Trust Sanger Institute is operated by Genome Research
 Limited, a charity registered in England with number 1021457 and a
 company registered in England with number 2742969, whose registered
 office is 215 Euston Road, London, NW1 2BE.

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse

Picture 7.png (27K) Download Attachment
Picture 8.png (23K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: bigwig track rendering failure with sparse data

Lincoln Stein
Sadly, yours is a different bug. Tim was getting a long wait followed by a track rendering timeout error. Does the error always occur at the same magnification level, and is there any semantic zooming active on your track?

Lincoln

On Thu, Apr 7, 2011 at 2:41 PM, Keiran Raine <[hidden email]> wrote:
Hi Lincoln,

I thought I was looking at the same bug, but perhaps not.  Was this happening when the tracks were not sparse?

I'm getting behaviour as show in the 2 attached images.  I start from the view which shows the wiggle plot correctly then use the '+' zoom to move in by 10%.  By my eye I should still have plenty of data but I get an empty track.


Regards,

Keiran Raine
Senior Computer Biologist
The Cancer Genome Project
Ext: 7703
[hidden email]




--
The Wellcome Trust Sanger Institute is operated by Genome ResearchLimited, a charity registered in England with number 1021457 and acompany registered in England with number 2742969, whose registeredoffice is 215 Euston Road, London, NW1 2BE.



--
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 <[hidden email]>

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse
Reply | Threaded
Open this post in threaded view
|

Re: bigwig track rendering failure with sparse data

Timothy Parnell
v. 2.20 fixed my bug (thanks, Lincoln!). But I can't reproduce Keiran's problem with my bigwig data files (both fixedStep and variableStep, with either dense or sparse data).


From: Lincoln Stein <[hidden email]<mailto:[hidden email]>>
Date: Thu, 7 Apr 2011 13:59:25 -0600
To: Keiran Raine <[hidden email]<mailto:[hidden email]>>
Cc: Timothy Parnell <[hidden email]<mailto:[hidden email]>>, "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Subject: Re: [Gmod-gbrowse] bigwig track rendering failure with sparse data

Sadly, yours is a different bug. Tim was getting a long wait followed by a track rendering timeout error. Does the error always occur at the same magnification level, and is there any semantic zooming active on your track?

Lincoln

On Thu, Apr 7, 2011 at 2:41 PM, Keiran Raine <[hidden email]<mailto:[hidden email]>> wrote:
Hi Lincoln,

I thought I was looking at the same bug, but perhaps not.  Was this happening when the tracks were not sparse?

I'm getting behaviour as show in the 2 attached images.  I start from the view which shows the wiggle plot correctly then use the '+' zoom to move in by 10%.  By my eye I should still have plenty of data but I get an empty track.


Regards,

Keiran Raine
Senior Computer Biologist
The Cancer Genome Project
Ext: 7703
[hidden email]<mailto:[hidden email]>




--
The Wellcome Trust Sanger Institute is operated by Genome ResearchLimited, a charity registered in England with number 1021457 and acompany registered in England with number 2742969, whose registeredoffice is 215 Euston Road, London, NW1 2BE.



--
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 <[hidden email]<mailto:[hidden email]>>

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse
Reply | Threaded
Open this post in threaded view
|

Re: bigwig track rendering failure with sparse data

Keiran Raine
In reply to this post by Lincoln Stein
Hi Lincoln,

Yes there is a pattern.

Details multiplier is on (*3)

I have the same view through 2 different data sources, one with semantic zoom to switch between BAM and BW at 1500, the other at 4500.  Both displays give an incorrect display but at different points dictated by the semantic zoom.

Zoom at 1500 is as follows

1500 bps in view (4500 once multiplied) display fails
1501 bps in view (4503 once multiplied) display works

Zoom at 4500 is as follows

4500 bps in view (13500 once multiplied) display fails
4501 bps in view (13503 once multiplied) display works

The problem resolves when you turn details multiplier off

Hope this is useful.

Keiran Raine
Senior Computer Biologist
The Cancer Genome Project
Ext: 7703





On 7 Apr 2011, at 20:59, Lincoln Stein wrote:

Sadly, yours is a different bug. Tim was getting a long wait followed by a track rendering timeout error. Does the error always occur at the same magnification level, and is there any semantic zooming active on your track?

Lincoln

On Thu, Apr 7, 2011 at 2:41 PM, Keiran Raine <[hidden email]> wrote:
Hi Lincoln,

I thought I was looking at the same bug, but perhaps not.  Was this happening when the tracks were not sparse?

I'm getting behaviour as show in the 2 attached images.  I start from the view which shows the wiggle plot correctly then use the '+' zoom to move in by 10%.  By my eye I should still have plenty of data but I get an empty track.


Regards,

Keiran Raine
Senior Computer Biologist
The Cancer Genome Project
Ext: 7703
[hidden email]




--
The Wellcome Trust Sanger Institute is operated by Genome ResearchLimited, a charity registered in England with number 1021457 and acompany registered in England with number 2742969, whose registeredoffice is 215 Euston Road, London, NW1 2BE.



--
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 <[hidden email]>


-- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a compa ny registered in England with number 2742969, whose registered office is 2 15 Euston Road, London, NW1 2BE.

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse