Wiggle tracks now calculate averages instead of max when multiple points... #504

Merged
merged 1 commit into from Nov 24, 2015

Conversation

Projects
None yet
3 participants
@hotdogee
Contributor

hotdogee commented Aug 19, 2014

Wiggle tracks now calculate averages instead of max when multiple points map to a single pixel, this fixes the display issue under certain zoom levels when using wiggle tracks to display GC content, and correctly calculates the average GC percentage when zooming out.

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Sep 18, 2014

Contributor

I am not sure about this change because for these tracks you often want to know peak values so we would want to know the max of that region. It is actually already hard to see peaks when you are zoomed out in a BigWig track. That said, this is an interesting change and we might want to consider it somehow.

Contributor

cmdcolin commented Sep 18, 2014

I am not sure about this change because for these tracks you often want to know peak values so we would want to know the max of that region. It is actually already hard to see peaks when you are zoomed out in a BigWig track. That said, this is an interesting change and we might want to consider it somehow.

@hotdogee

This comment has been minimized.

Show comment
Hide comment
@hotdogee

hotdogee Sep 18, 2014

Contributor

Without this patch, there's currently a discontinuity of max to average that happens when zooming out. Consistency during zooming is one additional reason for this patch.

Contributor

hotdogee commented Sep 18, 2014

Without this patch, there's currently a discontinuity of max to average that happens when zooming out. Consistency during zooming is one additional reason for this patch.

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Feb 6, 2015

Contributor

There is a new "summary score" type being planned that allows "maxScore" to be part of the summary type instead of the default average score which could alleviate to the behavior that you mention (discontinuity when zooming out)

Would this pull request still be needed?
cc @childers

Contributor

cmdcolin commented Feb 6, 2015

There is a new "summary score" type being planned that allows "maxScore" to be part of the summary type instead of the default average score which could alleviate to the behavior that you mention (discontinuity when zooming out)

Would this pull request still be needed?
cc @childers

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Feb 6, 2015

Contributor

See #518

Contributor

cmdcolin commented Feb 6, 2015

See #518

@childers

This comment has been minimized.

Show comment
Hide comment
@childers

childers Feb 10, 2015

We use this patch now. Do you have ETA for the changes to the summary score, and addition of a summary type? I don't mind merging this in on my end in the interim.
cc @hotdogee

We use this patch now. Do you have ETA for the changes to the summary score, and addition of a summary type? I don't mind merging this in on my end in the interim.
cc @hotdogee

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Feb 10, 2015

Contributor

I guess I'm just not really sure what this patch does. do you have screenshots of where it makes a difference?

The summary score is merged now but it only makes a difference when you are zoomed out

Contributor

cmdcolin commented Feb 10, 2015

I guess I'm just not really sure what this patch does. do you have screenshots of where it makes a difference?

The summary score is merged now but it only makes a difference when you are zoomed out

@childers

This comment has been minimized.

Show comment
Hide comment
@childers

childers Aug 28, 2015

Sorry for the delay in responding. The issue we've got is that not averaging scores based on the view gives an incorrect idea of whats happening. In this case, looking at a track showing the %GC content makes the sequence look like it has a high GC content, when what it is doing is just taking the highest score. I understand your reasoning, but spikes in score are still visible and now high coring bases swamp regions of low scores.

bw_track_zoom_out_to_average_scores

Zoomed in, the score averaging stops, and displays the highest score per visible region.

bw_track_zoomed_in_a_bit_no_average_scores

On our patched JBrowse, the averaging behavior is consistent across zoom levels.
patched_zoomed_out
Zoomed into the same level as above.
patched_zoom_in

I think that this gives a better visualization, and prefer the consistent behavior at different zoom levels.
If you think this is limited to a minority of cases and feel it is best to not incorporate this as default behavior, could you implement it as an alternative feature type for bigwigs?

Sorry for the delay in responding. The issue we've got is that not averaging scores based on the view gives an incorrect idea of whats happening. In this case, looking at a track showing the %GC content makes the sequence look like it has a high GC content, when what it is doing is just taking the highest score. I understand your reasoning, but spikes in score are still visible and now high coring bases swamp regions of low scores.

bw_track_zoom_out_to_average_scores

Zoomed in, the score averaging stops, and displays the highest score per visible region.

bw_track_zoomed_in_a_bit_no_average_scores

On our patched JBrowse, the averaging behavior is consistent across zoom levels.
patched_zoomed_out
Zoomed into the same level as above.
patched_zoom_in

I think that this gives a better visualization, and prefer the consistent behavior at different zoom levels.
If you think this is limited to a minority of cases and feel it is best to not incorporate this as default behavior, could you implement it as an alternative feature type for bigwigs?

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Sep 1, 2015

Contributor

thanks for the details @childers. the screenshot where it shows "Zoomed in, the score averaging stops, and displays the highest score per visible region." is surprising!

Contributor

cmdcolin commented Sep 1, 2015

thanks for the details @childers. the screenshot where it shows "Zoomed in, the score averaging stops, and displays the highest score per visible region." is surprising!

@childers

This comment has been minimized.

Show comment
Hide comment
@childers

childers Sep 1, 2015

No problem, I'm glad this helps illustrate what I'm talking about. I'm not sure how this might apply to other quantitative data, like QTL peaks, but it seriously impacts our GC tracks.

childers commented Sep 1, 2015

No problem, I'm glad this helps illustrate what I'm talking about. I'm not sure how this might apply to other quantitative data, like QTL peaks, but it seriously impacts our GC tracks.

@cmdcolin cmdcolin referenced this pull request in GMOD/Apollo Sep 8, 2015

Closed

(3w) enable genome folding #525

93 of 93 tasks complete
@childers

This comment has been minimized.

Show comment
Hide comment
@childers

childers Nov 20, 2015

Was there any updates on pulling this into the main code base?

Was there any updates on pulling this into the main code base?

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Nov 20, 2015

Contributor

I think in principal this is actually a good idea, however, I actually think that being able to see the max value is useful in many situations. For example, many bioinformatics applications are looking for peaks. It would be good (IMO) if this could be re-configured instead of replacing the behavior here.

Contributor

cmdcolin commented Nov 20, 2015

I think in principal this is actually a good idea, however, I actually think that being able to see the max value is useful in many situations. For example, many bioinformatics applications are looking for peaks. It would be good (IMO) if this could be re-configured instead of replacing the behavior here.

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Nov 20, 2015

Contributor

I suppose you noted this as well when you referred to QTL peaks. Maybe I can take a look at it really quick...probably could be integrated with the "scoreType" variable....

Contributor

cmdcolin commented Nov 20, 2015

I suppose you noted this as well when you referred to QTL peaks. Maybe I can take a look at it really quick...probably could be integrated with the "scoreType" variable....

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Nov 21, 2015

Contributor

I made a modified version of this on this branch which keeps the ability to have a max score view. https://github.com/GMOD/jbrowse/compare/wiggle-avg-value

Now if the user wants to keep peaks, they can do so sensibly with the "scoreType":"maxValue"

And by default, it will use the average value that was defined here.

It also unifies the calculatePixelValue into WiggleBase, as I think the specialized version in XYPlot did not actually have extra functionality, and so now the average value code used here applies to both wiggle track types (XYPlot and Density)

Contributor

cmdcolin commented Nov 21, 2015

I made a modified version of this on this branch which keeps the ability to have a max score view. https://github.com/GMOD/jbrowse/compare/wiggle-avg-value

Now if the user wants to keep peaks, they can do so sensibly with the "scoreType":"maxValue"

And by default, it will use the average value that was defined here.

It also unifies the calculatePixelValue into WiggleBase, as I think the specialized version in XYPlot did not actually have extra functionality, and so now the average value code used here applies to both wiggle track types (XYPlot and Density)

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Nov 21, 2015

Contributor

Example screenshots showing the behavior with maxScore is being kept.

New behavior, with the nice average value calculated (the "correct" values for GC with "averageScore" calculation on top, maxScore blue on bottom)
ex1

Previous 1.11.6 code where both used "maxScore" effectively making both tracks blue
ex2

Contributor

cmdcolin commented Nov 21, 2015

Example screenshots showing the behavior with maxScore is being kept.

New behavior, with the nice average value calculated (the "correct" values for GC with "averageScore" calculation on top, maxScore blue on bottom)
ex1

Previous 1.11.6 code where both used "maxScore" effectively making both tracks blue
ex2

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Nov 21, 2015

Contributor

And of course, here was the original motivation for scoreType: maxScore, in that it can show peaks when zoomed out

ex3

Contributor

cmdcolin commented Nov 21, 2015

And of course, here was the original motivation for scoreType: maxScore, in that it can show peaks when zoomed out

ex3

@childers

This comment has been minimized.

Show comment
Hide comment
@childers

childers Nov 23, 2015

@cmdcolin Thanks for the updates! I think that having this as a configurable option will make it much more flexible and useful in different scenarios.

@cmdcolin Thanks for the updates! I think that having this as a configurable option will make it much more flexible and useful in different scenarios.

cmdcolin added a commit that referenced this pull request Nov 24, 2015

Merge pull request #504 from hotdogee/wiggle-average-values
Wiggle tracks now calculate averages instead of max when multiple points...

@cmdcolin cmdcolin merged commit 2f92ad8 into GMOD:master Nov 24, 2015

@cmdcolin cmdcolin referenced this pull request Nov 24, 2015

Merged

Wiggle avg value #664

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment